Skip to content

[BUG] Subagents spawned via Task tool cannot execute MCP tools despite appearing in tool registry #16491

Closed as not planned

Description

@jeremyakers

Description

Bug Description

When a subagent session is spawned via the Task tool, MCP tools from configured MCP servers appear in the subagent's tool registry but cannot be executed due to missing session permissions. The subagent can see the tools (e.g., tymemud-builder_read_room, context7_resolve-library-id) in its function list, but when attempting to call them, the permission system blocks execution.

What Happened

  • Parent agent successfully uses MCP tools (e.g., tymemud-builder_list_rooms_in_zone)
  • Subagent spawned via Task tool reports MCP tools are "not appearing in available function list" or gets permission denied
  • Subagent can see MCP tools in the registry but lacks permission to execute them
  • Permission check fails at execution time in packages/opencode/src/session/prompt.ts

Root Cause Analysis

In packages/opencode/src/tool/task.ts (lines 66-102), when creating a subagent session, only explicit permissions are granted for native tools (todowrite, todoread, task). MCP tools are not included in the session's permission array:

return await Session.create({
  parentID: ctx.sessionID,
  title: params.description + ` (@${agent.name} subagent)`,
  permission: [
    {
      permission: "todowrite",
      pattern: "*",
      action: "deny",
    },
    {
      permission: "todoread",
      pattern: "*",
      action: "deny",
    },
    // ... MCP tools NOT explicitly granted permission
  ],
})

When MCP tools are added to the tool registry in packages/opencode/src/session/prompt.ts (lines 830-921), they are wrapped with a permission check via ctx.ask(). The permission ruleset is merged from input.agent.permission and input.session.permission (line 778), but since subagent sessions don't have MCP tool permissions explicitly granted, the check fails.
Relevant Code Locations

File: packages/opencode/src/tool/task.ts, lines 66-102 - Subagent session creation
File: packages/opencode/src/session/prompt.ts, lines 773-780, 830-921 - Permission merging and MCP tool wrapping
File: packages/opencode/src/mcp/index.ts, line 598 - MCP tools retrieval

Impact

I have a number of MCP servers for things like grepai, and query tools for querying/updating non-SQL data stores. This issue makes it nearly impossible for any subagents to do useful work in my environment because they cannot access any of my MCP tools needed to do their work.

Plugins

oh-my-opencode

OpenCode version

1.2.20

Steps to reproduce

Steps to Reproduce

  1. Configure an MCP server in opencode.json
    
  2. Start OpenCode and verify MCP shows as "connected" via opencode mcp list
    
  3. Use parent agent to successfully call an MCP tool 
    
  4. Spawn a subagent via Task tool with a prompt that requires MCP tool usage
    
  5. Observe that subagent reports MCP tools are not available or gets permission denied when attempting to execute
    

Screenshot and/or share link

Image

Operating System

Ubuntu 22.04

Terminal

Web UI

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 7, 2026
  2. github-actions commented on Mar 7, 2026

    @github-actions
    Contributor

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

  3. btbxbob commented on Mar 16, 2026

    @btbxbob

    today i met this problem with jenkins mcp. i think the sub-agents doesn't get any mcp at all.

  4. thanhnndev commented on Mar 19, 2026

    @thanhnndev

    Same here. Spawn sub-agent to double check code with context7. But can't

  5. Hyp3rSon1X commented on Mar 29, 2026

    @Hyp3rSon1X

    This is still a problem and it seems the Pull Request that tried to solve this issue got closed.

    I had to wrap my mcp into an opencode plugin to register it as a native tool to circumvent this problem... but that really shouldn't be needed...

  6. luoshuijs commented on Apr 9, 2026

    @luoshuijs

    I've also noticed that subtasks sometimes fail to invoke MCP under specific circumstances. Currently, it's difficult to consistently reproduce this issue.

  7. ZiyiTsang commented on Apr 14, 2026

    @ZiyiTsang

    Same here. I call the subagent to use MCP, but clearly observed failing to use (it seems the subagent does not see it at all)

  8. EL4CTEO commented on Apr 24, 2026

    @EL4CTEO

    reading comments

  9. assigned and unassigned on Apr 26, 2026
  10. removed
    bugSomething isn't working
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  11. added 2 commits that reference this issue on May 11, 2026
    f7c0ecf
    5d6c74a
  12. duan2026 commented on Jun 11, 2026

    @duan2026

    I want to know if this bug has been resolved in the latest version. I have also been troubled by this bug and after ruling it out for two hours, I began to suspect that the subagent was unable to call MCP. After finding this post, I confirmed that this is the case. Also, I found that the sub agent cannot call the plug, right? If there is any progress on this, please let me know. Thank you all. If the sub agent can call MCP, it will be very convenient for development

  13. added a commit that references this issue on Jun 20, 2026
    5df7955
  14. entrptaher commented on Jul 14, 2026

    @entrptaher

    I think in v2 it's possible to fix this.

    Image

    Three changes decouple MCP tools from the execute mechanic:

    packages/core/src/mcp/guidance.ts

    -    `    Use tools from this server through \`execute\` under \`tools[${JSON.stringify(McpTool.group(server.server))}]\`.`,
    -        if (PermissionV2.evaluate("execute", "*", agent.permissions).effect === "deny")
    -          return source(Instructions.removed)

    packages/core/src/tool/mcp.ts

    -          ([group, record]) => tools.register(record, { group }),
    +          ([group, record]) => tools.register(record, { group, codemode: false }),

    packages/tui/src/context/data.tsx

    -              const result = await client.api.mcp.list({ location: locationQuery(ref) })
    +              const result = await client.api.mcp.list({ location: locationQuery(ref ?? defaultLocation()) })
    -              const result = await client.api.mcp.resource.catalog({ location: locationQuery(ref) })
    +              const result = await client.api.mcp.resource.catalog({ location: locationQuery(ref ?? defaultLocation()) })

    If you make these changes,

    • MCP tools now register as regular tools (codemode: false) rather than code-mode tools, so they don't require execute permission.
    • MCP server instructions are always included — removed the gate that suppressed them when execute was denied.
    • The execute usage hint is removed from guidance, since the model no longer routes through execute to use MCP tools.
    • Fixed TUI refresh() to default the location when ref is undefined, which was silently breaking MCP list/catalog calls.

    And then in your config file,

    {
      "$schema": "https://opencode.ai/config.json",
      "agents": {
        "explore": {
          "description": "Fast agent specialized for exploring codebases",
          "mode": "subagent",
          "permissions": [
            { "action": "grep", "resource": "*", "effect": "allow" },
            { "action": "glob", "resource": "*", "effect": "allow" },
            { "action": "webfetch", "resource": "*", "effect": "allow" },
            { "action": "websearch", "resource": "*", "effect": "allow" },
            { "action": "read", "resource": "*", "effect": "allow" },
            { "action": "context7_*", "resource": "*", "effect": "allow" },  // <--explicitely allow the tool
            { "action": "pencil_*", "resource": "*", "effect": "allow" } // <--explicitely allow the tool
          ]
        },
    }
    

    The code hardcodes some restrictions which are responsible for this issue.

    However, this is also probably a critical security issue as you can see the closed PRs connected to this issue.

  15. github-actions commented on Sep 13, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  16. jeremyakers commented on Sep 13, 2026

    @jeremyakers
    Author

    Every freaking issue or PR I open in OpenCode gets closed with this same BS. So obnoxious. Nothing that actually effects real people ever gets fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions