Sub-agents dispatched via Task tool have empty MCP tool registry — parent's MCP server connections don't propagate to sub-agent process

Summary

When a parent Claude Code session has MCP servers connected via --mcp-config <path> + --allowedTools listing mcp__<server>__* wildcards, dispatching a sub-agent via the Task tool produces a sub-agent process whose MCP tool registry is empty. The sub-agent has ToolSearch as a tool name (it's in the sub-agent's frontmatter tools: allowlist), but ToolSearch.select:<any-tool> reports No matching deferred tools found. Every mcp__* tool call from the sub-agent returns "No such tool available."

This blocks the documented use-case of dispatching sub-agents to do multi-step MCP-tool work in a separate context.

Environment

• Claude Code: bundled with agt-cli 0.27.49 (latest at time of report). Repro consistent across 5+ recent Claude Code versions tested over the past 24h.
• Session shape: persistent tmux session spawned by a manager daemon. Parent claude args (via ps -eo args):

``
/usr/bin/claude ... --mcp-config /root/.augmented/don/project/.mcp.json
--system-prompt-file /root/.augmented/don/project/CLAUDE.md
--model opus
--allow-dangerously-skip-permissions
--dangerously-skip-permissions
--strict-mcp-config
--name agt-don
--allowedTools mcp__augmented__*,mcp__slack__*,mcp__telegram__*,mcp__direct_chat__*,mcp__granola__*,mcp__composio_gmail__*,mcp__composio_googlecalendar__*,mcp__composio_salesforce__*,mcp__composio_attio__*,Bash,Read,Write,Edit,Grep,Glob,Agent,Skill,ToolSearch
``

• Sub-agent definition (project-scope, ~/.augmented/don/project/.claude/agents/augmented-worker.md):

``yaml
---
name: augmented-worker
background: true
tools: Bash, Read, Write, Edit, Grep, Glob, Skill, Agent, ToolSearch, mcp__augmented__*, mcp__slack__*, mcp__telegram__*, mcp__direct_chat__*, mcp__granola__*, mcp__composio_gmail__*, mcp__composio_googlecalendar__*, mcp__composio_salesforce__*, mcp__composio_attio__*
---
``

Reproduction

1. Spawn Claude Code with --mcp-config <path> pointing at a .mcp.json listing multiple MCP servers (augmented, slack, composio_*, etc.)
2. Pass --allowedTools including mcp__<server>__* wildcards + ToolSearch
3. In the parent session, confirm mcp__augmented__kanban_list (or any mcp__* tool) works.
4. Confirm ToolSearch.select:mcp__augmented__kanban_list in the parent returns a schema that can be invoked.
5. Define a project-scope sub-agent with an explicit tools: allowlist that includes ToolSearch + the same mcp__* wildcards (see definition above).
6. Have the parent dispatch the sub-agent via Task({subagent_type: 'augmented-worker', ...}).
7. From inside the sub-agent, try:

• mcp__augmented__kanban_list({}) → returns "No such tool available."
• ToolSearch.select:mcp__augmented__kanban_list → returns "No matching deferred tools found."
• Any other mcp__* invocation → same "No such tool available."

Expected

Per the sub-agent docs:

Subagents inherit the internal tools and MCP tools available in the main conversation by default.

The sub-agent's tools: allowlist explicitly enumerates mcp__*__* wildcards, so the sub-agent should be able to invoke those tools (subject to its allowlist filter). With ToolSearch in the sub-agent's allowlist, the deferred-tool registry should be populated from the parent's MCP server set.

Actual

The sub-agent's MCP tool registry is empty. ToolSearch is present as a tool name but its registry contains zero entries — no MCP server's tools are inherited.

Tested workarounds that did NOT fix it

1. Adding ToolSearch to parent's --allowedTools (it was missing) — parent worked fine before/after; sub-agent unchanged.
2. Adding ToolSearch to sub-agent's frontmatter tools: — sub-agent now has ToolSearch (no longer reports "tool exists but not enabled in this context") but its registry is still empty.
3. Explicit mcp__<server>__* wildcards in sub-agent's tools: — wildcards present in allowlist text, but no schemas to back them.

Additional finding

Task is blocked inside sub-agents ("Task is not available inside subagents"). Combined with the above, a sub-agent has no way to verify its own MCP availability via nested dispatch — making the issue harder to triage from within a sub-agent context.

Severity / impact

This breaks the documented dispatch pattern of "use a sub-agent for multi-step background tool work in a separate context window" for any session that depends on MCP servers (the modern Claude Code default for most non-trivial agents). On our infrastructure (Augmented — managed-agent platform) every channel-reply path, every integration-tool dispatch, every long-running sub-task that should go to a sub-agent currently fails silently with "No such tool available."

We've shipped 6 issues' worth of platform-side fixes (correct sub-agent file rendering, correct allowlist text, correct manager spawn flags) chasing this and confirmed every layer we control is correct — the gap is squarely in Claude Code's sub-agent dispatch path not propagating MCP server connections to the sub-agent process.

Cleanest possible repro file

augmented-worker.md content shown above; parent ps args shown above; sub-agent's empirical output from probe (Don, 2026-06-03):

ToolSearch ✅ present, but every query (select:<tool>, combined, semantic) → No matching deferred tools found. Empty registry. 6-tool probe 0/6 bound — all No such tool available.

Happy to provide a containerised repro on request.