Agent tool description references `SendMessage` to continue spawned subagents, but the tool is unavailable

Same setup, different impact — adding a use-case data point:

I dispatched 5 parallel background subagents via Agent(run_in_background: true) to implement independent workstreams in isolated worktrees, then realized mid-flight that I needed to add a smoke-test requirement to each agent's brief. Without SendMessage to push the addendum, the only path was TaskStop + cold respawn × 5 (losing each agent's ramp-up), or accept the under-spec and do integration verification serially at merge time in the orchestrator's worktree.

Picked the serial-at-merge path. Costs:

• ~50 min of serial verification that should have been in-place parallel.
• Mock-vs-real-API drift fixes happen in the orchestrator's worktree without each agent's context.
• The orchestrator pattern degrades from "fan out, narrow each in flight, fan in" to "fan out, take what you get, fix from outside."

+1 to option 1 in the OP's expected behavior. If exposing SendMessage to the dispatching session is heavier than the docs fix, even a clear note in the Agent description that resumption only applies to foreground/Task-mode agents would unblock planning — the current docs imply the parallel-background workflow is fully bidirectional, which it isn't.

This should be fixed at the capability-manifest boundary.

The Agent tool description should be generated from the actual enabled tool registry for the current session. If SendMessage is disabled, experimental, or unavailable in this mode, the description should say so and expose the supported alternative.

Good regression:

1. start with agent-teams off
2. inspect Agent tool description
3. assert it does not instruct the model to use unavailable SendMessage
4. enable the mode that provides SendMessage
5. assert the tool appears and the Agent description links to the same capability

The damaging behavior is a stale affordance: the model plans around a tool that cannot exist in the current session.

---

_Generated with ax._

Update: as of v2.1.187 SendMessage is available without the flag — but the change looks undocumented, so flagging it here.

On v2.1.187 (macOS and Windows), SendMessage now resolves via ToolSearch select:SendMessage and successfully resumes a completed background subagent without CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS set — i.e. the exact behavior this issue asked for. Spawning a background agent and then messaging it by agentId restores its prior context (verified: the resumed agent answered a follow-up that only made sense if it remembered its earlier turn).

The thing is, I can't find any changelog entry for this. Nothing in the v2.1.186 or v2.1.187 notes mentions SendMessage, the flag, or tool availability — the only agent-teams bullet in that range is unrelated (--effort inheritance). A source comparison across releases suggests the flag gate was present through ~v2.1.185 and removed around v2.1.186, but since it's unannounced I can only state for certain that it's flag-off on v2.1.187.

So, two questions for the maintainers:

1. Is the ungating intentional? It resolves the documented-but-unavailable mismatch this issue (and #44080, #61867, #42737, #35240) reported — but shipping it silently makes it hard to tell whether it's a sanctioned change or an incidental gate leak.
2. Is it stable to depend on? We're deciding whether to build a multi-agent orchestration flow on background-subagent resume. If flag off SendMessage is here to stay, great; if it might revert in a future release, we'll set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 explicitly instead. A one-line confirmation either way (and ideally a changelog note) would let people build on it with confidence.

Still broken in practice on v2.1.196 — deferred ≠ available for subagents

Following up on @oviano's observation: on v2.1.196, SendMessage does appear in the deferred tool list and resolves via ToolSearch("select:SendMessage"). However, subagents spawned via the Agent tool don't load the schema before calling it, so calls fail with:

InputValidationError: SendMessage failed due to the following issue:
The required parameter `message` is missing

Root cause (per claude-opus-4-6's own analysis): deferred tools require a ToolSearch call to load their schema before invocation. The orchestrating session can do this manually, but subagents decide on their own to call SendMessage — and they don't know to load the schema first. There's no way for the user to force a subagent to run ToolSearch before its first SendMessage call.

This means the fix from ~v2.1.186 (ungating SendMessage) only works when the parent session calls SendMessage after manually loading it. For subagent-to-parent communication (the more common case in background agent workflows), it's still effectively broken.

Suggested fix (also from claude-opus-4-6): SendMessage should be a pre-loaded tool (not deferred) — its schema is tiny, and it's a core primitive for agent communication. Alternatively, the subagent harness could auto-load deferred schemas for tools referenced in the Agent tool description.

Environment:

• Claude Code v2.1.196
• macOS
• Anthropic API
• Model: claude-opus-4-6