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

[FEATURE]: Allow showing/hiding subagents from primary agents #3125

New Issue
Closed
opened 2026-02-16 17:38:45 -05:00 by yindo · 8 comments
yindo commented 2026-02-16 17:38:45 -05:00
Owner
Copy Link
Copy Source

Originally created by @Sewer56 on GitHub (Nov 25, 2025).

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

The docs show you can show/hide tools from primary agents using the tools config:

{
  "agent": {
    "plan": {
      "tools": {
        "write": false,
        "bash": false
      }
    }
  }
}

It would be useful to have similar control over which subagents a primary agent can invoke.

Proposed Solution

Add a subagents config option to control subagent visibility per primary agent:

{
  "agent": {
    "build": {
      "subagents": {
        "general": true,
        "code-reviewer": false
      }
    }
  }
}

Use Case

I have certain primary agents with varying presets, e.g.

  • orchestrator
  • orchestrator-slow
  • orchestrator-fast

These primary agents follow a loop, which calls underlying subagents. These subagents are specific to their orchestrator modes, and should not be invoked anywhere else.

However, by default, all subagents are available to all modes.
This has resulted in some cases of:

  • An orchestrator mode calling the wrong subagent (rare)
  • Regular build/plan agents calling the subagents made for orchestrator (e.g. when being asked to make a code edit).

A filter would prevent this from happening.

Originally created by @Sewer56 on GitHub (Nov 25, 2025). ### 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 The docs show you can show/hide tools from primary agents using the `tools` config: ```jsonc { "agent": { "plan": { "tools": { "write": false, "bash": false } } } } ``` It would be useful to have similar control over which subagents a primary agent can invoke. ## Proposed Solution Add a subagents config option to control subagent visibility per primary agent: ```json { "agent": { "build": { "subagents": { "general": true, "code-reviewer": false } } } } ``` ## Use Case I have certain primary agents with varying presets, e.g. - `orchestrator` - `orchestrator-slow` - `orchestrator-fast` These primary agents follow a loop, which calls underlying subagents. These subagents are specific to their `orchestrator` modes, and should not be invoked anywhere else. However, by default, all subagents are available to all modes. This has resulted in some cases of: - An orchestrator mode calling the wrong subagent (rare) - Regular build/plan agents calling the subagents made for orchestrator (e.g. when being asked to make a code edit). A filter would prevent this from happening.
yindo added the discussion label 2026-02-16 17:38:45 -05:00
yindo closed this issue 2026-02-16 17:38:45 -05:00
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 25, 2025):

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

  • #4267: [bug] Restrict which subagents a custom agent can spawn - Requests the ability to control which subagents a primary agent can spawn, with a specific focus on preventing agents with restricted permissions from spawning subagents with more capabilities. This is very closely related to your proposed solution for controlling subagent visibility.

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

@github-actions[bot] commented on GitHub (Nov 25, 2025): This issue might be a duplicate of existing issues. Please check: - #4267: [bug] Restrict which subagents a custom agent can spawn - Requests the ability to control which subagents a primary agent can spawn, with a specific focus on preventing agents with restricted permissions from spawning subagents with more capabilities. This is very closely related to your proposed solution for controlling subagent visibility. Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@Sewer56 commented on GitHub (Nov 25, 2025):

Oh damn, I didn't catch the duplicate with manual search.
I'll keep open for now, am considering adding this myself.

This at least has a proposal; and the reason is slightly different.

@Sewer56 commented on GitHub (Nov 25, 2025): Oh damn, I didn't catch the duplicate with manual search. I'll keep open for now, am considering adding this myself. This at least has a proposal; and the reason is slightly different.
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@JunarisAlf commented on GitHub (Nov 26, 2025):

+1

@JunarisAlf commented on GitHub (Nov 26, 2025): +1
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@Sewer56 commented on GitHub (Nov 26, 2025):

I got a prototype of this on my end.

@Sewer56 commented on GitHub (Nov 26, 2025): I got a prototype of this on my end.
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@jschmdt commented on GitHub (Nov 30, 2025):

Please expand this feature to slash-commands-usage, too! 🙏 Additionally, make the config option controllable via frontmatter as well. As a side note: would also be super handy if we can config permissions and tools to tailor down the scope of slash-commands even further:

---
description: Reviews code snippets and gives suggestions.
subagents:
  general: false
  code-reviewer: true
tools:
  context7*: true
  webfetch: false
permissions:
  bash: "deny"
  read: "allow"
  write: "ask"
---

Please review the code: $ARGUMENTS
Give suggestions for code improvements & refactor.

I have many ideas where I’d like to narrow permissions, tool usage for my slash-commands and primary agents (for delegation mainly) to save tokens and keep the context to a minimum.

@jschmdt commented on GitHub (Nov 30, 2025): Please expand this feature to `slash-commands`-usage, too! 🙏 Additionally, make the config option controllable via frontmatter as well. As a side note: would also be super handy if we can config `permissions` and `tools` to tailor down the scope of `slash-commands` even further: ```markdown --- description: Reviews code snippets and gives suggestions. subagents: general: false code-reviewer: true tools: context7*: true webfetch: false permissions: bash: "deny" read: "allow" write: "ask" --- Please review the code: $ARGUMENTS Give suggestions for code improvements & refactor. ``` I have many ideas where I’d like to narrow permissions, tool usage for my slash-commands and primary agents (for delegation mainly) to save tokens and keep the context to a minimum.
yindo commented 2026-02-16 17:38:45 -05:00
Author
Owner
Copy Link
Copy Source

@Sewer56 commented on GitHub (Nov 30, 2025):

@jschmdt Have you tried actually using the PR?
Some of that functionality is already in there; I got my own stuff configured via the frontmatter.

@Sewer56 commented on GitHub (Nov 30, 2025): @jschmdt Have you tried actually using the PR? Some of that functionality is already in there; I got my own stuff configured via the frontmatter.
yindo commented 2026-02-16 17:38:46 -05:00
Author
Owner
Copy Link
Copy Source

@jschmdt commented on GitHub (Nov 30, 2025):

@Sewer56 Not yet, I was more asking if this feature would also generally work with command/slash.md. Since I always thought slashcommands do not support other fields than description as frontmatter - as of now. But maybe I'm wrong 😅

@jschmdt commented on GitHub (Nov 30, 2025): @Sewer56 Not yet, I was more asking if this feature would also generally work with `command/slash.md`. Since I always thought slashcommands do not support other fields than `description` as frontmatter - as of now. But maybe I'm wrong 😅
yindo commented 2026-02-16 17:38:46 -05:00
Author
Owner
Copy Link
Copy Source

@jschmdt commented on GitHub (Jan 5, 2026):

@rekram1-node With the newly implemented permission system in 1.1.1, is there any update in regards to this issue with managing subagent availability for primary agents & slash-commands?

@jschmdt commented on GitHub (Jan 5, 2026): @rekram1-node With the newly implemented permission system in 1.1.1, is there any update in regards to this issue with managing subagent availability for primary agents & slash-commands?
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#3125
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?