[BUG] Desktop app: turns triggered by cross-session messages hang at 0 tokens (manual prompts work)

Update after more testing (all on Windows 11 Pro build 26200):

1. Reproduces in 1.30096. The desktop app auto-updated from 1.28929 to
1.30096 and the bug is unchanged: a turn triggered by an incoming
cross-session message starts (spinner, session state = running) and hangs
indefinitely at zero tokens. Observed hangs of 2-5+ minutes before we gave up,
across multiple sessions and two days. Typing a manual prompt into the same
session still works normally, immediately.

2. Ruled out on our side:

• Windows Efficiency Mode: disabled it on all the app's processes (Task

Manager) and set power mode to Best Performance — no change.

• Network: measured ~53 Mbps sustained upload (curl to Cloudflare) while the

bug reproduced; small manual prompts in the SAME sessions go through fine,
so it is not payload size or connectivity.

• Antivirus: the app is on AVG's allowed list — no change.
• Receiving session size: fresh sessions with small context hang exactly like

sessions with 600k+ context, so it is not context pressure.

3. New and worse — the message can be LOST, not just delayed. In at least
one observed case, the message consumed by the hung turn was NOT persisted to
the receiving session's transcript: after the hung spinner ended (app was
closed / spinner stopped, nothing was typed), the message no longer appears
anywhere in that session's history. Earlier the same day, a different session
DID keep the queued message and processed it after a manual prompt — so the
loss seems to depend on how the hung turn ends. Either way, cross-session
messages currently risk silent loss.

4. Timeline anchor: this exact flow worked reliably before the
2026-08-12 auto-update — sessions replied to each other's messages
automatically with no human intervention, all day, for weeks.

Happy to provide transcripts or run a debug build; this blocks multi-session
agent workflows (a coordinator session + specialist sessions in one project
folder) and currently every cross-session message needs a human to open the
receiving chat and type something to unstick it.

Confirmed from the receiving side: when shown the message as a screenshot, the
receiving session states it never saw it at all — so delivery fails entirely,
not just the turn trigger.

Additional diagnostics after the tests above:

I found that the Desktop app is not using the standalone Claude Code installation on PATH.

My current versions are:

• Claude Desktop: 1.30096.1.0
• Standalone Claude Code CLI: 2.1.232
• Claude Code actually spawned by Desktop: 2.1.229

The live Desktop child process confirms this directly:

C:\Users\Admin\AppData\Roaming\Claude\claude-code\2.1.229\claude.exe

and the Desktop log contains:

[CCD] Initialized with version 2.1.229
[CCD-autoupdate] Disabled: MSIX install

So this bug is still reproducible with Desktop's bundled 2.1.229, not only with the older 2.1.212 version I originally reported.

I also tested the receiving side more closely:

1. ProjectManager sends a message via mcp__ccd_session_mgmt__send_message.
2. The receiving chat visibly shows the "Message from ProjectManager" card.
3. The receiving session immediately enters the spinner / running state but produces zero tokens.
4. While it is hung, I manually sent . in that same chat. This did not unstick the cross-session turn.
5. After interrupting the hung turn, the manual turn executed normally.
6. Crucially, the model then explicitly behaved as if the ProjectManager message had never reached its context — it said that nothing had arrived with the manual prompt and that the queue was still empty.

This seems to narrow the failure boundary further:

Desktop UI/event layer receives and renders the cross-session message, but the spawned Claude Code session does not receive/persist it as model input.

That would also explain the silent-loss case reported above: the UI can display the incoming-message card even though the actual Claude Code transcript/context never receives the corresponding user turn.

I also re-ran the official Windows installer over the existing installation. Desktop remained on 1.30096.1.0 and its bundled runtimes remained 2.1.227 / 2.1.229, so the standalone 2.1.232 CLI update does not affect the runtime used by Desktop Code sessions.

If useful, I can provide the relevant Desktop logs, spawned-process command line, session IDs, or a minimal pair of transcripts showing sender-side send_message success versus the missing receiving-side turn.

This looks like the "wedge" mechanism documented in the follow-up comment on #86298, with app-log evidence: an injected cross-session message that the CLI holds (consent gate) gets drained into the CLI at a turn boundary and is never "echoed" back as a user turn; the app then logs isRunning held by unechoed input at result … pendingEchoUuids: […] and treats the session as busy indefinitely — phantom turn, watchdog kills, and the user's own typed prompts queue/stall behind a turn that never ends until a priority=next send (typing another message force-flushes) or a restart reclaims it. The 0-token hang on message-initiated turns while manual prompts work is the phantom-turn state.