[BUG] Cowork "VM connection timeout after 60 seconds" — all repair paths exhausted

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 fails to start the workspace with "VM connection timeout after 60 seconds" on every attempt. Worked normally through June 8, 2026; first failure June 9, 2026 at 07:50 with no intervening reboot, Windows update, or app update.

All host-side startup steps succeed (vm_boot completes in ~500ms, add_plan9_shares completes), but the Linux guest never establishes the host connection — it polls for 60 seconds and times out.

Exhaustive repair attempts, all failing identically:

1. App restarts (multiple)
2. Deleted .auto_reinstall_attempted + .rootfs.vhdx.origin + rootfs.vhdx → app re-extracted fresh image from checksum-verified .zst
3. App self-updated 1.11187.4.0 → 1.11847.5.0 with new bundle (c9b42670...) downloaded and checksum-validated
4. Windows reboot (×3)
5. Replaced sessiondata.vhdx (fresh disk created by app)
6. Set bcdedit hypervisorlaunchtype Auto (was unset) + reboot
7. Full network stack reset (winsock reset, IP reset, ghost adapter cleanup, HNS Default Switch regenerated) + reboot
8. In-app "reinstall the workspace" repair

Environment: Lenovo 83N3 (Snapdragon ARM64), Windows 11 Home 10.0.26200, HypervisorPresent=True, VirtualMachinePlatform enabled, CoworkVMService running (StartType=Automatic), 298 GB free disk, Windows Defender only (zero detections/blocks logged).

Possibly useful observations:

• Failed on two app versions AND two VM bundle versions (5680b11... and c9b42670...)
• The failed VM holds rootfs.vhdx/sessiondata.vhdx locked ~60-70s after app exit before HCS teardown releases them
• One boot logged "smol-bin.vhdx locked by running VM (EBUSY), skipping copy" from a stale prior VM instance
• ssh.log shows frequent "network-interface change detected; probing SSH controllers" (Qualcomm FastConnect 7800 Wi-Fi)
• No guest console output available in logs to diagnose the guest side

Likely related: #65128, #42784

What Should Happen?

The workspace VM should boot and the guest should connect, as it did until June 8, 2026.

Error Messages/Logs

From %APPDATA%\Claude\logs\cowork_vm_node.log:

2026-06-10 08:15:35 [info] [VM:steps] vm_boot completed (448ms)
2026-06-10 08:15:35 [info] [VM:steps] add_plan9_shares started
2026-06-10 08:15:35 [info] [VM:steps] add_plan9_shares completed (4ms)
2026-06-10 08:15:35 [info] [VM:start] Still waiting for guest connection... 10134ms elapsed, 21 polls
2026-06-10 08:16:05 [info] [VM:start] Still waiting for guest connection... 50671ms elapsed, 101 polls
2026-06-10 08:16:15 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-06-10 08:16:15 [info] Dispatching startup error: VM connection timeout after 60 seconds
2026-06-10 08:16:15 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
    at ZBr (C:\Program Files\WindowsApps\Claude_1.11847.5.0_arm64__pzs8sxrjxfjjc\app\resources\app.asar\.vite\build\index.js:534:5902)
2026-06-10 08:16:15 [info] [VM:start] Skipping auto-reinstall (already attempted once)

UI error:
Failed to start Claude's workspace
VM connection timeout after 60 seconds
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Steps to Reproduce

Open Claude desktop on Windows and start any Cowork session

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Yes — last worked June 8, 2026

Claude Code Version

1.11847.5.0 (desktop, arm64

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

windows arm 64