[BUG] Cowork VM guest kernel never boots on Snapdragon X Plus (ARM64) — connection timeout every attempt
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 consistently fails with "VM connection timeout after 60 seconds" on a Snapdragon X Plus ARM64 device. The HCS compute system starts successfully and Plan9 shares are added, but the Linux guest kernel never boots — the daemon log remains completely empty and no HVSock connection is ever established.
WSL2 runs a Linux aarch64 kernel on the same device without any issues, confirming that ARM64 virtualization works correctly. The problem is specific to Cowork's VM guest image/configuration.
Related ARM64 issues (same broader pattern):
- #30566 — VM not running on Snapdragon X Elite (same root cause, different symptom)
- #30864 — Feature request for Cowork ARM support (closed)
- #28529 — Desktop fails to render on ARM64
- #27677 — Bun runtime panic on ARM64
- #28184 — Failed to load session on ARM64
- #13251 — ACCESS_VIOLATION on ARM64
This issue provides detailed diagnostic evidence (empty daemon log, full troubleshooting matrix) that none of the above include.
Environment:
- Device: Microsoft Surface Laptop (Snapdragon X Plus 8-core @ 3.30 GHz)
- OS: Windows 11 Home ARM64, Build 10.0.26200.8039
- Claude Desktop: v1.1.8986.0 (arm64 native, MSIX)
- WSL: 2.6.3.0, kernel 6.6.87.2-1 (aarch64, fully functional)
- Windows Features: VirtualMachinePlatform ✅ Enabled, HypervisorPlatform ✅ Enabled
- Subscription: Max plan
The smol-bin.arm64.vhdx file is correctly selected and copied, suggesting the build pipeline is ARM64-aware. The failure point is the guest kernel boot itself — HCS reports success creating and starting the VM, but the Linux kernel inside never reaches init. This could indicate an incompatibility between the guest kernel/initrd and the Snapdragon X Plus virtualization implementation, or a missing kernel configuration (e.g., Hyper-V guest drivers for ARM64).
The key diagnostic finding is that the daemon log is completely empty. This proves the guest OS never starts, distinguishing this from network/API connection issues reported in other ARM64 bugs.
What was ruled out:
| Possible cause | Status | Evidence |
|---|---|---|
| Missing VirtualMachinePlatform | ✅ Ruled out | Feature enabled |
| Missing HypervisorPlatform | ✅ Ruled out | Was disabled, enabled it, rebooted — same result |
| WSL2 conflict | ✅ Ruled out | wsl --shutdown before Cowork — same result |
| Antivirus (Malwarebytes) | ✅ Ruled out | Disabled real-time protection — same result |
| Firewall blocking | ✅ Ruled out | Claude has Allow rules for both Inbound and Outbound |
| Corrupted bundle | ✅ Ruled out | Full delete + reinstall multiple times — same result |
| EBUSY file lock | ✅ Ruled out | Clean reinstall with service stopped — same result |
| Disk space | ✅ Ruled out | 22+ GB free |
| ARM64 virtualization broken | ✅ Ruled out | WSL2 runs aarch64 kernel perfectly |
| Outdated WSL | ✅ Ruled out | WSL 2.6.3.0 (latest), clean reinstall |
| Store package corruption | ✅ Ruled out | WSL Store package repaired and re-registered |
Severity: Critical — Cowork is completely unusable on this ARM64 device. 100% reproduction rate.
What Should Happen?
Cowork workspace should start successfully and the guest VM should establish an HVSock connection to the host.
Error Messages/Logs
cowork_vm_node.log (host-side):
[VM:steps] download_and_sdk_prepare completed (5ms)
[VM:steps] load_swift_api completed (0ms)
[VM:start] smol-bin.arm64.vhdx copied successfully
[VM:start] Windows VM service configured
[VM:steps] create_network completed (1ms)
[VM:steps] create_vm_config completed (140ms)
[VM:steps] vm_boot completed (211ms)
[VM:steps] add_plan9_shares completed (62ms)
[VM:start] Still waiting for guest connection... 10314ms elapsed, 21 polls
[VM:start] Still waiting for guest connection... 20545ms elapsed, 41 polls
[VM:start] Still waiting for guest connection... 30862ms elapsed, 61 polls
[VM:start] Still waiting for guest connection... 41160ms elapsed, 81 polls
[VM:start] Still waiting for guest connection... 51439ms elapsed, 101 polls
[error] [VM:start] Connection timeout, last completed step: add_plan9_shares
[error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
cowork-service.log (VM service):
[HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=home path=C:\Users\ivang port=9999
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] Starting daemon console reader: pipe=\\.\pipe\cowork-daemon-console-cowork-vm-...
[VM] VM started successfully
Daemon log (guest-side):
Completely empty — the guest kernel never produces any output.
WSL2 confirmation (same device, same virtualization layer):
$ uname -a
Linux Igoded-Surface 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC aarch64 GNU/Linux
Bundle info:
smol-bin.arm64.vhdx (37 MB) correctly selected and copied.
Bundle version: fb30784dadb34104626c8cf6d8f90dd47cd393ccSteps to Reproduce
- Open Claude Desktop v1.1.8986.0 (arm64)
- Switch to Cowork tab
- Wait for workspace initialization
- Observe "VM connection timeout after 60 seconds" error (100% reproducible)
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
N/A
Claude Code Version
N/A — Claude Desktop v1.1.8986.0 (arm64 MSIX), not Claude Code CLI
Platform
Other
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Note: This is a Claude Desktop app bug, not a Claude Code CLI issue. Filing here as there is no separate Claude Desktop repo.
Platform: Windows 11 Home ARM64 (Build 26200.8039), Snapdragon X Plus 8-core @ 3.30 GHz.
Terminal/Shell used for diagnostics: PowerShell
33 Comments
Updated to Claude Desktop v1.1.9134.0 (arm64) — same VM connection timeout after 60 seconds. Issue persists.
Same issue
Same issue here.
Same, running: ARMv8 (64-bit) Family 8 Model 1 Revision 201 Qualcomm Technologies Inc ~3417 Mhz
Updated to Claude Desktop v1.1.9310.0 (arm64) — still the same VM connection timeout after 60 seconds. Third version tested (v1.1.8986.0, v1.1.9134.0, v1.1.9310.0), none resolve the issue.
Could a maintainer re-label this as
bug+area:cowork+platform:windows? Theinvalidlabel was auto-applied by the bot, but this is a legitimate Claude Desktop bug — same as other Desktop issues filed in this repo (e.g. #30566, #25663, #27801). There is no separate repo for Claude Desktop bugs.Updated to Claude Desktop v1.1.9493.0 (arm64) — same result. Fourth version tested, none resolve the ARM64 VM boot failure.
<html>
<body>
<!--StartFragment--><h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Extended diagnostic update — March 31, 2026</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Continued testing across <strong>5 versions</strong> now: v1.1.8986.0, v1.1.9134.0, v1.1.9310.0, v1.1.9493.0, v1.1.9669.0 — all produce the same VM connection timeout after 60 seconds. Daemon log remains completely empty in every attempt.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">New findings</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>HCS error code 0xC0370103:</strong>
Hyper-V Compute event logs show <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">0xC0370103</code> during both <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Create compute system</code> and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Start compute system</code> for <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-vm-8480bc00</code>. Despite this error, HCS continues to report success on subsequent operations (Plan9 shares, etc.), but the guest kernel never boots. This error code may be key to diagnosing the ARM64-specific failure.</p>
<blockquote class="ml-2 border-l-4 border-border-300/10 pl-4 text-text-300">
<p class="font-claude-response-body break-words whitespace-pre-wrap leading-[1.7]">[cowork-vm-8480bc00] Create compute system, result 0xC0370103
[cowork-vm-8480bc00] Start compute system, result 0xC0370103</p>
</blockquote>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]"><strong>Hyper-V Hypervisor log:</strong> Partitions are created and destroyed rapidly (every ~2 minutes), suggesting the VM is being created but immediately failing to execute the guest kernel, triggering retry loops.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Additional tests performed (all ruled out)</h3>
<div class="overflow-x-auto w-full px-2 mb-6">
Test | Result
-- | --
Disable HVCI/Memory Integrity (registry) | Same timeout, daemon log still empty. Re-enabled after test.
Secure Boot status | Active — but WSL2 runs aarch64 kernel fine with Secure Boot on, so not the cause
HCS Compute event logs | Revealed 0xC0370103 error code on Create/Start (new finding)
Hyper-V Hypervisor logs | Partitions created/destroyed rapidly, no errors
Kernel hash verification | vmlinuz SHA256: 96F13530CECB6928CF72838CF0C935D4ADC63D1F2D5F8F51026ED99D27A44B43 (59 MB)
5 clean bundle reinstalls | Same result every time
Chat mode in Cowork | Works (uses API directly, doesn't need VM)
Plugin installation | 3 plugins installed successfully (productivity, data, engineering) — these don't require VM
</div>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Summary</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The 0xC0370103 HCS error and the empty daemon log together confirm the guest kernel is never executed inside the VM on Snapdragon X Plus. HCS creates the VM container successfully but the kernel binary fails to boot within it. WSL2's Microsoft-signed kernel boots fine on the same hardware, so the issue is specific to Cowork's vmlinuz/initrd for ARM64.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This likely requires Anthropic to either:</p>
<ol class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">Rebuild the guest kernel with proper ARM64 Hyper-V guest support for Qualcomm/Snapdragon</li>
<li class="whitespace-normal break-words pl-2">Sign the kernel in a way compatible with the ARM64 HCS boot path</li>
<li class="whitespace-normal break-words pl-2">Align the VM configuration with what WSL2 uses successfully on this hardware</li>
</ol>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Could a maintainer also re-label this as <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">bug</code> + <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">area:cowork</code> + <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">platform:windows</code>? The <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">invalid</code> label was auto-applied by the bot, but this is a legitimate Claude Desktop bug filed here because there is no separate Claude Desktop repo.</p><!--EndFragment-->
</body>
</html>
Updated to Claude Desktop v1.569.0.0 (arm64, new versioning scheme). New bundle version 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d. Same VM connection timeout, daemon log still empty. Sixth version tested.
v1.1062.0.0 (arm64) — seventh version tested, same result.
The bundle hasn't changed since v1.569.0.0 — same commit hash. The fix needs to come from a new VM image/kernel build, not app updates.
New finding: The vmlinuz in the bundle is Ubuntu 6.8.0-106-generic (aarch64), NOT a Microsoft-customized kernel. WSL2 uses a microsoft-standard-WSL2 kernel specifically built for HCS containers. The Ubuntu generic kernel has Hyper-V guest modules (hv_core.c, mshyperv.c) but may lack critical HCS-specific configuration for ARM64.
This likely explains why WSL2 boots fine but Cowork doesn't — different kernels, same virtualization layer. The fix may require using a kernel built with Microsoft's WSL2 kernel config or equivalent HCS guest support for ARM64.
vmlinuz details:
I spent several days trying to get Cowork working, went through every troubleshooting step I could find, and even upgraded from Windows 11 Home to Windows 11 Pro only to discover that ARM64 is simply not supported yet. This should be clearly stated in Anthropic's documentation and system requirements before users invest significant time and money trying to fix something that cannot be fixed on their hardware.
Well its really is a bust. I just bought a thin & light laptop specifically to work on the claude cowork desktop. I've researched some laptop and end up on an arm64 laptop that i like because it only weighs 900g. Confirming that claude works on arm64 before buying it. After digging up for a whole day and apparently this cant be fixed. I guess i can only wait for the mercy of anthropic for rolling out the fix.
v1.3561.0.0 — twelfth version tested. Kernel hash still 96F13530. One month since first report, 12 app updates, zero kernel updates. Cowork is now GA but still broken on ARM64. New duplicate issues keep appearing (#46516, #50674) with no maintainer response on any of them, nor on this one. Support ticket also went unanswered — got an auto-reply about a "login issue" that had nothing to do with my report.
same issue, lost too many hours trying to fix cowork. Laptop lenovo System Type ARM64-based PC, Processor Snapdragon(R) X Plus - X1P42100 - Qualcomm(R) Oryon(TM) CPU, 3244 Mhz, 8 Core(s), 8 Logical Processor(s)
Same issue and diagnostics on my end:-
Summary
The Cowork VM boots successfully on ARM64 Snapdragon hardware, but a hardcoded 60-second timeout appears in multiple places in the Cowork stack — not just at initial VM boot. In every case, the 60-second limit is too short for ARM64 guest response latency, causing user-facing failures even when the underlying VM is healthy or on its way to becoming healthy.
Observed surfaces of the same ceiling:
Initial VM boot / guest HVSocket connection — times out after 60s even though the guest does eventually connect (sometimes hours later).
In-session tool calls to mcp__workspace__bash — every shell command, including trivial echo, returns "Workspace still starting" and fails at ~60s, preventing any shell use in that session even after the VM is running.
Session re-attach after timeout — retry produces "VM is already running" because the prior VM was never torn down; the client does not reattach.
This is not a hardware incompatibility. The ARM64 guest works. The issue is a family of 60-second timeouts that are too aggressive for Snapdragon guest latency, combined with a lack of graceful reattach logic.
Environment
OS: Windows 11 ARM64 (fully patched, activated)
Processor: Qualcomm Snapdragon X series
Hyper-V services confirmed running:
vmcompute (Hyper-V Host Compute Service) — Running
vmms (Hyper-V Virtual Machine Management) — Running
CoworkVMService (Claude) — Running (MSIX variant)
MSIX package: Clean install, no cross-drive symlinks, no EXDEV errors
VM bundle: Rebuilt from scratch during troubleshooting (deleted and re-downloaded)
Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
Reproduction
Scenario A — Cold VM Boot
Open Claude Desktop on ARM64 Snapdragon hardware.
Click Cowork to start the workspace.
Observe "Starting Claude's workspace..." message.
After ~60 seconds, UI displays "Failed to start Claude's workspace — VM connection timeout after 60 seconds."
Clicking retry produces "VM is already running" because the prior VM was never terminated.
Leave the machine running. After an extended period (observed: ~11 hours overnight), Cowork connects successfully.
Scenario B — In-Session Shell Timeout (NEW)
Start a new Cowork session on the same hardware.
In the session, invoke the mcp__workspace__bash tool with any command, including trivial ones such as echo ready.
The tool returns Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.
Retry the same command. Each retry either returns the same "Workspace still starting" message immediately, or hangs for 60s before returning MCP server "workspace" tool "bash" timed out after 60s.
This behaviour persists for the duration of the session — the shell tool never becomes usable, even though file-access tools (Read / Write / Edit / Glob) function normally against the mounted workspace and MCP deferred tools load fine.
Effect: any workflow that requires Python/openpyxl, LibreOffice, or any other sandboxed binary (e.g. editing .xlsx, .pptx, .pdf files in the user's workspace) is blocked for the whole session.
Diagnostic Evidence
Failed Cold Startup — 23 April 2026, 21:43
VM boots in 101ms, Plan9 shares mount in 2ms, then the guest connection times out after 60s of polling:
2026-04-23 21:43:06 [info] [VM:steps] vm_boot started
2026-04-23 21:43:06 [info] [VM:steps] vm_boot completed (101ms)
2026-04-23 21:43:06 [info] [VM:steps] add_plan9_shares started
2026-04-23 21:43:06 [info] [VM:steps] add_plan9_shares completed (2ms)
2026-04-23 21:43:16 [info] [VM:start] Still waiting for guest connection... 10150ms elapsed, 21 polls
2026-04-23 21:43:26 [info] [VM:start] Still waiting for guest connection... 20322ms elapsed, 41 polls
2026-04-23 21:43:36 [info] [VM:start] Still waiting for guest connection... 30470ms elapsed, 61 polls
2026-04-23 21:43:46 [info] [VM:start] Still waiting for guest connection... 40615ms elapsed, 81 polls
2026-04-23 21:43:57 [info] [VM:start] Still waiting for guest connection... 50771ms elapsed, 101 polls
2026-04-23 21:44:06 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-04-23 21:44:06 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds
VM instance ID: 75751271-49fe-44f6-8e3b-d9fcf2708618
Retry Collision — 23 April 2026, 22:28
The VM from the previous attempt was never killed. The VHDX is locked (EBUSY), and the boot call correctly identifies the VM is already running — but instead of reattaching, the client errors:
2026-04-23 22:28:57 [warn] [VM:start] smol-bin.vhdx locked by running VM (EBUSY), skipping copy
2026-04-23 22:28:57 [error] [VM:start] VM boot failed: VM is already running
VM instance ID: 0e5f205e-26eb-40df-9bf1-735c383a277d
Eventual Successful Connection — 24 April 2026, 09:29
Without any user intervention, the guest eventually connects:
2026-04-24 09:29:12 [info] [VM] Network status: CONNECTED
2026-04-24 09:29:21 [info] [VM] API reachability: REACHABLE
2026-04-24 09:57:11 [info] [startVM] VM already connected
2026-04-24 09:57:11 [info] [postConnect] Installing SDK: subpath=c/Users/[USER]/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm, version=2.1.111
2026-04-24 09:57:14 [info] [Keepalive] Starting (interval=2000ms)
In-Session Shell Timeout — 24 April 2026 (NEW)
During a Cowork session on 24 April 2026, every mcp__workspace__bash invocation exhibited one of two failure modes:
Immediate return of Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.
Silent hang followed by MCP server "workspace" tool "bash" timed out after 60s.
This occurred across at least seven consecutive attempts spanning multiple minutes, on commands as trivial as echo ready and uname -m. In parallel, the following non-shell capabilities worked normally in the same session:
File tools (Read, Write, Edit, Glob) against the mounted workspace folder — files listed and written successfully.
MCP deferred tools (ToolSearch, skill invocation, memory tools) — all responsive.
Skill system — skills loaded and executed without issue.
The isolation of the failure to mcp__workspace__bash specifically, while file tools against the same mount worked, suggests that the bash tool has its own guest-readiness gate (likely a 60s poll for guest-agent readiness on the HVSocket) that is distinct from the VM-level boot timeout but has the same too-short ceiling.
What Has Been Ruled Out
The following host-side causes were systematically eliminated during a multi-hour troubleshooting session:
Hyper-V services: All three services (vmcompute, vmms, CoworkVMService) confirmed running and successfully restarted.
MSIX package integrity: No cross-drive symlinks in the package folder. All MSIX directories confirmed on C: drive with empty Target fields.
Storage redirection (EXDEV): "Where new content is saved" confirmed set to C:. No stray symlinks detected via Get-ChildItem with -Force flag.
Stale VM bundle: Bundle deleted and re-downloaded from scratch. Same timeout behaviour on fresh bundle.
Stale session/lock files: LocalState folder confirmed empty. No orphan lockfiles found.
Windows activation and patching: Windows is activated and fully updated.
Service type: Confirmed MSIX install (CoworkVMService, not CoworkVMServiceStore).
Root Cause Analysis
The ARM64 guest kernel inside smol-bin.arm64.vhdx runs correctly on Snapdragon, but several Cowork code paths assume the guest will be ready to serve requests within 60 seconds. On ARM64 Snapdragon hardware this assumption fails in at least two places:
VM-level guest connection poll — the initial HVSocket handshake after vm_boot. Host-side boot and Plan9 mounting complete in <200ms; the bottleneck is entirely within the guest's init sequence.
Tool-level guest-agent readiness check — the mcp__workspace__bash tool appears to perform its own readiness probe before executing a command, and this probe is gated by a similar ~60s ceiling. When the guest isn't ready within that window, every subsequent bash call in the session fails with the same "Workspace still starting" response, and the gate never re-opens within the session's lifetime. File-tool paths against the same workspace mount do not hit this gate and continue to work normally — which is how a session can appear "alive" while shell access is permanently broken.
No reattach on VHDX lock — after a timeout, the VM is left running and the VHDX remains EBUSY. A retry correctly detects this but errors out ("VM is already running") instead of reattaching to the in-progress guest. The guest kernel continues its boot in the background and eventually establishes the HVSocket connection — at which point a fresh Cowork launch will find the VM already up. This is why overnight sessions eventually "just work" without any user intervention.
In all three cases the underlying VM is healthy. The failures are in host-side readiness logic.
Recommended Fix
Audit every 60-second timeout in the Cowork stack, not just VM boot. At minimum, the tool-level mcp__workspace__bash readiness probe needs the same extension as the VM-boot timeout. Any other code path that polls for guest readiness should be reviewed for the same ceiling.
Make timeouts configurable on ARM64, or detect slow guests and auto-extend. A 5-minute default (or a user-visible setting) would cover observed Snapdragon guest-init latencies. An exponential-backoff probe that gives up only after several minutes of silence would be preferable to a hard ceiling.
Detect and reattach to existing VMs. When a startup or tool call finds EBUSY on the VHDX or a running VM instance, Cowork should attempt to attach to the existing guest instead of erroring. This is the single highest-leverage UX fix: right now, the guest's slow boot is wasted because the user has usually closed the app before the VM becomes usable.
Reset tool-level readiness gates when the underlying guest becomes ready. Currently, even after the guest is up, mcp__workspace__bash does not recover within the session — it keeps returning "Workspace still starting." The gate should re-check on each tool call, not cache a stale "not ready" verdict for the session's lifetime.
Suppress misleading error messaging. The current UI shows "VM connection timeout" and then "VM is already running" on retry, neither of which communicates the actual state. The bash tool returns "Workspace still starting" indefinitely, with no indication of how long the user should wait or whether waiting will help. Recommended message: "The workspace is still starting — this may take several minutes on ARM64 hardware. File tools are available now; shell access will resume automatically."
User Impact
Cold boot: the user must wait indefinitely (observed: hours) for the first successful connection after installing or updating Cowork. Most users will interpret the initial timeout as an outright failure and abandon the product.
In-session: when the bash gate fails, the session becomes silently crippled. File tools work, which makes the session look operational — until the user requests any workflow that requires Python, LibreOffice, a compiler, a formatter, or any other sandboxed binary. This includes core document workflows (.xlsx, .pptx, .pdf), which is effectively the reason most non-developer users opened Cowork in the first place.
Trust: because the error messaging doesn't distinguish between "not ready yet" and "broken," users can't self-diagnose and often assume their files or hardware are at fault.
Update on v1.4758.0.0:
✅ Scenario A (cold VM boot) — RESOLVED. File tools work, VM connects on first try.
❌ Scenario B (in-session bash sandbox) — STILL BROKEN. Tested in fresh session after closing Cowork completely. mcp__workspace__bash returns "Workspace unavailable. The isolated Linux environment failed to start." File tools (Read/Write/Edit) work normally in the same session.
Confirmed: vmlinuz hash still 96F13530, bundle still 5680b11b. The host-side VM-boot timeout was extended, but the tool-level guest-agent readiness gate still fails — exactly as @SiteChief predicted.
Half the bug remains. Without the bash sandbox, Python/LibreOffice/compilers/formatters are blocked, which means .xlsx/.pptx/.pdf workflows are still unusable on ARM64.
v1.5354.0.0 (29 April 2026) — Bug persists. Identical reproduction:
Additional ruled out this round:
Note: I previously reported v1.4758.0.0 as "Scenario A resolved" — that was premature. Subsequent attempts on that version reverted to the same timeout. The fix appears to have been intermittent or environment-dependent, not a real fix.
In-session test (Scenario B per @SiteChief): Even when file tools work, mcp__workspace__bash never recovers within the session. Tested ~25 retries across multiple fresh Cowork sessions (closing the entire app between attempts). Sandbox stays in "starting" indefinitely or returns "Workspace unavailable. The isolated Linux environment failed to start." Cowork itself confirms the sandbox runs on Anthropic infrastructure, so this is a backend/host-side issue, not local.
15 versions tested over a month. Anthropic keeps shipping app updates but the VM bundle/kernel and host-side readiness logic remain unchanged. The bug fingerprint is identical every time.
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 got Workspace still starting. The isolated Linux environment is booting in the background (usually 10–30 seconds). Try again shortly.
in r5 5600 amd cpu windows
Same issue. Surface 12 pro, Snapdragon X Plus (8-core), win pro
Same issue. Acer 16 Ai, Snapdragon X 126-100. I hope at least 1 Anthropic developer has an SD based laptop.
Confirming this on another Snapdragon ARM64 device, current build, in case another data point helps.
Environment
Symptom
Identical to this issue. The host completes every step (create_network, create_vm_config, vm_boot, add_plan9_shares) in a few hundred ms, then polls for the guest and times out after 60s with
last completed step: add_plan9_shares. The Linux guest never establishes a connection. Across my logs going back to late March there are 21 start attempts and 57 timeouts, with zero successful guest connections, ever. Cowork has never worked on this machine.Host stack confirmed healthy (so this is not a host-side misconfig)
CoworkVMService,vmcompute,hnsall RunningHypervisorPresent= True,hypervisorlaunchtype= AutoVirtualMachinePlatformEnabledGet-HnsNetworkempty only because no VM build ever reaches the network-bringup the guest would trigger; the host creates its network fine during startup per the logsRuled out from the user side
Skipping auto-reinstall (already attempted once))vm_bundles\claudevm.bundlefolder to force a fresh download ofrootfs.img.zst/sessiondata.img(which the in-app reinstall preserves). Fresh download, same timeout. This rules out a corrupt local image.This matches the conclusion already in this thread and in #38945: the host side is fine on ARM64 and the failure is inside the guest, i.e. the shipped rootfs/kernel in the VM bundle does not boot under ARM Hyper-V guest execution. As others noted, WSL2 runs an aarch64 Linux kernel on this class of hardware without issue, so ARM virtualisation itself is working.
Sanitised
cowork_vm_node.logexcerpt (one representative cycle, username/UUID/stack frame redacted):Happy to provide the full
cowork_vm_node.logorcoworkdguest log if useful.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.
Confirming this on different OEM hardware, same silicon — so it's not device-specific.
ASUS Vivobook S15 (S5507QA), Snapdragon X Plus X1P42100 (Qualcomm Oryon, ARM64), Win 11 Pro 25H2 build 26200.8524, Claude 1.11187.4.0 (arm64). Same
VM connection timeout after 60 seconds, deterministic, stalls atadd_plan9_shares.One extra data point that corroborates your "guest kernel never boots" finding: polling
hcsdiag list(admin) during a start shows the compute system at stateRunningcontinuously for the full ~60 s window, yethcsdiag execagainst that same live ID failsinstantly every time:
-> A virtual machine or container with the specified identifier does not exist.
So the hypervisor partition is up, but there's no attachable guest compute service — nothing for the host to talk to. Matches your empty guest-daemon-log result from a second angle.
Also confirming WSL2's aarch64 kernel boots fine on this exact machine — and Cowork ships its own
vmlinuz, not WSL's — so this is isolated to the Cowork ARM64 guest image, not the platform.Full host-side diagnostics (HvHost/vmcompute/hns/etc. all healthy, bundle intact, GuestCommunicationServices registered) in #64592.
Another ARM64/Snapdragon report — VM shows Running but connection times out 100% of the time
Environment
Symptom
"Failed to start Claude's workspace — VM connection timeout after 60 seconds." Happens on every single attempt since first install (day 1), regardless of restarts, reboots, or workspace reinstall.
Diagnostics performed
CoworkVMService: Runninghcsdiag list: VM exists and reports RunningGet-NetAdapter: no vEthernet adapter created — only physical Wi-Fi/Bluetooth adaptersGet-NetNat: fails withInvalid class(0x80041010)systeminfo: "A hypervisor has been detected"; VBS runningVirtualMachinePlatformEnabled; enabledHypervisorPlatform+ reboot → no changeroute printshows no 172.16 routes)Summary
HCS reports the VM as Running, but no virtual network adapter is ever created on the host and Claude can never connect — consistent with the guest never completing boot on Snapdragon hardware. All documented host-side fixes exhausted; 100% reproducible. Same symptoms as #46516 (now locked)
Three-bundle comparison on Snapdragon X: the guest boots in ~22 min — the 60 s timeout is the bug
ASUS Vivobook S15 (Snapdragon X Plus X1P42100, ARM64), Win 11 Pro 25H2 build 26200.8655. Measured across the three VM bundles Anthropic has shipped:
| Bundle | Kernel (extracted from vmlinuz) | Shipped with | Guest connects? |
|---|---|---|---|
|
5680b11b| Ubuntu 6.8.0-106-generic | ≤1.11187 | ✅ after ~21 min ||
c9b42670| Ubuntu 6.8.0-124-generic | 1.11847 (Jun 9) | ❌ never (soaks up to 90+ min) ||
6d1538ba| Ubuntu 6.8.0-124-generic | 1.12603 (Jun 11) | ✅ after ~22 min |The guest DOES boot on Snapdragon X. Today on 1.12603 / bundle 6d1538ba, measured live:
17:41:16 vm_boot completed → polling
17:42:17 Startup failed: VM connection timeout after 60 seconds ← user sees error
18:03:35 [VM] Network status: CONNECTED ← ~22 min after boot
18:03:46 [VM] API reachability: REACHABLE
→ reopening the workspace attaches: "[startVM] VM already connected"
Same pattern (≈21 min) reproduced multiple times June 6–8 on the old bundle. This confirms @SiteChief's analysis: it's a too-aggressive 60 s timeout against a ~20+ min ARM64 boot, not a hardware incompatibility.
Working user workaround: open the workspace → ignore the 60 s error → leave the app open ~25 min (do NOT restart the app/service/PC — that kills the booting VM; the error dialog's "restart" advice is counterproductive) → open the workspace again.
Note for maintainers: bundle
c9b42670(Jun 9) never connected (90+ min soak: VM wrote ~900 MB to rootfs, went idle, never dialed back) — whatever changed in its rootfs/initrd vs 5680b11b broke ARM64 boot completely; 6d1538ba fixed that. Since bothship the same kernel, the remaining work is: (1) raise/adapt the 60 s timeout or add background reattach, (2) figure out why a generic Ubuntu kernel takes ~22 min to boot in this micro-VM on Snapdragon X (WSL2's kernel boots in seconds on the same machine), and
(3) surface the guest console so users can see boot progress.
<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal"><strong>Device & Environment</strong></p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">Device: HP OmniBook 5 (he0015QU)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">CPU: Snapdragon X (X126100), Qualcomm Oryon @ 2.96 GHz</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">GPU: Qualcomm Adreno X1-45, 128 MB (driver 31.0.148.0, Feb 28 2026)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">OS: Windows 11 Home Single Language (CoreSingleLanguage), Build 26200.8655</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Claude Desktop: 1.12603.1.0 ARM64</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">VM Bundle: 6d1538ba</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">WSL2: Installed, Default Version 2</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Hyper-V: Installed via DISM script (Home edition workaround)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">HypervisorPlatform: Enabled</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">VirtualMachinePlatform: Enabled</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Hyper-V Administrators group: Added</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">vmms: Running (Automatic)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">vmcompute: Running (Manual)</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">vEthernet adapter: Present, Up, 10 Gbps</li>
</ul>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Three independent bugs — two of which conflict when workarounds are applied</strong></p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Bug 1 — Claude Desktop fails to launch via MSIX on X126100</strong></p>
<p class="font-claude-response-body break-words whitespace-normal">Claude Desktop fails to launch via Start Menu, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">shell:AppsFolder</code>, or any standard MSIX launch method. Process starts briefly then exits silently. No window renders. <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">main.log</code> shows:</p>
<div role="group" aria-label="Code" tabindex="0" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
isolate
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md backdrop-blur-md _fill_10ocf_9 _ghost_10ocf_96" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3A1.5 1.5 0 0 1 14 4.5V6h1.5A1.5 1.5 0 0 1 17 7.5v8a1.5 1.5 0 0 1-1.5 1.5h-8A1.5 1.5 0 0 1 6 15.5V14H4.5A1.5 1.5 0 0 1 3 12.5v-8A1.5 1.5 0 0 1 4.5 3zm1.5 9.5a1.5 1.5 0 0 1-1.5 1.5H7v1.5a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5H14zM4.5 4a.5.5 0 0 0-.5.5v8a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.188 5.11a.5.5 0 0 1 .752.626l-.056.084-7.5 9a.5.5 0 0 1-.738.033l-3.5-3.5-.064-.078a.501.501 0 0 1 .693-.693l.078.064 3.113 3.113 7.15-8.58z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>GPU process gone: {
</span></span><span> type: 'GPU',
</span><span> reason: 'crashed',
</span><span> exitCode: 101457950,
</span><span> serviceName: 'GPU'
</span><span>}</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal">Root cause is confirmed to be <strong>MSIX sandbox restriction</strong> — not a GPU driver issue. Evidence: running <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">claude.exe</code> directly after bypassing MSIX permissions via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">takeown</code>/<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">icacls</code> launches Claude successfully without any GPU flags required. The sandbox is preventing something the direct exe launch does not restrict.</p>
<p class="font-claude-response-body break-words whitespace-normal"><strong>Workaround:</strong></p>
<div role="group" aria-label="powershell code" tabindex="0" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
isolate
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md backdrop-blur-md _fill_10ocf_9 _ghost_10ocf_96" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3A1.5 1.5 0 0 1 14 4.5V6h1.5A1.5 1.5 0 0 1 17 7.5v8a1.5 1.5 0 0 1-1.5 1.5h-8A1.5 1.5 0 0 1 6 15.5V14H4.5A1.5 1.5 0 0 1 3 12.5v-8A1.5 1.5 0 0 1 4.5 3zm1.5 9.5a1.5 1.5 0 0 1-1.5 1.5H7v1.5a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5H14zM4.5 4a.5.5 0 0 0-.5.5v8a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.188 5.11a.5.5 0 0 1 .752.626l-.056.084-7.5 9a.5.5 0 0 1-.738.033l-3.5-3.5-.064-.078a.501.501 0 0 1 .693-.693l.078.064 3.113 3.113 7.15-8.58z"></path></svg></div></div></div></button></div></div><div class="text-text-500 font-small p-3.5 pb-0">powershell</div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-powershell" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span><span>takeown </span><span class="token token" style="color: rgb(234, 236, 240);">/</span><span>f </span><span class="token token" style="color: rgb(155, 233, 99);">"C:\Program Files\WindowsApps\Claude_1.12603.1.0_arm64__pzs8sxrjxfjjc"</span><span> </span><span class="token token" style="color: rgb(234, 236, 240);">/</span><span>r </span><span class="token token" style="color: rgb(234, 236, 240);">/</span><span>d y
</span></span><span><span>icacls </span><span class="token token" style="color: rgb(155, 233, 99);">"C:\Program Files\WindowsApps\Claude_1.12603.1.0_arm64__pzs8sxrjxfjjc"</span><span> </span><span class="token token" style="color: rgb(234, 236, 240);">/</span><span>grant <username>:F </span><span class="token token" style="color: rgb(234, 236, 240);">/</span><span>t</span></span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal">Claude launches successfully via direct exe after this. Additional flags <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">--enable-features=Vulkan --disable-gpu-compositing --ignore-gpu-blocklist</code> were added to shortcut for GPU rendering stability but are NOT required for launch.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Bug 2 — Claude running outside MSIX cannot communicate with CoworkVMService pipe</strong></p>
<p class="font-claude-response-body break-words whitespace-normal">CoworkVMService is a WIN32_PACKAGED_PROCESS (type 210) that creates its named pipe <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">\\.\pipe\cowork-vm-service</code> within MSIX sandbox context. When Claude is launched outside MSIX via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">takeown</code> workaround, the Claude process cannot communicate with the pipe — fails with <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">ENOENT \\.\pipe\cowork-vm-service</code>.</p>
<p class="font-claude-response-body break-words whitespace-normal"><strong>Important:</strong> Bug 2 is NOT caused by the Bug 1 workaround. It is an independent architectural issue — Claude running outside MSIX simply cannot reach the CoworkVMService pipe regardless of how it got there. Evidence: CoworkVMService starts correctly when triggered by MSIX Claude (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">STATE: 4 RUNNING</code> confirmed). The problem is communication between outside-MSIX Claude and inside-MSIX service.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Bug 3 — HVSock connection never established on X126100</strong></p>
<p class="font-claude-response-body break-words whitespace-normal">Even when CoworkVMService is running (triggered via MSIX launch before MSIX Claude crashes), the Linux guest kernel never establishes an HVSock connection back to the host. VM ran for 70+ minutes — <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vm_boot completed</code> and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">add_plan9_shares completed</code> confirmed — but daemon never started.</p>
<p class="font-claude-response-body break-words whitespace-normal"><strong>VM log pattern (every attempt):</strong></p>
<div role="group" aria-label="Code" tabindex="0" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
isolate
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md backdrop-blur-md _fill_10ocf_9 _ghost_10ocf_96" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3A1.5 1.5 0 0 1 14 4.5V6h1.5A1.5 1.5 0 0 1 17 7.5v8a1.5 1.5 0 0 1-1.5 1.5h-8A1.5 1.5 0 0 1 6 15.5V14H4.5A1.5 1.5 0 0 1 3 12.5v-8A1.5 1.5 0 0 1 4.5 3zm1.5 9.5a1.5 1.5 0 0 1-1.5 1.5H7v1.5a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5H14zM4.5 4a.5.5 0 0 0-.5.5v8a.5.5 0 0 0 .5.5h8a.5.5 0 0 0 .5-.5v-8a.5.5 0 0 0-.5-.5z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.188 5.11a.5.5 0 0 1 .752.626l-.056.084-7.5 9a.5.5 0 0 1-.738.033l-3.5-3.5-.064-.078a.501.501 0 0 1 .693-.693l.078.064 3.113 3.113 7.15-8.58z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>[VM:steps] vm_boot completed (137-397ms)
</span></span><span>[VM:steps] add_plan9_shares completed (5ms)
</span><span>[VM:start] Still waiting for guest connection... 10195ms elapsed
</span><span>[VM:start] Still waiting for guest connection... 20377ms elapsed
</span><span>[VM:start] Still waiting for guest connection... 30539ms elapsed
</span><span>[VM:start] Connection timeout, last completed step: add_plan9_shares</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal">No <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">Network status: CONNECTED</code> ever logged. No <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-service.log</code> ever created across multiple attempts including one 70+ minute run.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Interaction between bugs when workarounds are applied</strong></p>
<div class="overflow-x-auto w-full px-2 mb-6">
Scenario | Claude opens | CoworkVMService starts | HVSock connects
-- | -- | -- | --
Normal MSIX | ❌ Bug 1 | ✅ | ❌ Bug 3
takeown only | ✅ | ❌ Bug 2 | N/A
MSIX trigger + takeown | ✅ | ✅ briefly | ❌ Bug 3 — MSIX crashes before 22min boot
</div>
<p class="font-claude-response-body break-words whitespace-normal">The partial workaround (MSIX trigger → takeown launch) is blocked by Bug 1 — MSIX Claude crashes after ~3 minutes killing CoworkVMService before the 22-minute ARM64 boot completes.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Comparison with Vivobook X126100 in this thread</strong></p>
<p class="font-claude-response-body break-words whitespace-normal">Same chip (X126100), different result:</p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">Vivobook: bundle 6d1538ba connects at ~22 minutes ✅</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">HP OmniBook: bundle 6d1538ba never connects after 70+ minutes ❌</li>
</ul>
<p class="font-claude-response-body break-words whitespace-normal">Possible differentiator unknown — same chip, same bundle, different outcome. Further investigation needed.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>Fix required from Anthropic — three changes:</strong></p>
<ol class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-decimal flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Fix MSIX sandbox GPU configuration on ARM64</strong> — sandbox incorrectly restricts GPU process initialisation on Adreno X1-45 / X126100. Direct exe launch works fine. Suggested fix: add <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">--enable-features=Vulkan --disable-gpu-compositing</code> to Electron launch config for ARM64, or fix the sandbox GPU permission.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Fix Claude outside-MSIX to CoworkVMService pipe communication</strong> — or ensure CoworkVMService stays running independently of MSIX Claude process lifecycle so the takeown workaround can use it.</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2"><strong>Raise VM timeout or implement background reconnect for ARM64</strong> — guest kernel takes 20+ minutes on Snapdragon X per analysis in this thread. 60-second timeout fires long before boot completes.</li>
</ol>
<p class="font-claude-response-body break-words whitespace-normal">Fix 1 is the most critical — it unblocks Fix 2 and Fix 3 by allowing proper MSIX launch.</p>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">
<p class="font-claude-response-body break-words whitespace-normal"><strong>References:</strong></p>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="font-claude-response-body whitespace-normal break-words pl-2">Same chip (X126100) VM timeout: #46033</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">MSIX GPU sandbox: #25801, #45031</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">Window rendering: #50875, #28529</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">VM guest never starts: #54011</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">CoworkVMService pipe: #47737</li>
<li class="font-claude-response-body whitespace-normal break-words pl-2">22-minute ARM64 boot analysis: this thread (#39636)</li></ul><!--EndFragment-->
</body>
</html>
+1 — confirming this bug still exists.
Status as of June 2026 (three months after original report)
This bug is still being reproduced on the latest Claude Desktop builds. Issue #66535 (filed June 9, 2026 by @anhtuan96a8) reports the identical symptom on Claude Desktop v1.11187.1.0 — a much newer build than the v1.1.8986.0 in this original report and my v1.8089.1.0 below. Three Claude Desktop major version generations affected by the same bug.
For context on prioritization: the closely related ARM64 Cowork issue #45549 (smol-bin.arm64.vhdx not copied to writable location on Snapdragon X Elite) was closed as "not planned" without a fix. I want to respectfully flag concern about the trajectory — every Snapdragon ARM64 device tested in the field hits this wall (Surface Pro 11, Surface Pro 12, Samsung Galaxy Book4 Edge, ASUS Zenbook A14, HP Omnibook — see related issues #39636, #40198, #45549, #46033, #46389, #46516, #50674, #66535), and the affected user base grows monthly as Windows-on-ARM adoption accelerates.
My environment
5680b11bcdab215cccf07e0c0bd1bd9213b0c25dIdentical log signature
Same
last completed step: add_plan9_shares, same silent guest, same 100% reproducibility (3+ consecutive runs after full diagnostic reset, identical signature each time). I also confirmed\\.\pipe\cowork-vm-serviceand\\.\pipe\cowork-daemon-console-cowork-vm-*are both present at the moment of failure, so the host side is healthy.Additional ruled-out causes (beyond the original report's matrix)
CoworkVMServicerecovery configured (sc.exe failure CoworkVMService reset= 60 actions= restart/5000/restart/5000/restart/5000) — no change.sessiondata.vhdxto force a clean guest state — no change.Likely root cause: Pluton-enforced HVCI on Snapdragon ARM64
After all the above, I attempted to disable Memory Integrity (HVCI) to test whether VBS was interfering with Cowork's Hyper-V VM. The toggle in Windows Security was greyed out as "managed by your administrator" despite being on a personal device. I overrode it via registry:
After reboot:
HVCI remained enforced despite the registry override. This is Microsoft Pluton enforcing VBS/HVCI from the firmware level — a security feature baked into Snapdragon X chips that is not user-disableable from the OS.
This strongly suggests the root cause of the Cowork failure on Snapdragon ARM64:
WSL2 works fine on the same hardware because Microsoft explicitly engineered WSL2 to coexist with VBS/HVCI on ARM64. Cowork's custom VM stack apparently hasn't been engineered for this, which is why every Snapdragon ARM64 user (Surface, ASUS, Samsung, HP — see related issues) hits the same wall.
This explains:
Concrete fix path for Anthropic: the Cowork Linux guest needs to be built with VBS-coexistent Hyper-V Integration Services, the same way Microsoft built WSL2's kernel. Reference: https://learn.microsoft.com/en-us/windows/security/hardware-security/pluton/microsoft-pluton-security-processor
Secondary bug worth flagging (not covered in original report)
The auto-reinstall logic in Claude Desktop actively makes recovery harder when this primary bug fires.
After the first
VM connection timeoutfailure, Claude Desktop's auto-reinstall routine:rootfs.vhdx,vmlinuz, andinitrdfrom the bundle (log:[deleteVMBundle] Deleted rootfs.vhdx).CoworkVMServiceends upStopped, and Claude can't restart it.VM service not running. The service failed to start.— 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 create a
.auto_reinstall_attemptedmarker file to break the loop. This effectively turns a single fixable display of the bug into a cascade that destroys the install.Suggested fixes (independent of the primary bug):
rootfs.vhdx/vmlinuz/initrdon a guest-side timeout — those files aren't the problem.CoworkVMServiceis healthy at the end and surface a clear error if it isn't.Note on issue labeling and triage
This issue is currently labeled
invalid — Issue doesn't seem to be related to Claude Code. With respect, this is a Cowork bug, and Cowork ships as part of the same Claude Desktop product that includes Claude Code's agentic capabilities. There's no separate Claude Desktop issue tracker linked from the download page, and other Cowork-tagged ARM64 issues in this same repo (#40198, #66535, etc.) are correctly labeledarea:cowork+platform:windowsrather thaninvalid. Could this issue be re-labeled to match? The current label discourages affected users from upvoting and consolidating evidence here, which is the only signal Anthropic has for prioritization.Happy to provide additional logs, run targeted diagnostics, or test patches.
Follow-up on v1.15962.0.0 — long-soak measurement on this Surface: guest shows idle-level CPU and zero disk writes over 2h40, unlike the Vivobook that boots in ~22 min
Following my previous comment (new kernel
F194146C/ bundle6d1538ba, same 60s timeout), I let the VM soak for 2h40 from a clean boot — plugged in, sleep/hibernate disabled, completely untouched (no app/service restart, per @vsaintloup's warning that those kill the booting guest). I measured the Hyper-V worker process (vmwp) CPU at two points to characterise whether the guest is actually making progress.Measurements
The Cowork VM's
vmwp(PID 35688, started 12:50) accumulated CPU as follows, with my idle WSL2 VM on the same machine as a reference baseline:| Time | Cowork vmwp CPU | WSL2 vmwp CPU (idle, reference) |
|------|-----------------|-------------------------------|
| 15:30 | 4.41 s | 92.95 s |
| 15:39 | 4.69 s | 93.44 s |
| Δ over ~9 min | +0.28 s | +0.49 s |
Over the full 2h40 the Cowork
vmwpaccumulated only ~4.7s of CPU. The per-interval delta (0.28s/9min) is in the same ballpark as my idle WSL2 VM (0.49s/9min) — i.e. the Cowork guest is consuming roughly idle-VM overhead, not the sustained CPU you'd expect from an active 20-minute boot. I can't attribute that small trickle to a specific cause from the host side (it could be hypervisor/vmwpoverhead for a powered-on partition, or the guest looping in some very early init step) — distinguishing those would need the guest console, which isn't surfaced today.Disk: zero writes
More tellingly, across the entire 2h40 soak:
rootfs.vhdxlast-write timestamp never changedsessiondata.vhdxnever writtenA guest that is actually booting writes to disk (the Vivobook reportedly writes hundreds of MB during its ~22-min boot). Here, nothing is written at all.
hcsdiag listshows the compute systemRunningthe whole time, but the guest produces no disk I/O and only idle-level CPU.Why this matters: two distinct Snapdragon failure modes
This thread now has two measurably different behaviours on the same bundle
6d1538ba:| Reporter | Device | Same bundle | Result |
|----------|--------|-------------|--------|
| @vsaintloup | ASUS Vivobook S15 |
6d1538ba| connects at ~22 min, writes hundreds of MB during boot || this report | Surface Laptop |
6d1538ba| never (2h40); idle-level CPU, zero disk writes || @suryanshagarwal2000-bot | HP OmniBook 5 |
6d1538ba| never (70+ min); nocowork-service.logever created |So "Snapdragon X" does not look like a single bug:
What this suggests (and rules out)
crng initblocking): that scenario has the kernel up and services actively waiting, with disk writes from earlier boot stages already on disk. Here there are no writes at all, so any stall is earlier than that.SecurityServicesRunning = 3regardless). WSL2 runs fine because Microsoft built its kernel + integration services to coexist with VBS on ARM64; the generic Ubuntu guest here was not. I want to be clear this is a hypothesis, not a proven cause — the measurements above establish that the guest stalls early, not why.Suggested next step for maintainers
A serial console dump from one of the "stalled boot" machines (Surface / OmniBook) would pinpoint where the kernel halts. The guest console isn't surfaced today, so we can only infer from CPU + disk I/O. If Anthropic can ship a debug build that exposes the guest console (or adds
earlycon/earlyprintkto the kernel cmdline), the two failure modes could be separated — the Vivobook's 22-min boot vs. this Surface's never-progresses stall are almost certainly different root causes needing different fixes.Happy to capture a serial dump or run any targeted diagnostic if a debug build is provided.
@vsaintloup @suryanshagarwal2000-bot — to test the VBS/Pluton hypothesis without needing a debug build, could you each paste the output of this? It's a 30-second check and gives us a hard correlation instead of anecdote.
Legend — VBS status: 2 = enabled+running. Services (enum array, each value = one running service): 1 = Credential Guard, 2 = HVCI, 3 = System Guard Secure Launch, 4 = SMM. The key question: does your machine show
3(Secure Launch) underSecurityServicesRunning?| Device | Failure mode | VBS status | SecurityServicesRunning |
|--------|-------------|-----------|------------------------|
| Surface Laptop (this report) | stalled, 0 disk writes | 2 |
{2, 3}|| ASUS Vivobook S15 | slow, connects ~22 min | ? | ? |
| HP OmniBook 5 | stalled, 70+ min | ? | ? |
On my Surface,
3(Secure Launch) shows up underRunningbut not underConfigured— my local DeviceGuard policy only requested HVCI. That asymmetry is at least consistent with the platform/firmware enabling Secure Launch by default rather than the OS (which is what you'd expect on a Snapdragon Secured-core device with Pluton), though I'd treat that interpretation as tentative until we have the other two rows.Falsifiable prediction: the two stalled machines (Surface + OmniBook) show Secure Launch running, and the slow-but-alive Vivobook does not. If the Vivobook also shows
{2,3}, then VBS-running doesn't distinguish the two failure modes and the Pluton hypothesis weakens — the differentiator would be elsewhere (SoC stepping, a kernel feature, or an OEM firmware quirk). Either way the answer is useful.Separately, for maintainers: since the Cowork guest is an HCS compute system, the concrete equivalent of "surface the guest console" would be adding a COM device to the HCS schema plus
earlycon/earlyprintkon the kernel cmdline. That would let the two failure modes be diagnosed directly instead of inferred from CPU + disk I/O.@ivangc1 — Vivobook row for your table. Result weakens the prediction: my slow-but-alive machine has the same
{2,3}as your stalled Surface.VirtualizationBasedSecurityStatus : 2
SecurityServicesConfigured : {2, 3}
SecurityServicesRunning : {2, 3}
RequiredSecurityProperties : {1}
| Device | Failure mode | VBS status | SecurityServicesRunning |
|--------|-------------|-----------|------------------------|
| ASUS Vivobook S15 (X1P42100) | slow, connects ~22 min | 2 |
{2, 3}|So Secure Launch (3) is running on my machine too — the slow-but-alive Vivobook has the identical VBS profile to your stalled Surface. Per your own falsifiable prediction, that means VBS/Secure-Launch-running does not distinguish the two failure modes, and the Pluton/Secure-Launch theory doesn't hold as the differentiator.
One nuance on the asymmetry you flagged: on my machine
3appears under bothConfiguredandRunning— no Running-but-not-Configured split like your Surface. So that asymmetry isn't universal either.Net: both
{2,3}, opposite boot outcomes → the differentiator between "slow-but-boots" and "never-boots" is elsewhere — SoC stepping, a kernel feature, or an OEM firmware/UEFI quirk, as you anticipated. A guest serial console (earlycon/earlyprintk) remains the thing that would actually separate them.(Context: still bundle
6d1538ba, Claude 1.15962.1, Win11 26200.8655. Boot has trended slower — ~22 min early June → ~45 min on June 24 — but still eventually connects.)@vsaintloup — thanks, decisive row. Both machines show
{2, 3}(HVCI + Secure Launch running) yet opposite boot outcomes, so per the pre-registered prediction Secure-Launch-running is ruled out as the differentiator. A pre-registered negative — saves chasing it.Precise about scope:
{2,3}, opposite outcomes, kills that.{2}configured vs your{2,3}) only says who enabled Secure Launch (firmware default vs OS policy), not the active state, which is identical. Doesn't rescue it.So the stalled-vs-slow differentiator is elsewhere. Next cheap probe — flagging up front it's weaker than the VBS one, since the fields are hard to compare across OEMs (WMI's ARM CPU Description is coarse and likely identical on all three; firmware version strings aren't on the same scale across Surface/ASUS/HP):
My row, in WMI format so the three are directly comparable:
| Device | Failure mode | CPU (WMI) | Revision | BIOS |
| --- | --- | --- | --- | --- |
| Surface Laptop (this report) | stalled, 0 writes | Snapdragon X Plus (8-core); ARMv8 Family 8 Model 1 | 513 | 8.722.235 |
| ASUS Vivobook S15 | slow, ~22→45 min | ? | ? | ? |
| HP OmniBook 5 | stalled, 70+ min | ? | ? | ? |
(WMI only exposes "Snapdragon X Plus (8-core)" for me, not the X1P-xx SKU — so I'm not claiming my chip differs from the Vivobook's X1P42100; could be the same. Need the same WMI output from both to say anything.)
The thing that would actually separate stalled from slow remains a guest serial console (
earlycon/earlyprintkvia a COM device in the HCS schema); this probe just narrows the hardware axis while we wait on that.(@vsaintloup — your boot drift 22→45 min on the same bundle is its own thread in the slow mode; worth isolating against Windows build / app version / cold-vs-warm.)