claude-code - 💡(How to fix) Fix Spawned subagents cannot originate SendMessage despite CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and explicit name= parameter [1 comments, 2 participants]

Environment

• Claude Code, Opus 4.6 (1M), alwaysThinkingEnabled: true
• .claude/settings.json env: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• .claude/settings.json permissions.allow includes SendMessage(*)
• Subagent type: general-purpose
• Launched via Agent tool with name= set and run_in_background: true

What happened

Parent agent (named "field-manager") spawned four named subagents (query, schema, indexes, tests) as a coordinated team. Each subagent's prompt:

• Listed the full roster with teammate names
• Defined explicit SendMessage edges to peers
• Included a mandatory escalation clause: "SendMessage(to='field-manager') immediately" when finding cross-domain conflicts, blast-radius concerns, or invalidated assumptions

Parent called SendMessage(to="indexes", ...) and received {"success":true,"message":"Message queued for delivery to indexes at its next tool round."}. Parent could originate.

Three of four subagents reported in their deliverables that SendMessage was not in their toolset:

• query: "SendMessage tool not available in this environment (verified via ToolSearch — no match). Messages below are logged as intended-to-send and should be delivered by field-manager on my behalf."
• schema: "(SendMessage tool not loaded; relaying for field-manager to route)"
• tests: "SendMessage is not available in my current toolset. I documented the three messages inline above… Field-manager should route them or grant the tool."

Subagents could receive SendMessage (parent's messages resumed them with the content in context), but could not originate. Asymmetric.

Impact

• Broken team coordination. The point of EXPERIMENTAL_AGENT_TEAMS=1 is peer-to-peer messaging; subagents degraded to isolated workers producing reports requiring manual parent-side relay.
• Escalation clause became dead — agents could not actually escalate mid-analysis, the exact case the clause exists for.
• Forced the parent to re-run agents after manually relaying messages. Double the cost and wall-clock time; still lost parallelism for everything the initial run would have needed to cross-resolve.
• Users cannot rely on prompts that include SendMessage directives; the tool contract is silently violated.

Expected

Subagents launched with name= under a parent whose team context has CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and SendMessage(*) permission inherit SendMessage in their toolset.

Actual

SendMessage is missing from subagent toolsets. ToolSearch("select:SendMessage") in subagents returns no match.

Workaround

Parent manually pastes each agent's "intended-to-send" message blocks as fresh outbound SendMessage calls. Works, but defeats the parallel-team design and adds orchestration burden to the parent context.

Ask

Either: (a) Auto-provision SendMessage in subagent toolsets when CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and a name= is set on the Agent call, or (b) Document the limitation explicitly so callers can either stop including SendMessage directives in subagent prompts, or grant the tool via some other mechanism.

Repro

Minimal: enable teams, spawn any general-purpose subagent with name= and a prompt instructing it to call SendMessage(to='<peer>'). The subagent's first ToolSearch("select:SendMessage") returns no match and the instruction cannot be followed.