[Bug] Cross-session SendMessage to native-Windows silently fails to ingest despite success response
Bug Description
Title: Cross-session SendMessage to a native-Windows session silently no-ops — success:true + identical Remote Control echo, but the message is never ingested
Environment: Sender: Claude Code 2.1.233, macOS. Target: native-Windows Claude Code session connected via Remote Control (same account). Control peer: macOS Claude 2.1.234, also via Remote Control.
What happens
- SendMessage to the native-Windows Remote-Control session returns success:true.
- The message renders on the Remote Control web/mobile view of that Windows session — identically to the working macOS case.
- But the native-Windows local session never ingests it: it doesn't appear in the local terminal transcript, no turn starts, no action, session stays idle. Repeatable across multiple sends.
- Control: the same send to a macOS peer delivers, is ingested, and the peer replies. And the inbound message shows on the RC view in both cases.
Root cause (likely): cross-session local ingestion is macOS/Linux-only (Unix /tmp socket inbox); native Windows lacks that local inbox path, but the Remote Control relay/display path is platform-agnostic — so the message is displayed but never delivered locally. (Note: Windows has supported AF_UNIX since 2018, so this is an implementation gap, not an OS limitation.)
Why this is a footgun (the actual issue): there is no signal distinguishing "delivered to a session that will ingest it" from "displayed but will never be ingested." Both the sender's success:true and the RC echo look identical to the working case. A user reasonably concludes the message was delivered when the target Claude will never see it — a silent, success-looking failure.
Suggested fixes (any one helps)
- Have SendMessage distinguish "queued to relay" vs "delivered to an ingest-capable session," and warn/error when the target can't ingest (e.g., native Windows).
- Mark un-ingestable inbound messages in the Remote Control view ("this session can't process cross-session messages").
- At minimum, warn at send time when the recipient is a native-Windows session.
- Best of all: add the cross-agent messaging feature to native Windows!
Environment Info
- Platform: darwin
- Terminal: Apple_Terminal
- Version: 2.1.227
- Feedback ID: 9ab6835e-5563-44af-9792-e684f3f17a8c
Errors
[]Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Thanks for the report. Following up on the "sender says success, recipient refused" mismatch: a fix is up for review that (1) makes a refused cross-session message report back to the sender as refused (with the reason) instead of appearing sent, and (2) makes
ListAgentsand Remote Control mark a session that cannot currently receive cross-session messages, and refuse the send up front rather than posting into the void. It will note here once it lands and which release carries it. Separately, the Windows-side rollout that caused most of these "refused" results is being enabled independently of the code fix.Independent reproduction with a Windows sender (not macOS), so this is not sender-platform-specific — the determining factor is the Windows Remote Control
target.
Windows 11, both sessions same account/project, target listed by ListAgents as
Remote Control. ~14 sends over ~5 hours, every one returning success + msg id.Transcript-level confirmation, which may help verification: the recipient's JSONL contains zero occurrences of
from-name=(the marker every delivered envelope carries), and text unique to the sent messages appears only in the sender's transcript. On the remote control season in the app the message appears. The recipient, asked directly, reported "nothing has arrived." Even when challenged to look for it, and shown screen shots, nothing.Impact worth noting for prioritisation: this was an agent review pairing. The reviewing agent believed ~14 directives were delivered; the working agent acted only on items that happened to also be written to a shared file, and sat idle with an empty queue while correctness work went unrequested. Because every send reports success, no fallback can trigger. The proposed "refuse up front" fix would have caught this in the first minute.
Confirmed fixed as of Claude Code 2.1.263 — native Windows now receives cross-session messages (no WSL2).
Original reporter here. Verified live today (2026-09-08) with a full bidirectional round-trip:
SendMessagefrom the Mac was ingested in-session on the Windows side and replied to; the reply landed back on the Mac. Repeatable across multiple sends this session, both directions.2026-09-08 14:46:55 EDT), confirming the message was received and acted on natively.This matches the note above that the Windows-side receive rollout was being enabled independently of the code fix — it has evidently shipped. From my end this can be closed as fixed, unless you're holding it open to track the sender-side "report refused instead of phantom success" / "refuse up front" changes separately.