Cross-session messages silently lost on Windows desktop app (no 'Mapping internal session' after 'Sending message'; infinite spinner on idle targets)

Environment

• Claude desktop app (Windows), MSIX package Claude_1.30096.1.0_x64__pzs8sxrjxfjjc
• Windows 11 Pro 10.0.26200
• Bundled CLI engines observed: 2.1.227 and 2.1.229 (%APPDATA%\Claude\claude-code\<ver>\claude.exe, MSIX-virtualized)
• Cross-session messaging via the desktop app's session-management MCP (mcp__ccd_session_mgmt__send_message)

Summary

On 2026-08-14, all 4 cross-session message deliveries on this machine were silently lost — both directions, targets both active and idle. The sender's tool call returns success and the message card renders in the target window's UI, but the message never reaches the target session's engine: the target transcript (~/.claude/projects/<proj>/<session>.jsonl) receives zero bytes.

• Idle target: the target window shows an infinite spinner (observed 10+ minutes, at 5m24s and 10m28s) with zero transcript writes and no new process spawned. Esc discards the turn; the message is never redelivered.
• Active target: completely silent loss — no spinner, no card behavior difference, nothing in the transcript. The receiving session (and its user) have no way to know a message was sent.

No error is logged anywhere. Cross-session messaging on this same machine worked on 2026-08-10 and 2026-08-11 (multiple documented round-trips).

Evidence (app main.log)

Success signature for app→engine injection (typed messages, task notifications — observed working all day):

2026-08-14 13:55:59 [info] LocalSessions.sendMessage: sessionId=local_6e9b67d4-..., messageLength=..., priority=next
2026-08-14 13:55:59 [info] Sending message to session local_6e9b67d4-...
2026-08-14 13:55:59 [info] Mapping internal session local_6e9b67d4-... to CLI session b65c41db-...
→ turn starts, transcript written

The four lost cross-session sends (no LocalSessions.sendMessage prefix — expected for the MCP path) all stop after Sending message, and no Mapping internal session line ever follows (verified: next 5+ lines are unrelated interval noise; target transcripts confirmed untouched):

2026-08-14 11:42:59 [info] Sending message to session local_6e9b67d4-...   ← to ACTIVE session, intact workspace — lost
2026-08-14 11:44:03 [info] Sending message to session local_6e9b67d4-...   ← to ACTIVE session, intact workspace — lost
2026-08-14 13:10:48 [info] Sending message to session local_af30fc74-...   ← to IDLE session — lost, infinite spinner
2026-08-14 13:52:37 [info] Sending message to session local_af30fc74-...   ← to IDLE session — lost, infinite spinner

All other Sending message to session lines that day (user-typed messages, 18+ spot-checked) have an adjacent Mapping line. The sole additional Mapping-less line is itself a casualty of the stuck delivery: a user-typed message queued behind one of the stuck spinner turns (13:13:07 ... priority=next) that the user manually cancelled 14 seconds later (13:13:21 LocalSessions.cancelQueuedMessage).

Regression window

• 2026-08-10 / 08-11: cross-session round-trips worked repeatedly on this machine (same app usage pattern).
• 2026-08-14 11:42:16: main.log records [CCD] Initialized with version 2.1.229 (secondary instance bounce: "Not main instance, returning early"). 43 seconds later (11:42:59) the first delivery was lost. Engines running at failure time: 2.1.227 (spawned 10:09, target of the first two losses) and 2.1.229 (spawned 10:30, target of the last two) — losses hit both engine versions, suggesting the break is in the app-side delivery pipeline rather than the engine.

Post-restart retest — restart does NOT fix it

Fully restarted the desktop app at 14:26:31 (all engines respawned 14:26:45 / 14:27:06, both now 2.1.229, correct --resume). Then:

• Control (typed message into the target window, 14:26:58): Sending message + Mapping internal session → CLI session logged in the same second; target processed the turn normally (transcript written).
• Cross-session send (14:31:09, tagged PING-20260814-1431): Sending message logged, no Mapping line after 2+ minutes, target transcript polled every 5s for 3 minutes — the ping never appears. Target window again shows the infinite spinner.

Same failure signature after a clean restart → deterministic regression in the current app/CLI version, not stale state.

Expected behavior

Either deliver the message as a user turn in the target session (as on 08-10/11), or surface an explicit delivery error to the sender/UI. Never: success-shaped send + rendered card + infinite spinner + silent loss with no timeout and no redelivery.

Notes

• Official docs state CLI cross-session messaging (socket-based SendMessage) is not offered on native Windows. The desktop app's own session-management channel, however, demonstrably delivered on 08-10/11 on this machine — if the app recently unified onto the socket path on Windows, that would explain the regression and the silent failure mode.
• Happy to provide fuller log excerpts on request.