Subagents don’t respect `"*": "allow"` agent permissions

[brittlewis12]

Description

Custom agent permission rules don't propagate to subagents spawned via TaskTool. When a custom primary agent is configured with "permission": "allow" (for unattended/autonomous use), subagents spawned by that agent do not inherit the parent's permissive rules. Any tool call in the subagent that evaluates to "ask" will block indefinitely since there's no human to respond.

The root cause is in packages/opencode/src/session/prompt.ts:416:

ruleset: PermissionNext.merge(taskAgent.permission, session.permission ?? [])

opencode/packages/opencode/src/session/prompt.ts

Line 416 in 4abf804

ruleset: PermissionNext.merge(taskAgent.permission, session.permission ?? []),

This merges the subagent's built-in permission ruleset with the child session's permission — neither of which includes the parent agent's permission rules. The child session created at packages/opencode/src/tool/task.ts:72-101 only receives hard-coded deny rules for todowrite, todoread, and optionally task — it never inherits the parent agent's or parent session's permission configuration.

Plugins

n/a

OpenCode version

1.1.53

Steps to reproduce

1. Add a custom agent with permissive rules to opencode.json:

   {
     "agent": {
       "auto": {
         "description": "Autonomous mode with full permissions",
         "mode": "primary",
         "permission": "allow"
       }
     }
   }

2. Switch to the auto agent
3. Perform a task that triggers a subagent (e.g., TaskTool spawning explore or general)
4. The subagent hits a permission prompt (e.g., bash command matching "ask") and blocks forever

Expected behavior: The subagent should inherit the parent agent's "allow" permission, or the parent session's permission rules should propagate to the child session so the merged ruleset at prompt.ts:416 includes them.

Screenshot and/or share link

No response

Operating System

macos 15.7.1

Terminal

Ghostty

[github-actions]

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

• Permission requests from child sessions do not get forwarded via ACP and hangs forever #12133: Permission requests from child sessions do not get forwarded via ACP and hangs forever

Both issues describe situations where subagents/child sessions have difficulty with permissions that prevent normal execution. While #12133 focuses on ACP mode specifically, this issue describes a more general case where permission rules from the parent agent don't propagate to subagents spawned via TaskTool.

Feel free to ignore if your case involves different circumstances.

[doodhout]

Have you tried this?

Permission: "*": "allow"

[brittlewis12]

hi @doodhout,

yes i did, and you can see that is how the regression test i introduced expresses the same maximally permissive agent configuration: https://github.com/anomalyco/opencode/pull/12584/changes#diff-f25c41495cbe32842ca866f893c1a8dece566524887dc47b84b9155e87c0e1d4R26

my understanding is they should be equivalent:

opencode/packages/opencode/src/config/config.ts

Line 610 in 7c6b8d7

if (typeof x === "string") return { "*": x as PermissionAction }

---

EDIT: i see i transposed the key & value in the issue title now. i’ve corrected this. thanks!

[doodhout]

I'm wondering if this problem is not really a problem, but by design.

I.e. when you define a custom agent with type primary, then that rules out using that agent as a subagent, which seems like what's happening here.

What happens if you define the agent without an explicit type? Does the subagent inherit the custom agent? Because AFAIK the current primary agent is responsible for choosing the best-fitting agent definition for the subagent it's spawning, which can be a subagent where the permissions are very different to those of the primary agent.

So, for an elaborate test:

1. create a custom agent that is both a primary and a subagent
2. when using your primary agent and when you're about to spawn subagents, make sure that the primary agents selects the correct subagent (in this case, the same custom agent, which obviously should have the same permissions)

What happens then?

[brittlewis12]

I see your point — i don’t think there’s any problem with primary agents delegating and expressly limiting permissions, eg read only. that is fine and ok by me. the problem arises with “ask”

my use case currently that doesn’t work is as follows:

1. create a remote sandbox & start opencode server
2. create a new session with a message via server api
3. expect agent to work until completion

invariably the agent spawns a subagent which triggers an "ask" permission, even though the only configured agent is permitted all ("*": “allow”), so the session gets stuck.

is there some configuration (session level, project level, globally?) where i can only allow or deny, no ask? this is not possible as far as i’m aware

[doodhout]

even though the only configured agent is permitted all ("*": “allow”)

That's disregarding the built-in subagents. Are they also available in this use case? If the answer is yes, can you try and avoid those being used by your primary agent? There is this permission system where you can limit the subagents available to a certain agent: https://opencode.ai/docs/agents/#task-permissions