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

[FEATURE]: Allow configurable subagent-to-subagent task delegation with call limits #4413

New Issue
Open
opened 2026-02-16 17:43:42 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:43:42 -05:00
Owner
Copy Link
Copy Source

Originally created by @NamedIdentity on GitHub (Jan 8, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem
Currently, task.ts hardcodes task: false for all subagent sessions (lines 65-69, 132-137), preventing any subagent from delegating to another subagent. This blocks legitimate workflows like:

  • Principal-Partner delegating to Assistants
  • Assistant-Sonnet having Assistant-Flash cross-check its work
  • Assistant-Flash asking Assistant-Sonnet for thorough analysis

The agent config already supports granular task permissions:

assistant-sonnet: {
tools: { task: true },
permission: {
task: { *: deny, assistant-flash: allow }
}
}

But this config is ignored because task.ts unconditionally overrides it.

Proposed Solution

  1. Respect agent-level task permissions instead of hardcoding task: false
  2. Add optional task_limit config to prevent infinite loops:
    assistant-sonnet: {
    tools: { task: true },
    permission: {
    task: { *: deny, assistant-flash: allow }
    },
    task_limit: 3 // Max task calls per session (0 = current behavior)
    }

Use Case
Building an Agentic Collaboration Framework where:

  • Principal-Opus orchestrates work
  • Principal-Partner (subagent) can delegate to Assistants
  • Assistant-Sonnet and Assistant-Flash can cross-check each other's work

The permission system already expresses "Sonnet can only task Flash" - it just needs to be honored.

Backward Compatibility
Default behavior unchanged - task_limit: 0 (or absent) means task tool disabled for subagents, matching current behavior. Only users who explicitly configure permissions get the new capability.

Originally created by @NamedIdentity on GitHub (Jan 8, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request **Problem** Currently, task.ts hardcodes task: false for all subagent sessions (lines 65-69, 132-137), preventing any subagent from delegating to another subagent. This blocks legitimate workflows like: - Principal-Partner delegating to Assistants - Assistant-Sonnet having Assistant-Flash cross-check its work - Assistant-Flash asking Assistant-Sonnet for thorough analysis The agent config already supports granular task permissions: assistant-sonnet: { tools: { task: true }, permission: { task: { *: deny, assistant-flash: allow } } } But this config is ignored because task.ts unconditionally overrides it. **Proposed Solution** 1. Respect agent-level task permissions instead of hardcoding task: false 2. Add optional task_limit config to prevent infinite loops: assistant-sonnet: { tools: { task: true }, permission: { task: { *: deny, assistant-flash: allow } }, task_limit: 3 // Max task calls per session (0 = current behavior) } **Use Case** Building an Agentic Collaboration Framework where: - Principal-Opus orchestrates work - Principal-Partner (subagent) can delegate to Assistants - Assistant-Sonnet and Assistant-Flash can cross-check each other's work The permission system already expresses "Sonnet can only task Flash" - it just needs to be honored. **Backward Compatibility** Default behavior unchanged - task_limit: 0 (or absent) means task tool disabled for subagents, matching current behavior. Only users who explicitly configure permissions get the new capability.
yindo added the discussion label 2026-02-16 17:43:42 -05:00
yindo commented 2026-02-16 17:43:42 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 8, 2026):

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

  • #4439: Subagents are using the task tool (reports subagents unexpectedly delegating to other agents)
  • #3808: Task should inherit current agent permissions/tools for MCP (discusses task tool circumventing agent permission restrictions)
  • #5887: [feat] True Async/Background Sub-Agent Delegation (related feature request for allowing subagent-to-subagent delegation with async execution)

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 8, 2026): This issue might be a duplicate of existing issues. Please check: - #4439: Subagents are using the task tool (reports subagents unexpectedly delegating to other agents) - #3808: Task should inherit current agent permissions/tools for MCP (discusses task tool circumventing agent permission restrictions) - #5887: [feat] True Async/Background Sub-Agent Delegation (related feature request for allowing subagent-to-subagent delegation with async execution) Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:43:43 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 8, 2026):

I am exploring trying to make a PR for this myself. I have no coding background, or developer experience. But I figure it's time to try to vibe code a contribution.

It also seemed logical, that at the very least I need to construct a more detailed design for the PR to make sure it does what my use-case requires.

My thinking is, even if I fail miserably in producing fully working code that can be pulled into the repo, I will succeed in defining a design that experienced developers managing the project can use to make a proper PR.

@NamedIdentity commented on GitHub (Jan 8, 2026): I am exploring trying to make a PR for this myself. I have no coding background, or developer experience. But I figure it's time to try to vibe code a contribution. It also seemed logical, that at the very least I need to construct a more detailed design for the PR to make sure it does what my use-case requires. My thinking is, even if I fail miserably in producing fully working code that can be pulled into the repo, I will succeed in defining a design that experienced developers managing the project can use to make a proper PR.
yindo commented 2026-02-16 17:43:43 -05:00
Author
Owner
Copy Link
Copy Source

@akirfman commented on GitHub (Jan 9, 2026):

+1 to this feature request.

I'd even be inclined to view parts of this as a bug since I was actively able to leverage subagents that could invoke other subagents before the v1.1.1 release.

Example from v1.0.223 (https://github.com/anomalyco/opencode/blob/01237c5325f5c3eda142f459b22f902b5aa07d7c/packages/opencode/src/tool/task.ts)

      const result = await SessionPrompt.prompt({
        messageID,
        sessionID: session.id,
        model: {
          modelID: model.modelID,
          providerID: model.providerID,
        },
        agent: agent.name,
        tools: {
          todowrite: false,
          todoread: false,
          task: false,
          ...Object.fromEntries((config.experimental?.primary_tools ?? []).map((t) => [t, false])),
          ...agent.tools,
        },

Even though task was hardcoded to false, I could override it by adding task: true into my subagent definitions. For example, I have a research orchestrator subagent that delegates to more focused subagents scoped to different groups of docs and sources that I didn't want to group together into one agent.

Agent YAML frontmatter example:

---
description: Research coordinator that routes queries to appropriate sources and consolidates results. Cross-cutting utility for all SDLC agents.
mode: subagent
tools:
  // ... other tools here
  task: true
---

Working Example from v1.0.223:

Image

Running the same test with the same config on newer versions of OpenCode doesn't work any longer. I'm sure there's more nuance to the topic here in general, but it would be nice to have that optional override behavior back.

@akirfman commented on GitHub (Jan 9, 2026): +1 to this feature request. I'd even be inclined to view parts of this as a bug since I was actively able to leverage subagents that could invoke other subagents before the `v1.1.1` release. Example from `v1.0.223` (https://github.com/anomalyco/opencode/blob/01237c5325f5c3eda142f459b22f902b5aa07d7c/packages/opencode/src/tool/task.ts) ``` const result = await SessionPrompt.prompt({ messageID, sessionID: session.id, model: { modelID: model.modelID, providerID: model.providerID, }, agent: agent.name, tools: { todowrite: false, todoread: false, task: false, ...Object.fromEntries((config.experimental?.primary_tools ?? []).map((t) => [t, false])), ...agent.tools, }, ``` Even though task was hardcoded to false, I could override it by adding `task: true` into my subagent definitions. For example, I have a research orchestrator subagent that delegates to more focused subagents scoped to different groups of docs and sources that I didn't want to group together into one agent. Agent YAML frontmatter example: ``` --- description: Research coordinator that routes queries to appropriate sources and consolidates results. Cross-cutting utility for all SDLC agents. mode: subagent tools: // ... other tools here task: true --- ``` Working Example from v1.0.223: <img width="1100" height="331" alt="Image" src="https://github.com/user-attachments/assets/074c3e72-edc6-4e52-85e6-6e305a703c05" /> Running the same test with the same config on newer versions of OpenCode doesn't work any longer. I'm sure there's more nuance to the topic here in general, but it would be nice to have that optional override behavior back.
yindo commented 2026-02-16 17:43:43 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 11, 2026):

I have submitted a PR which provides these features. https://github.com/anomalyco/opencode/pull/7756

@NamedIdentity commented on GitHub (Jan 11, 2026): I have submitted a PR which provides these features. https://github.com/anomalyco/opencode/pull/7756
yindo commented 2026-02-16 17:43:43 -05:00
Author
Owner
Copy Link
Copy Source

@macastro9714 commented on GitHub (Jan 19, 2026):

@NamedIdentity I'd suggest to not close the issue until the PR gets approved, since it might still be rejected or not reviewed/allowed

@macastro9714 commented on GitHub (Jan 19, 2026): @NamedIdentity I'd suggest to not close the issue until the PR gets approved, since it might still be rejected or not reviewed/allowed
yindo commented 2026-02-16 17:43:43 -05:00
Author
Owner
Copy Link
Copy Source

@NamedIdentity commented on GitHub (Jan 19, 2026):

@macastro9714 I'm new to this so I'll go with your suggestion to reopen this issue until the PR is accepted into main.

@NamedIdentity commented on GitHub (Jan 19, 2026): @macastro9714 I'm new to this so I'll go with your suggestion to reopen this issue until the PR is accepted into main.
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 discussion
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#4413
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?