Agent tool ignores the subagent definition: dispatched subagents inherit the dispatcher's prompt and tools (built-in and plugin types)
Summary
The Agent tool ignores the subagent definition: a dispatched subagent receives the
dispatching session's system prompt and tool surface wholesale — for built-in and plugin
agent types alike — while that same definition appears, correctly parsed, in the agent-type
registry listing.
tools: is neither a ceiling nor a floor under dispatch. The agent body is never applied. The
dispatch does not error; it returns a plausible-looking agent that is not the one requested.
The same definitions are applied correctly at top level via claude --agent <name>.
Environment
- Claude Code 2.1.263
- macOS 26.6.2 (Darwin 25.6.0)
Reproduction — stock install, no plugins, no MCP servers, one call
In any interactive session:
Agent({
subagent_type: "Explore",
prompt: "Reply with exactly two lines. Line 1: do you have the Write tool — yes or no. Line 2: the first sentence of your system prompt."
})
Explore is defined as *"All tools except Agent, Artifact, ArtifactComments, ArtifactData,
ArtifactCheck, ExitPlanMode, Edit, Write, NotebookEdit"*.
Expected: no, and the Explore agent's own prompt.
Observed: yes, and "You are an interactive agent that helps users with software — the generic prompt. Confirmed separately that the child also holds
engineering tasks."Agent, Edit and Artifact, all excluded by the definition.
The inheritance is positive, not merely a default: the child reproduced verbatim a sentence
unique to the dispatching session's own system prompt (a project-specific instruction that
appears nowhere in any agent definition).
Contrast: claude --agent Explore at top level applies the definition correctly —
restricted tools, agent prompt present.
Second reproduction — plugin agents, same result
Three subagents dispatched in one batch from a session holding several MCP servers. Agent
definitions declare nine built-in tools plus exactly one MCP namespace each, and are
byte-identical on disk to the installed plugin version.
Every child received:
- No agent body. No
# <agent-name>heading, none of the definition's role instructions.
Generic prompt, opening "You are Claude Code, Anthropic's official CLI for Claude, running
within the Claude Agent SDK."
- No tool ceiling.
Bash,Agent,Artifact,ToolSearch, and every MCP server the
dispatcher had — 460 deferred tool names in one case — against a declared list of ~28.
Three of three, in one batch. Survives a full restart. Deterministic.
Notably, the harness does load the definitions: the "Available agent types" listing
delivered to the children reproduced each agent's name, description and frontmatter tool list
verbatim. Registration and parsing work; instantiation is what fails.
Why this is worth separating from the existing MCP reports
#30280 and #80036 report that MCP tools are not reliably inherited by subagents. That is one
visible consequence of this, not the whole of it — MCP tools are simply the most conspicuous
thing that goes missing when a dispatcher has few and the child expected many. The underlying
behaviour is not MCP-specific at all, and reproduces with zero MCP servers configured.
Framing it as MCP inheritance also hides the inverse failure, which is the more serious one: a
child dispatched from a well-stocked parent silently gains tools its definition excludes.
Impact
Any project whose least-privilege story rests on agent definitions has no ceiling under
dispatch, and every MCP server registered in the session leaks into every subagent.
In our case three agents are deliberately pinned to three different roles, each declaring one
role's MCP namespace, so that a planner cannot grade its own work and a builder cannot rewrite
its own acceptance criteria. Under dispatch all three receive all three namespaces plus an
unpinned one, and none receive the role instructions that were the second half of the
separation. Server-side authorization still refuses cross-role writes in our setup, so this
was contained for us — but the containment is ours, not the harness's, and any project relying
on tools: alone has none.
Because a child dispatched from a well-stocked parent looks like it works, this gets reported
as intermittent. It is not.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗