| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: Potential Duplicate Found:
Other Related PRs:
Recommend checking PR #26845 first as it directly addresses the parent edit deny inheritance issue. |
Sorry, something went wrong.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Sorry, something went wrong.
|
Quick context on how this differs from the other PRs people might find:
@kitlangton — this builds on your #27201 fix. That PR fixed most of the regression, but orchestrator→editor patterns where the parent has edit: deny and the subagent has edit: allow are still broken. This PR adds the subagent self-declaration check on top. |
Sorry, something went wrong.
|
This PR only applies fix for "*": allow, but adding allow to specific file paths/globs is still not possible, e.g. like in But the fix is rather trivial, just removing the explicit * |
Sorry, something went wrong.
|
Good catch @Sewer56, fixed — any edit: allow rule (scoped or wildcard) now prevents parent edit:deny inheritance, not just pattern === "*". Added a test for scoped patterns too. |
Sorry, something went wrong.
|
@kitlangton Ready for review. |
Sorry, something went wrong.
|
@thdxr would be really awesome to get this one sometime soon |
Sorry, something went wrong.
|
@kitlangton @jlongster @Brendonovich @rekram1-node — this PR has been open for 6 days with no review. It is the final missing piece of the subagent permission inheritance fix chain. The progression:
Without this, orchestrator→editor and commander→worker patterns remain broken for every multi-agent setup. The fix is small (one conditional in subagent-permissions.ts), preserves Plan Mode security, and all 114 tests pass. Community members blocked by this: @nabilfreeman @BurnySc2 @ROKO108 @nmzpy @Sewer56 @tppawelgrzesik Ready to merge — please review. |
Sorry, something went wrong.
|
🎻 |
Sorry, something went wrong.
|
Well I guess we can try to get some more attention here, this one is blocking many of us from updating to newer versions of opencode for quite a while now. @adamdotdevin @Hona @Brendonovich pretty please guys, lets fix it 💯 |
Sorry, something went wrong.
When a parent agent (e.g. an orchestrator) has edit:deny and spawns a subagent (e.g. an editor) that has edit:allow, the parent's deny was unconditionally inherited into the subagent's session permission. Because permission evaluation is last-match-wins, the inherited deny overrode the subagent's own allow — removing the edit tool from the subagent's palette. Fix: only inherit parent edit:deny rules when the subagent does NOT explicitly declare edit:allow. If a subagent says it can edit, the parent's self-restriction should not override that declared capability. This preserves Plan Mode security: subagents without explicit edit declarations (like general, explore) still inherit the parent's edit:deny as before. Relates to anomalyco#26700 anomalyco#26747 anomalyco#26758 anomalyco#27123
…d parent denies deriveSubagentSessionPermission no longer forwards a parent agent's edit deny (or parent-session denies) for any permission the subagent explicitly allows, so custom subagents like general-opus-4.7 (edit: allow) spawned by edit-denying orchestrators keep edit/write access. Built-in explore/general still inherit the Plan Mode ceiling since they don't declare edit: allow. Adds regression tests and documents the recurring regression + invariant in AGENTS.md. Refs anomalyco#26514 anomalyco#27201 anomalyco#27654.
|
I just run my own OpenCode fork; since it's the easiest way to proceed in a case like this. |
Sorry, something went wrong.
|
Well it seems that on this project it's impossible to escalate a PR to get critical fixes merged quick. For example opencode-mem plugin is completely broken for a long time too. Meanwhile releases get pushed sometimes "hourly" because of bugs and bad quality. Imo. what this project really needs is a "new-feature-freeze", a phase that focuses on getting more stability and a less bugged experience. |
Sorry, something went wrong.
|
This behavior is intentional |
Sorry, something went wrong.
Why? |
Sorry, something went wrong.
@rekram1-node my use-case:
With current version of opencode Developer cannot use edit/write tool because he inherits Orchestrator deny. Now I could set Orchestrator to edit: allow, however now I risk that if he forgets his primary instruction to not edit/write files on his own, he WILL start doing it by mistake. Also a side note if i recall correctly, other use-cases: Here dev can use write/edit tool. Because the bug seems to only affect forced permission from direct parent only. Because lead dev has in leadDev.md edit permission: allow Another use-case: Here dev cannot use write/edit tool either. I don't understand how this can be intentional. |
Sorry, something went wrong.
|
Heads up — I've forked opencode to a stable branch and I'm maintaining it separately for now. What I fixed (all things upstream doesn't currently have):
Not chasing upstream. No new features. Only important, high-impact fixes — and only once they're stable. If a new upstream feature fits and we need it, I'll add it. @tppawelgrzesik @Sewer56 — fork is here if useful: https://github.com/OrShmuel22/opencode @rekram1-node the delegation pattern (orchestrator edit:deny → editor edit:allow) is in your own agent docs. If it's "intentional," the docs need updating. |
Sorry, something went wrong.
|
I can just guess that in the end nobody will care but yeah the way this project currently runs seems sadly fundamentally broken. Nonetheless, thanks everyone, including the community for trying to make things better and all the contributions. @thdxr @adamdotdevin @kitlangton @iamdavidhill @fwang @jayair @Brendonovich @nexxeln @Hona @kommander @jlongster |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #26758
Type of change
What does this PR do?
deriveSubagentSessionPermission unconditionally inherits the parent agent's edit: deny rules into the subagent's session. Because permission evaluation is last-match-wins, the inherited deny overrides the subagent's own edit: allow. The subagent loses the edit tool entirely.
This breaks any setup where a restricted parent (like an orchestrator with edit: deny) deliberately delegates to a capable subagent (like an editor with edit: allow).
The fix: only inherit the parent's edit: deny when the subagent does NOT explicitly declare edit: allow. If a subagent says it can edit, the parent's self-restriction shouldn't override that. If the subagent has no edit rule, the parent's deny still applies as a ceiling.
This works because the permission system is all about ordering — rules that appear last in the merged array win. By not injecting the parent's deny into the session when the subagent explicitly allows edit, the subagent's own allow rule is the last match and wins. The core evaluate(), merge(), and disabled() functions are not touched.
How did you verify your code works?
Added 3 new tests in plan-mode-subagent-bypass.test.ts:
All existing Plan Mode security tests still pass because general and explore don't have explicit edit: allow — so they still inherit the plan agent's deny.
Full test run: 114 tests pass (8 subagent-bypass + 85 permission + 21 permission-task).
Screenshots / recordings
N/A — no UI changes.
Checklist