Environment
- macOS (Darwin 25.5.0), Claude Desktop app 1.28929.0 (auto-updated from 1.26832.0 on Aug 11–12), bundled Claude Code engine 2.1.227, standalone CLI 2.1.220
- Many concurrent sessions in the desktop app, heavy use of inter-session messaging
Symptom
Turns that are started without a human typing in the focused window — i.e. (a) turns triggered by an inter-session message, or (b) turns that require waking a session previously paused by idle timeout — intermittently produce no first token at all. The spinner runs until the health watchdog logs:
[CCD CycleHealth] unhealthy cycle for local_… (980s, hadFirstResponse=false, reason=no_response)
Human-typed turns in a focused session almost always work. A Mac restart did not help; an app restart clears it only temporarily.
Measurements (from ~/Library/Logs/Claude/main.log, frozen copy, Asia/Seoul time)
- 70
no_response rows across 29 sessions between Aug 12 11:16 and Aug 13 19:29. The three previous log files (Jul 30 – Aug 11, main1/2/3.log) contain 1 such row in total.
- Session-resume correlation: of 34
Resuming session events in the affected window, 19 (56%) fall within ±60s of a stall start (stall start = watchdog time minus reported duration). The older logs contain 412 resume events with at most 1 no_response row total (upper bound ≈0.2%, measured with a coarser method). The pause/resume lifecycle itself existed in older versions.
- 43 of the 70 stalls had an inter-session
Sending message to session delivery within −60s/+180s of stall start. Total deliveries were ~220/day and most were processed fine — the failure is intermittent (confirmed lower bound ~10% of deliveries).
- Example trace (one session, sanitized):
11:02:43 [WarmLifecycle:session] Idle timeout reached, disconnecting local_…
11:02:43 [CCD] Pausing session local_… (idle_timeout)
11:07:31 Resuming session local_… / Starting local session / Loaded 137 transcript messages
(no start-timing, no output)
11:23:46 [CCD CycleHealth] unhealthy cycle for local_… (976s, hadFirstResponse=false, reason=no_response)
- Stalled turns never log a
[CCD start-timing] entry, so we cannot tell from the client side whether the query failed to start or the first response never arrived.
Confounders we could not separate
- An account re-login happened on the same day as the auto-update.
- The Aug 12 "degraded performance for multiple models" incident (status.claude.com) overlaps only 6 of the 70 stalls by start time; the rest are outside that window.
Workaround
Pressing Esc and re-typing the prompt as a human turn recovers the session. Re-sending the inter-session message does not.
Related
Similar but not identical to #40462 (that one reports mid-turn stalls with no timeout, revived by any new message; ours never starts the turn and is killed by the watchdog).
Happy to provide sanitized log excerpts on request.
Environment
Symptom
Turns that are started without a human typing in the focused window — i.e. (a) turns triggered by an inter-session message, or (b) turns that require waking a session previously paused by idle timeout — intermittently produce no first token at all. The spinner runs until the health watchdog logs:
Human-typed turns in a focused session almost always work. A Mac restart did not help; an app restart clears it only temporarily.
Measurements (from
~/Library/Logs/Claude/main.log, frozen copy, Asia/Seoul time)no_responserows across 29 sessions between Aug 12 11:16 and Aug 13 19:29. The three previous log files (Jul 30 – Aug 11, main1/2/3.log) contain 1 such row in total.Resuming sessionevents in the affected window, 19 (56%) fall within ±60s of a stall start (stall start = watchdog time minus reported duration). The older logs contain 412 resume events with at most 1 no_response row total (upper bound ≈0.2%, measured with a coarser method). The pause/resume lifecycle itself existed in older versions.Sending message to sessiondelivery within −60s/+180s of stall start. Total deliveries were ~220/day and most were processed fine — the failure is intermittent (confirmed lower bound ~10% of deliveries).[CCD start-timing]entry, so we cannot tell from the client side whether the query failed to start or the first response never arrived.Confounders we could not separate
Workaround
Pressing Esc and re-typing the prompt as a human turn recovers the session. Re-sending the inter-session message does not.
Related
Similar but not identical to #40462 (that one reports mid-turn stalls with no timeout, revived by any new message; ours never starts the turn and is killed by the watchdog).
Happy to provide sanitized log excerpts on request.