MCP-originated cross-session sends (`ccd_session_mgmt send_message`) never deliver — payload lost in app layer; receiving session UI hangs on "phantom" turn

Environment: Windows 11 Home 26200, Claude Desktop app 1.28929.0
(MSIX, SignatureKind: Developer), managed CLI 2.1.227 (standalone CLI
2.1.229 also installed), Max subscription. Reproduces across app
restart, full process kill, and reinstall-over-top of the same build.
Also reproduced on a second machine that had never run Claude
(Windows 11 Pro 26200, same app 1.28929.0, CCD 2.1.227 — see clean-room
section below).

Summary: Calling mcp__ccd_session_mgmt__send_message from one
local session to another reports success to the sender, and the message
text is visible in the target's transcript viewer, but the payload is
never delivered to the target's CLI/model. The app opens a turn cycle
for the target that never starts (hadFirstResponse=false indefinitely);
the UI shows an endless spinner; Esc/"Stopping" also hangs (it is
interrupting a turn that never began). 7/7 attempts failed on the
original machine across three target states, plus 2/2 on the clean
machine.

Discriminating log signature (main.log, under the MSIX LocalCache
path): a healthy UI-typed send logs
LocalSessions.checkTrust → LocalSessions.sendMessage → Sending
message to session … → Mapping internal session … to CLI session …
within ~2s, then queue-operation: enqueue in the target transcript.
Every MCP-originated send logs only the bare
Sending message to session … line — no sendMessage, no mapping, no
enqueue, ever. The payload dies in the app's MCP-handler layer before
the session-manager delivery path.

Receiver state is irrelevant (controlled experiment): failures
reproduced against (a) cold resume — CLI spawned, 698-message
transcript loaded, then 983s of silence to app timeout; (b) warm-idle —
healthy turn completed 27s before the send; (c) actively mid-turn —
target was running a 75s tool loop when the send fired (22:55:00);
send died identically while the target kept working normally.

Deferred-queue variant: one attempt entered a deferred-send queue
behind a held=true steering flag that never released (245s); a
subsequent UI-typed message (sendSteeredNow, priority=next)
force-drained the queue — log line drained 1 deferred send(s) — but
the drained payload was still never enqueued: the drain path loses
the message.

Regression evidence (partial): an MCP-originated send was
successfully absorbed by its target earlier the same day on app
1.26832 (receipt: the target's response quoted content unique to the
message), and one logged successful delivery exists on 1.22209.3
(2026-07-19). All failures are on 1.28929.0. Caveat: the path was
rarely exercised before, and a same-day environment audit
(second CLI install, experimental agent-teams flag, new plugins) is
documented in the source reports. Environment fully exonerated
(2026-08-13): reproduced on (a) a fresh Windows profile on the
original machine, (b) a SECOND machine that had never run Claude, on
BOTH the original account and a different account, with a fresh
~/.claude + re-login between account passes (log excerpts below).

Clean-room reproduction — second machine (2026-08-13): a laptop
that had never run Claude (Windows 11 Pro 26200, app 1.28929.0, CCD
2.1.227, no plugins, no settings changes) reproduced the bug on the
FIRST attempt on both accounts. Same three symptoms each time: sender
gets a success result, message appears in the target's transcript
viewer as a user turn, target's model is never invoked (automated
watcher on the target's on-disk jsonl found no assistant turn in 95s;
list_events minutes later still shows the target "running" with the
cross-session message as the final entry).

*Test 1 (account 1), send at 11:56:08 local — main.log lines
864–870:*

2026-08-13 11:55:58 [info] LocalSessions.sendMessage: sessionId=local_8f483e0e-3c97-48ef-8b14-ec9d780fdb20, messageLength=30, imageCount=0, toolStates=0, attachmentCount=0, priority=(default)
2026-08-13 11:55:58 [info] Sending message to session local_8f483e0e-3c97-48ef-8b14-ec9d780fdb20
2026-08-13 11:55:58 [info] Mapping internal session local_8f483e0e-3c97-48ef-8b14-ec9d780fdb20 to CLI session 3d987206-7ff7-4f48-8693-41973d2d5c8d
2026-08-13 11:56:08 [info] Sending message to session local_9dc604a7-9270-4509-b521-b551088edea0
2026-08-13 11:56:13 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-08-13 11:56:13 [info] [WarmLifecycle:preview] Warming up session local_9dc604a7-9270-4509-b521-b551088edea0
2026-08-13 11:56:13 [info] [oauth-v2] lookup orgId=d9054120-eb8d-4436-a751-45624608262f cacheKey=...

The 11:55:58 lines are the healthy path (UI-typed send to the sender
session): sendMessage → Sending message → mapping in the same
second. The 11:56:08 MCP-originated send to the target is the bare
Sending message line — no Mapping internal session
local_9dc604a7… follows, not within 2s, not anywhere in the
subsequent ~50s of log. The mapping data itself exists: the target
was mapped at startup (line 791, 11:55:12 —
Mapping internal session local_9dc604a7-9270-4509-b521-b551088edea0
to CLI session dcdb62ad-96b3-4740-b215-114e18d3b029). The send path
fails to perform/complete the lookup; the data is not missing.

*Test 2 (different account, after logout → login and a fresh
~/.claude — new orgId confirmed in all subsequent authenticated
activity), send at 12:12:23 — main.log lines 2198–2204:*

}
2026-08-13 12:12:22 [info] LocalSessions.startShellPty: sessionId=local_4b667cbd-23b0-43be-b8c3-5a2c43b014aa, cols=80, rows=24
2026-08-13 12:12:22 [info] [PluginsFetcher] fetchPluginEnabledState: 1 overrides
2026-08-13 12:12:23 [info] Sending message to session local_4b667cbd-23b0-43be-b8c3-5a2c43b014aa
2026-08-13 12:12:24 [info] [CCD] LocalSessions.setFocusedSession: sessionId=null
2026-08-13 12:12:24 [info] [WarmLifecycle:preview] Warming up session local_f4498c5b-85ab-41e0-b8a7-42e254790273
2026-08-13 12:12:24 [info] [CCD] LocalSessions.setFocusedSession: sessionId=local_f4498c5b-85ab-41e0-b8a7-42e254790273

Identical signature: bare Sending message at 12:12:23, and a grep
from that line to EOF finds ZERO
Mapping internal session local_4b667cbd… hits. The target's
startup mapping exists at line 2168 (12:12:05 —
Mapping internal session local_4b667cbd-23b0-43be-b8c3-5a2c43b014aa
to CLI session 00dfc11c-ee78-4d69-95a4-fa4242941bfe).

Repro: two local Desktop-app sessions; from session A call
mcp__ccd_session_mgmt__send_message targeting session B (any state).
Observe: A gets a success result; B's transcript viewer shows the
message; B's model never receives it; B's UI spins on a turn that never
starts. Log shows the bare Sending message line with no mapping.

Key log excerpts on request: smoking-gun deferred/held trace
(~lines 8850–9030), 983s cold-resume timeout (~4450), mid-turn kill
window (22:54–22:56), CLI EPERM unlink during update (~917).