SendMessage returns success but silently drops messages; Remote Control sessions should still do local inter-session messaging

Summary

Two related problems with cross-session messaging (SendMessage / ListAgents) when Remote Control is involved:

1. Feature request: a session connected to Remote Control should still participate fully in local inter-session messaging.
2. Bug (the damaging part): when messaging does break for a session, SendMessage still returns success. Nothing surfaces the failure, so both sides sit waiting on each other.

The silent-success part is what actually cost us time — roughly two hours of two agent sessions each believing the other had gone quiet.

Environment

• Claude Code 2.1.247, entrypoint: claude-desktop, Windows 11
• 5–6 concurrent interactive sessions in the same working directory
• Two of them had bridgeSessionId set in ~/.claude/sessions/<pid>.json (Remote Control connected)

What we observed

One session (call it S1) stopped exchanging messages entirely:

• Outbound: 8 consecutive SendMessage calls to 5 different peers all returned success with a msg_id. None of them appear in any recipient's transcript. Verified by grepping each recipient's ~/.claude/projects/<slug>/<sessionId>.jsonl for <cross-session-message user turns.
• Inbound: S1's last genuine inbound message was at 11:07 local time. Nothing after.
• Both directions stopped within ~3 minutes of each other, and within ~3 minutes of S1's registry entry being rewritten with a bridgeSessionId.
• ListAgents continued to list peers normally the whole time, so nothing in the UI suggested a problem.

Meanwhile a second session that was also bridged (bridgeSessionId present) kept exchanging messages with an unbridged peer normally, in both directions, during the same window. So "bridged = broken" is not the rule — whatever the trigger is, it is narrower than that. We could not isolate it further from the client side.

Why this is hard to notice

There is no observable difference between "delivered" and "silently dropped":

• The tool result is success plus a msg_id.
• ListAgents still shows the peer as alive and interactive.
• The only way we found to check delivery was to read the recipient's transcript file directly and grep for the message.

Two sessions each concluded the other was unresponsive, and each wrote that into its own status reports. A blocked production promotion sat idle for ~50 minutes because an approval message was never delivered.

Suggested fixes, in priority order

1. Do not report success for a message that was not delivered. Either await an ack from the recipient socket, or return a distinct result (queued, undeliverable, unknown) so the caller can retry or escalate.
2. Surface bridge/transport state in ListAgents. Today the annotation ; it is also connected via Remote Control appears on the recipient row, but there is no indication of the sender's own transport health. A row like myproj-a1 · interactive · messaging: degraded would have made this visible in seconds.
3. Let Remote Control sessions participate in local messaging (the original request). A session being reachable from claude.ai/code or mobile should not change its local peer connectivity.
4. Optionally, a self-check — something like /remote-control reporting "local messaging: OK / not delivering" — would make this diagnosable without reading raw transcript files.

Reproduction

We could not reduce this to a deterministic repro; it appeared during a normal multi-session working day and persisted for hours. What we can say precisely:

• It is observable by comparing SendMessage results against the recipient's .jsonl transcript.
• It correlates with bridgeSessionId appearing in ~/.claude/sessions/<pid>.json, but that correlation has a counterexample on the same machine at the same time (n=1 for the failing case), so we are reporting the correlation rather than asserting causation.

Happy to provide more detail if useful.