claude-code - 💡(How to fix) Fix [BUG] Cowork (Windows): Sessions complete with cycle_health: 'healthy' but had_first_response: false — response never renders in UI

Preflight Checklist

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

What's Wrong?

Every Cowork session on this Windows machine completes silently. The message is submitted, the session runs for ~12 seconds, and Turn succeeded is logged — but no response ever renders in the UI. The response bubble stays empty. The session transitions to idle. No error is surfaced to the user.

This is distinct from existing process-crash reports (#51886, #49473, #49485). Those show cycle_health: 'unhealthy', error_category: 'process_crashed', and seconds_to_outcome: 1. This failure shows a healthy cycle with a 12-second runtime and no crash — the process completes normally but the response is silently lost before reaching the renderer.

Platform: Windows 11 (personal machine, not domain-joined)
App version: Claude Desktop MSIX v1.8555.2.0 (Claude_pzs8sxrjxfjjc)
Subscription: Claude Max
Feature affected: Cowork
Claude Code works fine on the same machine via terminal CLI
Cowork works fine on macOS (same account)

Reproduces 100% of the time across all projects and all task types.

Analysis

The failure appears to be in the response streaming path from the CLI execution layer back to the Electron renderer, not in the VM or API layer:

• VM boots cleanly, API reachable ✓
• Daemon receives pre-flight SDK checks ✓
• Turn succeeded fires in main.log ✓
• had_first_response: false — response tokens never reach renderer ✗
• mcpServerStatus query closes before response received during teardownIdleProcess ✗
• No error surfaced to user ✗

The mcpServerStatus warning fires during teardownIdleProcess → transitionTo → close → cleanup, suggesting the MCP query channel closes before the response delivery path completes. On macOS, timing appears sufficient; on Windows (HvSock IPC path through Hyper-V VM), the response delivery may be racing against the session teardown timer.

What I've Already Ruled Out

• Windows Firewall (disabled entirely, no change)
• "Act without asking" mode (toggled to "Ask before acting", no change)
• Project-specific working folder (same behavior across all projects)
• MCP connectors (all disabled in this account's connector settings)
• Domain/corporate policy (personal machine, not domain-joined)
• GPU rendering (--disable-gpu not yet tested per preference; not a GPU-related issue, NVIDIA GeForce RTX 4060 Ti)

What Should Happen?

cycle_health: 'healthy' should be accompanied by had_first_response: true and a visible response in the UI.

Error Messages/Logs

## Key Log Evidence

### `main.log` — healthy cycle, zero response delivered:


2026-05-25 10:56:18 [info] [Lifecycle] Session local_786f2ff2-d8cb-44b2-a155-f635e27061b6: initializing → running
2026-05-25 10:56:18 [info] [FileWatching] Starting file watcher: C:\Users\cld-main\Desktop\claude-dump
2026-05-25 10:56:25 [info] Mapping internal session local_786f2ff2-... to CLI session 80e41805-...
2026-05-25 10:56:25 [info] [Result] Turn succeeded for session local_786f2ff2-d8cb-44b2-a155-f635e27061b6
2026-05-25 10:56:25 [info] [Lifecycle] Session local_786f2ff2-d8cb-44b2-a155-f635e27061b6: running → idle
2026-05-25 10:56:25 [warn] [LocalAgentModeSessionManager] Failed to query mcpServerStatus: Query closed before response received
    at S4i.performCleanup (...)
    at XG.teardownIdleProcess (...)
    at XG.transitionTo (...)
2026-05-25 10:56:25 [info] [CycleHealth] Healthy cycle: {
  session_id: 'local_786f2ff2-d8cb-44b2-a155-f635e27061b6',
  host_loop_mode: true,
  vm_instance_id: '2fbbd5ee-7ab3-4364-ab37-a19a1d2d24bc',
  model: 'claude-sonnet-4-6',
  cli_session_id: '80e41805-6a72-4137-ac48-d0084a9a2cc7',
  user_message_uuid: '15320898-10b3-4a34-b154-b33255656ad5',
  cycle_health: 'healthy',
  had_first_response: false,
  seconds_to_outcome: 12,
  is_resume: false,
  transcript_size_bytes: undefined
}


### `cowork-service.log` — VM boots and API is confirmed reachable (no errors):


2026/05/25 10:56:11 [RPC] sdk-daemon connected from VM 0c333f13-bcfd-576a-8ba7-3853d9b38592
2026/05/25 10:56:11 [RPC] Network status: CONNECTED
2026/05/25 10:56:11 [VM] sdk-daemon is ready!
2026/05/25 10:56:12 [VM] API reachability: REACHABLE


### `coworkd` daemon log — VM is healthy, daemon waiting, SDK binary checks fire per attempt, but no task execution entries ever appear:


2026/05/25 15:56:12 [coworkd] reachability check passed (status=404)
2026/05/25 15:56:12 [coworkd] connected, waiting for commands
2026/05/25 15:56:12 [coworkd] SDK binary v2.1.149 already installed, skipping
2026/05/25 15:56:13 [coworkd] SDK binary v2.1.149 already installed, skipping
2026/05/25 15:56:14 [coworkd] SDK binary v2.1.149 already installed, skipping


The SDK binary check fires once per task submission attempt — confirming the app is communicating with the daemon for pre-flight — but no `[task]`, `[spawn]`, or `[claude]` execution entries ever follow.

Steps to Reproduce

Steps to Reproduce

1. Open Claude Desktop (Microsoft Store / MSIX version) on Windows 11
2. Open any Cowork project or start a new task
3. Submit any message (e.g., "Acknowledge your environment")
4. Observe: session runs ~12 seconds, transitions to idle, UI shows empty response bubble — no text, no error

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.149

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• OS: Windows 11
• Machine type: Personal (not domain-joined, not corporate-managed)
• App install: Microsoft Store MSIX (Claude_pzs8sxrjxfjjc)
• App version: 1.8555.2.0
• Claude Code CLI version (terminal): 2.1.149
• Subscription: Claude Max
• Working on macOS: Yes — same account, Cowork fully functional
• Working via terminal CLI on Windows: Yes — Claude Code CLI works fine

Related Issues

• #51886 — Windows, process crashes (exit code 1) — different failure: unhealthy cycle, process_crashed, 1s outcome
• #55879 — Windows Cowork instability, blank screen — overlapping symptom, different error path
• #40281 — Dispatch: Turn succeeded but response not delivered — closest analog, different feature (Dispatch/macOS)