2.1.229 Windows: cross-session message now delivers but immediately freezes the recipient session (zero output until watchdog) — regression persists from 2.1.227 #86557

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   platform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows

   area:desktop

   area:agent-viewclaude agents TUI / --bg / FleetView / daemon bg sessionsclaude agents TUI / --bg / FleetView / daemon bg sessions

   regression

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   on Aug 14, 2026
2. arthurmoraesfernandes-afk commented on Aug 14, 2026

   

   arthurmoraesfernandes-afk

   on Aug 14, 2026

   More actions

   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. Post-2.1.228 delivery success shifting to freeze-on-arrival is consistent with the hold moving further down the same pipeline.
3. knkryo commented on Aug 14, 2026

   

   knkryo

   on Aug 14, 2026

   More actions

   Independent reproduction on 2.1.229 with an older desktop app build (1.28929.0), plus a mechanism-level detail that I think points at the shared root cause with #74017.

   What differs from the report above

   In our case the message never reaches the model at all, even though the recipient UI renders the cross-session-message block.

   We verified this from the sending side, without relying on a human watching the screen: mcp__ccd_session_mgmt__list_events reads the recipient's transcript, and our messages are absent from it while the chip is visibly rendered in the recipient window. So on this build the axis is not "delivered then frozen" — it is "rendered but never injected into the transcript", with the recipient then wedged.

   list_events seems worth adding to the repro steps generally: it separates "rendered" from "delivered" without a second operator, which neither the sender's success string nor the recipient's UI can do.

   Result

   0 of 4 messages delivered, both directions, between two local sessions on the same machine and OS user.

   Direction	Sent	Present in recipient transcript
   A → B	2	0
   B → A	2	0

   Sender received Message queued for session local_… ; it will be processed after the in-flight turn finishes if that session stays healthy every time.

   Environment

   • Windows 11 Pro 10.0.26200, native (not WSL)
   • Claude Code desktop app 1.28929.0 (Store/MSIX) — note this is older than the 1.30096.0.0 in the report above
   • Bundled runtime 2.1.229, auto-updated 2026-08-14 11:34:56 local (from 2.1.227, installed 2026-08-13 11:31:32)
   • Runtime path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\2.1.229\claude.exe
     (on MSIX installs there is no Claude folder under %APPDATA%, which makes the usual log/runtime paths in other reports misleading)
   • CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_TELEMETRY, DO_NOT_TRACK, DISABLE_GROWTHBOOK all unset

   Log signature

   11:39:58 [info] [LocalSessionManager] drained 1 deferred send(s) for local_d8d9f4ec-…
   11:39:58 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_d8d9f4ec-…
            { resultUuid: '7a94eb22-…', pendingEchoUuids: [ '894b579c-…' ],
              nextCycleUuid: null, hasPendingCycle: true, inputStreamHasPending: false }
   11:43:03 [info] LocalSessions.interrupt: sessionId=local_d8d9f4ec-…
   11:43:03 [info] [CCD CycleHealth] healthy cycle for local_d8d9f4ec-… (185s, hadFirstResponse=false)
   11:43:10 [warn] [LocalSessionManager] reaped 1 stale pendingEchoUuids for local_d8d9f4ec-…
            — CLI dropped the isReplay echo { reaped: [ '894b579c-…' ], remaining: [], remainingCount: 0 }
   

   The second send (11:47:53, uuid ffbc4fb7-…) produced an identical sequence.

   This looks like the same root cause as #74017

   #74017 (macOS, app 1.18286.0, runtime 2.1.197) describes a manual /compact wedging a session, with this root cause:

   the app defers a send when the session is still "running", and drains it at the turn result. The drained send is echo-tracked by the uuid the app assigned. But when that send is a local slash command, the CLI writes the command message to the transcript with a different uuid, so the echo the app waits for never arrives.

   Our logs show the same drained N deferred send(s) → isRunning held by unechoed input → pendingEchoUuids-never-clears sequence, with a cross-session message as the deferred send instead of a slash command. Different trigger, same echo-tracking failure. If that is right, several of the open cross-session reports (#86012, #86212, #86319, #86386, #86456, this one) may be one bug in the deferred-send echo tracking rather than a cross-session-messaging bug as such.

   What is and isn't new in the logs (regression boundary)

   I checked ~4.5 months of retained logs (main.log … main4.log, back to 2026-03-25) to see whether this machinery is new. It is not — only the reaper is:

   Log line	First seen	Count before 2026-08-13
   drained N deferred send(s)	2026-06-11	1,262
   isRunning held by unechoed input	2026-07-07	1,255
   reaped N stale pendingEchoUuids — CLI dropped the isReplay echo	2026-08-13 13:44:28	0

   So the deferred-send/echo-tracking path predates the regression by months, and the reaped … CLI dropped the isReplay echo warning appears only after runtime 2.1.227 was installed on this machine (2026-08-13 11:31:32, first occurrence 2h13m later). I read that as a reaper added to clean up stale pending echoes, not as the origin of the fault — i.e. the app now detects that the echo never arrived and silently discards the message, which is why the sender never learns the send was lost. I can't tell from logs alone whether the underlying echo mismatch also became more frequent in 2.1.227; I'm only claiming the reaper line is new.

   Workarounds that did NOT work

   Tested deliberately, because #86088 identifies window focus as its determining factor:

   Attempt	Result
   Focus the recipient window before sending	No effect — the recipient was the foreground session for both sends (setFocusedSession confirms it in the log)
   Send only while the recipient is idle	No effect — send #2 went to an idle session and was lost identically
   Esc on the recipient, then type something to nudge it	Clears the spinner, but the held message is discarded, not delivered

   The third one matters for anyone following #86088's suggested workaround: the nudge unwedges the session but does not recover the message, so it looks like it worked while the message is gone.

   Impact

   Same shape as #86275: automation built on the sender's success signal breaks invisibly. We were coordinating work across several sessions and had to fall back to passing files through a shared directory with a human relaying the "go read it" notification by hand. Sender-side list_events polling is the only reliable delivery check we found.

   Happy to provide fuller log extracts or the session ids if useful.
4. codebytere-ant commented on Aug 25, 2026

   

   codebytere-ant

   on Aug 25, 2026

   More actions

   duplicate of #86012
5. codebytere-ant

   closed this as a duplicateof [Regression, Windows+macOS] Cross-session messaging silently broken since CCD 2.1.224+ — messages dropped, recipient sessions wedged 15-20 min (hadFirstResponse=false); fixed in 2.1.237 for some installs, stable channel still affected #86012 on Aug 25, 2026