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

[FEATURE]: Granular Agent-to-Agent Visibility Control #4446

New Issue
Closed
opened 2026-02-16 17:43:48 -05:00 by yindo · 4 comments
yindo commented 2026-02-16 17:43:48 -05:00
Owner
Copy Link
Copy Source

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

Originally assigned to: @rekram1-node 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

Add permission.agent to control which agents appear in an agent's inventory. Currently, permission supports bash, skill, edit, etc., but not agent.

OpenCode uses mode to control agent visibility:

  • subagent = hidden from inventory (can't be called)
  • primary = visible, directly invocable by user
  • all = visible, can call other agents

Problem: When you set mode: "all" to enable agent-to-agent calls, the agent sees the entire agent inventory. There's no way to restrict visibility to specific agents.

Why This Matters

Context bloat: An agent that only needs 2 subagents sees all 20+ agents in the system, wasting tokens and potentially causing confusion.

Security/correctness: A build agent shouldn't even know that deploy-production exists, preventing accidental or mistaken calls.

Example

deploy (orchestrator)
├── build
├── verify
├── release
└── promote

With mode: "all", the build agent sees ALL agents including deploy-staging, deploy-production, etc. It should only see its 2 relevant subagents.

Proposed Solution

Add permission.agent following the same pattern as permission.skill:

Current (for skills - already works):

{
  "permission": {
    "skill": {
      "git-*": "allow",
      "experimental-*": "deny"
    }
  }
}

Proposed (for agents):

{
  "agent": {
    "build": {
      "mode": "all",
      "permission": {
        "agent": {
          "compile": "allow",
          "test-unit": "allow"
        }
      }
    }
  }
}

Result: When build runs, its <available_agents> section only includes agents it's allowed to call.

Implementation

  1. Schema: Add agent?: PermissionRuleConfig to the permission object
  2. Inventory filtering: Filter agent inventory by both mode AND permission.agent
  3. Runtime enforcement: Reject calls to agents not in the allowlist
Originally created by @macastro9714 on GitHub (Jan 8, 2026). Originally assigned to: @rekram1-node 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 Add `permission.agent` to control which agents appear in an agent's inventory. Currently, `permission` supports `bash`, `skill`, `edit`, etc., but not `agent`. OpenCode uses `mode` to control agent visibility: - `subagent` = hidden from inventory (can't be called) - `primary` = visible, directly invocable by user - `all` = visible, can call other agents **Problem**: When you set `mode: "all"` to enable agent-to-agent calls, the agent sees the **entire** agent inventory. There's no way to restrict visibility to specific agents. ### Why This Matters **Context bloat**: An agent that only needs 2 subagents sees all 20+ agents in the system, wasting tokens and potentially causing confusion. **Security/correctness**: A `build` agent shouldn't even know that `deploy-production` exists, preventing accidental or mistaken calls. ### Example ``` deploy (orchestrator) ├── build ├── verify ├── release └── promote ``` With `mode: "all"`, the `build` agent sees ALL agents including `deploy-staging`, `deploy-production`, etc. It should only see its 2 relevant subagents. ## Proposed Solution Add `permission.agent` following the same pattern as `permission.skill`: **Current** (for skills - already works): ```json { "permission": { "skill": { "git-*": "allow", "experimental-*": "deny" } } } ``` **Proposed** (for agents): ```json { "agent": { "build": { "mode": "all", "permission": { "agent": { "compile": "allow", "test-unit": "allow" } } } } } ``` Result: When `build` runs, its `<available_agents>` section only includes agents it's allowed to call. ## Implementation 1. **Schema**: Add `agent?: PermissionRuleConfig` to the `permission` object 2. **Inventory filtering**: Filter agent inventory by both `mode` AND `permission.agent` 3. **Runtime enforcement**: Reject calls to agents not in the allowlist
yindo added the discussion label 2026-02-16 17:43:48 -05:00
yindo closed this issue 2026-02-16 17:43:48 -05:00
yindo commented 2026-02-16 17:43:48 -05:00
Author
Owner
Copy Link
Copy Source

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

This issue might be related to existing discussions about agent visibility and permissions. Please check:

  • #7269: Reduce token overhead - discusses limiting which subagents appear in agent inventory to reduce token consumption and improve focus
  • #7296: Allow configurable subagent-to-subagent task delegation - proposes granular control over which agents can call which other agents
  • #6527: Plan mode restrictions bypassed when spawning sub-agents - security issue where subagents inherit full permissions regardless of parent restrictions

Your proposal for permission.agent appears to be the architectural solution these issues need. The related issues highlight the problem from different angles:

  • #7269: Token bloat from seeing all agents
  • #7296: Inability to restrict which agents a subagent can call
  • #6527: Missing permission inheritance

Feel free to ignore if these don't align with your specific use case.

@github-actions[bot] commented on GitHub (Jan 8, 2026): This issue might be related to existing discussions about agent visibility and permissions. Please check: - #7269: Reduce token overhead - discusses limiting which subagents appear in agent inventory to reduce token consumption and improve focus - #7296: Allow configurable subagent-to-subagent task delegation - proposes granular control over which agents can call which other agents - #6527: Plan mode restrictions bypassed when spawning sub-agents - security issue where subagents inherit full permissions regardless of parent restrictions Your proposal for `permission.agent` appears to be the architectural solution these issues need. The related issues highlight the problem from different angles: - #7269: Token bloat from seeing all agents - #7296: Inability to restrict which agents a subagent can call - #6527: Missing permission inheritance Feel free to ignore if these don't align with your specific use case.
yindo commented 2026-02-16 17:43:48 -05:00
Author
Owner
Copy Link
Copy Source

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

I believe what you are requesting here has already been implemeted in https://github.com/anomalyco/opencode/pull/4773

@justfortheloveof commented on GitHub (Jan 8, 2026): I believe what you are requesting here has already been implemeted in https://github.com/anomalyco/opencode/pull/4773
yindo commented 2026-02-16 17:43:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 8, 2026):

You can do this actually, using task tool permissions, example:

"agent": {
"build": {"permission": {"task": {"*": "deny", "explore": "allow"}}}
}

@rekram1-node commented on GitHub (Jan 8, 2026): You can do this actually, using task tool permissions, example: "agent": { "build": {"permission": {"task": {"*": "deny", "explore": "allow"}}} }
yindo commented 2026-02-16 17:43:48 -05:00
Author
Owner
Copy Link
Copy Source

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

Ah I see, yes that works. Thank you. @rekram1-node do you think it will work for subagents too eventually if we allow subagents to instantiate other subagents?

In any case, since this is supported already, I'll close the issue thanks guys!

@macastro9714 commented on GitHub (Jan 8, 2026): Ah I see, yes that works. Thank you. @rekram1-node do you think it will work for subagents too eventually if we allow subagents to instantiate other subagents? In any case, since this is supported already, I'll close the issue thanks guys!
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#4446
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?