Cross-session SendMessage: messages not delivered, or echoed back to sender mislabeled as inbound

Description

Cross-session messaging (SendMessage / ListAgents, sessions bridged via Remote Control) is unreliable in two distinct ways observed on the same setup within one debugging session:

1. Messages claimed-sent but never delivered. A receiving session ("build-kill-gate", running bypassPermissions) reported in its own transcript that it had called SendMessage to another session ("admin", running normal prompting mode) — but the target session never received anything. This happened twice with the same pair of sessions.
2. A message echoed back to its own sender, mislabeled. After a held cross-session message (see below) sat pending approval, the human owner asked the receiving session, in its own chat, to "resend this message to the admin." Shortly after, the original sender ("admin") received a new <cross-session-message> — but its from-name attribute was "admin" (the sender's own name) and its from bridge session ID matched the sender's own session ID. The message body was verbatim identical to the original message "admin" had sent earlier. In other words, the sender's own outbound message came back to itself, mislabeled as an inbound message from itself.

Environment

• Several Claude Code sessions running persistently via tmux + systemd on a Linux server (not phone/laptop-tied), one running normal (prompting) permission mode, several running bypassPermissions.
• Sessions reachable from each other via ListAgents (all listed as reachable via "Remote Control" transport) and SendMessage.
• The documented crossSessionInbound / held-message-for-approval behavior (messages sent to a bypassPermissions session are held pending human approval; messages to normal/prompting sessions auto-deliver) was independently confirmed working correctly via the local Claude Code changelog and observed in practice (a held-message approval dialog rendered correctly with "Deny" / "Deliver this message to Claude" options). That part is NOT what's reported as broken here — this report is specifically about delivery/echo failures once messages are supposed to be in the "auto-deliver" or "approved-and-delivered" path.

Steps that led to the issue

1. Session A ("admin", prompting mode) sends a message to session B ("build-kill-gate", bypassPermissions) via SendMessage. Confirmed via direct pane inspection: this correctly rendered as a held approval dialog in B's session (expected behavior).
2. Instead of using the dialog's "Deliver this message to Claude" action, the human typed a chat message directly to session B asking it to "resend this message... to the admin."
3. Session B's transcript shows it responding "Resent to the admin session," implying it called SendMessage back to A.
4. Session A then received an incoming <cross-session-message> — but with from-name="admin" (A's own name) and a from bridge session ID matching A's own session, containing text identical to A's original message from step 1. Session B's actual answer/content was never received.
5. Separately (different occasion, same two sessions): session B's own transcript stated "I've already messaged the admin with the exact one-liner" regarding an unrelated request — but session A never received any such message, and re-requesting it from B did not resolve normally (see the echo in step 4 above, believed to stem from the same underlying bug).

Expected behavior

• A message that a session's transcript claims was sent via SendMessage should reliably arrive at the intended recipient, not vanish or bounce back to the original sender relabeled as if newly inbound.

Actual behavior

• Messages are sometimes not delivered to the intended recipient at all (per sender-side self-report; the sender-side claim itself could conceivably be inaccurate, we could not independently verify B's tool-call from outside its own transcript).
• In one clearly reproducible instance, an outbound message was echoed back to its own original sender, mislabeled with the sender's own name/session ID as the "from" party.

Notes

• We could not inspect backend/relay-level logs for the Remote Control bridge from either session — only each session's own rendered transcript/pane output was available, so root-causing beyond "the retry/relay path over the Remote Control bridge appears to mis-route or loop a message back to its origin" isn't possible from the client side.
• Happy to provide more specifics (approximate timestamps, session/bridge IDs) via follow-up if useful — omitted here since they're only meaningful internally.