[BUG]

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 with "Failed to start Claude's workspace — VM connection timeout after 60 seconds" on a Snapdragon X Plus (ARM64) device running Windows 11 Home 25H2 (build 10.0.26200.8655).

Unlike a typical stale-state failure, I have host- and guest-side log evidence showing the Linux guest kernel hangs before producing any console output, and that the guest clocksource was frozen in the sessions leading up to the failure. This looks like an ARM64 hypervisor timer issue in the Cowork guest kernel — WSL2 Ubuntu boots and runs normally on the same host throughout.

This appears to be the same defect as the now-closed #42784 (same CPU family, same Windows build line), filed as a new issue with additional diagnostic evidence.

What Should Happen?

The Cowork workspace VM should boot and the guest should connect on vsock, as it did on this same machine ~200 times between April and July 7, 2026.

Error Messages/Logs

Failed to start Claude's workspace
VM connection timeout after 60 seconds

Host side (logs\cowork_vm_node.log) — VM creation fully succeeds, guest never connects:
[VM:steps] vm_boot completed (179ms)
[VM:steps] add_plan9_shares completed (4ms)
[VM:start] Still waiting for guest connection... 50925ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares

Service side (C:\ProgramData\Claude\Logs\cowork-service.log):
[HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] VM started successfully

(then nothing — guest never connects on vsock port 1024)

Guest console (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log) — zero output from any boot attempt since 2026-07-07. Final entries before the failure began show the guest clock not advancing between timesync corrections:
[timesync] stepped clock by 7.004s (host=...20:25:47Z guest=...20:25:40Z)
[timesync] stepped clock by 7.026s (host=...20:25:54Z guest=...20:25:47Z)
[timesync] stepped clock by 6.987s (host=...20:26:01Z guest=...20:25:54Z)
(continues: +~7s correction every ~7s — guest clocksource frozen)

Additional host-side observations from the same period:


CoworkVMService terminated unexpectedly twice (SCM event 7034; second crash silent — service log simply stops, no WER report). The service cannot register crash recovery: "failed to open service for recovery config: Access is denied" — and even an elevated admin gets OpenService FAILED 5 due to the MSIX service ACL, so a crashed service stays down.
Qualcomm AI Runtime error reports (QAIRTErrorReport, code 0x0000003A) fire in the Application event log at the exact timestamps of VM start attempts.
On 2026-07-07 the auto-reinstall failed to replace the root filesystem: "rootfs.vhdx locked by running VM (EBUSY), skipping" — the image swap silently half-failed.
In-app "reinstall workspace" never re-downloads; it re-extracts the locally cached rootfs.vhdx.zst, so whatever state is bad reproduces itself on every reinstall.

Steps to Reproduce

1. Snapdragon X Plus device, Windows 11 Home 25H2 (26200.8655), Claude Desktop 1.19367.0.0 arm64 (Store/MSIX).
2. Open Cowork → "VM connection timeout after 60 seconds".
3. Exhausted remedies, error persists in all cases:

• App restart, full PC restart
• In-app "reinstall workspace"
• Killing zombie cowork-vm-* compute system via hcsdiag, restarting CoworkVMService
• Deleting the entire VM bundle including the compressed cache to force a genuine fresh ~1.2 GB re-download (verified fresh image on disk)

1. Every attempt: HCS reports the VM started successfully; guest produces no console output and never connects.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A

Claude Code Version

Claude Desktop (Cowork) 1.19367.0.0 arm64

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

CPU: Snapdragon X Plus (8-core) @ 3.30 GHz (Qualcomm Oryon), 16 GB RAM, virtualization enabled, Defender only, ~100 GB free disk.
WSL2 (Ubuntu) boots and runs normally on this host at all times, including after the Cowork failures — generic Hyper-V Linux guests are fine. Suggests the Cowork guest kernel is missing an ARM64 arch-timer workaround the WSL2 kernel has.
The frozen-clock signature (+7s timesync step every 7s) may be what KernelBugMonitor is designed to detect; it logged "State reset" on each attempt but no detection.
Previous report of the same symptom/hardware: #42784 (closed). Filing anew with guest-side evidence.
Full diagnostic timeline available; debug logs shared via the in-app "share your debug logs" option on 2026-07-09.

Suggested areas to look at:

ARM64 guest kernel arch-timer handling under Windows 26200.x hypervisor (guest clock freeze → later boots hang pre-console).
CoworkVMService silent crash path + inability to self-register SCM recovery under MSIX ACLs.
"Reinstall workspace" should invalidate the compressed cache (or verify image integrity) instead of re-extracting rootfs.vhdx.zst.
Auto-reinstall proceeding while rootfs.vhdx is EBUSY-locked leaves a half-swapped bundle without surfacing an error.