Repository navigation
[BUG] Desktop app: turns triggered by cross-session messages hang at 0 tokens (manual prompts work) #86386
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
Environment: Claude Code desktop app on Windows 11 Pro (build 26200), Claude Code
version 2.1.212, multiple local sessions in the same project folder (D:\Vexalia),
subscription plan (Max).
When one local session sends a message to another via the built-in cross-session
messaging (send_message), the receiving session's turn starts automatically
(spinner shows, session state = running) but hangs forever: 5+ minutes observed,
zero tokens spent, nothing appended to the receiving session's transcript.
Typing a manual prompt into the same receiving session works normally, and it then
also processes the queued cross-session message correctly.
This worked before the desktop app auto-update on 2026-08-12: sessions replied to
each other's messages automatically with no human intervention.
What Should Happen?
A turn triggered by an incoming cross-session message should run exactly like a
manually typed prompt: call the model, spend tokens, and produce a reply.
Error Messages/Logs
No error is shown anywhere. The spinner just runs indefinitely at zero tokens.
Nothing is appended to the receiving session's transcript file while stuck.Steps to Reproduce
I run multiple local Claude Code sessions in the same project folder (a PM session
coordinating specialist sessions). Sessions message each other via the built-in
cross-session messaging (send_message).
Steps:
- Session A sends a message to Session B via send_message. Session B's process is
awake (its chat is open and it had just completed a manual turn successfully). - Session B's turn starts automatically (spinner shows, session state = running).
- The turn hangs forever: 5+ minutes observed, ZERO tokens spent, nothing written
to the session's transcript (.jsonl). - Stopping the spinner and typing any manual prompt into Session B works normally,
and it then also processes the queued cross-session message correctly.
This worked before the desktop app update on 2026-08-12: sessions replied to each
other's messages automatically with no human intervention.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown exact number — whatever version was current until 2026-08-12 (auto-updated that day; the hang started right after).
Claude Code Version
2.1.212 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
No response
Activity
BaltaKid commentedon Aug 14, 2026
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:
Manager) and set power mode to Best Performance — no change.
bug reproduced; small manual prompts in the SAME sessions go through fine,
so it is not payload size or connectivity.
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.
BaltaKid commentedon Aug 14, 2026
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.
BaltaKid commentedon Aug 14, 2026
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:
1.30096.1.02.1.2322.1.229The live Desktop child process confirms this directly:
C:\Users\Admin\AppData\Roaming\Claude\claude-code\2.1.229\claude.exeand the Desktop log contains:
[CCD] Initialized with version 2.1.229[CCD-autoupdate] Disabled: MSIX installSo this bug is still reproducible with Desktop's bundled 2.1.229, not only with the older
2.1.212version I originally reported.I also tested the receiving side more closely:
ProjectManagersends a message viamcp__ccd_session_mgmt__send_message..in that same chat. This did not unstick the cross-session turn.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.0and its bundled runtimes remained2.1.227/2.1.229, so the standalone2.1.232CLI 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_messagesuccess versus the missing receiving-side turn.arthurmoraesfernandes-afk commentedon Aug 14, 2026
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 apriority=nextsend (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.codebytere-ant commentedon Aug 25, 2026
duplicate of #86012