What
SendMessage now recognises targets that look like Claude Desktop session ids and delivers plain-text messages to them through Claude Desktop itself, alongside the existing local-socket and remote-bridge delivery paths.
Details
- Requires Claude Desktop's own session messaging tool to be present in the session; without it the send fails as not reachable, with the message quoted below.
- Has its own guards for empty messages and for "hop loops", where agents keep messaging each other automatically, separate from the guards on the other delivery paths.
Evidence
Claude Desktop's session messaging tool is not available in this session, so SendMessage cannot deliver to it
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Names in the bundleSendMessage
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added since
A small documentation edit on Create custom subagents touched a line naming SendMessage after this was published.
The second filter applies to subagents running in the background. Apart from `Agent` and `ExitPlanMode`, which follow the first filter's conditions wherever the subagent runs, a background subagent keeps every MCP tool but only these built…sub-agents see the edit
Confirmed since
Anthropic's documentation has since written up SendMessage, on Claude Code changelog.
* Fixed cross-session messages held by the receiving session's permission-mode policy leaving no trace: headless senders now get a delivery notice, and `SendMessage` results no longer imply it was readchangelog see the edit
Two sources agreeTwo things we can check say the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up SendMessage, on Claude Code changelog.
Anthropic's release notes agree
Fixed replying to a message Claude Desktop delivered from another session: SendMessage to that session id now delivers through Claude…