[BUG] Cowork hangs after first message on Windows — clean VM boot confirmed, matches #26805/#26921/#44776/#59532 cluster

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?

Cowork hangs after first message on Windows — clean VM boot confirmed, matches #26805/#26921/#44776/#59532 cluster

Relates to: #59532, #44776, #26921, #26805
Platform: Windows 11 Version 23H2 OS Build 22631.6199, x64
Claude Desktop package: Claude_pzs8sxrjxfjjc (MSIX)
Claude Desktop version: 1.46388.4.0
Claude Code CLI (native): 2.1.263, confirmed healthy via claude doctor

Summary

Cowork sessions answer the first message normally, then hang indefinitely on every subsequent message — spinner/"Working" state never resolves. This reproduces consistently across multiple fresh sessions and is not caused by MCP servers, plugins, VM provisioning, or host virtualization — all of which I've ruled out with logs below. The symptom and timing match the existing #26805 → #44776 → #59532 regression chain ("Responses not rendering until user types" / "working through complex response hangs indefinitely"), which the April 23, 2026 postmortem says was addressed in v2.1.116 but appears to have resurfaced.

Steps to Reproduce

1. Open Claude Desktop, navigate to Cowork.
2. Start a new session (or open an existing one).
3. Send any message — a normal response is returned.
4. Send a second message in the same session.
5. Observe: the UI shows the "Working"/in-progress state indefinitely. No response ever arrives, and no error is shown.
6. Confirm the backend is not actually stuck by checking C:\ProgramData\Claude\Logs\cowork-service.log and the per-user coworkd log under C:\ProgramData\Claude\Logs\coworkd\ — both show the VM booted cleanly and reached API reachability: REACHABLE for step 3, then received no further activity for step 4 onward, despite the message having been sent from the UI.
7. Starting a brand-new Cowork session repeats the same pattern: first message succeeds, every message after hangs.

Expected Behavior

Every message in a Cowork session should receive a response, not just the first one.

Actual Behavior

Only the first message in any Cowork session ever completes. All subsequent messages hang indefinitely with no error, timeout, or recovery — the session becomes unusable and a new session must be started to get one more working message.

What's ruled out

• Not a cache/install issue: full app restart + Claude cache wipe, no change.
• Not an MCP/plugin issue: a separate, unrelated hang in Claude Code CLI was traced to a plugin (rtfm) and fixed via --safe-mode. Cowork continues to hang with that plugin fully disabled at the desktop level — confirming Cowork's hang is independent of that cause.
• Not a Hyper-V/HCS/service issue: CoworkVMService, vmcompute, hns all report Running. hcsdiag list shows no orphaned/zombie compute systems.
• Not a VM boot failure: cowork-service.log shows a fully clean lifecycle for a fresh session — HcsCreateComputeSystem → HcsStartComputeSystem → all 4 Plan9 shares mounted → sdk-daemon connected → Network status: CONNECTED → 73 CA certs installed → API reachability: REACHABLE. No errors anywhere in the sequence.
• Not a guest-side crash: the guest daemon log (coworkd) shows the VM boot completing, reaching connected, waiting for commands, and then going silent — the guest process itself never errors or exits, it simply never receives anything further.

Key log evidence

Host side (cowork-service.log) — full successful boot, ending at reachability confirmation:

[HCS] HcsCreateComputeSystem returned: hr=0x0, ...
[HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] Adding Plan9 share ... (x4, all hr=0x0)
[VM] VM started successfully
[RPC] sdk-daemon connected from VM ...
[RPC] Network status: CONNECTED
[VM] sdk-daemon is ready!
[Certs] Loaded 73 unique CA certificates from Windows ROOT+CA stores
[RPC] API reachability: REACHABLE
[VM] API reachability: REACHABLE

No further entries appear after this, despite sending additional messages in the session minutes later.

Guest side (coworkd per-user log) — same story, boot completes, then silence:

[coworkd] connected, waiting for commands
[coworkd] SDK binary v2.1.260 already installed, skipping   <- one routine check-in

No further command activity logged, though multiple follow-up messages were sent in the Cowork UI after this point.

One transient anomaly noted at boot (self-resolved on retry, may be worth a look):

[coworkd] early host dial failed (will retry after init): vsock dial: dial vsock host(2):51234: connect: no such device

Conclusion

The backend (VM + host orchestration) is healthy and idle, waiting for commands that never arrive after the first turn. This points to the failure being in the desktop app's message-dispatch/IPC layer between the Electron UI and the session backend — consistent with the root cause described in the #26805/#59532 cluster, not a new/environment-specific bug.

Ask

• #59532 was closed/locked as resolved on macOS, but this Windows report reproduces the same underlying pattern (backend healthy, UI/dispatch layer stops relaying after turn one). Is this a distinct regression, or should #59532 be reopened?
• Is there a known workaround short of downgrading (and if so, which version is last-known-good)?
• Happy to provide full untrimmed logs or run further diagnostics on request.

What Should Happen?

Expected Behavior

Every message in a Cowork session should receive a response, not just the first one.

Actual Behavior

Only the first message in any Cowork session ever completes. All subsequent messages hang indefinitely with no error, timeout, or recovery — the session becomes unusable and a new session must be started to get one more working message.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce
Open Claude Desktop, navigate to Cowork.
Start a new session (or open an existing one).
Send any message — a normal response is returned.
Send a second message in the same session.
Observe: the UI shows the "Working"/in-progress state indefinitely. No response ever arrives, and no error is shown.
Confirm the backend is not actually stuck by checking C:\ProgramData\Claude\Logs\cowork-service.log and the per-user coworkd log under C:\ProgramData\Claude\Logs\coworkd\ — both show the VM booted cleanly and reached API reachability: REACHABLE for step 3, then received no further activity for step 4 onward, despite the message having been sent from the UI.
Starting a brand-new Cowork session repeats the same pattern: first message succeeds, every message after hangs.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.263

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_