[BUG] [BUG] Cowork VM fails to start on Windows ARM64 (Samsung Galaxy Book4 Edge, Snapdragon)
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
- Device: Samsung Galaxy Book4 Edge (NP750XQA-KB2UK)
- Processor: Snapdragon (ARM64)
- OS: Windows 11 Home, Build 10.0.26200
- Claude Desktop: v1.1.9310.0 (MSIX, ARM64)
- Architecture confirmed: Arm64 via Get-AppxPackage
Problem
Cowork workspace fails to start. Three different errors appear depending on the sequence of troubleshooting steps:
EBUSY: resource busy or locked, open 'C:\Users\darry\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx'VM service not running. The service failed to start.VM connection timeout after 60 seconds
The VM bundle downloads successfully (progress bar completes to 100%), but the VM itself never boots.
Services status
CoworkVMService and vmcompute both exist and can be manually started:
What Should Happen?
Running CoworkVMService Claude
Running vmcompute Hyper-V Host Compute Service
and then Claude Cowork Workspace should run with Virtual Machine
Error Messages/Logs
However, even with both running, Cowork times out after 60 seconds.
## What I've tried
- Enabled VirtualMachinePlatform via Admin PowerShell (succeeded, RestartNeeded: False)
- `Microsoft-Hyper-V-All` returns "Feature name is unknown" on ARM64
- Manually started vmcompute and CoworkVMService — both start, but VM still times out
- Deleted vm_bundles folder and let Claude re-download fresh — same result
- Full uninstall and reinstall of Claude Desktop
- Multiple reboots
- Stopped all services and processes before relaunching
- BIOS (Samsung Aptio Setup Utility) has no virtualization toggle — Snapdragon has no VT-x/AMD-V equivalent
- `VirtualizationFirmwareEnabled` reports False on ARM64 (expected — not applicable to Snapdragon)
## Log file locations
Logs are at: `C:\Users\darry\AppData\Roaming\Claude\logs\`
- cowork-service.log (736 KB)
- cowork_vm_node.log (275 KB)
- coworkd-user-S-1-5-21-*.log (495 KB)
- main.log (9.8 MB)
## Related issues
- #29428 (VM service not running — Windows 11 Home)
- #30566 (VM not running on Snapdragon X Elite)
- #28779 (ARM64 installer issues on Snapdragon X)
- #32004 (Virtual Machine Platform not available despite features enabled)Steps to Reproduce
AS above
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Desktop:** v1.1.9310.0 (MSIX, ARM64)
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
cowork-service.log
coworkd-user-S-1-5-21-3309502803-3079381605-1452027300-1001.log
coworkd.log
main1.log
claude_vm_node.log
main.log
cowork_vm_node.log
claude.ai-web.log
unknown-window.log
gpu-info.json
mcp-info.json
supported-features-info.json
system-info.txt
61 Comments
Can reproduce on a different Snapdragon device.
Environment
Symptoms
Same as OP — Cowork spins indefinitely on first setup, VM never boots.
Hyper-V event log shows:
0xC0370103= HCS_E_HYPERV_NOT_INSTALLED — "The virtual machine could not be started because a required feature is not installed."Additional finding:
smol-bin.arm64.vhdxis present in the package resources but is NOT automatically copied to%APPDATA%\Claude\vm_bundles\claudevm.bundleon first launch. Manual copy did not resolve the issue.All Hyper-V features are enabled:
cowork_vm_node.logis never created — failure occurs before logging initializes.This appears to be a Snapdragon ARM64 platform compatibility issue rather than a configuration problem. Happy to provide additional diagnostics if helpful.
#30566 was a similar issue and incorrectly closed as a duplicate. It is not a duplicate of #29428 or #29941. Those issues are about signature verification failures and general service startup errors on x64 hardware. This issue is specifically about Snapdragon ARM64 platform compatibility — the VM fails with
0xC0370103(HCS_E_HYPERV_NOT_INSTALLED) even with all available Hyper-V features enabled.I can reproduce #30566 on a separate Snapdragon ARM64 device (Windows 11 Pro, Claude Desktop v1.1.9310.0 ARM64). The root cause appears to be that Cowork's VM configuration requires a Hyper-V capability that Qualcomm's hypervisor implementation does not expose — this is fundamentally different from the errors in the linked issues.
Please keep both issues open as a distinct ARM64/Snapdragon tracking issue.
Can reproduce on a newer Claude Desktop build.
Environment
claude.ai/api/desktop/win32/arm64/msix/latest/redirect)HypervisorPlatformEnabled,VirtualMachinePlatformEnabledvmmsservice,Get-VMSwitchnot recognized)Symptoms
Same as OP — cycles through all three errors depending on state:
EBUSY: resource busy or lockedonsmol-bin.vhdxVM service not running. The service failed to start.VM connection timeout after 60 secondsNew finding: invalid JSON in Hyper-V Compute logs
The Hyper-V Compute Admin event log shows this error on every Cowork attempt:
This suggests the VM config JSON being passed to the Host Compute Service is empty or malformed. This error appears in
Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-Compute-Admin"and occurs consistently on every startup attempt.What I confirmed
smol-bin.arm64.vhdxIS copied to the bundle directory on this version (v1.1.9493.0) — the log shows it explicitlyadd_plan9_sharesboth complete successfullyvmcomputeservice starts successfully but logs the invalid JSON error abovevm_bundlesand letting it re-download (~11 GB) does not helpRelevant log snippet (
cowork_vm_node.log)Notes
This confirms the issue persists in v1.1.9493.0 (newer than OP's v1.1.9310.0). Combined with the Pro user above also failing, this is clearly a Snapdragon ARM64 platform issue regardless of Windows edition. The
0xC037010Dinvalid JSON error may be a useful lead for the team.please keep open. Thanks
Also affected by this issue.
Device info:
Surface Pro
OS: Windows 11 Home 25H2
Architecture: ARM64
Claude Desktop version: v1.1.9493.0 (ARM64, non-Store install)
Symptoms:
The Cowork workspace fails to start with "VM connection timeout after 60 seconds." On subsequent attempts, it fails with "VM service not running. The service failed to start."
What I've tried (all failed):
Confirmed virtualization is enabled in Task Manager
Enabled VirtualMachinePlatform, HypervisorPlatform, and WSL features
Confirmed CoworkVMService is running and set to Automatic
Deleted vm_bundles folder and let Claude re-download
Full uninstall and reinstall of Claude Desktop
Multiple reboots
From cowork_vm_node.log:
The VM boots, copies smol-bin.arm64.vhdx, creates the network, and starts the VM, but gets stuck at "Still waiting for guest connection..." and times out after 60 seconds. On the next attempt, the service itself fails to start at the "Configuring Windows VM service" step.
This appears to be the same ARM64-specific issue. Regular Claude chat works fine — only Cowork is affected.
Facing same issue https://github.com/anthropics/claude-code/issues/39161
facing same issue on: Asus A14, Snapdragon X Elite, ARM64
OS: Windows 11 Pro (upgraded from Home), Hyper-V enabled, vmms running
Claude: v1.1.9669.0 ARM64
Facing same issue on Thinkpad Thinkbook G7 Snapdragon X Plus, Arm 64
Windows 11 Pro, Hyper-V enabled
Version 1.1.9669 (aea25d)
My Claude says your issue is of the same type as #40147 , #40196, #39527. Let Anthropic pay attention to your issues.
facing same issue on microsoft surface pro 12 inch. Pls help to solve the issue , PLEASE
Yes it’s very annoying. Hopefully this bug is tackled soon. We’re just paying max subscription for product which could do much more
Same issue on Snapdragon X Plus (X1P42100)
Adding another data point for ARM64 Windows.
Environment
ComponentDetailsCPUQualcomm Snapdragon X Plus X1P42100 (Oryon, 3.24 GHz)OSWindows 11 Pro (ARM64)Claude Desktopv1.569.0.0 (arm64)Claude PlanProHyper-V (all features)EnabledHypervisorPlatformEnabledVirtualMachinePlatformEnabledCoworkVMServiceRunningvmmsRunning / AutomaticvmcomputeRunninghypervisorlaunchtypeAuto
Symptom
Cowork tab is visible. VM downloads all files successfully (rootfs.vhdx, vmlinuz, initrd, smol-bin.arm64.vhdx). VM boots (vm_boot completed in ~190ms). But the guest never connects -- times out after 60 seconds every time, consistently failing at add_plan9_shares.
Key log lines
[cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported), checking for stale bundle...
[VM:start] Copying smol-bin.arm64.vhdx to bundle [...]
[VM:steps] vm_boot completed (190ms)
[VM:steps] add_plan9_shares completed (4ms)
[VM:start] Still waiting for guest connection... 10219ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 51001ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds
What I tried (all unsuccessful)
Enabled all Hyper-V features via DISM
Enabled HypervisorPlatform separately (was disabled) -- no effect
Manually started vmcompute and CoworkVMService
Deleted vm_bundles folder and let Claude re-download fresh
Full uninstall and reinstall of Claude Desktop
Multiple reboots
Note: Microsoft-Hyper-V-All returns "Feature name is unknown" via Enable-WindowsOptionalFeature on ARM64, but works via DISM. Get-HnsNetwork returns no output -- no virtual switch is created.
Root cause hypothesis
The VM boots but the Linux guest never establishes a vsock connection back to the Windows host. This appears to be a fundamental incompatibility between Cowork's guest networking and Snapdragon's Hyper-V implementation -- not a configuration problem. The 190ms vm_boot time suggests the guest starts but cannot communicate back.
Expected behavior
Cowork should work on ARM64 Windows (Snapdragon X series), or Anthropic should clearly document that it is not supported so users don't spend time troubleshooting.
Steps to reproduce
Install Claude Desktop on Windows 11 Pro ARM64 (Snapdragon X series)
Enable Hyper-V via DISM: Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
Enable HypervisorPlatform: Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform
Reboot
Verify CoworkVMService, vmms and vmcompute are running
Open Claude Desktop and navigate to the Cowork tab
Observe: VM downloads all files and boots, but times out after 60 seconds waiting for guest connection
Check %APPDATA%\Claude\logs\cowork_vm_node.log for "Connection timeout, last completed step: add_plan9_shares"
Same issue here.
Environment:
Symptoms:
PCI\VEN_1AF4&DEV_1043&SUBSYS_00401AF4&REV_01(FlexIO)0xC0370103Tried (all failed):
.auto_reinstall_attemptedflagAlso experiencing this on a new Surface Pro 12 running Windows 11 Home, Version 10.0.26200 Build 26200.
System SKU Surface_Pro_12in_1st_Ed_with_Snapdragon_2110
Processor Snapdragon X Plus (8-core) @ 3.30 GHz, 3244 Mhz, 8 Core(s), 8 Logical Processor(s)
BIOS Version/Date Microsoft Corporation 8.722.235, 02-Jul-25
Claude desktop version: 1.569.0 (49894a) 2026-04-02T20:01:42.000Z
Chat still works, but Cowork doesn't. Summary of conversation I had with Chat to diagnose the issue:
Device: Surface Pro 12 (Snapdragon X, Windows ARM64)
Issue: Cowork fails to start with EBUSY: resource busy or locked, open '...\claudevm.bundle\smol-bin.vhdx'
Troubleshooting steps taken:
Restarted and reinstalled workspace multiple times — no change
vm_bundles\claudevm.bundle directory never gets created
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V returned nothing
systeminfo showed: "A hypervisor has been detected. Features required for Hyper-V will not be displayed" and HypervisorPlatform state: Disabled
Enabled HypervisorPlatform via Enable-WindowsOptionalFeature and rebooted
Error changed to "VM connection timeout after 60 seconds" — VM never successfully starts
Conclusion: Hyper-V platform can be enabled on the device but Cowork's VM still fails to boot, suggesting an ARM64/Snapdragon compatibility issue beyond just the feature flag.
Same problem on SnapDragon in Lenovo Ideapad. Please fix!
Same issue — Snapdragon X Plus (X1P42100), Claude 1.569.0.0, Arm64, Windows 11 Home
CoworkVMService manually starts (STATE 4 RUNNING via sc.exe start) but Claude Desktop still reports "VM service not running"
No logs folder created at %APPDATA%\Claude\logs\
EXIT_CODE 1067 on cold start, EXIT_CODE 0 on manual start
Attaching debug logs below.
Claude-logs-2026-04-07T09-34-07-728Z.zip
Snapdragon X Plus (X1P42100), Claude 1.569.0.0, ARM64, Windows 11 Pro
VM starts successfully but coworkd never responds within 60s timeout.
Manual sc.exe start + immediate Cowork click = same timeout.
Attaching logs.
Issue persists after updating to Claude 1.1062.0 (b81bcd) 2026-04-06T21:20:28.000Z
Update: Still failing on v1.1062.0 (ARM64)
Upgraded to Claude Desktop v1.1062.0 — new UI with
Projects, Dispatch, Ideas menus appeared.
Cowork now shows "Starting Claude's workspace..."
instead of the previous "VM service not running" error,
but still times out after 60 seconds with:
"VM connection timeout after 60 seconds"
Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Claude: v1.1062.0
Cowork is still not functional on ARM64.
Same issue here.
Setup:
Snapdragon X — X126100 (Qualcomm Oryon)
Windows 11 Pro (upgraded from Home specifically for Cowork)
Claude Desktop v1.1062.0.0 (ARM64 package)
Paid Pro subscription
Symptoms:
"VM connection timeout after 60 seconds" every time
CoworkVMService running, VM shows as Running in hcsdiag list, but never connects
No vm_bundles folder created, no cowork_vm_node.log generated
Full reinstall, network cleanup, NAT reconfiguration — nothing helps
Impact:
Purchased Windows Pro upgrade (~145€) trying to fix this before discovering ARM64 is unsupported
Spent several hours troubleshooting
No clear mention of ARM64 incompatibility on the download page or in Cowork documentation
Request:
Please either add ARM64/Snapdragon support or clearly state the limitation on the download page and Cowork docs. The number of Snapdragon PCs is growing fast — this affects a lot of users.
Same issue here.
Device: Samsung Galaxy Book4 (NP750X, not Edge)
Processor: Snapdragon X Plus - X1P42100 - Qualcomm Oryon
OS: Windows 11, Build 26200
Claude Desktop: v1.1062.0.0 (tried both ARM64 and x64 MSIX)
Memory: 16 GB LPDDR5X
Tried everything listed in the original post plus:
Both ARM64 and x64 versions fail. VM bundle downloads fine, VM never boots. This is blocking Cowork entirely on Snapdragon X Plus hardware.
Still failing on v1.1617.0.0 (ARM64)
Upgraded to Claude Desktop v1.1617.0.0
Cowork now reaches "VM connection timeout after 60 seconds"
(previously "VM service not running" on older versions)
Manual sc.exe start CoworkVMService succeeds (STATE 2 START_PENDING)
but Cowork still times out after 60 seconds
Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Claude: v1.1617.0.0
<html>
<body>
<!--StartFragment--><html><head></head><body><p>Hier der vollstaendige Inhalt der Datei zum Reinkopieren:</p>
<hr>
<pre><code class="language-markdown"># Cowork VM startet auf Snapdragon X (ARM64) extrem langsam — RPC-Verbindung erst nach ~9 Minuten, neuere Starts schlagen ganz fehl
Ergänzung zu #40198 — gleiche Plattform, neue Diagnose-Daten aus den Logs.
System
Beobachtetes Verhalten
UI zeigt: "Fehler beim Starten von Claudes Arbeitsbereich — VM connection timeout after 60 seconds"
Vorher (vor dem Update auf 1.1062.0) lautete die Fehlermeldung:
> failed to add Plan9 share 'g': HcsWaitForOperationResult failed with HRESULT 0x80070003
Der Plan9-
g-Fehler ist erklärbar (siehe #44486): LaufwerkG:war ein Cloud-Drive (virtuelles Dateisystem, nicht als Plan9 mountbar). Nachdem das Cloud-Drive beendet wurde, ist der Plan9-Fehler weg — die VM startet auf Host-Seite erfolgreich, aber die RPC-Verbindung aus der Gast-VM zurück zum Host kommt nicht innerhalb des 60-Sekunden-Timeouts zustande.Logs — das Eigentliche
Host-Seite (
cowork-service.log)Auf Host-Seite läuft alles glatt:
``
[HCS] HcsStartComputeSystem returned: hr=0x0
[HCS] HcsModifyComputeSystem returned: hr=0x0 (Plan9 share "c" — C:\)
[VM] VM started successfully
[Console] Connected to daemon console pipe
Danach: nichts mehr. Der Daemon in der VM meldet sich heute überhaupt nicht.
Gast-Seite (
coworkd/user-…log)Hier wird es interessant. Beim aktuellen Start gibt es keinen einzigen Eintrag, obwohl der Service-Log "VM started successfully" zeigt. Der Linux-Daemon in der VM produziert keinerlei Konsolenausgabe.
Bei früheren Starts (vor dem 1.1062.0-Update) hat es funktioniert, aber mit massiven Verzögerungen:
``
HH:16:23 [coworkd] checking for Hyper-V host
HH:16:23 [hyperv] modules loaded successfully
HH:16:26 [tapvsock] connected to host network, bridge running
… ~9 Minuten Stille …
HH:25:37 [proxy] CA certificate installed to system trust store
HH:25:37 [rpc] connecting to host CID=2 port=51234
HH:25:37 [rpc] connected successfully
Zwischen
tapvsock connectedundproxy CA installedliegen rund 9 Minuten. Während dieser Zeit passiert in der VM nichts Sichtbares — die CA-Generierung/Installation hängt offenbar.Bei einem anderen Boot war die Lücke sogar noch absurder: tapvsock verbunden, dann RPC-Verbindung erst nach Suspend/Resume des Hosts (mehrere Stunden später).
60-Sekunden-Timeout vs. 9-Minuten-Realität
Der vom UI gemeldete Timeout liegt bei 60 Sekunden. Auf dieser ARM64-Plattform braucht der VM-Boot bis zum funktionsfähigen RPC im besten Fall ~9 Minuten, im aktuellen Zustand offenbar gar nicht mehr. Das Timeout ist für ARM64 unrealistisch knapp.
Vermutete Ursachen
vmlinuz/initrdim VM-Bundle nicht ARM64-optimiert sind oder weil bestimmte Init-Schritte (CA-Generierung?) auf der Snapdragon-Plattform sehr langsam laufen.vmlinuz/initrd/coworkdetwas geändert, das auf ARM64 jetzt komplett bricht statt nur langsam zu sein.Was hilfreich wäre
</code></pre>
<hr>
Same issue on a Surface Pro 12in 1st Edition with Snapdragon X Plus (8-core).
The interesting is that I have another Snapdragon Surface (laptop) that works fine !?
Why ?
Both using Claude Desktop Version 1.1617.0.0
Both 16GB RAM
Both Windows Home 26200.8117
Difference:
The one that works is a Surface Laptop 7th Edition (Model 2037) with Snapdragon X 12-core (X1E80100)
Upgraded to Windows Pro on my Surface Pro 12in....
Then, added Windows Sandbox feature to make sure it was working and upgraded to Pro, and it was.
Reinstalled Hyper-V features and Claude Desktop and but still not working.
Still failing on v1.2773.0.0 (ARM64)
Upgraded to Claude Desktop v1.2773.0.0
CoworkVMService STATE 4 RUNNING confirmed via sc.exe query
but Cowork still times out: "VM connection timeout after 60 seconds"
Note: Cowork worked once randomly on a previous session
but has not been reproducible since.
Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Claude: v1.2773.0.0
Full timeline update (all versions, ARM64 Snapdragon X Plus X1P42100):
v1.569.0.0 — Windows 11 Home → Pro
Error: "VM service not running"
CoworkVMService starts manually (STATE 4) but Claude
Desktop still reports "VM service not running"
No logs created at %APPDATA%\Claude\logs
EXIT_CODE 1067 on cold start
v1.1062.0 — New UI with Projects, Dispatch, Ideas menus
Error changed to: "VM connection timeout after 60 seconds"
Progress: VM now attempts to boot instead of failing immediately
v1.1617.0.0
Error: "VM connection timeout after 60 seconds"
Manual sc.exe start CoworkVMService succeeds (STATE 2)
but Cowork still times out after 60 seconds
v1.2773.0.0 (current)
CoworkVMService confirmed STATE 4 RUNNING via sc.exe query
Cowork still times out: "VM connection timeout after 60 seconds"
Note: Cowork worked once randomly but was not reproducible
Summary: Each version shows progress (error message changed)
but coworkd inside the Linux VM never responds within 60 seconds
on ARM64 Snapdragon hardware.
Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Cowork on ARM64 (Snapdragon X) — Successful Test Report
Date: April 15, 2026
Author: Andy Schock
GitHub Issue: anthropics/claude-code#40198
---
Summary
Cowork mode is now functional on a Snapdragon X ARM64 laptop. This document details the environment, the prior issues encountered, and the technical steps taken to confirm a successful session — culminating in a simple file-creation test that proves end-to-end functionality (VM boot → guest connection → sandbox execution → file I/O to the user's mounted workspace).
---
Environment
| Component | Detail |
|---|---|
| Device | Snapdragon X laptop |
| OS | Windows 11 Home 24H2 (Build 26200) |
| Claude Desktop | v1.1.9493.0 (ARM64 MSIX) |
| Install source |
claude.ai/api/desktop/win32/arm64/msix/latest/redirect|| Virtualization |
HypervisorPlatformEnabled,VirtualMachinePlatformEnabled || Full Hyper-V | Not available (Windows 11 Home — no
vmmsservice) |---
Prior Issues (Documented in GitHub Comment)
Before this successful session, Cowork on this ARM64 device consistently failed. The symptoms cycled through three errors depending on state:
EBUSY: resource busy or lockedonsmol-bin.vhdxVM service not running. The service failed to start.VM connection timeout after 60 secondsRoot Cause Identified
The Hyper-V Compute Admin event log revealed an invalid JSON error on every Cowork startup attempt:
This indicated that the VM configuration JSON being passed to the Host Compute Service (
vmcompute) was empty or malformed. Despitesmol-bin.arm64.vhdxbeing correctly copied and the boot sequence completing throughadd_plan9_shares, the guest never responded — the host polled for 60 seconds and timed out.What Did NOT Fix It
vm_bundlesand re-downloading (~11 GB)vmcomputeservice manually---
What Changed (Resolution)
Between the initial failure report and this successful test, Anthropic shipped updates to Claude Desktop that resolved the ARM64 VM guest connection issue. The fix addressed the malformed JSON configuration that was being passed to the Host Compute Service, allowing the lightweight VM to boot and establish a guest connection on ARM64/Snapdragon hardware.
---
Successful Test — Technical Steps
Step 1: Launch Cowork Session
Opened Claude Desktop (v1.1.9493.0, ARM64 MSIX) and initiated a new Cowork session. The VM boot sequence completed successfully — no
0xC037010Derrors in the Hyper-V Compute Admin log, and the guest connection was established without timeout.Step 2: Select Workspace Folder
Selected a local folder ("Cowork test") as the workspace directory. This folder was mounted into the sandbox VM via Plan9 file shares, making it available for read/write operations from within the Cowork session.
Step 3: File Creation Test
Issued a simple request: "Create a .txt file in this folder that says 'Hello World!'"
Claude executed the following within the sandboxed Linux environment:
Hello World.txtto the mounted workspace folderStep 4: Verification
The presence of
Hello World.txtin the user's local "Cowork test" folder confirms the full pipeline is working:| Stage | Status |
|---|---|
| ARM64 VHDX image copy | Successful |
| VM boot (
vmcompute/ HCS) | Successful || Guest connection established | Successful |
| Plan9 share mount (workspace) | Successful |
| Sandbox code execution | Successful |
| File I/O to host filesystem | Successful |
---
Conclusion
Cowork mode is now fully operational on Snapdragon X ARM64 hardware running Windows 11 Home. The prior
0xC037010Dinvalid JSON error and 60-second connection timeout have been resolved. This test confirms end-to-end functionality from VM startup through file delivery to the user's local filesystem.---
References
Hello World.txt(created in Cowork session, opened successfully in Notepad)Still failing on v1.2773.0.0, Asus A14 Snapdragon X Elite, Windows 11 Pro
The fix reported in the resolution comment (v1.1.9493.0) has not resolved the issue on this device. Running v1.2773.0.0 ARM64, Hyper-V fully enabled, vmms running. Log pattern identical to original report:
[VM:steps] vm_boot completed (141ms)
[VM:steps] add_plan9_shares completed (4ms)
Still waiting for guest connection... [60s timeout]
Last completed step: add_plan9_shares
The reported fix appears device-specific. The guest connection timeout on Snapdragon X Elite persists on the latest version.
I can confirm: Still failing to start Claude's workspace on version 1.2773.0 (884b37) on my Asus Zenbook A14 Snapdragon(R) X Elite - X1E78100 - Qualcomm(R) Oryon(TM) CPU (3.42 GHz), Win 11 Pro too.
HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80004001: {"Error":-2147467263,"ErrorMessage":"Ikke implementeret","ErrorEvents":[{"Message":"'cowork-vm-a5c25623' kunne ikke starte. (Virtuel maskine-id C0ABF616-2674-51CD-9002-504270ADFA61)","Provider":"51ddfa29-d5c8-4803-be4b-2ecb715570fe","EventId":12030,"Flags":13,"Data":[{"Type":"String","Value":"cowork-vm-a5c25623"},{"Type":"String","Value":"C0ABF616-2674-51CD-9002-504270ADFA61"}]},{"Message":"'cowork-vm-a5c25623' Microsoft Virtual BIOS (Forekomst-id AC6B8DC1-3257-4A70-B1B2-A9C9215659AD): Start var ikke mulig pga. fejl 'Ikke implementeret' (0x80004001). (Virtuel maskine-id C0ABF616-2674-51CD-9002-504270ADFA61)","Provider":"51ddfa29-d5c8-4803-be4b-2ecb715570fe","EventId":12010,"Flags":5,"Data":[{"Type":"String","Value":"cowork-vm-a5c25623"},{"Type":"String","Value":"C0ABF616-2674-51CD-9002-504270ADFA61"},{"Type":"String","Value":"Microsoft Virtual BIOS"},{"Type":"String","Value":"%%2147500033"},{"Type":"String","Value":"0x80004001"},{"Type":"String","Value":"AC6B8DC1-3257-4A70-B1B2-A9C9215659AD"},{"Type":"String","Value":""}]}],"Attribution":[{"OperationFailure":{"Detail":"Start"}},{"VirtualDeviceFailure":{"Detail":"PowerOnCold","Name":"Microsoft Virtual BIOS","DeviceId":"ac6b8dc1-3257-4a70-b1b2-a9c9215659ad","InstanceId":"ac6b8dc1-3257-4a70-b1b2-a9c9215659ad"}}]}
@sea-andy ,
I have 2 Microsoft Surfaces, both with ARM processors.
I don't know why, but Cowork works in one of those computers.
1- Surface Pro 12in 1st Edition with Snapdragon X Plus (8-core).
Claude Desktop, updated 16/April
Windows 26200.8117
16GB RAM
--> Cowork does NOT work. Same error as you reported.
2- Surface Laptop 7th Edition (Model 2037) with Snapdragon X 12-core (X1E80100)
Claude Desktop, updated 16/April
Windows 26200.8117
16GB RAM
--> Cowork mysteriously works.
Obs:
On my second Surface device (the working one), I installed several Windows features— such as Virtual Machine — using scripts months before installing Claude Desktop. Windows Home doesn't normally allow installation of these features through the Control Panel, but I needed them at the time, so I forced the installation via scripts.
This might explain why that one works.
Please let me know if (and how) I can use this one to help the community to workaround this bug.
Still failing on v1.2773.0 (ARM64 MSIX) — 0xC037010D persists
Environment:
Snapdragon X, Windows 11 Home 24H2, Build 26200
Claude Desktop v1.2773.0.0 (ARM64 MSIX, Claude_pzs8sxrjxfjjc)
VirtualMachinePlatform Enabled, HypervisorPlatform Enabled
Full Hyper-V: Disabled (all Microsoft-Hyper-V-* components disabled)
Matches @andyschock's working config exactly
Symptom: VM boots through add_plan9_shares, guest never connects, 60-second timeout. Identical to the original report.
Root cause still present: 0xC037010D invalid JSON error fires on every Cowork attempt:
The specified property query is invalid: The virtual machine or container
JSON document is invalid. (0xC037010D, 'Invalid JSON document '$'').
Source: Get-WinEvent -LogName "Microsoft-Windows-Hyper-V-Compute-Admin"
What I've tried (none resolved it):
Disabled all Microsoft-Hyper-V-All components (clean match to working config)
Deleted vm_bundles, let bundle re-download from scratch — error persists
Stopped/restarted vmcompute service
Reinstalled Claude Desktop
Multiple reboots
...
[VM:start] Connection timeout, last completed step: add_plan9_shares
The 0xC037010D appears in the Hyper-V Compute Admin log at every attempt, consistently. The fix referenced in @andyschock's success report does not appear to resolve the issue on this device.
UPDATE: WSL2 boots and runs successfully on this device (Ubuntu 24.04 via wsl --install), confirming HCS and vmcompute are fully functional on Snapdragon X + Win11 Home + VirtualMachinePlatform + HypervisorPlatform. The 0xC037010D invalid JSON error is specific to Cowork's VM configuration generation, not a platform-level issue. The HCS can create, boot, and connect to guest VMs — Cowork's config JSON is the problem.
RESOLVED: Installing WSL2 (wsl --install Ubuntu) fixed it. The missing dependency was the WSL2 Linux kernel, which HCS lightweight VMs require to boot a guest. VirtualMachinePlatform + HypervisorPlatform alone are insufficient — WSL2 must also be installed.
Samsung Galaxy Book4 Edge
ARM64 / Snapdragon X
WSL2 installé ✅, Hyper-V activé ✅
Bloque à add_plan9_shares → timeout guest connection
HELP !
Installing WSL2 (wsl --install Ubuntu) do NOT fix it for me.
"Failed to start Claude's workspace" status on Claude version 1.3109.0 (35cbf6) on Snapdragon(R) X Elite - X1E78100 - Qualcomm(R) Oryon(TM) CPU (3.42 GHz) Windows 11 Pro build 26200.8246 🙁
Has this been fixed yet? I don't see it on my computer.
On Fri, Apr 17, 2026, 4:27 AM Trogind @.***> wrote:
----
Secured by Paubox - HITRUST certified
https://www.paubox.com
----
Its not fixed yet, cowork worked for me only once by a fluke when i was trying and playing with installing ubuntu etc. It has never worked since and shows vm timeout or vm already running error
WORKING on v1.2773.0.0 (ARM64)
Cowork is now working on Snapdragon X Plus (X1P42100)
What changed:
Previously failing across v1.569.0.0, v1.1062.0, v1.1617.0.0
with "VM connection timeout after 60 seconds"
Confirmed stable after system restart.
Note: Not sure if selecting a Working Folder was the key factor
or if v1.2773.0.0 fixed the issue — but this combination works.
Device: Snapdragon X Plus (X1P42100)
OS: Windows 11 Pro ARM64
Claude: v1.2773.0.0
it works for me too. Yay !! Thanks to the Claude dev team :)
My version is 1.3883.0 (93ff6c), and the update option tells me I'm on the latest.
For me, the behavior has really actually changed - it's no longer showing the timeout error....
However, when requesting a task from CoWork, I noticed some things that made me doubt whether they are actually using the VM. So, it seems they "worked around" the issue, not really solving it:
....
Ran 3 commands, loaded tools >
The Linux sandbox isn't available right now, so I can't actually run a simulated test. I've instead carefully hand-traced the algorithm against the edge cases that typically break batch scripts. Here's the trace so you can see the logic is sound:
....
To test, I asked Cowork the following bat script:
_Create and test a bat file to rename all files on a folder. The pattern is: the file should begin with YYYYMM + current name and extension. The YYYY is the year and MM is the month. The bat should use the file created date (year and month) - 1. For example, if the file created date is 202602 (February, 2026), the name should be 202601 + Currente name._
Appears to work for me. as well Lenovo Thinkbook SbapdragonX Plus.
Its working but there are issues.
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Cowork on ARM64 Snapdragon X — Recurring Failure Report</h1>
<p><strong>
<strong>Date range of observations:</strong> April 7 – April 24, 2026
<strong>Related issue:</strong> <a href="https://github.com/anthropics/claude-code/issues/40198">anthropics/claude-code#40198</a></p>
<hr>
<h2>Environment</h2>
Component | Detail
-- | --
Device | Snapdragon X laptop
CPU | Snapdragon(R) X — X126100 — Qualcomm(R) Oryon(TM)
RAM | 15.61 GB (typical usage 78–82% during issue)
OS | Windows 11 Home 24H2
OS Build | 26100.1.arm64fre.ge_release.240331-1435
Claude Desktop | 1.3883.0 (ARM64 MSIX)
Install source | claude.ai/api/desktop/win32/arm64/msix/latest/redirect
VM Bundle version | 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
SDK version | 2.1.111
Virtualization | HypervisorPlatform Enabled, VirtualMachinePlatform Enabled
Full Hyper-V | Not available (Home edition — no vmms service)
<h2>Reproducibility</h2>
<ul>
<li>Mode 1 + Mode 2: Near-deterministic. Sleep/resume while Claude is running triggers within one cycle roughly half the time. Two cycles almost always trigger it.</li>
<li>Mode 3: Was deterministic for a ~24 hour window on April 23 regardless of user action. Appears tied to a transient bad coworkd release (coworkd auto-updates via smol-bin on every launch, so exact version is hard to pin down).</li>
</ul>
<h2>Suggested Diagnostic Additions for Future Releases</h2>
<ol>
<li>Log <code>coworkd</code> version explicitly on every boot (user cannot currently tell what guest version is running).</li>
<li>Log guest-side mke2fs stderr in full on format failure.</li>
<li>Expose <code>debugLoggingEnabled</code> toggle more prominently — user had to ask to find it.</li>
<li>Include Windows event log captures (<code>Microsoft-Windows-Hyper-V-Compute-Admin</code>) in log export zip — the <code>0xC037010D</code> error only appears there on first occurrence.</li>
</ol>
<hr>
<h2>Attached Evidence</h2>
<p>The log export zips from the following timestamps contain the raw data for all the above:</p>
<ul>
<li><code>Claude-logs-2026-04-17T17-03-58-900Z.zip</code> (Mode 1, Mode 2)</li>
<li><code>Claude-logs-2026-04-20T19-20-57-110Z.zip</code> (Mode 4 onset)</li>
<li><code>Claude-logs-2026-04-20T19-49-13-664Z.zip</code> (Mode 4 after bundle delete)</li>
<li><code>Claude-logs-2026-04-20T20-19-57-125Z.zip</code> (Mode 4 after clean reinstall)</li>
<li><code>Claude-logs-2026-04-20T20-34-55-081Z.zip</code> (Mode 4 with debug logging enabled)</li>
<li><code>Claude-logs-2026-04-23T18-10-08-745Z.zip</code> (Mode 3 — SCSI regression)</li>
<li><code>Claude-logs-2026-04-23T18-16-43-386Z.zip</code> (Mode 3 — post sessiondata delete)</li>
<li><code>Claude-logs-2026-04-24T16-29-47-425Z.zip</code> (Mode 2 — sleep/resume zombie)</li>
</ul>
<p>Happy to provide any or all of these on request.</p>
<hr>
<
Date range of observations: April 7 – April 24, 2026
Related issue: [anthropics/claude-code#40198](https://github.com/anthropics/claude-code/issues/40198)
---
Environment
| Component | Detail |
|---|---|
| Device | Snapdragon X laptop |
| CPU | Snapdragon(R) X — X126100 — Qualcomm(R) Oryon(TM) |
| RAM | 15.61 GB (typical usage 78–82% during issue) |
| OS | Windows 11 Home 24H2 |
| OS Build |
26100.1.arm64fre.ge_release.240331-1435|| Claude Desktop | 1.3883.0 (ARM64 MSIX) |
| Install source |
claude.ai/api/desktop/win32/arm64/msix/latest/redirect|| VM Bundle version |
5680b11bcdab215cccf07e0c0bd1bd9213b0c25d|| SDK version | 2.1.111 |
| Virtualization |
HypervisorPlatformEnabled,VirtualMachinePlatformEnabled || Full Hyper-V | Not available (Home edition — no
vmmsservice) |---
Summary
Cowork has been intermittently broken on this device across multiple sessions between April 7 and April 24. The failure manifests as at least four distinct failure modes that appear to be related but are triggered by different conditions. Some sessions succeed; the next day the same hardware + app combination fails. Full reinstall, bundle deletion,
vmcomputerestart, and Windows reboot provide only temporary relief. The most common trigger is a Windows sleep/resume cycle while Claude Desktop is running.---
Failure Modes Observed
Failure Mode 1: Invalid JSON to Host Compute Service (0xC037010D)
Matches the symptoms reported in [issue #40198](https://github.com/anthropics/claude-code/issues/40198).
Symptom:
HcsShutdownComputeSystemorHcsCreateComputeSystemfails with:Observed in
cowork-service.log:This is the same error documented in #40198 and not yet resolved on this hardware. Occurs most reliably during VM shutdown after a sleep/resume cycle.
Failure Mode 2: Zombie VM State After Sleep/Resume
Symptom: App reports
"VM is already running"on every subsequent boot attempt. Auto-recovery gives up with"Skipping auto-reinstall (already attempted once)".Reliable reproduction:
VM is already runningLog excerpt (
cowork_vm_node.log, 2026-04-24):User-side workaround (every occurrence):
Then relaunch Claude. The app itself does not attempt this or recommend it — the user must know the workaround.
Suggestion: On
VM is already runningerrors, have the app callStop-Service vmcomputeprogrammatically (or prompt the user with a one-click "Reset VM Service" button) before attempting re-creation, instead of silently giving up after one auto-reinstall attempt.Failure Mode 3: SCSI Device Ordering Regression
Symptom: Guest Linux finds smol-bin and sessiondata on the same device node, causing mke2fs to fail repeatedly against a read-only disk in a tight restart loop (logged 294+ consecutive failures in one session).
Working boot enumeration (April 21–22):
Broken boot enumeration (April 23, same hardware, no user action):
The host-side SCSI config (from
cowork-service.log) appeared identical between the working and broken boots — samerootfs.vhdx,smol-bin.vhdx,sessiondata.vhdxattachments granted to the VM. But the guest kernel enumerated them differently.coworkdthen entered a tight restart loop:starting coworkd→ fail to format → restart → fail again, at ~2 second intervals for hundreds of iterations. There is no backoff.Suggestions:
coworkdshould use a stable device identifier (UUID, label, or serial) rather than SCSI enumeration order to identify the session disk vs. smol-bin.coworkdshould stop retrying and surface a clear error to the host.Failure Mode 4: VM Connection Timeout with Zero Guest Output
Reported separately on April 20 — resolved itself between April 21 and April 22, likely by a server-side or app update. Documented here for completeness because it was severe:
Symptom: Host reports
Daemon console read error: No process is on the other end of the pipe. Guest-side log (coworkd-user-*.log) has zero new entries — kernel never reaches userspace far enough to initialize virtio-serial.Host log excerpt:
All three VHDX files (
rootfs.vhdx,vmlinuz,initrd) freshly downloaded with validated checksums. Full app reinstall + cleanAppDatawipe did not resolve. Went away on its own.---
What User-Side Troubleshooting Did NOT Fix
Stop-Service vmcompute; Start-Service vmcompute(fixes Mode 2 only, temporarily)vm_bundles\claudevm.bundleand letting Claude re-extractsessiondata.vhdxspecificallyAppData\Local\Packages\Claude_pzs8sxrjxfjjcwipe + reinstallMicrosoft-Hyper-V-AllON vs OFF)What the App Itself Does NOT Do
vmcomputerestart automaticallyEPERMerrors (observed on April 20, caused extraction to fail silently)---
Timeline
| Date | Events |
|---|---|
| Apr 7–8 | Initial Cowork successful runs |
| Apr 16–17 | Mode 1 + Mode 2 (zombie VM after sleep). Resolved by
vmcomputerestart + WSL2 install || Apr 18 | Last successful Cowork session:
20:04:45|| Apr 20 | App auto-updated 1.3109 → 1.3561. Mode 4 hit. Multiple reinstall attempts, clean install, bundle deletion — no resolution. Guest kernel produces zero output. |
| Apr 21–22 | Cowork working again (no user action) |
| Apr 23 | App updated to 1.3883.0. Mode 3 (SCSI ordering) hit. 294+ failed boot attempts in one session. User deleted
sessiondata.vhdx— no effect. || Apr 23 evening / 24 overnight | 4 Cowork sessions ran successfully |
| Apr 24 morning | Mode 2 hit after two sleep/resume cycles (07:00 and 08:59). Workaround:
vmcomputerestart |Reproducibility
Suggested Diagnostic Additions for Future Releases
coworkdversion explicitly on every boot (user cannot currently tell what guest version is running).debugLoggingEnabledtoggle more prominently — user had to ask to find it.Microsoft-Windows-Hyper-V-Compute-Admin) in log export zip — the0xC037010Derror only appears there on first occurrence.---
Attached Evidence
The log export zips from the following timestamps contain the raw data for all the above:
Claude-logs-2026-04-17T17-03-58-900Z.zip(Mode 1, Mode 2)Claude-logs-2026-04-20T19-20-57-110Z.zip(Mode 4 onset)Claude-logs-2026-04-20T19-49-13-664Z.zip(Mode 4 after bundle delete)Claude-logs-2026-04-20T20-19-57-125Z.zip(Mode 4 after clean reinstall)Claude-logs-2026-04-20T20-34-55-081Z.zip(Mode 4 with debug logging enabled)Claude-logs-2026-04-23T18-10-08-745Z.zip(Mode 3 — SCSI regression)Claude-logs-2026-04-23T18-16-43-386Z.zip(Mode 3 — post sessiondata delete)Claude-logs-2026-04-24T16-29-47-425Z.zip(Mode 2 — sleep/resume zombie)Happy to provide any or all of these on request.
---
Same issue on Surface Laptop 7 (Snapdragon X Elite, Qualcomm Adreno X1-85).
Device: Microsoft Surface Laptop 7
OS: Windows 11 Home, Version 24H2, Build 26100.8457
GPU: Qualcomm Adreno X1-85, Driver 31.0.112.0 (2025-06-02)
Claude Version: 1.7196.0.0 (MSIX, ARM64)
Symptom: Claude Desktop icon appears in taskbar for 1 second and disappears. No app window opens. CoworkVMService is running.
Key log entry from main.log:
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
Workarounds attempted without success:
Note: The same device model (Surface Laptop 7) with an older Qualcomm driver ran Claude Desktop without issues. The regression appears tied to driver 31.0.112.0. No newer driver is available via Windows Update.
This is a blocker. Claude Desktop is completely unusable on this device. Browser fallback works but Cowork is not available there.
Same issue reproduced on ASUS Zenbook A14 (Snapdragon X)
Hardware/OS:
Symptoms matching this issue:
Diagnostic confirmation that guest kernel never boots:
cowork_vm_node.log(host side):cowork-service.log(host service):coworkdlog (inside VM): completely empty for this boot. The previous boot (before nuclear reset) had normal entries, so logging works — the new guest just never reaches userspace.Bundle is correct ARM64:
vmlinuzfirst bytes4D 5A 40 FA ... 41 52 4D 64("ARMd" magic at offset 0x38, confirming ARM64 Linux kernel image format).smol-bin.arm64.vhdxcopied from app resources (host log: "Copying smol-bin.arm64.vhdx to bundle").What I tried (none fixed it):
Stop-Service CoworkVMService+Start-Service(cleared a zombie VM but new one still fails)sessiondata.vhdxand let it regeneratevm_bundles\claudevm.bundle\(12.76 GB), let app re-download freshrootfs.vhdx.zst/vmlinuz.zst/initrd.zstand decompress — checksums all validated, files all present, guest kernel still doesn't boot.WSL2 works fine on this machine, so ARM64 Hyper-V is functional — the problem appears to be in the distributed kernel/initrd's compatibility with Snapdragon X virtualization, OR the 60s connection timeout is too short for this hardware.
Happy to provide full logs if useful.
I'm hitting the same thing.
Hardware/OS:
Symptoms:
I've tried relaunching Claude, reinstalling the workspace with the link provided, manually deleting the claudevm.bundle folder.
Log entries:
Hitting the same issue.
Hardware/OS:
Symptoms:
Troubleshooting already tried:
The readiness check passing without warning is particularly misleading for ARM users and has led to wasted troubleshooting time and unnecessary expenses. Please prioritise ARM/Snapdragon support.
Adding another data point to support prioritization of this issue.
Environment
Device: Microsoft Surface Laptop, 7th Edition
Processor: Snapdragon X 12-core X1E80100 @ 3.40 GHz (ARM64)
OS: Windows 11 Enterprise, Build 10.0.26100
Error copy pasta
Error Breakdown
Cowork fails immediately on launch with an HCS operation failure — the VM never reaches boot:
Failed to start Claude's workspace
HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80004001
ErrorMessage: "Not implemented"
EventId 12030: 'cowork-vm-39a86248' failed to start. (VM ID: ACCEE0C1-998A-5146-9F28-AB3D0A45A3C9)
EventId 12010: Microsoft Virtual BIOS failed to Power On with Error 'Not implemented' (0x80004001)
Attribution: VirtualDeviceFailure → PowerOnCold → Microsoft Virtual BIOS
Root cause signal: 0x80004001 E_NOTIMPL on PowerOnCold at the Virtual BIOS layer indicates the Hyper-V virtualization stack is invoking an x86/x64-specific code path that has no implementation on Snapdragon/ARM64. This is distinct from the timeout errors reported above — the VM isn't stalling, it's hard-failing at BIOS power-on.
Troubleshooting attempted
Multiple restarts (both Claude desktop and device)
Claude Desktop reinstall
Extended troubleshooting — no change in behavior
Prioritization note
The Surface Laptop 7th Edition is a Microsoft first-party device shipping with Snapdragon X as its standard configuration — this isn't a niche hardware choice. Between this thread and related issues (#29428, #30566, #28779, #32004, #40147, #40196, #39527, +++), it's clear this is a systemic ARM64/Snapdragon compatibility gap affecting a meaningful and growing segment of the Windows user base, including Pro subscribers. Cowork is a paid feature. At minimum, the download page and Cowork documentation should carry a clear ARM64 incompatibility notice until a fix is available.
Adding another data point to support prioritization of this issue.
Environment
dows 11 Enterprise, Build 10.0.26100
Error
Cowork fails immediately on launch with an HCS operation failure — the VM never reaches boot:
Root cause signal: 0x80004001 E_NOTIMPL on PowerOnCold at the Virtual BIOS layer indicates the Hyper-V virtualization stack is invoking an x86/x64-specific code path that has no implementation on Snapdragon/ARM64. This is distinct from the timeout errors reported above — the VM isn't stalling, it's hard-failing at BIOS power-on.
Troubleshooting attempted
Prioritization note
The Surface Laptop 7th Edition is a Microsoft first-party device shipping with Snapdragon X as its standard configuration — this isn't a niche hardware choice. Between this thread and related issues (#29428, #30566, #28779, #32004, #40147, #40196, #39527), it's clear this is a systemic ARM64/Snapdragon compatibility gap affecting a meaningful and growing segment of the Windows user base, including Pro subscribers. Cowork is a paid feature. At minimum, the download page and Cowork documentation should carry a clear ARM64 incompatibility notice until a fix is available.
Same issue on:
Device: Asus Zenbook A14 UX3407RA
Processor: Snapdragon(R) X Elite - X1E78100 - Qualcomm(R) Oryon(TM) CPU (3.42 GHz)
OS: Windows 11 Pro 25H2 Build 26200.8524
Claude Desktop for Windows Version 1.9255.2 (1dc8f7)
Cowork is giving this error; tried reinstalling in full, but still this issue persists:
Failed to start Claude's workspace
HCS operation failed: failed to start VM: HcsWaitForOperationResult failed with HRESULT 0x80004001: {"Error":-2147467263,"ErrorMessage":"Not implemented","ErrorEvents":[{"Message":"","Provider":"51ddfa29-d5c8-4803-be4b-2ecb715570fe","EventId":12030,"Flags":13,"Data":[{"Type":"String","Value":"cowork-vm-c885fde8"},{"Type":"String","Value":"48B57D86-E809-5F8E-9848-BF3636F1E539"}]},{"Message":"","Provider":"51ddfa29-d5c8-4803-be4b-2ecb715570fe","EventId":12010,"Flags":5,"Data":[{"Type":"String","Value":"cowork-vm-c885fde8"},{"Type":"String","Value":"48B57D86-E809-5F8E-9848-BF3636F1E539"},{"Type":"String","Value":"Microsoft Virtual BIOS"},{"Type":"String","Value":"%%2147500033"},{"Type":"String","Value":"0x80004001"},{"Type":"String","Value":"AC6B8DC1-3257-4A70-B1B2-A9C9215659AD"},{"Type":"String","Value":""}]}],"Attribution":[{"OperationFailure":{"Detail":"Start"}},{"VirtualDeviceFailure":{"Detail":"PowerOnCold","Name":"Microsoft Virtual BIOS","DeviceId":"ac6b8dc1-3257-4a70-b1b2-a9c9215659ad","InstanceId":"ac6b8dc1-3257-4a70-b1b2-a9c9215659ad"}}]}
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.
I am seeing lots of people having the same issue but no progress in resolution. Has anyone managed to enable CoWork on Snapdragon ARM64? Is there a path to resolution or a case of too bad/ too sad?
@davidwallie-netizen feels like a too bad/so sad
Heads up, Anthropic!
Better fix this now. Nvidia is about to launch the RTX Spark / N1X, their first ARM-based processor designed as the primary CPU/GPU for Windows PCs and Claude Code will not run on this unless you do.
Same issue on:
Device: ASUS Zenbook A14 UX3407QA
Processor: Qualcomm Snapdragon X1-26-100 - Processore 8C/OctaCore 3GHz
OS: Windows 11 Pro
Claude Desktop for Windows latest version, downloaded yesterday June 2nd.
Same issue here — Snapdragon X Plus, Windows 11 ARM64, Claude Desktop arm64 MSIX installer. VM connection timeout after 60 seconds every time, last completed step add_plan9_shares, daemon log completely empty.
Tried: Hyper-V ✅, Windows Hypervisor Platform ✅, WSL 2 set as default ✅, ran as administrator ✅, firewall allows Claude ✅, downloads.claude.ai reachable ✅, MCP_CONNECT_TIMEOUT_MS set to 120000 ✅. Nothing works.
This has been broken for 2+ weeks. Would appreciate any update on whether ARM64/Snapdragon support is on the roadmap.
<html>
<body>
<!--StartFragment--><html><head></head><body><h2>The VM never attempts to boot — this is a path-resolution bug, not a hardware limitation</h2>
<p>I'm on ARM64 (Snapdragon) / Windows 10 Home / Claude Desktop v1.9255.2.0 ARM64 MSIX package. I've traced the failure to a specific, reproducible mechanism: <strong>MSIX filesystem virtualization causes the app to send a nonexistent path to CoworkVMService.</strong></p>
<p>The VM bundle is fully provisioned. <code>rootfs.vhdx</code> (8.5 GB), <code>vmlinuz</code>, <code>initrd</code>, <code>sessiondata.vhdx</code> — all present and intact. The VM never gets a chance to boot because the service can't find the disk image it's being pointed to.</p>
<h3>The mechanism</h3>
<p>The app correctly identifies the bundle at the real filesystem path. But when it hands off to <code>CoworkVMService</code> during the "Configuring Windows VM service" step, the VHDX path resolves through MSIX filesystem virtualization — which redirects <code>%APPDATA%</code> to a package-scoped location. The service runs outside the MSIX sandbox and can't see the redirected path. Result: "VHDX file not found" on every attempt.</p>
<pre><code>App logs bundlePath → C:\Users\...\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
Service errors on → C:\Users\...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx
File actually exists → C:\Users\...\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx (8.5 GB, intact)
</code></pre>
<p>The MSIX-redirected path is completely empty — no files, no subdirectories. The real path has everything.</p>
<h3>Why this matters beyond my machine</h3>
<p>The OP's error path uses the un-redirected <code>AppData\Roaming\</code> path (suggesting non-MSIX or different packaging behavior), while mine uses the MSIX-virtualized path. This may explain why the OP hits <code>EBUSY</code> (correct path, lock contention) while I hit <code>file not found</code> (wrong path, nothing there). <strong>If other ARM64 MSIX installs have the same path divergence, fixing this single path-resolution issue could clear multiple open ARM64 reports</strong> — including potentially #29428, #30566, #28779, and #32004.</p>
<p>Also worth noting: <code>smol-bin.arm64.vhdx</code> ships with the ARM64 package and copies successfully during startup. Someone on the team is actively building ARM64 VM support — the MSIX packaging layer is blocking it from running.</p>
<h3>What works, what doesn't</h3>
<p>Host-side Cowork file operations (Write, Read, present_files, Filesystem MCP) work normally. The agent-mode loop (Claude Code v2.1.149) runs, dispatches API calls, loads skills and plugins — all without the VM. The failure is isolated to the VM subsystem's path resolution. I can use Cowork for everything that doesn't require the code-execution sandbox (bash/Python).</p>
<h3>Environment</h3>
Component | Value
-- | --
Processor | Snapdragon (ARM64)
OS | Windows 10 Home, Build 10.0.26200
Claude Desktop | v1.9255.2.0 (MSIX, ARM64)
Claude Code | v2.1.149
CoworkVMService | Running, Automatic
vmcompute | Running, Manual
vmms | Absent (expected — Home edition)
<details>
<summary><strong>VM startup log — cowork_vm_node.log (five consecutive failures, same session)</strong></summary>
<p>Each attempt follows the identical sequence. Representative single cycle:</p>
<pre><code>2026-06-04 08:42:36 [info] [KernelBugMonitor] State reset
2026-06-04 08:42:36 [info] [VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-06-04 08:42:36 [info] [VM:start] Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
2026-06-04 08:42:36 [info] [VM:start] VM instance ID: cb7694f8-489a-4e0e-8a37-58b34a32f09a
2026-06-04 08:42:36 [info] [VM:steps] download_and_sdk_prepare started
2026-06-04 08:42:36 [info] [VM:steps] download_and_sdk_prepare completed (2ms)
2026-06-04 08:42:36 [info] [VM:steps] load_swift_api started
2026-06-04 08:42:36 [info] [VM:steps] load_swift_api completed (0ms)
2026-06-04 08:42:36 [info] [VM:start] Copying smol-bin.arm64.vhdx to bundle: C:\Program Files\WindowsApps\Claude_1.9255.2.0_arm64__pzs8sxrjxfjjc\app\resources\smol-bin.arm64.vhdx -> C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx
2026-06-04 08:42:36 [info] [VM:start] smol-bin.arm64.vhdx copied successfully
2026-06-04 08:42:36 [info] [VM:start] Configuring Windows VM service...
2026-06-04 08:42:36 [error] [VM:start] Startup failed: Error: failed to set VHDX path: VHDX file not found: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx
2026-06-04 08:42:36 [info] [VM:start] Skipping auto-reinstall (already attempted once)
</code></pre>
<p>The five attempts occurred at 08:41:16, 08:41:20, 08:42:36, 08:43:23, and 08:44:00. All identical failure. Auto-reinstall marker (<code>.auto_reinstall_attempted</code>, 0 bytes) dates to April 16 — the self-repair path has been exhausted.</p>
</details>
<details>
<summary><strong>Bundle directory listing — files at real path, nothing at MSIX path</strong></summary>
<p><strong>Real path (<code>%APPDATA%\Claude\vm_bundles\</code>) — fully provisioned:</strong></p>
<pre><code>claudevm.bundle\.auto_reinstall_attempted 0 bytes 4/16/2026
claudevm.bundle\.initrd.origin 40 bytes 5/27/2026
claudevm.bundle\.rootfs.vhdx.origin 40 bytes 5/27/2026
claudevm.bundle\.vmlinuz.origin 40 bytes 5/27/2026
claudevm.bundle\initrd 167,025,284 5/27/2026
claudevm.bundle\initrd.zst 164,952,826 5/14/2026
claudevm.bundle\rootfs.vhdx 9,118,416,896 5/27/2026
claudevm.bundle\rootfs.vhdx.zst 2,200,624,253 5/14/2026
claudevm.bundle\sessiondata.vhdx 641,728,512 5/25/2026
claudevm.bundle\smol-bin.vhdx 37,748,736 6/4/2026
claudevm.bundle\vmlinuz 59,068,808 5/27/2026
claudevm.bundle\vmlinuz.zst 15,041,757 5/14/2026
</code></pre>
<p><strong>MSIX-redirected path (<code>AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\</code>):</strong></p>
<pre><code>Test-Path: False
Get-ChildItem: (empty — no files, no subdirectories)
</code></pre>
<p>Same divergence applies to logs: all log files are at <code>%APPDATA%\Claude\logs\</code>, nothing at the MSIX-redirected path.</p>
</details>
<details>
<summary><strong>Diagnostic commands used (PowerShell)</strong></summary>
<pre><code class="language-powershell"># MSIX-redirected path check (empty)
$bundle = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles"
Test-Path "$bundle\claudevm.bundle\rootfs.vhdx" # False
Get-ChildItem -Recurse $bundle -EA SilentlyContinue # (nothing)
Real path check (fully provisioned)
$altBundle = "$env:APPDATA\Claude\vm_bundles"
Test-Path $altBundle # True
Get-ChildItem -Recurse $altBundle -EA SilentlyContinue # (full listing above)
Architecture and edition
Get-ComputerInfo | Select OsArchitecture, WindowsProductName, WindowsEditionId
ARM 64-bit Processor | Windows 10 Home | Core
Services
Get-Service vmcompute, CoworkVMService, vmms -EA SilentlyContinue | Select Name, Status, StartType
CoworkVMService Running Automatic | vmcompute Running Manual | vmms absent
</code></pre>
</details></body></html><!--EndFragment-->
</body>
</html>
Same issue on a Samsung Galaxy Book4 Edge (Snapdragon, ARM64), Windows 11 Home build 26200. MSIX install; CoworkVMService exists and shows Running. Hypervisor detected, VBS running, virtualization enabled in BIOS.
Cowork's file/web tools work, but the workspace VM times out on every start attempt. App reinstall didn't help. Matches the original report exactly. Happy to provide logs if useful.
Same issue here
Title: [BUG] Cowork VM connection timeout on Windows 11 Pro ARM64 (Snapdragon) — guest never connects despite full Hyper-V stack
Environment:
What's wrong: Cowork fails with "VM connection timeout after 60 seconds" on every launch. VM boots and mounts plan9 shares successfully, but the guest agent never establishes a connection to the host; host times out after 100+ polls / 60s.
Config ruled out: Upgraded Home→Pro, enabled Hyper-V + VirtualMachinePlatform, confirmed vmms Running, clean reboots, restarted app, cleared stale VM lock. Error persists identically.
Log signature:
[VM:steps] vm_boot completed (343ms)
[VM:steps] add_plan9_shares completed (6ms)
[VM:start] Still waiting for guest connection... 50845ms elapsed, 101 polls
[VM:start] Connection timeout, last completed step: add_plan9_shares
[VM:start] Startup failed: Error: VM connection timeout after 60 seconds
Regression: No — never worked on this hardware.
Same issue — 100% reproduction rate, adding my configuration to the affected list.
Environment:
Log signature (cowork_vm_node.log): all host-side steps succeed — smol-bin.arm64.vhdx copied successfully, create_network, create_vm_config, vm_boot completed (518ms), add_plan9_shares completed — then "Still waiting for guest connection..." until "Connection timeout, last completed step: add_plan9_shares" → "VM connection timeout after 60 seconds".
Already tried, no effect: full app quit + relaunch, manual CoworkVMService start, multiple reboots, complete vm_bundles wipe with fresh rootfs.vhdx re-download. On the clean bundle the previous EBUSY lock on smol-bin.vhdx was confirmed cleared, yet the guest Linux still never connects back.
+1 on the request to either add ARM64/Snapdragon support or clearly document the limitation. Happy to provide full logs if helpful.
Same issue on Samsung Galaxy Book4 Edge (ARM64).
Device: Samsung Galaxy Book4 Edge (NP750XQA-KB1UK), Snapdragon X Plus X1P42100, 16 GB RAM
OS: Windows 11 Home, build 26200 (ARM64)
Symptoms:
Verified on this machine:
Debug logs submitted via the in-app error dialog.