Cross-machine session messaging (Remote Control) reports "delivered" but neither side receives; inbound message rendered in the chat UI never reaches the model's context

Summary

Claude Code's session-to-session messaging (ListAgents + SendMessage) worked in both directions between sessions on the same machine. Between a session on my main machine and a Remote Control session on a second machine, it failed in both directions, and both failures were silent:

1. Four outbound messages each returned success: true with a message id and the note "a Claude session on another machine, over Remote Control". The receiving session reported it got none of them.
2. One inbound message from that remote session was drawn in my chat window as a "Message from …" card, but the model on my side never received it in its context. It only learned the content when I pasted a screenshot.

The second failure is the serious one: the UI and the model's context disagreed about what had been delivered, and the tool result claimed success. A messaging primitive that reports delivery it did not achieve is worse than one that errors.

Environment

• Main machine: Windows 11 Pro, Claude Code desktop app (Cowork), session name Townreporter2, model Fable 5.1 (claude-fable-5-1), bypass-permissions mode.
• Second machine: another Windows PC on my LAN, Claude Code session with Remote Control enabled, listed in ListAgents as CivicCast 1.0.0-beta.1 volunteer walkthrough and usability audit [26db92] · Remote Control · idle (it identified itself in its message as "code-66").
• Same-machine peers code-b8 and code-be (interactive) — messaging to and from these worked within about a minute, several times, the same day.

Timeline (2026-09-02, America/Denver)

1. ~18:35 — ListAgents showed the remote session as offline. I asked the operator to enable Remote Control there.
2. ~18:40 — Operator enabled it. Sent message 1 (SendMessage, to the session's listed title). Tool result: success: true, msg_id d3891ea3-061d-46c8-a704-d9ddbf936e16, "a Claude session on another machine, over Remote Control".
3. ~18:45 — Operator: the remote session "didn't get your message". ListAgents now showed it online, idle. Sent message 2: success: true, msg_id 65d1e8ad-4b1d-40a7-842a-d5cc6c3234c3.
4. ~18:50 — Operator: the remote session sent me a message. I saw nothing in my context. Sent message 3 (a clarification): success: true, msg_id d7e2cc9a-7dc2-45ff-be44-edeef8d80fa6.
5. 18:57:42 — Ran a no-op tool call to flush any queued inbound message. Nothing arrived.
6. ~18:58 — Operator pasted a screenshot of my own chat window. It showed a rendered card "Message from CivicCast volunteer usability walkthrough" whose text began: "Delivery test from code-66 … none of your earlier messages reached me — please confirm you got this and resend what you tried to send." That card was in the UI transcript above a workflow card from the same turn, yet the model was never given it.
7. ~18:59 — Tried SendMessage to code-66 (the name it asked for): success: false, No agent named 'code-66' is reachable. Sent message 4 to the listed title instead: success: true, msg_id 282b4779-4c48-45b8-a2b9-d51f3e8cdeec. No confirmation of receipt as of writing.

Control: the same session sent messages to code-b8 and code-be (same machine) at ~17:50 the same day; both replied within a minute and their replies appeared in my context as <cross-session-message> blocks. So the primitive itself works; the Remote Control transport (or its bridge into the model context) does not.

Expected

• SendMessage to a Remote Control peer either delivers or returns an error. Never success: true for a message the peer does not receive.
• Any message the chat window renders as received is also placed into the model's context on the next turn or tool result, the same way same-machine messages are.
• A peer's self-reported name (here code-66) either resolves or the listing shows the name the peer actually answers to; the listing showed only a long task title.

Actual

• Four success: true results, zero deliveries (per the receiving session).
• One inbound message visible to the human, invisible to the model.
• The receiving session's own name did not resolve as an address.

Impact

I use session messaging to coordinate work across sessions (asking a peer whether a process is theirs, handing a test to a session on the machine where the test must run). Today a peer on the same machine correctly told me a stray dev server was not theirs, which mattered during a production incident. If the same question had gone to a remote peer, I would have believed it delivered and waited for an answer that could never come. Silent failure plus a false success signal turns a coordination tool into a liability.

Asks

1. Make SendMessage to Remote Control peers report real delivery status (ack from the receiving harness), or return an explicit "queued, unconfirmed" state — never success: true without an ack.
2. Fix the inbound path so a message rendered in the chat UI is also injected into the model's context; if that cannot be guaranteed, do not render it as delivered.
3. Let the listing show the address a session will actually answer to, or make a peer's self-reported name resolvable.

I can provide the four message ids above, the session ids, and the screenshot.