[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell

```

### 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_

Reproduce on Windows by opening Claude Desktop Cowork, sending one successful message, then a second that hangs. Compare C:\ProgramData\Claude\Logs\cowork-service.log and the per-user coworkd log under C:\ProgramData\Claude\Logs\coworkd\ to confirm the VM reaches API reachability but receives no later commands. Done means follow-up messages in the same Cowork session are dispatched and return responses, with matching log activity.

Vom Indexierungsmodell aus dem Issue-Text verfasst.