[BUG] Claude Desktop (Windows x64) — CCD session watchdog timeout after subprocess goes silent for 80+ minutes, mid-task

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

During an overnight session, a Claude Code task (running inside Claude Desktop) appeared to hang — the UI showed continued activity (pulsing indicator) with no visible progress for an extended period. The app eventually surfaced an error indicating the session had stopped working on the task. Resuming/"nudging" the session recovered it successfully, with no data loss.

main.log shows the underlying mechanism: a CCD (session/query lifecycle) watchdog fired after 994 seconds of inactivity — but the more striking detail is that the underlying subprocess had produced no stderr output for 4,882 seconds, over 81 minutes, before the watchdog gave up. That figure doesn't match the stated 994-second inactivity threshold, suggesting either a subprocess that was stuck far longer than the watchdog's own window implies, or a stderr-monitoring gap that let a stuck process run silently well past when it should have been caught.

This is a single observed occurrence, not an established pattern, and is filed separately from two other Desktop app issues investigated in the same effort (an AppContainer Job leak causing relaunch failures, and a longer-running "freeze-then-vanish" crash signature) because the mechanism is distinct from both: this is a session/query-level timeout with a clean recovery path, not a process crash or a relaunch lock.

What Should Happen?

If a subprocess genuinely stalls, the watchdog should catch it within a timeframe consistent with the timeout value it reports (994s), not let it run silently for over 80 minutes first. At minimum, the user-facing error message should be specific enough to distinguish "your session hung and is being restarted, no data lost" from a generic, alarming failure — the actual wording seen was vague enough that the reporter didn't retain it.

Error Messages/Logs

2026-08-25 01:34:00 [warn] [CCD] Session local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134 timed out after 994s of inactivity 
  (hadFirstResponse=true, last_message_type=assistant, last_tool_name=Edit, seconds_since_stderr=4882, 
   clock_gap_ms_max=none, ms_since_clock_gap=none)
2026-08-25 01:34:00 [warn] [CCD] Session local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134 stderr tail:
2026-08-25 01:34:00 [info] [CCD CycleHealth] unhealthy cycle for local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134 
  (1129s, hadFirstResponse=true, reason=incomplete_response)


Recovery, ~3.5 minutes later:

2026-08-25 01:37:25 [info] Resuming session local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134 in E:\Claude Projects
2026-08-25 01:37:25 [info] Starting local session local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134 in E:\Claude Projects
2026-08-25 01:37:25 [info] Using Claude Code binary at: C:\Users\GAMII\AppData\Roaming\Claude\claude-code\2.1.237\claude.exe
2026-08-25 01:37:25 [info] Loaded 130 transcript messages for session local_3f74ffed-e9f4-4c8e-bab3-6dfa4c008134

Steps to Reproduce

Not reliably reproducible — single occurrence. Task was a web-research/review task; app showed no progress for an extended period before the error appeared. Sending a follow-up message ("nudging") the same session resumed it successfully.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

The version around 3 months ago.

Claude Code Version

Claude 1.37937.0 (61bfd4) 2026-08-25T05:51:27.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Claude Desktop app (Windows)
Environment: Windows 11 Pro, Version 25H2 (OS Build 26200.9168), x64. Claude Desktop version at the time: 1.34493.1.0. Working directory: E:\Claude Projects.

Analysis: last_tool_name=Edit does not obviously match the reporter's recollection of a web-research task stalling — this field may only record the last completed tool call rather than whichever tool call was in flight when the hang began (e.g. a web-fetch/browsing tool dispatched next and never returned would not appear here). Not confirmed either way. Recovery was clean: the same session ID resumed with all 130 prior transcript messages intact, no data loss.

Suggested fixes:

1. Clarify what "994s of inactivity" is actually measuring — it does not appear to correspond to the 81-minute stderr-silence duration reported in the same log line.
2. Consider whether this matches the same subprocess-hang class implicated elsewhere (the AppInfo/AppContainer Job leak, or the event-loop-stall accumulation documented in a companion "freeze-then-vanish" report, filed separately), or is a distinct third mechanism.
3. Surface a clearer, more specific error message distinguishing a recoverable session hang from a more alarming generic failure.