›_ Claude Code Issues
Claude Code Issues / #69901

[BUG] Claude Desktop Cowork: Four Compounding Failures on Windows ARM64 / Snapdragon X — VM Never Becomes Ready

Open 💬 0 comments Opened Jun 21, 2026 by hyperion14

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?

Environment

| Field | Value |
|---|---|
| Device | Lenovo ThinkPad T14s Gen 6 (ARM) |
| CPU | Qualcomm Snapdragon X (ARM64) |
| OS | Windows 11 ARM64 |
| Claude Desktop version | Latest (ARM64 installer from claude.ai/download) |
| Subscription | Pro |
| Virtual Machine Platform | Enabled (Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform) |
| Microsoft-Hyper-V-All | Returns "Feature name is unknown" on ARM64 — expected |
| VirtualizationFirmwareEnabled | Reports False on ARM64 — expected (no VT-x/AMD-V on Snapdragon) |
| CoworkVMService | Installed, StartType: Automatic, but Status: Stopped after every reboot |
| vmms (Hyper-V VM Management) | Running |
| WSL2 | Installed and functional |

---

What's Wrong

Cowork is completely unusable on this device. Three distinct but compounding failures prevent the sandbox from ever becoming ready. None of them are surfaced to the user in a meaningful way, and the built-in "Reinstall workspace" button does not fix any of them.

---

Bug #1: CoworkVMService Does Not Start After Reboot (Service Startup Race Condition)

Symptom

After every reboot, CoworkVMService is in Stopped state despite StartType: Automatic. Claude Desktop opens, Cowork tab appears, but the sandbox never initializes. No error is shown to the user — Cowork simply hangs indefinitely.

Diagnosis

Get-Service CoworkVMService | Format-List Name, Status, StartType
# Name      : CoworkVMService
# Status    : Stopped        <-- should be Running
# StartType : Automatic

Get-Service vmms | Format-List Name, Status, StartType
# Name      : vmms
# Status    : Running
# StartType : Automatic

Root Cause

Claude Desktop triggers CoworkVMService startup too early in the boot sequence, before the Hyper-V Host Compute Service (vmms) and related HCS infrastructure are fully ready. The service fails silently and does not retry. StartType: Automatic is set, but the dependency chain is not correctly declared in the service manifest — CoworkVMService does not list vmms as a hard dependency, so Windows starts it too early.

Additionally, when Claude Desktop is not shut down gracefully (e.g. force-killed via Task Manager, or interrupted during sleep/wake), Hyper-V resources from the previous session remain held. On next boot, CoworkVMService crashes immediately because it cannot acquire those resources, and does not recover.

Workaround Required

The user must manually run Start-Service CoworkVMService in an elevated PowerShell session after every reboot, or register a Scheduled Task with a 30-second delay at logon.

Expected Behavior

CoworkVMService should declare vmms and HvHost as explicit service dependencies so Windows Service Control Manager starts it in the correct order. Alternatively, Claude Desktop should detect a stopped CoworkVMService and restart it automatically with appropriate retry logic.

---

Bug #2: vm_bundles Download Silently Fails When Claude Desktop Is Run Elevated

Symptom

After deleting vm_bundles to force a fresh download, rootfs.vhdx.zst and rootfs.vhdx remain at 0 bytes indefinitely. No error is shown. No progress indicator. The download simply never starts.

Diagnosis

Get-ChildItem "$env:APPDATA\Claude\vm_bundles" -Recurse | Select-Object Name, Length, LastWriteTime
# rootfs.vhdx.zst    0    [timestamp never changes]
# rootfs.vhdx        0    [timestamp never changes]

Network connectivity confirmed active (Claude processes have established HTTPS connections to Anthropic CDN on port 443). The download infrastructure is reachable but the transfer does not begin.

Root Cause

The vm_bundles download fails silently when Claude Desktop is launched with elevated privileges (Run as Administrator). The MSIX AppX package model is designed for user-context execution. When run elevated, the download process runs under the admin token, which conflicts with the MSIX package's AppContainer security model and the expected user-profile write paths.

The download only succeeds when Claude Desktop is started as a normal user (non-elevated). Launching via explorer.exe shell:AppsFolder\<PackageFamilyName>!App correctly de-escalates privileges and allows the download to proceed normally.

This is a critical usability failure because:

  1. Anthropic's own troubleshooting instructions tell users to try running as Administrator
  2. Many users naturally try "Run as Administrator" when something doesn't work
  3. The failure is completely silent — no error, no log entry, just 0-byte files

Expected Behavior

Claude Desktop should either (a) detect that it is running elevated and warn the user that the vm_bundles download requires non-elevated context, or (b) spawn the download subprocess explicitly in the user's non-elevated context regardless of how Claude Desktop itself was launched.

---

Bug #3: Linux Guest Kernel Stuck in timesync Loop — VM Never Connects (ARM64 HVSock / Hyper-V Timesync Bug)

Symptom

After the vm_bundles download completes, CoworkVMService starts, and the HCS VM boots successfully (HcsStartComputeSystem hr=0x0), but the Linux guest daemon (sdk-daemon) never connects back to the host. Connection times out after 60 seconds.

Diagnosis

cowork-service.log (VM starts, but no sdk-daemon connection ever arrives):

[HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[HVSock] Listening on port 51234
[RPC] Server started, waiting for sdk-daemon connection on port 51234
[VM] VM started successfully
[Console] Connected to daemon console pipe: \\.\pipe\cowork-daemon-console-cowork-vm-55c0bbd5
# -- no further entries -- connection timeout after 60s

coworkd daemon log (the Linux guest is booting but stuck):

2145/05/25 11:03:06 [timesync] ClockSettime failed: invalid argument
2145/05/25 11:03:07 [timesync] ClockSettime failed: invalid argument
2145/05/25 11:03:09 [timesync] ClockSettime failed: invalid argument
[... repeating indefinitely ...]

Note the timestamp: year 2145. The Linux guest clock is wildly wrong and the timesync subsystem cannot correct it.

Root Cause

This is a fundamental incompatibility between Claude's Linux VM guest kernel and the Hyper-V timesync implementation on Qualcomm Snapdragon ARM64.

On x86/x64 hardware, Hyper-V provides a well-tested TSC-based timesync mechanism that the Linux guest kernel can use via the VMICTimeProvider. On Snapdragon ARM64, Hyper-V uses the Windows Container Host Compute Service (HCS) rather than full Hyper-V, and the timesync mechanism behaves differently — the guest receives an invalid or wildly incorrect initial clock value (apparently set to year 2145) and the ClockSettime syscall fails with EINVAL because the Linux kernel refuses to set a clock value that deviates too far from a reasonable reference.

The daemon is stuck in the timesync initialization loop and never proceeds to establish the HVSock connection. The 60-second timeout fires before the loop resolves (which it never does).

Attempted workaround (disabling Windows-side VMICTimeProvider via registry) had no effect:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider" -Name "Enabled" -Value 0

This is expected — the fix needs to be in the Linux guest kernel or the VM configuration passed to HCS, not on the Windows host side.

Root Cause Summary

The Claude VM's Linux guest kernel (or its init/daemon startup sequence) does not handle the case where the Hyper-V-provided initial clock is invalid or in the far future. On Snapdragon ARM64, HCS provides an invalid timestamp to the guest, the guest's timesync fails with EINVAL, and the daemon initialization loop never exits. The guest kernel needs to either (a) handle EINVAL from ClockSettime gracefully and fall back to a safe default clock, or (b) the HCS VM configuration needs to pass a valid initial clock to the guest on ARM64.

---

Combined Impact

All three bugs compound:

  1. After reboot → CoworkVMService is stopped → Cowork hangs (Bug #1)
  2. User tries to fix by deleting vm_bundles and running as Admin → download silently fails (Bug #2)
  3. Even after correct download with non-elevated start → VM boots but Linux guest is stuck in timesync loop → timeout (Bug #3)

The net result: Cowork is completely non-functional on Snapdragon ARM64 out of the box, despite:

  • The Cowork Readiness Check returning "SUPPORTED"
  • Virtual Machine Platform being enabled
  • CoworkVMService being installable and startable
  • The HCS VM itself starting successfully

---

Bug #4: Session Lock Files and Cache Not Cleaned Up on Shutdown — VM Fails on Reconnect to Existing Session

Symptom

After Claude Desktop is closed (normally or force-killed), stale lock files, cache files, and session state remain in local-agent-mode-sessions\. On next launch, Claude Desktop reads this stale state and attempts to reconnect the VM to the old session context — which fails because the VM has a new runtime ID. The result: Cowork works fine in a new session but consistently times out or hangs when reopening an existing session.

Specifically observed:

  • audit.jsonl is held open by Claude Desktop processes even after the UI is closed
  • cowork-gb-cache.json, cowork-clientdata-cache.json, cowork-policy-limits-cache.json persist across restarts and are read back on next launch
  • The VM is started fresh (new runtime ID, new HVSock port) but Claude Desktop tries to connect it to the old session state, causing a state mismatch
  • Outside the affected session (new session) Cowork works normally within seconds — proving the VM itself is functional and the problem is session-state-specific

Root Cause

Claude Desktop does not perform session cleanup on shutdown. Specifically:

  1. No lock release on exit: audit.jsonl and related session files are kept open with exclusive locks. On abrupt shutdown (sleep/wake, force-kill, crash), these locks are never released. On next start, Claude Desktop finds the locks and either fails to write or reads stale/corrupt state.
  1. Cache files not invalidated: Session cache files (cowork-gb-cache.json, cowork-clientdata-cache.json) store VM-session-specific state (runtime IDs, connection parameters) that is invalid after a VM restart. These are never cleared on shutdown, so Claude Desktop reads stale connection parameters on next launch and attempts to use them with a new VM — which fails.
  1. No graceful session teardown: When the VM is stopped (either by shutdown or timeout), the session's expected VM state is not reset to "uninitialized". On next launch, Claude Desktop sees a session that appears "configured" (because the cache says so) but the actual VM has a new identity — causing call 'configure' first errors in the logs.
  1. "Reinstall workspace" does not fix this: The built-in reinstall button explicitly preserves sessiondata.img and rootfs.img.zst — making it ineffective for this failure mode.

Evidence

  • New Cowork session: works within seconds on same hardware
  • Existing Cowork session after restart: always times out or hangs
  • Manual deletion of cowork-gb-cache.json, cowork-clientdata-cache.json, cowork-policy-limits-cache.json from the session directory allows reconnection
  • audit.jsonl remains locked by a dead process: The process cannot access the file because it is being used by another process

Expected Behavior

On graceful shutdown, Claude Desktop should:

  • Release all file locks on session files
  • Invalidate or clear VM-session-specific cache entries (runtime IDs, connection parameters)
  • Write a "session suspended" marker so the next launch re-initializes the VM connection

On crash/force-kill recovery, Claude Desktop should:

  • Detect stale locks on startup (files locked by a process that no longer exists)
  • Automatically clear them before attempting VM connection
  • Never reuse cached VM runtime IDs or HVSock connection parameters from a previous session

Impact

This bug affects all Windows installations, not just ARM64. On ARM64 it compounds with Bug #3 to make recovery nearly impossible without manual PowerShell intervention. The built-in "Reinstall workspace" button does not help.

---

Combined Impact (All Four Bugs)

| # | Bug | Platform | Workaround available |
|---|---|---|---|
| 1 | CoworkVMService startup race condition | Windows ARM64 + x64 | Manual Start-Service + Scheduled Task |
| 2 | vm_bundles download silent failure when elevated | Windows ARM64 + x64 | Launch via explorer.exe (non-elevated) |
| 3 | Linux guest timesync loop / year 2145 (HVSock timeout) | Windows ARM64 only | None — requires fix in Linux image |
| 4 | Session lock/cache not cleaned up on shutdown | Windows ARM64 + x64 | Manual deletion of cache files |

| #1 Service startup race | Declare vmms / HvHost as explicit SCM dependencies in CoworkVMService manifest; add auto-restart and retry logic in Claude Desktop |
| #2 Elevated download failure | Detect elevated context and either warn user or spawn download in user context via CreateProcessAsUser / explorer.exe shell delegation |
| #3 ARM64 timesync | Fix Linux guest to handle EINVAL from ClockSettime gracefully (fall back to NTP or CMOS); or fix HCS VM config to pass a valid initial clock on ARM64 |

What Should Happen?

Requested Fixes

| Bug | Fix |
|---|---|
| #1 Service startup race | Declare vmms / HvHost as explicit SCM dependencies in CoworkVMService manifest; add auto-restart and retry logic in Claude Desktop |
| #2 Elevated download failure | Detect elevated context and warn user or spawn download in user context via explorer.exe shell delegation |
| #3 ARM64 timesync | Fix Linux guest to handle EINVAL from ClockSettime gracefully; or fix HCS VM config to pass valid initial clock on ARM64 |
| #4 Session lock/cache cleanup | Release all file locks and invalidate VM-session cache on shutdown; detect and clear stale locks on startup; never reuse cached VM runtime IDs across restarts |

Error Messages/Logs

**cowork-service.log** (last 30 lines, showing successful HCS start but no daemon connection):

[VM] Got VM runtime ID: f4b7af0c-7ae7-5128-bd9c-047050608b69
[HVSock] Listening on port 51234 (service GUID: 0000c822-facb-11e6-bd58-64006a7986d3)
[RPC] Server started, waiting for sdk-daemon connection on port 51234
[VM] Granted VM access to: rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx, sessiondata.vhdx
[HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] VM started successfully
[Console] Connected to daemon console pipe


**coworkd daemon log** (showing timesync failure loop with year 2145):

2145/05/25 11:03:06 [timesync] ClockSettime failed: invalid argument
2145/05/25 11:03:07 [timesync] ClockSettime failed: invalid argument
2145/05/25 11:03:09 [timesync] ClockSettime failed: invalid argument
[... ~50 further identical entries, no other output ...]


Full logs available on request.

Steps to Reproduce

  1. Install Claude Desktop (ARM64) on a Snapdragon X device running Windows 11
  2. Reboot
  3. Open Claude Desktop → navigate to Cowork
  4. Observe: sandbox never becomes ready (Bug https://github.com/anthropics/claude-code/pull/1 — service stopped)
  5. Delete %APPDATA%\Claude\vm_bundles, right-click Claude Desktop → "Run as Administrator"
  6. Observe: rootfs.vhdx.zst stays at 0 bytes indefinitely (Bug https://github.com/anthropics/claude-code/issues/2 — elevated download fails)
  7. Kill Claude, relaunch normally (non-elevated), wait for download to complete
  8. Observe: VM starts (HcsStartComputeSystem hr=0x0) but times out after 60s (Bug https://github.com/anthropics/claude-code/issues/3 — timesync loop)
  9. Check daemon log: endless [timesync] ClockSettime failed: invalid argument with year 2145

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.13576.0

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

  • #66535 — Cowork sandbox never becomes ready on Windows ARM64 / Snapdragon X Plus
  • #46516 — Cowork not working on Windows ARM64 (Snapdragon X Plus Surface) — tried everything
  • #40198 — Cowork VM fails to start on Windows ARM64 (Samsung Galaxy Book4 Edge)
  • #46033 — Can't run Cowork in Snapdragon X (passes readiness check, still times out)
  • #50674 — Cowork fails on ARM64 despite passing readiness check
  • #30566 — VM not running error on Windows ARM64 (Snapdragon X Elite)

View original on GitHub ↗