Repository navigation
Bug: Subagents no longer have access to tools (in commander+worker pattern) #26758
Description
Description
I am using a commander + worker pattern, where the commander is the default agent.
The commander has almost no permissions (no read, no write), however it delegates tasks (or task chunks) to subagents which have specific permissions (for example a finder subagent has read permissions, but not write).
Simple example:
The commander can delegate the "code-writer" agent to modify a file.
However, since version 1.14.46 (worked in 1.14.45) my code-writer agent no longer has the read and write tools available, so it cannot read or modify files.
Prompt example: Use code-writer to modify my hello_world.py to say "Hi world" instead of "Hello world"
The tools seems to show up for the subagents again if I add permission "allow" or "ask" for the commander.
Commander:
---
description: Master orchestrator. Analyzes user intent, decomposes tasks, coordinates subagents for all pipelines.
mode: primary
permission:
task: allow
todowrite: allow
todoread: allow
question: allow
read: deny
write: deny
edit: deny
bash: deny
webfetch: deny
glob: deny
grep: deny
external_directory: deny
---Code-writer:
---
description: Code writer. Creates new files, modifies existing files, adds features while maintaining backward compatibility.
mode: subagent
permission:
read: allow
write: allow
edit: allowPlugins
No plugins
OpenCode version
1.14.46
Steps to reproduce
Use the commander + worker pattern from the example in the description. Prompt the commander agent to use a worker agent to read or modify a file, while commander has no read/write (read: deny) permissions while the subagent has them (read: allow).
Screenshot and/or share link
No response
Operating System
ManjaroLinux
Terminal
Alacritty
Activity
github-actions commentedon May 10, 2026
This issue might be a duplicate of existing issues. Please check:
deriveSubagentSessionPermission()change from PR fix(task): subagent inherits parent agent's deny rules (Plan Mode security bypass) #26597).Both issues describe the exact same behavior you're seeing: subagents losing access to their configured tools when the parent/commander agent has explicit deny rules.
nabilfreeman commentedon May 11, 2026
Root cause is here #26700
kitlangton commentedon May 13, 2026
This was fixed in #27201 and should be out in the next release.
The fix keeps Plan Mode’s inherited edit restriction, but stops parent agent self-restrictions like
read,bash, andtaskfrom erasing a subagent’s own explicit permissions.Thanks for the commander/worker repro, that was exactly the workflow the regression broke.
OrShmuel22 commentedon May 15, 2026
For anyone still hitting this with v1.14.50+: #27201 fixed bash/read/task inheritance, but
edit: denyon a parent still blocks subagents that haveedit: allow. I opened #27654 which checks the subagent's own permission — if it explicitly allows edit, the parent deny doesn't override it. Plan Mode security is preserved sincegeneralandexploredon't declareedit: allow.fix(task): subagent explicit edit:allow overrides parent edit:deny