Cross-session messaging is one-way: receiving session has no SendMessage tool, but ListAgents and inbound system-reminders instruct it to use one

Status Fixed / completed

Maintainer reply None cached

Activity 0 comments · opened Sep 9, 2026 · closed Sep 25, 2026

Cross-session messaging is one-way: receiving session has no SendMessage tool, but is told to use it

Summary

In a multi-session (Remote Control) setup, one session could send messages to
another, but the receiving session had no SendMessage tool available at all.
The receiving session is nonetheless told — by both ListAgents output and by the
system-reminder attached to each inbound message — to reply using SendMessage.

The result is a silent one-way channel. All coordination had to be manually
copy-pasted by the human between two Claude sessions, roughly six times over a
multi-hour debugging session.

Environment

Claude Code desktop app (Code tab)
Host: WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2)
Peer sessions labelled Remote Control
Model: Opus 5

Expected

If ListAgents lists peer sessions and states that a session is addressable,
and if inbound messages instruct a reply via SendMessage, then SendMessage
should be available in that session.

Actual

SendMessage was never available in the receiving session. Verified six times
across the session, at different points, including after an MCP server
disconnect/reconnect cycle:

ToolSearch("select:SendMessage") -> No matching deferred tools found
ToolSearch("select:SendMessage,Message,...") -> No matching deferred tools found
ToolSearch("send message to another session") -> returned Monitor, TaskStop,
EnterWorktree, PushNotification,
CronCreate, ListPlugins — no SendMessage
ToolSearch("reply cross-session peer bridge") -> returned Gmail reply tool + TaskStop

Meanwhile inbound delivery worked flawlessly — five or more messages arrived
intact and in order, from bridge:session_01SBciyS5AdHxwzxcQ4StFd4.

The contradictory guidance

ListAgents output begins:

This session is cgopa-bc [ffb50d] — the name other sessions use to message it

which implies the session is addressable and, by extension, can address others.

The system-reminder appended to every inbound cross-session message ends:

After completing your current task, decide whether/how to respond
(reply via SendMessage to the from= address).

This instructs the use of a tool that is not present and cannot be loaded.

The peer session was left waiting on a reply that could never be sent, and had
no way to detect this. At one point it was still running — actively iterating
on a problem the other session had already conclusively closed — because the
answer could not reach it.

Secondary: unstable session identity

Session identity changed mid-conversation without any reconnect initiated by the
session itself:

Early in the session, ListAgents reported: cgopa-05 [ab7386]
Later, unprompted: cgopa-bc [ffb50d]
The peer reported seeing it as: Pi remote debug session [6db32c]

That third name never appeared in this session's own peer list. So the two sides
disagreed on identity in three different ways simultaneously, while messages
still routed correctly. This makes it impossible for a session to tell a peer
how to address it.

Impact

Two Claude sessions collaborating on one physical device (one with SSH access,
one with the code checkout) could not talk to each other. Every finding — package
names, a corrected systemd unit name, a wrong success criterion, and a final
root-cause conclusion — had to be written to a file, handed to the human, and
pasted by them into the other session. The human explicitly noted this was a
waste of their time, which is what prompted this report.

Suggested fixes

Make SendMessage available wherever cross-session messages can be received,

If outbound messaging is intentionally unavailable in some contexts, stop

instructing the session to use SendMessage in the inbound system-reminder,
and have ListAgents state that this session can receive but not send.