Redefining permission in subagents stopped working #27497

Activity

1. github-actions

   assigned

   jlongster

   on May 14, 2026
2. github-actions commented on May 14, 2026

   

   github-actionsBot

   on May 14, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Permission rules not enforced for "edit" operation performed by Task subagents #23519: Permission rules not enforced for "edit" operation performed by Task subagents — similar issue where subagent permissions don't behave as expected
   • Opencode ignoring deny permissions? #25515: Opencode ignoring deny permissions? — similar issue where deny permissions set on an agent are not respected

   If your issue is specifically about subagents being unable to override (loosen) a permission set by the parent/orchestrator agent, it may be distinct — please clarify in those threads if so.
3. Vizualni commented on May 19, 2026

   

   Vizualni

   on May 19, 2026

   More actions

   I can confirm. This happens to me as well. I am on 1.15.5

   👍React with 👍1Reacted by smcgough
4. mcgoughprogress commented on May 27, 2026

   

   mcgoughprogress

   on May 27, 2026

   More actions

   I have this issue too, if I delegate subagent with edit: allow from a primary agent that has edit allow, it will work. When the 'orchestrator' style agent with no permissions delegates the subagent, the edit: allow is ignored
5. felixnorden commented on May 28, 2026

   

   felixnorden

   on May 28, 2026

   More actions

   When the 'orchestrator' style agent with no permissions delegates the subagent, the edit: allow is ignored.

   This is to prevent permission leakage, e.g., the Plan agent delegating to another agent to write on its behalf.

   I added the PR above to find a middle ground, where if you have a matching edit permission rule between the parent agent and subagent, the rule won't be added to the new session's permission ruleset. This means that global deny permissions won't be added to the end of the list and overrule your other edit permissions (permissions match in a LIFO order.
6. Vizualni commented on May 29, 2026

   

   Vizualni

   on May 29, 2026

   More actions

   While I understand the reasoning of

   This is to prevent permission leakage, e.g., the Plan agent delegating to another agent to write on its behalf.

   then the whole point of the "orchestrator" pattern falls to the ground. Right now my orchestrator has much higher privileges than it should have because of that and I had to instruct it very hard not to do things on its own (like write), but rather delegate.

   I think it should be solved with documenting and saying that agent might try to be sneaky and delegate to subagents when it's missing some permissions and not trying to protect users from it, because naturally I expected it to work because subagent had edit but it failed to do anything.

   On top of that, I'd think of adding another option/setting on the agent definition which when set to true would behave as it currently does.

   👍React with 👍2Reacted by smcgough and Dmitriy Gast
7. felixnorden commented on May 29, 2026

   

   felixnorden

   on May 29, 2026

   More actions

   I agree with you @Vizualni , that's why I created the PR to find the middle ground, so I can continue with my orchestrator pattern without breaking the core premise of circumventing expected permissions.

   I had more granular permissions set for edit, which all got overridden as well for the subagent session, but the above should now work (potentially with some caveats depending on how your orchestrator is configured).
8. github-actions commented on Jul 29, 2026

   

   github-actionsBot

   on Jul 29, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
9. github-actions

   closed this as not plannedon Jul 29, 2026