You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(core): a session-wide "always" approval overrides a subagent's explicit deny (findLast ordering) #47825
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.
Thanks for updating the issue! It now clearly describes the bug with concrete code references and a scenario. Everything looks good — appreciate the thorough write-up.
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.
Activity
github-actions commentedon Sep 7, 2026
Thanks for updating the issue! It now clearly describes the bug with concrete code references and a scenario. Everything looks good — appreciate the thorough write-up.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊