[BUG] Cowork VM connection timeout on Windows 11 Pro ARM64 — guest agent boots successfully but exceeds 60s timeout (follow-up to #64746)

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?

Re-filing this as a follow-up to #64746, which was auto-closed by the stale bot for inactivity — not because it was resolved. The issue is still present and I now have detailed diagnostic evidence pinpointing the cause.

Device

Surface Laptop (13", 1st Ed Snapdragon), Snapdragon X Plus 8-core @ 3.30GHz, 16GB RAM, Windows 11 Pro, version 25H2, build 26200.8737.

Symptom

Cowork's workspace VM consistently fails with: Failed to start Claude's workspace. VM connection timeout after 60 seconds. On one occasion the underlying tool error was: bash failed on resume, create, and re-resume. resume: request timed out after 30s; create: request timed out after 30s.

Ruled out

Antivirus/firewall/VPN (Bitdefender fully disabled — issue persisted)
Permissions (confirmed via secedit /export /cfg out.inf /areas USER_RIGHTS that S-1-5-83-0, the Virtual Machines service account, has SeServiceLogonRight and no SeDenyServiceLogonRight entry)
Windows updates and Claude desktop app version (both current)
RAM pressure as sole cause (freed available memory from 2.3GB to 4.5GB before a retest — still timed out)
Cowork's own readiness check passes fully (Windows version, arm64 architecture, Virtual Machine Platform services present: vmcompute, HNS, vfpext, disk space, memory, page file all green)

Root cause (from Event Viewer)

Using Event Viewer, I traced a specific VM instance (cowork-vm-e8eaaea0f) through Hyper-V-Compute, Hyper-V-Worker, and Hyper-V-VSmb Operational logs:

13:23:41 — VSMB share creation begins (Event 301, Hyper-V-VSmb): mounting claudevm.bundle as share os
13:23:41–13:23:42 — burst of setup events (Hyper-V-Worker Admin: Event IDs 33103, 3086 ×2, 18601, 18500, 12148, 18609)
Then nothing for over 3 minutes
13:26:55 — VM finally powers on a virtual PCI device (Event 33107, Hyper-V-Worker): 'cowork-vm-e8eaaea0f': The guest operating system powered on a virtual PCI device: {C4B741F5-5582-4C98-8F8B-2E082933C396} Slot 0

No Warning or Error level events anywhere in the sequence — the VM isn't crashing, it's just taking roughly 3 minutes 14 seconds to boot against a hardcoded 60-second timeout.

During this boot window, Task Manager consistently shows Vmmem at the top of CPU usage, suggesting the VM itself is CPU-bound while starting — plausibly consistent with an x64 workspace image running under emulation on ARM64 hardware, though I can't confirm the image architecture from my side.

Prior support interaction

I raised this through in-app feedback separately. Anthropic support confirmed the 60-second timeout is not user-configurable, there's no current workaround, and it's being passed to engineering as a known ARM64 platform limitation — but there's no tracking mechanism or ETA visible to users.

Ask

Is a native ARM64 workspace image planned, or is the current image x64-under-emulation?
Could the timeout be extended (or made configurable) specifically for ARM64 devices, given the VM does successfully boot given enough time?
Could this issue stay open/tracked rather than auto-closing, given it's an active, reproducible platform bug affecting ARM64 Windows devices generally, not just this one machine?

Happy to provide further logs or run additional diagnostics if useful.

What Should Happen?

The Cowork workspace VM should connect and become available for running commands within the timeout window, the same as it does on x64 Windows devices. Since Event Viewer confirms the VM does successfully boot (just taking ~3 minutes instead of under 60 seconds), the expected fix would be either a longer timeout on ARM64 devices, or a faster-booting native ARM64 workspace image.

Error Messages/Logs

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.

On one occasion, the underlying tool error was:
bash failed on resume, create, and re-resume. resume: request timed out after 30s; create: request timed out after 30s.

Event Viewer (Windows), tracing VM instance cowork-vm-e8eaaea0f:

Hyper-V-VSmb Operational log:
13:23:41 - Event 301: 'cowork-vm-e8eaaea0f': VSMB Share is creating ShareName: 'os' SharePath: 'C:\Users\...\AppData\Roaming\Claude\vm_bundles\claudevm.bundle' ShareFlags: 0x1

Hyper-V-Worker Admin log:
13:23:41-13:23:42 - burst of setup events (Event IDs 33103, 3086 x2, 18601, 18500, 12148, 18609)
[gap of 3+ minutes, no further events]
13:26:55 - Event 33107: 'cowork-vm-e8eaaea0f': The guest operating system powered on a virtual PCI device: {C4B741F5-5582-4C98-8F8B-2E082933C396} Slot 0
13:26:55 - Event 33100 also logged

No Warning or Error level events at any point - the VM boots successfully but takes ~3 minutes 14 seconds, well past the 60-second timeout. Task Manager shows Vmmem consistently topping CPU usage throughout the boot window.

Steps to Reproduce

1. Use Claude desktop (Cowork mode) on a Windows 11 Pro ARM64 device (tested on Surface Laptop, Snapdragon X Plus, 16GB RAM, build 26200.8737).
2. Ask Claude to perform any task requiring the sandbox (e.g. run a shell command).
3. Observe: the workspace VM begins starting but the connection times out after 60 seconds with "Failed to start Claude's workspace."
4. Confirm via Windows Event Viewer (Hyper-V-Worker Operational log) that the VM continues booting in the background and succeeds only after ~3+ minutes - past the timeout window.
5. Issue is reproducible consistently across multiple sessions/days, and persists even after: disabling all antivirus/firewall/VPN (Bitdefender), confirming correct VM service permissions (SeServiceLogonRight for S-1-5-83-0), freeing available RAM from 2.3GB to 4.5GB, and confirming Windows/Claude app are fully up to date.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.24012.9.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_