anomalyco / anomalyco/opencode
fix(core): a session-wide "always" approval overrides a subagent's explicit deny (findLast ordering)
@neriousy is already working on this.
Since Sep 7, 2026.
- Dominant language
- TypeScript
- Stars
- 209k
- Forks
- 27.5k
- PR merge metrics
- PR metrics pending
Description
Description
A parent answering "always" to a permission ASK grants allow for the whole process, defeating an explicit deny in a subagent's ruleset.
Related: #46357 documents the instance-wide scope of "always" approvals and a pending/future timing inconsistency — this report adds the security consequence: the same instance-wide approval also overrides an explicit subagent deny via findLast ordering.
Mechanism: evaluate(permission, pattern, ruleset, approved) = findLast over [...ruleset, ...approved] (permission/index.ts:28-38) — approved comes AFTER the ruleset, so a match in approved WINS over a ruleset deny. approved lives in the Permission Service state per instance (permission/index.ts:46-65), SHARED across all sessions of the process (parent + subagents).
Concrete scenario: parent answers "always" to a bash ASK for git * (patterns suggested by BashArity, shell.ts:409) → approved holds git *→allow. A subagent whose ruleset has "git push *": deny evaluates git push origin main: the deny matches, approved matches too, findLast takes the last = ALLOW. The subagent's deny is bypassed by an "always" granted in ANOTHER session.
Current docs (permissions.mdx:196) say "for the rest of the current OpenCode session" (singular) — neither the instance-wide sharing nor the approved>deny priority is documented.
Proposed fix
Scope approvals by sessionID (not per instance), OR place the ruleset AFTER approved in the findLast (agent deny wins), OR at minimum document the priority.
Mechanism verified by code reading only (dev@57ef382843) — no runtime repro, stated honestly. Searched "approved permissions override", "always allow session" — no duplicate found.
opencode v1.18.29, Linux.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.