[BUG] Cowork on Windows ARM64: Linux guest never establishes vsock callback — stuck at add_plan9_shares, 100% reproducible after exhaustive diagnosis

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 on every launch with "VM connection timeout after 60 seconds" on Windows 11 ARM64. The Windows host side is fully functional — CoworkVMService runs, named pipes are created (\\.\pipe\cowork-vm-service and \\.\pipe\cowork-daemon-console-cowork-vm-*), the hypervisor boots the VM in under 500ms, and add_plan9_shares completes in 5–10ms. The failure is inside the Linux guest: it never makes the vsock callback to the host within 60 seconds, every time, with zero variation. The host log just shows "Still waiting for guest connection..." repeating every 10 seconds until timeout, with last completed step: add_plan9_shares — the next expected step (guest_vsock_connect) never starts.

After a multi-hour structured diagnosis I ruled out every commonly-cited cause (VPN, third-party AV, Hyper-V misconfiguration, bundle corruption, service issues, Windows Defender, auto-reinstall loop). The failure persists in a clean, reproducible form. I believe this is a platform-level issue with the ARM64 guest image's vsock initialization or Hyper-V Integration Services on Windows-on-ARM.

100% reproducible across 3+ consecutive runs after a full diagnostic reset, identical log signature each time.

What Should Happen?

Cowork workspace should start and become usable within a normal startup window (≤60 seconds), as it does on Windows x64 and macOS.

Error Messages/Logs

[VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
[VM:start] Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
[VM:start] VM instance ID: 2ca07f1c-b361-4b76-af59-87e2006bb9c3
[VM:steps] download_and_sdk_prepare completed (2ms)
[VM:steps] load_swift_api completed (0ms)
[Callbacks] VM event callbacks initialized
[VM:start] Copying smol-bin.arm64.vhdx to bundle: ... -> ...\smol-bin.vhdx
[VM:start] smol-bin.arm64.vhdx copied successfully
[VM:start] Configuring Windows VM service...
[VM:start] Windows VM service configured
[VM:steps] create_network completed (0ms)
[VM:steps] create_vm_config completed (96ms)
[VM:steps] vm_boot completed (94ms)
[VM:steps] add_plan9_shares completed (5ms)
[VM:start] Still waiting for guest connection... 10163ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20369ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30508ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 40692ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 50908ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Steps to Reproduce

1. Install Claude Desktop on Windows 11 ARM64 (MSIX install path: C:\Program Files\WindowsApps\Claude_1.8089.1.0_arm64__pzs8sxrjxfjjc\)
2. Open Claude Desktop and sign in
3. Click the Cowork tab
4. Wait ~60 seconds
5. Observe error: "Failed to start Claude's workspace — VM connection timeout after 60 seconds"

Reproducibility: 100% across all attempts (3+ consecutive runs after full diagnostic reset, identical signature each time).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.8089.1.0 (arm64) — MSIX install

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• OS: Windows 11 ARM64
• Architecture: ARM64
• Claude Desktop version: 1.8089.1.0 (arm64)
• Install path: C:\Program Files\WindowsApps\Claude_1.8089.1.0_arm64__pzs8sxrjxfjjc\
• Data path: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
• VM bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
• VPN: None (verified via Get-NetAdapter and Get-Service)
• Third-party AV: None (Windows Defender only)

Windows virtualization features (all Enabled):

• VirtualMachinePlatform: Enabled
• HypervisorPlatform: Enabled
• Microsoft-Hyper-V-All: Enabled

Troubleshooting Already Attempted (all failed to fix)

1. Full Claude restart + CoworkVMService manual restart — service starts, pipe \\.\pipe\cowork-vm-service appears, VM still times out.
2. Verified all virtualization features Enabled.
3. Verified no VPN software (Get-NetAdapter and Get-Service filtered for VPN strings: Tailscale, WireGuard, OpenVPN, Cisco, Forti, GlobalProtect, NordVPN, ExpressVPN, ProtonVPN, Surfshark — all returned empty).
4. Verified no third-party antivirus — only Windows Defender.
5. Deleted sessiondata.vhdx and .auto_reinstall_attempted marker to force a clean guest state — no change.
6. Configured CoworkVMService recovery: sc.exe failure CoworkVMService reset= 60 actions= restart/5000/restart/5000/restart/5000.
7. Re-created .auto_reinstall_attempted marker to suppress destructive auto-reinstall loop (see Secondary Bug below).
8. Added Windows Defender exclusions for install dir, package data dir, and Claude.exe — no change.
9. Verified named pipes present at Claude launch: both \\.\pipe\cowork-vm-service and \\.\pipe\cowork-daemon-console-cowork-vm-<id> exist.
10. Verified VM bundle integrity: rootfs.vhdx (9.1 GB), vmlinuz, initrd, smol-bin.vhdx (37 MB) all present with validated checksums on each launch.

Secondary Bug: Destructive Auto-Reinstall Loop

After the first VM connection timeout, Claude Desktop's auto-reinstall routine deletes rootfs.vhdx, vmlinuz, and initrd from the bundle ([deleteVMBundle] Deleted rootfs.vhdx etc.) and quits/restarts the app. On restart it tries to shut down the orphaned VM instance through a pipe that no longer exists, CoworkVMService ends up Stopped, and Claude can't restart it — producing a different error ("VM service not running") that masks the actual underlying problem.

Users hitting the underlying ARM vsock bug will chase phantom service issues for hours unless they know to manually re-create the .auto_reinstall_attempted marker file to break the loop.

Suggested fixes:

• Don't delete bundle binaries on a guest-side timeout — those files weren't the problem.
• Don't quit the app as part of auto-reinstall; recover in-process.
• If auto-reinstall must run, verify CoworkVMService is still healthy at the end and surface a clear error if it isn't.

Suspected Root Cause

The failure pattern (host healthy, hypervisor healthy, guest fails to call back over vsock) on Windows-on-ARM matches what would be expected if:

• The Hyper-V vsock integration driver isn't loading correctly in the ARM64 guest, OR
• coworkd inside the guest is crashing during init on ARM64 before it can bind to vsock, OR
• The host-side vsock dispatch on Windows-on-ARM isn't routing connections from the guest VM correctly.

Capturing guest-side console/kernel output (even via serial console) on timeout would make this diagnosable. Currently the host log has zero visibility into what's happening inside the guest, so users and engineers are both blind to the actual failure.

Asks

1. Fix the underlying guest-vsock issue on ARM64 (primary).
2. Add guest-side logging (serial console capture) so guest-init failures are diagnosable.
3. Fix the destructive auto-reinstall behavior so a single guest timeout doesn't make things worse.
4. Update Windows ARM support status in docs to reflect current reality.

Happy to provide additional logs, run targeted diagnostics, or test patches.