[BUG] Windows desktop (MSIX): cross-session send_message payloads silently lost — never reach the warm CLI process (regression since app 1.28929, still broken in 1.32352)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Since desktop app 1.28929 (Windows MSIX / Microsoft Store), cross-session messaging between
Claude Code sessions (mcp__ccd_session_mgmt__send_message) is broken: the payload NEVER reaches
the target session's warm CLI process.

• The message appears in the target's transcript view (app-side buffer) — looks delivered.
• The target's UI shows a "thinking" spinner forever (isRunning=true), but the CLI process never

reacts: no user-message append to its .jsonl (mtime frozen), no assistant turn, no error.

• main.log shows Sending message to session <id> with NO subsequent

Mapping internal session <id> to CLI session <uuid> (healthy sends map within ~1s).

• In 1.32352 the held message is logged as a "held steer" and flushed ~30s after the next DIRECT

user turn in the target session (flushed held steers). The flush clears the phantom spinner
and the session recovers — but the flushed payload STILL never arrives. Deferred sends drained
at turn end are dropped too (isRunning held by unechoed input → ~10 min later
reaped N stale pendingEchoUuids — CLI dropped the isReplay echo).

• Direct user messages can silently stall behind such a phantom turn: a 354-char user message

got no Mapping for 8 minutes and was delivered only after two intervening turns. To the user
this looks like the assistant ignoring them.

• An app restart deletes all unprocessed/queued messages without a trace, while the sender keeps

its "Message sent/queued" success receipts.

Measured broken on 1.28929.0.0, 1.30096.0.0 and 1.32352.1.0; app 1.24012.11.0 (2026-08-04) was
NOT affected. The CLI itself is exonerated: the exact same binary run standalone with the app's
exact argument list (incl. --input-format stream-json --replay-user-messages, same cwd/settings/
plugins) consumes a message injected into stdin 12s after turn end within 200ms. The failure is
in the app layer that writes into the warm process (input queue enqueued, consumer/pump appears
dead after a completed turn).

Any coordinator/worker multi-session orchestration breaks: recipients look "delivered" but never
process, retries queue behind a phantom turn, restarts destroy the queue silently.

What Should Happen?

The message reaches the target session's CLI process and triggers a processing turn — or, if
delivery is impossible, the sender gets an error instead of a success receipt. No silent loss.

Error Messages/Logs

Steps to Reproduce

1. Create session B in a project dir, let its first turn complete; keep it idle (warm CLI process).
2. From session A call send_message targeting B.
3. Observe: B spins forever, B's .jsonl never receives the message, main.log shows

Sending message with no subsequent Mapping internal session.

1. Type a direct message into B: ~30s later main.log logs flushed held steers, B recovers and

processes ONLY the direct message — the send_message payload is gone.

1. Alternatively restart the app: the pending message disappears from B without a trace.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

version pre 1.28929

Claude Code Version

1.32352

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

App: Claude Desktop for Windows 1.32352.1.0 (MSIX / Microsoft Store); also reproduced on
1.28929.0.0 and 1.30096.0.0. Last good: 1.24012.11.0.
Bundled CLI: 2.1.227 / 2.1.229. OS: Windows 11 Pro 10.0.26200.
Additional evidence: target CLI process Win32_Process ReadTransferCount delta = 0 bytes across
the send (bytes never reach stdin); recurring log lines reaped N stale pendingEchoUuids — CLI
dropped the isReplay echo, isRunning held by unechoed input at result, drained N deferred
send(s).
Workaround we use: file-based mailboxes + background-task notifications (task notifications are
unaffected by the bug), so this is diagnosable but painful for any multi-session setup.