[BUG] Windows Desktop: cross-session send_message reports success and renders in the target UI, but is never enqueued/persisted (ghost delivery, lost on restart)

Summary

Cross-session send_message between local sessions on Windows Desktop silently fails: the sender gets a success result and the message renders in the target session's UI and in the session-management transcript reader, but it is never written to the target's real transcript (.jsonl) and never reaches the model. Messages vanish on app restart. Receiving sessions intermittently freeze on a phantom turn (spinner, no output).

Likely related to #86671 (enqueue bypass, regression between CLI 2.1.222–2.1.227) and #87286 — filing separately per maintainer triage preference, with an independent reproduction and additional rule-outs.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop app 1.32352.0 (Squirrel, %LOCALAPPDATA%\AnthropicClaude) — also reproduced on 1.30096.5
• App-bundled CLI 2.1.229 (%APPDATA%\Claude\claude-code\2.1.229)
• npm-global CLI 2.1.234 (not used by app sessions)
• All sessions local, same machine/user, model claude-fable-5 / claude-opus-5

Steps to reproduce (marker method)

1. From session A, call mcp__ccd_session_mgmt__send_message targeting an idle local session B, with a unique marker string in the body (e.g. MARKER-XSM-20260818-0900).
2. Tool returns success (Message sent to session ...).
3. Poll session B's real transcript ~/.claude/projects/<projDir>/<cliSessionId>.jsonl for the marker.

Expected: marker appears as a user turn; session B processes it.
Actual: 0 occurrences after 2+ minutes, on every attempt (6+ sends, across app restarts and an app update).

Evidence collected

• Ghost rendering / false-positive delivery: the session-management transcript reader (list_events) shows the message wrapped in <cross-session-message> tags, while grep over the actual .jsonl finds 0 occurrences. Every delivery that "looked" successful via the reader was absent from disk.
• File-level confirmation: target transcript mtime stays frozen across the send (e.g. message "delivered" at 22:55:56Z while the target .jsonl last write remained 22:54:28Z).
• Restart data loss: all pending "delivered" messages disappeared after a full app restart — consistent with never having been persisted.
• Phantom turn freeze: receiving sessions intermittently show a spinner with no output for 5–8+ minutes, transcript mtime frozen, [result] error records visible after recovery; isRunning=true / lastActivityAt frozen during the hang.

Rule-outs

• "crossSessionInbound": "accept" in global ~/.claude/settings.json does not change the behavior — the failure is below the v2.1.232 inbound accept/hold policy layer.
• Not fixed by updating the app 1.30096.5 → 1.32352.0 (bundled CLI stayed 2.1.229).
• Not a permission-mode parity hold: messages never expire-drop into a denial report; they simply never reach the queue.
• Terminal-CLI sessions are not a workaround: sessions resumed via claude --resume don't get the session-management MCP server at all (app-only), so they can neither send nor receive.

Impact

Cross-session coordination (supervisor/worker patterns) is non-functional on Windows Desktop; the human must manually relay messages. Failures are silent — sender-side success + ghost rendering on the receiver produce false-positive delivery confirmations, which is worse than a hard error.

Workaround in use

File-based channel (ORDERS/STATUS.md files) between sessions + manual session wake-up by the user.