anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 18:25:32 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Subagents don’t respect "*": "allow" agent permissions #8761

New Issue
Open
opened 2026-02-16 18:10:46 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 18:10:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @brittlewis12 on GitHub (Feb 6, 2026).

Originally assigned to: @thdxr on GitHub.

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 ?? [])

https://github.com/anomalyco/opencode/blob/4abf8049c99b6adc0f130e28d0126f59b3869e49/packages/opencode/src/session/prompt.ts#L416

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

Originally created by @brittlewis12 on GitHub (Feb 6, 2026). Originally assigned to: @thdxr on GitHub. ### 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`: ```typescript ruleset: PermissionNext.merge(taskAgent.permission, session.permission ?? []) ``` https://github.com/anomalyco/opencode/blob/4abf8049c99b6adc0f130e28d0126f59b3869e49/packages/opencode/src/session/prompt.ts#L416 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`: ```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
yindo added the bug label 2026-02-16 18:10:46 -05:00
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 6, 2026):

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

  • #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.

@github-actions[bot] commented on GitHub (Feb 6, 2026): This issue might be a duplicate of existing issues. Please check: - #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.
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@doodhout commented on GitHub (Feb 8, 2026):

Have you tried this?

Permission: "*": "allow"

@doodhout commented on GitHub (Feb 8, 2026): Have you tried this? Permission: "*": "allow"
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@brittlewis12 commented on GitHub (Feb 8, 2026):

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:
https://github.com/anomalyco/opencode/blob/7c6b8d7a8a7180f330b83b736c46a62fb5f91258/packages/opencode/src/config/config.ts#L610

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

@brittlewis12 commented on GitHub (Feb 8, 2026): 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: https://github.com/anomalyco/opencode/blob/7c6b8d7a8a7180f330b83b736c46a62fb5f91258/packages/opencode/src/config/config.ts#L610 * * * EDIT: i see i transposed the key & value in the issue title now. i’ve corrected this. thanks!
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@doodhout commented on GitHub (Feb 9, 2026):

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?

@doodhout commented on GitHub (Feb 9, 2026): 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?
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@brittlewis12 commented on GitHub (Feb 9, 2026):

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

@brittlewis12 commented on GitHub (Feb 9, 2026): 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
yindo commented 2026-02-16 18:10:46 -05:00
Author
Owner
Copy Link
Copy Source

@doodhout commented on GitHub (Feb 9, 2026):

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

@doodhout commented on GitHub (Feb 9, 2026): > 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
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8761
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?