Windows Desktop: turns initiated while session window is unfocused (cross-session send_message delivery) never start; watchdog-killed after ~980s — regression 2.1.222 -> 2.1.227

Summary

After Claude Desktop auto-updated its bundled Claude Code runtime 2.1.222 → 2.1.227 (Windows), any session turn initiated while the session's window is not focused — most notably the delivery of a cross-session message sent via the ccd_session_mgmt send_message tool — never starts. The spawned/resumed session produces no output at all (seconds_since_stderr=never, hadFirstResponse=false) and the app watchdog kills the cycle after ~980s (~16 minutes), surfacing as an error in the UI. Turns initiated with the window focused (user typing directly, new-session launches) work normally on the same runtime.

This breaks multi-session coordination workflows (sessions messaging each other) that worked reliably on 2.1.222 and earlier.

Environment

• OS: Windows 11 Pro 10.0.26200
• App: Claude Desktop (Cowork/CCD), Electron updater version 1.28929.0
• Claude Code runtime: 2.1.227 (auto-installed by the app on 2026-08-12, ~05:55 UTC), previous 2.1.222
• Sessions run in git worktrees; 12 MCP servers configured (issue reproduces regardless — the child emits nothing before MCP init would even log)

Regression evidence (from %APPDATA%\Claude\logs\main.log)

• On 2.1.222 (Aug 9–11): 103 session spawns, zero timed out ... hadFirstResponse=false events; cross-session message delivery to idle sessions worked for weeks.
• 2.1.227 installed:

``
2026-08-12 11:25:59 [info] [CCD] Downloading from https://downloads.claude.ai/claude-code-releases/2.1.227/win32-x64/claude.exe.zst
2026-08-12 11:26:24 [info] [CCD] Installed at C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.227\claude.exe
``

• First failure begins ~40 min later. 5/5 background message deliveries after the update were killed with the identical signature; examples:

``
2026-08-12 12:22:59 [warn] [CCD] Session local_8af63ba7-... timed out after 1010s of inactivity (hadFirstResponse=false, last_message_type=user, last_tool_name=none, seconds_since_stderr=never)
2026-08-12 16:15:26 [warn] [CCD] Session local_1ec13f4b-... timed out after 980s of inactivity (hadFirstResponse=false, last_message_type=user, last_tool_name=none, seconds_since_stderr=never)
2026-08-12 16:26:26 [warn] [CCD] Session local_d385c4d8-... timed out after 979s of inactivity (hadFirstResponse=false, last_message_type=user, last_tool_name=none, seconds_since_stderr=never)
2026-08-12 16:15:26 [info] [CCD CycleHealth] unhealthy cycle for local_1ec13f4b-... (980s, hadFirstResponse=false, reason=no_response)
``

• A representative hung delivery (cold resume path) — after Loaded N transcript messages the child never logs anything again until the watchdog kill:

``
2026-08-12 15:59:05 [info] Resuming session local_1ec13f4b-... in C:\Users\<user>\...\worktrees\...
2026-08-12 15:59:05 [info] Starting local session local_1ec13f4b-...
2026-08-12 15:59:06 [info] [CCD] Passing 4 plugin(s) to SDK (skills: 1, remote: 3, local: 0)
2026-08-12 15:59:06 [info] Using Claude Code binary at: C:\Users\<user>\AppData\Roaming\Claude\claude-code\2.1.227\claude.exe
2026-08-12 15:59:06 [info] Loaded 72 transcript messages for session local_1ec13f4b-...
... (total silence from this session until) ...
2026-08-12 16:15:26 [warn] [CCD] Session local_1ec13f4b-... timed out after 980s ...
``

Analysis — focus at turn start is the discriminator

• Not context size: both large (6,000+ message) and freshly created sessions fail identically.
• Not warm-vs-cold: one hung delivery went to a warm process that had completed a healthy cycle 10 minutes earlier ([CCD CycleHealth] healthy cycle ... 178s, hadFirstResponse=true); it hung the same way on the unfocused delivery.
• Focused deliveries succeed: a cross-session message delivered while the user happened to be actively focused in the receiving session's window ran a healthy 218s cycle on 2.1.227. All direct user-typed turns ran healthy all day on 2.1.227.
• Focusing after the hang starts does not rescue it: the app pushed replaceEnabledMcpTools / replaceRemoteMcpServers to the hung session when its window was focused mid-hang; it was still killed at 980s.
• The undelivered message is not written to the session's .jsonl transcript, but survives as a pending user message in the UI; the next focused turn processes it.

It looks like the 2.1.227 spawn/resume path waits on something only provided when a renderer/window is attached at turn start (config handshake? stdin? permission-mode negotiation?), and deadlocks silently when the turn is initiated headlessly/in background.

Repro steps

1. Claude Desktop on Windows with runtime 2.1.227, two local sessions A and B.
2. Leave B idle/unfocused (or even warm but unfocused).
3. From A, send B a message via the session-management send_message tool.
4. B's window shows the incoming message with a spinner; B's process emits nothing; ~16 min later the turn errors (timed out after ~980s ... hadFirstResponse=false ... seconds_since_stderr=never).
5. Same message typed directly into B's focused window runs immediately.

Expected

Turns triggered by cross-session message delivery run headlessly (as on ≤2.1.222).

Workaround in use

After each cross-session send, the user manually focuses the receiving session, stops the spinner, and types a nudge — the pending message is then processed.