Repository navigation
Saved bash “Always” approval is reused across different working directories within the same project #51279
Description
Description
In the current V2 permission flow, persistent bash approval appears to be bound to the command string, but not to the working directory where that command executes.
In "packages/core/src/tool/bash.ts", bash permission is requested with:
action: "bash",
resources: [input.command],
save: [input.command],
"workdir" is resolved separately and is not part of the saved bash resource.
This means an approval such as:
npm test
can be saved once and then reused in another directory inside the same project, even though that second directory may have a different "package.json" and execute completely different code.
Minimal reproduction
Project:
repo/
a/
package.json
b/
package.json
Give "a/package.json" and "b/package.json" different "test" scripts.
- Run "npm test" with "workdir=a"
- Choose Always
- Run "npm test" with "workdir=b"
- Observe whether OpenCode asks again
If it does not, the saved permission is authorizing by command text alone, even though execution context changed.
Expected
Persistent bash approval should be scoped to enough execution context to preserve the meaning of the original authorization.
At minimum, that likely means binding the saved approval to:
project + command + canonical cwd
rather than only:
project + command
Why this matters
Commands such as:
npm test
npm run build
bun test
make
cargo run
./build.sh
can execute different code depending on "cwd".
So two identical command strings are not necessarily the same operation.
I found this while reviewing the authorization-to-execution binding in the current V2 permission path.
Valentyn Rukhaylo
Altru.dev
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
opencode-agent commentedon Oct 22, 2026
Closing as working as intended.
Persistent shell approvals in V2 are scoped to the project and keyed by command pattern, not by working directory. This matches the documented model:
alwaysapproves future requests matching the suggested patterns, and for shell those are command prefixes likegit status*. Configured shell permission rules are directory-agnostic in the same way.The code referenced here has also changed. Current
devsaves a parsed prefix pattern from the shell parser (inpackages/core/src/tool/plugin/shell.ts), not the exact command string. Commands that reach outside the project still go through the separateexternal_directorycheck.If you want per-directory control, keep the command on
ask, or use the config rules to limit what can be approved.