ListAgents tells you to use a SendMessage tool that is not present in the build — running subagents cannot be corrected mid-flight

Preflight Checklist

• [x] I have searched existing issues and this has not been reported yet
• [x] This is a single bug report
• [x] I am using the latest version available to me

Summary

Two built-in tool descriptions instruct the model to call a tool named SendMessage to continue or correct an already-running in-process subagent. No such tool exists in this build, and ToolSearch cannot produce it. The result is that a long-running background subagent is write-only: once dispatched, it cannot be told anything, even when the premise of its brief has changed.

Environment

• Claude Code 2.1.210, running inside the Claude desktop app (Code tab)
• Windows 11 Pro 10.0.26100
• Model: Opus 5 (claude-opus-5)

What the tools say

ListAgents returns, for each in-process subagent:

Subagents (2):
  ae8c3120595c2d3a5  ·  Plan  ·  running  ·  started 5m ago

and its own description states that names are the address and that you send with SendMessage. The Agent tool description says the same thing directly:

Use SendMessage with the agent's ID or name to continue a previously spawned agent with its context intact; a new Agent call starts fresh.

The Agent tool result also says it explicitly, per dispatch:

Use SendMessage with to: <agentId>, summary: <5-10 word recap> to continue this agent.

What actually happens

ToolSearch  query="select:SendMessage"
-> No matching deferred tools found

A keyword search ("send message to running subagent continue agent") returns only unrelated tools: a Gmail connector send_message, and mcp__ccd_session_mgmt__send_message. The latter is not a substitute — it addresses peer sessions by sessionId and its schema states the target "Must not be the current session", so it cannot address a subagent running inside the current one.

Expected vs actual

• Expected: either SendMessage is available (directly or via ToolSearch), or the tool descriptions do not instruct the model to call it.
• Actual: three separate places instruct the model to call a tool that cannot be loaded. The model follows the instruction, the lookup fails, and there is no documented fallback.

Impact, concretely

In the session that prompted this report, a Plan subagent was dispatched to design a self-updating deployment for a small daemon. Roughly two minutes in, the user corrected a premise the brief depended on — the reason a component was not run as a Windows service. There was no way to deliver that correction. The agent ran a further ~6 minutes and returned a design whose entire restart mechanism existed to work around the constraint that had just been removed, and that section had to be discarded.

For any subagent doing multi-minute work, this makes the dispatch a one-shot: every fact must be correct at launch, because nothing can be added or corrected afterwards.

Not a duplicate of

• #90481 — cross-session ListAgents/SendMessage stopped working after an update. That is about peer sessions; here the cross-session tool works fine and the gap is in-process subagents.
• #88970 — cross-session send_message has no return path. Also peer sessions, and about the reply direction rather than the tool being absent.

Suggested fix

Either expose SendMessage for in-process subagents in this build, or make the Agent and ListAgents descriptions state that continuing a running subagent is unavailable here, so the model does not spend a round trip discovering it.