[BUG] Desktop app: cross-session messages render in target session's UI but never reach the runtime input queue (regression 2.1.222 -> 2.1.227)

Likely-fix correlation from the changelog, for triage:

2.1.228 lists "Fixed cross-session messaging sometimes starting without an inbox in the first session after install." That matches the forensics above precisely: the broken runtime (2.1.227) was auto-installed at 15:39 on 12 Aug, every affected session was among the first after that install, and a session with no inbox is exactly one where messages render in the UI but produce no queue-operation entry and never reach the model. 2.1.225's "parked without a notice or expiry" fix and 2.1.229's display improvements sit in the same area.

Current state on the affected machine: the desktop app is at its latest published version (1.28929.0.0, confirmed via winget, no upgrade available) and it pins bundled runtime 2.1.227, so the 2.1.228 fix cannot be obtained on the desktop channel yet. Standalone CLI 2.1.229 on the same machine is unaffected either way (native Windows has no CLI cross-session messaging).

Will re-test the moment a desktop release ships a bundled runtime >= 2.1.228 and report pass/fail here. If the inbox fix is confirmed, this issue can likely be closed against that change.

Confirming same reproduction — Desktop app 1.28929.0 / runtime 2.1.227 on Windows 11

Seeing the exact behavior described here. Same environment as the original report:

Desktop app: 1.28929.0
Claude Code runtime: 2.1.227 (auto-updated; was working before)
OS: Windows 11
Auth: claude.ai subscription

Symptom: Cross-session send_message reports success on the sender side, and the message renders in the recipient session's UI, but the recipient runtime/model never receives it — no new turn is created, the session just sits idle and acts as if nothing arrived. As a human I can see the message in the recipient window, but the session doesn't know it got one.

What I've confirmed matches the report:

Sender gets a success/"message sent" response.
Message text is visible inline in the recipient's conversation UI.
Recipient never starts a turn and never replies.
Typing any text directly into the recipient session works normally, but the already-rendered cross-session message is never processed even after that.

This is a regression — cross-session messaging worked before the 2.1.227 auto-update. It breaks all unattended multi-session coordination on Windows, and the silent "success" on the sender side makes it especially hard to detect.

Happy to provide transcripts or additional details if useful. +1 on prioritizing a fix (or at minimum returning an explicit error instead of a false success).

Same regression here, with an additional symptom that makes it costlier than reported.

Environment

• Windows 11 Home 10.0.26200
• Desktop app 1.28929.0
• Runtime 2.1.222 (working, installed Aug 7) → 2.1.227 (auto-installed Aug 12, 11:14 local)
• Tool: mcp__ccd_session_mgmt__send_message, desktop-to-desktop sessions

Additional symptom: the recipient DOES start a turn, and burns tokens with no message

Both this issue and #86212 report that the recipient never acts. In our case the recipient session wakes up and consumes a turn without receiving anything:

07:35:0x  send_message -> "Message sent to session ..."   (recipient was idle)
07:35:16  recipient session isRunning = true              <- 16s later, a turn started
          the message card is rendered in its UI
          the model never receives the content and produces nothing useful

So the wake-up signal reaches the runtime but the message body does not. Unattended, this is the expensive failure mode: a session can sit consuming tokens with nobody watching. There is a public report of a session idling 11.3 hours before a human intervened (#78338).

Also observed, matching this issue exactly

• Same two acknowledgement strings, verbatim: "Message queued for session ...; it will be processed after the in-flight turn finishes if that session stays healthy" when the target is mid-turn, and "Message sent to session ..." when idle.
• Messages acknowledged as queued are lost if either session is cleared or restarted before processing.
• The recipient's .jsonl never records cross-session messages, so the transcript cannot be used to verify delivery.

Downgrade note

We tried reverting to 2.1.222 by renaming the 2.1.227 directory under %APPDATA%\Claude\claude-code\. On restart the updater re-downloaded 2.1.227 and removed both the renamed folder and the 2.1.222 install. We could not find a local setting to pin the runtime version or disable auto-update, so the published workaround is not reachable from the desktop app.

Card renders / model never sees it — #86298 documents the same failure chain with root-cause analysis (Windows desktop, regression at app 1.28929.0 / bundled CLI 2.1.227, still present on app 1.30096.1.0 / CLI 2.1.229): the desktop bridge sends the message with a class-less origin:{kind:'peer'}, the recipient CLI/SDK's cross-session consent gate holds it for an approval no desktop surface offers, and dialogExpiry (~5 min) then drops it — while the sender keeps a success receipt. A memory-dump repro in that thread shows the payload reaching the recipient CLI process but never its transcript. Setting crossSessionInbound: "accept" in user settings does not unblock it (tested on running, cold-started, and post-restart fresh sessions).

Update on the 2.1.228 inbox-fix hypothesis — it already shipped here, and the failure persists.

@mouarg — no need to wait for a desktop release with bundled runtime >= 2.1.228. This machine now has it:

desktop app         1.30096.1
bundled runtime     2.1.229
runtime directory   %APPDATA%\Claude\claude-code\2.1.229, created Aug 13 18:50 local

So the 2.1.228 fix ("cross-session messaging sometimes starting without an inbox in the first session after install") is present, and the behavior is unchanged.

Re-tested today on 2.1.229: 9 messages to 4 different sessions — including sessions created after the new runtime was installed, so not "the first session after install" in any sense. Zero delivered, zero written to any recipient transcript.

Verified by parsing ~/.claude/projects/<project>/*.jsonl and counting only real inbound <cross-session-message from=...> tags inside type: "user" turns:

1,945  inbound messages written to transcripts, historically
last:  2026-08-12T02:40:42Z
after: zero

Also negative on 2.1.229, for triage: app restart · app update/restore · recipient in permissionMode: "default" (verified in its transcript as auto -> auto -> default before testing) · crossSessionInbound: "accept" set before the session started · a bare working directory with no CLAUDE.md, hooks, or local settings.

⚠️ One methodology note that cost me hours: list_events renders the message for the recipient session even though it never reaches that session's transcript on disk, so it cannot be used to verify delivery. And a plain grep for cross-session-message gives false positives, because the sender's transcript also contains the message text — you have to parse the JSON and require a type: "user" turn.

Fuller write-up of the root-cause chain and the confounds I could not rule out locally is in #86298.