[BUG] Desktop app: turns started by session resume or inter-session message hang with no first token, watchdog kills after ~980s (no_response) — spiked after auto-update 1.26832.0 → 1.28929.0

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.