Cowork VM orchestrator loses handle to healthy VM, retries forever due to stuck .auto_reinstall_attempted sentinel

Cowork VM orchestrator loses handle to healthy VM, retries forever due to stuck .auto_reinstall_attempted sentinel

Claude Desktop version: 1.3109.0.0
OS: Windows 11 (Hyper-V host)
Related issues: #43534 (stale VM after idle), #47147 (CoworkVMService silently stopping)

This is a distinct failure mode from both linked issues — the service is healthy and a VM is running, but the desktop-app orchestrator cannot reconnect to it.

---

Summary

Under two conditions I've now hit in a single day, the Cowork orchestrator ends up in a retry loop trying to boot a VM that can't be booted because either (a) the Windows service handshake is wedged or (b) a previously-booted vmwp.exe is still holding the VM bundle. The self-heal path (auto-reinstall) is blocked because a sentinel file .auto_reinstall_attempted is written to disk and never removed, so every subsequent retry logs:

Skipping auto-reinstall (already attempted once)

…even after the app has been fully restarted. The only recovery is a full Windows reboot.

---

Symptom A — post-hard-reset: VM service not running

After a host hard reset (computer froze, held power button), CoworkVMService came back up (Status: Running, PID assigned, cowork-svc.exe alive), but every VM boot attempt failed:

2026-04-18 15:41:33 [error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
2026-04-18 15:41:36 [info]  [VM:start] Skipping auto-reinstall (already attempted once)
2026-04-18 15:41:49 [info]  [VM:start] Beginning startup, bundlePath=...
2026-04-18 15:41:49 [info]  [VM:start] VM instance ID: 522fcd48-2238-4dc7-bc36-1bb1b7948696
2026-04-18 15:41:54 [error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.
2026-04-18 15:41:54 [info]  [VM:start] Skipping auto-reinstall (already attempted once)

Eight successive boot attempts over 8 minutes, all failing identically. CoworkVMService was Running throughout per Get-Service, but the orchestrator's in-process view said otherwise — state mismatch between the Electron app and the actual Windows service.

Workaround: full Windows reboot. After reboot, VM booted cleanly on instance 4e1596ce-d9e0-4b7d-9128-9df63d2257a3 and ran healthy for ~5.5 hours.

---

Symptom B — after ~5 hours of healthy operation: VM is already running

After the working session went idle / the Cowork UI reconnected, the orchestrator lost its handle to the running VM and tried to provision a fresh one. Hyper-V correctly refused:

2026-04-18 22:07:52 [info]  [VM:start] Beginning startup, bundlePath=...
2026-04-18 22:07:52 [info]  [VM:start] VM instance ID: 4e1596ce-d9e0-4b7d-9128-9df63d2257a3
2026-04-18 22:07:53 [info]  [VM:start] Windows VM service configured
2026-04-18 22:07:53 [error] [VM:start] VM boot failed: VM is already running
2026-04-18 22:07:53 [info]  Dispatching startup error: VM is already running
2026-04-18 22:07:54 [info]  [VM:shutdown] App quit, stopping VM (instance: 4e1596ce-...)...
2026-04-18 22:07:54 [info]  [VM:shutdown] Completed in 25ms

The shutdown "completing in 25ms" is suspicious — vmwp.exe (PID 15128) was still alive and holding smol-bin.vhdx afterward (ls showed the VHDX with a recent mtime and the orchestrator kept hitting EBUSY). The shutdown appears to free only the orchestrator's handle, not the actual Hyper-V worker process.

Subsequent retries logged smol-bin.vhdx locked by running VM (EBUSY), skipping copy and looped:

2026-04-18 22:09:22 ... VM boot failed: VM is already running
2026-04-18 22:09:23 ... Skipping auto-reinstall (already attempted once)
2026-04-18 22:10:21 ... VM boot failed: VM is already running
2026-04-18 22:10:21 ... Skipping auto-reinstall (already attempted once)
2026-04-18 22:11:35 ... VM boot failed: VM is already running
2026-04-18 22:11:35 ... Skipping auto-reinstall (already attempted once)

Inside the Cowork UI this manifests as: Excel MCP (host-side) works, but any tool that requires the Linux sandbox (Python, Bash, openpyxl) fails. The session's model reports "the Linux sandbox is down" even though vmwp.exe is very much alive.

---

Root cause hypothesis

Two bugs stacking:

1. Orchestrator cannot reconnect to an already-running VM. When the Electron app loses its in-process reference to the VM (idle timeout, UI reconnect, session resume), it goes straight to "provision a fresh VM" instead of probing whether the existing vmwp.exe for its bundle is still reachable. Because the VM bundle can only host one VM at a time, Hyper-V refuses the fresh boot.

1. Self-heal is gated by a persistent on-disk sentinel. The file:

``
%APPDATA%\Claude\vm_bundles\claudevm.bundle\.auto_reinstall_attempted
`
is created the first time a boot attempt fails within an app session. The retry loop then forever logs Skipping auto-reinstall (already attempted once)`. The file is not deleted on successful VM boot, on app quit, or on a subsequent app launch — so once you're in this state, the auto-reinstall path is permanently disabled and a fresh install cycle can't run until the sentinel is removed manually. Confirmed on my machine: the file persisted from 15:41 this morning through multiple app restarts and was still on disk at 22:11.

The interaction matters: because (1) creates a self-perpetuating failure and (2) disables the recovery, a single transient hiccup (idle reconnect, brief service blip) escalates into an unrecoverable session.

---

Suggested fixes

• Before booting a new VM, check whether an existing vmwp.exe for this bundle is alive. If yes, attempt to reconnect instead of provisioning. Match by bundle path / VM instance ID stored in a runtime state file. Only fall through to fresh provisioning if the existing worker is non-responsive after a timeout.
• Make VM:shutdown actually terminate vmwp.exe, not just drop the orchestrator's handle. Current 25ms shutdown is not plausibly killing a Hyper-V worker. Verify with Get-Process vmwp after shutdown in an integration test.
• Scope the .auto_reinstall_attempted sentinel to the current app session, not to disk. A per-launch in-memory flag, or at minimum a stamped-timestamp file that expires after N minutes. Also: remove the file on clean shutdown and on successful VM boot.
• Log whether the in-process VM-service state matches the actual Windows service state. Today's error "VM service not running. The service failed to start." was flatly wrong — Get-Service said Running throughout. A reconciliation check on failure paths would catch this class of mismatch early.

---

Timeline of today's session (evidence summary)

| Time | Event |
|---|---|
| 10:03 | Previous session shut down cleanly |
| ~10:30 | Computer froze, hard reset |
| 14:27 | VM boot after reset, instance cace1c1b — success, session ran |
| 15:15–15:16 | Transient VM connection timeout after 60 seconds, fresh instance 13946c10 recovered |
| 15:40 | App quit |
| 15:41–15:49 | Symptom A: 8 failed boots with VM service not running. .auto_reinstall_attempted written at 15:41 |
| ~16:20 | Host reboot |
| 16:30 | VM boot clean on instance 4e1596ce, healthy keepalives |
| 16:30–17:11 | 30+ healthy keepalives, Python/Bash/openpyxl all working |
| ~17:11–22:07 | Quiet (VM stayed up, no new log entries) |
| 22:07 | Symptom B begins: orchestrator attempts boot of new instance, vmwp.exe PID 15128 still holds VHDX, Hyper-V refuses |
| 22:07–22:11+ | Retry loop: VM is already running + Skipping auto-reinstall |

---

Reproducibility

Symptom A reproduces reliably via hard reset during VM operation. Symptom B reproduces on my machine after a few hours of clean VM operation followed by a period of Cowork-session idleness. Both recover only via a full Windows reboot because the sentinel file prevents the app's self-heal from retrying.

I'll attach the full cowork_vm_node.log if useful.