[BUG] Claude Cowork sandbox never becomes ready on Windows ARM64 / Snapdragon X Plus

Confirming this on my setup — same VM connection timeout, 100% reproducible.
Device: ASUS Zenbook A14 (UX3407QA)

CPU: Snapdragon X – X1-26-100, Qualcomm Oryon CPU @ 2.96 GHz (ARM64)

GPU: Qualcomm Adreno X1-45

RAM: 32 GB

OS: Windows 11 Home, Version 25H2, Build 26200.8655 — System type: ARM-based (64-bit)

Claude app version: 1.13576.0.0
Symptom: Every Cowork session that needs the Linux sandbox fails with "Failed to start Claude's workspace — VM connection timeout after 60 seconds." The Windows side reports the VM as started, but the guest never becomes ready.
Reproduction: 100% — every session, every time.
Things I already ruled out (so this is clearly the ARM/virtualization issue, not config):

Moved my working folder off OneDrive onto a local C: drive → no change.
The folder/sync setup is not the cause; the failure happens before any file work.
File operations themselves work fine — reading/writing files in my workspace succeeds even while the VM times out. Only the Linux sandbox (running code, generating Office/PDF files) is broken.

Impact: Document generation (.docx/.xlsx/.pptx/.pdf) and any code execution are completely unusable on this device. Plain file/note work still functions.
Note: This matches several other reports for Snapdragon X / Windows ARM64 (#46516, #39636, #42784, #40198). Looks like the Linux guest kernel never reaches init under the ARM64 virtualization layer.

I was able to get Claude Desktop working again by fully restarting the background service.

Steps:

1. Quit Claude Desktop completely.
2. Press Win + R, type services.msc, and hit Enter.
3. Find the service named "Claude".

• Right‑click → Stop (if running).
• Then right‑click again → Start.
• Alternatively, in PowerShell you can run:

``powershell
Stop-Service CoworkVMService
Start-Sleep -Seconds 5
Start-Service CoworkVMService
``

1. Reopen Claude Desktop.
2. Wait ~2 minutes
3. Then in the Chat/Cowork tab test with a simple prompt like:

``
run echo "hello world"
``

<br/>

Credits:

• reddit comment/ok53gg5

[BUG] Cowork Linux sandbox never becomes ready on Windows 11 Pro ARM64 — VM boots, guest never connects (timeout after 60s)

Environment

• Device: Windows on ARM64 (Snapdragon)
• OS: Windows 11 Pro, ARM64
• App: Claude Desktop (Microsoft Store), version 1.18286.0.0, package Claude_1.18286.0.0_arm64__pzs8sxrjxfjjc
• Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
• Hyper-V: fully enabled, vmms service Running
• CoworkVMService: Running (Store build; startup type cannot be changed to Automatic — "Access denied" even as admin)

What's wrong

The Cowork Linux sandbox never becomes ready. Every attempt ends with:

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

All VM startup steps complete successfully, the VM boots, but the Linux guest / sdk-daemon never connects back to the host. Bash tool calls fall back to "Workspace unavailable"; Claude routes commands to Desktop Commander (host PowerShell) instead.

This appears identical to #66535 (Windows ARM64 / Snapdragon X Plus).

Steps already taken (no effect)

1. Enabled Hyper-V (Microsoft-Hyper-V-All), verified vmms Running — confirmed working
2. Verified/started CoworkVMService manually
3. Reinstalled workspace via the in-app "reinstall the workspace" link
4. Full Windows restarts (multiple)
5. Killed stale VM instances, stopped the service, deleted the VM bundle at the package-virtualized path %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles (note: earlier attempts at %APPDATA%\Claude\vm_bundles were ineffective due to MSIX path virtualization)
6. After the clean bundle re-copy, smol-bin.arm64.vhdx copied successfully (no more EBUSY) — issue still reproduces

Log excerpt — clean run after bundle reset (cowork_vm_node.log)

2026-07-03 14:49:46 [info] [VM:start] Beginning startup, bundlePath=C:\Users\...\vm_bundles\claudevm.bundle
2026-07-03 14:49:46 [info] [VM:start] Bundle version: 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a
2026-07-03 14:49:46 [info] [VM:steps] download_and_sdk_prepare completed (2ms)
2026-07-03 14:49:46 [info] [VM:steps] load_swift_api completed (0ms)
2026-07-03 14:49:46 [info] [VM:start] smol-bin.arm64.vhdx copied successfully
2026-07-03 14:49:46 [info] [VM:start] Windows VM service configured
2026-07-03 14:49:46 [info] [VM:steps] create_network completed (1ms)
2026-07-03 14:49:46 [info] [VM:steps] create_vm_config completed (58ms)
2026-07-03 14:49:47 [info] [VM:steps] vm_boot completed (1201ms)
2026-07-03 14:49:47 [info] [VM:steps] add_plan9_shares completed (5ms)
2026-07-03 14:49:57 [info] [VM:start] Still waiting for guest connection... 10163ms elapsed, 21 polls
...
2026-07-03 14:50:47 [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
2026-07-03 14:50:47 [error] [VM:start] Startup failed: Error: VM connection timeout after 60 seconds

Earlier runs (before the bundle reset) additionally showed smol-bin.vhdx locked by running VM (EBUSY), skipping copy on every attempt, including immediately after a full OS restart, and timeouts with last completed step: load_swift_api.

Additional service-side logs available on request: C:\ProgramData\Claude\Logs\cowork-service.log.

Expected behavior

The Linux sandbox should start and the guest should connect back to the host, allowing bash commands to run inside the Cowork workspace.

Notes

• Regular Claude Desktop chat, file tools, and MCP connectors work fine — only the Linux sandbox is broken.
• Secondary issue worth flagging: on the Store build, CoworkVMService ships with startup type Manual and cannot be switched to Automatic (access denied even elevated), so the service must be started manually after some reboots.

### 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? Device: Surface Pro 12-inch / Windows ARM64 CPU: Snapdragon X Plus (8-core) @ 3.30 GHz CPU manufacturer: Qualcomm Technologies Inc OS: Windows 11 Home, build 26200 Claude Desktop: 1.11187.1.0 arm64 Claude package: Claude_1.11187.1.0_arm64__pzs8sxrjxfjjc Claude Cowork chat opens normally, but the Cowork sandbox never becomes ready. When I ask Cowork to run a simple command such as: echo hello the command does not run. The output is always: `` Workspace still starting. The isolated Linux environment is booting in the background (usually 10-30 seconds). Try again shortly. ` Waiting several minutes does not fix it. Retrying does not fix it. I also sometimes see: ` VM connection timeout after 60 seconds ` The Windows/HCS VM appears to start successfully, but the Linux guest / sandbox daemon never connects back to the host. ### What Should Happen? Claude Cowork should successfully start the isolated Linux sandbox/VM and allow commands to run inside the selected workspace. A simple command like: echo hello should execute successfully and return: hello Claude should also be able to create and run a simple Python file in the workspace without the sandbox staying in a "Workspace still starting" state. ### Error Messages/Logs Command output in Claude Cowork: Workspace still starting. The isolated Linux environment is booting in the background (usually 10-30 seconds). Try again shortly. Sometimes the UI also shows: Failed to start Claude's workspace VM connection timeout after 60 seconds Relevant cowork_vm_node.log: [VM:start] Beginning startup [VM:steps] download_and_sdk_prepare completed [VM:steps] load_swift_api completed [VM:steps] create_network completed [VM:steps] create_vm_config completed [VM:steps] vm_boot completed [VM:steps] add_plan9_shares completed [VM:start] Still waiting for guest connection... 10193ms elapsed [VM:start] Still waiting for guest connection... 20381ms elapsed [VM:start] Still waiting for guest connection... 30568ms elapsed [VM:start] Still waiting for guest connection... 40809ms elapsed [VM:start] Still waiting for guest connection... 50964ms elapsed [VM:start] Connection timeout, last completed step: add_plan9_shares Dispatching startup error: VM connection timeout after 60 seconds [VM:start] Startup failed: Error: VM connection timeout after 60 seconds Relevant cowork-service.log: [HCS] HcsCreateComputeSystem returned: hr=0x0 [HCS] HcsStartComputeSystem returned: hr=0x0 [HVSock] Listening on port 51234 [RPC] Server started, waiting for sdk-daemon connection on port 51234 [VNet] Listening for VM network connections on vsock port 1024 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ [VM] Adding Plan9 share via HcsModifyComputeSystem: name=d path=D:\ [VM] VM started successfully The Windows/HCS VM appears to start successfully, but the Linux guest / sdk-daemon never connects back to the host. ### Steps to Reproduce 1. Use a Windows ARM64 device with Snapdragon X Plus. 2. Install Claude Desktop ARM64. 3. Open Claude Desktop and go to Claude Cowork. 4. Create or open a clean workspace, for example: C:\Users<user>\Claude\Projects\TEST COWORK 5. Ask Claude Cowork to run exactly one command: echo hello 6. The command does not run. Instead, it returns: Workspace still starting. The isolated Linux environment is booting in the background (usually 10-30 seconds). Try again shortly. 7. Wait several minutes and try again. The same message appears. 8. The issue also reproduces after restarting Windows and after resetting the Cowork VM bundle folders. ### Claude Model Sonnet (default) ### Is this a regression? No, this never worked ### Last Working Version _No response_ ### Claude Code Version 2.1.165 bundled with Claude Desktop/Cowork ### Platform Anthropic API ### Operating System Windows ### Terminal/Shell PowerShell ### Additional Information This is not using a globally installed Claude CLI. The claude` command is not available in PATH. Bundled versions found under Claude Desktop/Cowork data directory: Bundled Claude Code: 2.1.165 Bundled Claude Code VM: 2.1.165 Claude Desktop package: Claude_1.11187.1.0_arm64__pzs8sxrjxfjjc Hardware: CPU: Snapdragon X Plus (8-core) @ 3.30 GHz Manufacturer: Qualcomm Technologies Inc CPU architecture: ARM64 / WMI Architecture 12 OS: Windows 11 Home ARM64, build 26200 I tested a clean workspace on C: and also an existing workspace on D:. Both reproduce the same issue. I already tried: Restarting Claude Desktop Restarting Windows Enabling HypervisorPlatform, VirtualMachinePlatform, and WSL Confirming CoworkVMService, hns, and vmcompute are running Confirming the HCS VM is running via hcsdiag list Renaming/resetting vm_bundles, claude-code-vm, and local-agent-mode-sessions * Letting Claude re-download/recreate the VM bundle The issue still reproduces after all of the above.

comment_issue_66535.md

Reproduced this exact signature on a non-ARM64 device — Intel Core Ultra 7 165U, Windows 11, MSIX install (Claude_1.17377.2.0_x64 and Claude_1.18286.0.0_x64, both reproduce). Adding for corroboration since this issue is currently filed under Snapdragon X Plus specifically, but the failure doesn't appear to be ARM64-specific.

Identical failure point and timeout window:

2026-07-03 01:17:53 [info] [VM:steps] add_plan9_shares started
2026-07-03 01:17:56 [info] [VM] Network status: NOT_CONNECTED
2026-07-03 01:17:56 [info] [VM:network] Not connected, will show error in 30000ms if not resolved
2026-07-03 01:17:56 [info] [VM] Network status: CONNECTED
2026-07-03 01:18:51 [error] [VM:start] VM boot failed: Request timed out: startVM
2026-07-03 01:18:51 [info] Dispatching startup error: Request timed out: startVM

Same pattern as this issue's log — VM actually succeeds after the timeout is already reported:

2026-07-03 01:28:53 [info] [VM] API reachability: REACHABLE
2026-07-03 01:36:22 [info] [startVM] VM already connected
2026-07-03 01:40:00 [info] [postConnect] Installing SDK: version=2.1.197

So on my hardware, the VM wasn't stuck — it completed roughly 10 minutes after add_plan9_shares started, well past the ~58-60 second startVM timeout. The app never reconciles UI state once this happens; the user is left looking at a failure dialog for a session that's actually fine.

Reproduced twice across two app versions (1.17377.2.0 → auto-updated to 1.18286.0.0), both times hanging at the same step with the same ~60s timeout regardless of eventual boot duration. Both instances also show a brief NOT_CONNECTED→CONNECTED network status flip within ~3 seconds of add_plan9_shares starting, immediately before the hang — possibly worth checking whether the share-mount step is racing the virtual network interface coming up, though I can't confirm that's causal from the client-side logs alone.

Given this reproduces on Intel x64 as well as Snapdragon ARM64, seems safe to conclude the root cause is in the shared add_plan9_shares implementation / timeout logic itself, not architecture-specific.

Environment:

• Windows 11, MSIX install (Claude_pzs8sxrjxfjjc)
• Intel Core Ultra 7 165U, 32GB RAM, hypervisor active
• App versions: 1.17377.2.0 and 1.18286.0.0 (both reproduce)

System info

• CPU: Qualcomm Snapdragon(R) X - X126100 (Oryon), Windows ARM64
• Windows build: 10.0.26200.8655
• Claude Desktop version: 1.18286.0.0 (arm64)
• Hyper-V compute service (vmcompute, HvHost) running fine; WSL2 (Ubuntu) works

normally on this machine — base virtualization is not the issue.

Symptom

Same as reported here — every Cowork/workspace launch fails with:
Failed to start Claude's workspace / VM connection timeout after 60 seconds

Happening consistently since at least 2026-06-27, still occurring today (2026-07-04).

I tried the fix suggested in this thread (fully quitting Claude, restarting the
CoworkVMService Windows service via Stop-Service/Start-Service, then relaunching).
It did NOT resolve the issue. Confirmed via logs that the service got a new
ProcessId and the app processes had fresh start times, so the restart genuinely
happened — but the next VM start attempt failed at the exact same step:

create_network completed (1ms)
create_vm_config completed (125ms)
vm_boot completed (384ms)
add_plan9_shares completed (6ms)
Still waiting for guest connection... (times out at 60s)
Connection timeout, last completed step: add_plan9_shares

The VM itself boots and the plan9 shares are set up in single-digit milliseconds,
but the guest agent never phones back to the host. This points to the guest
image / HCS integration not completing correctly on this ARM64 chipset, rather
than a stale service/network state — a full service restart made no difference.

Full logs attached (cowork_vm_node.log, ssh.log).

Also affected — same root cause, different device.

CPU: Snapdragon X Plus (8-core) @ 3.30 GHz, Qualcomm Oryon architecture
RAM: 16 GB
GPU: Qualcomm(R) Adreno(TM) X1-45
OS: Windows 11, 64-bit, ARM-based processor
Claude Desktop: 1.20186.1.0 (arm64, installed via Microsoft Store/MSIX)

Same error every time: "VM connection timeout after 60 seconds"

Troubleshooting already attempted (no change):

• Confirmed CPU virtualization is enabled (Task Manager shows "Virtualization: Enabled")
• Enabled "Windows Hypervisor Platform" and "Virtual Machine Platform" (no standalone "Hyper-V" entry available on this ARM64 build — same as reported above)
• Added inbound/outbound Windows Firewall allow rules for claude.exe
• Restarted app and PC multiple times
• Confirmed via status.claude.com that no service-side incident was active at the time of failure

This matches the theory above that it's a Cowork VM image / ARM Windows compatibility issue rather than a per-device config problem. Please don't close this as stale — it's still actively affecting ARM64 Snapdragon users.

Same failure here on Snapdragon X / Windows 11 Home ARM64, but after instrumenting it over several weeks I think the "60s timeout" framing is hiding what's actually going on. Three findings that I haven't seen in this thread yet.

1. The guest always connects — just 20 minutes to 2 hours late. Every "success" is an adoption.

The host side never fails: HcsCreateComputeSystem and HcsStartComputeSystem both return hr=0x0, Plan9 shares attach, and the hv-socket listener binds on port 51234. The app then times out at 60s — but the VM is left running, and the guest eventually connects. A later start attempt finds it already up and adopts it, which surfaces as a "clean success".

I matched every sdk-daemon is ready! in cowork-service.log to the Creating HCS compute system that preceded it:

| VM booted | sdk-daemon ready | Guest took |
|---|---|---|
| 27 Apr 16:03 | 27 Apr 17:50 | 1h 47m |
| 05 May 22:57 | 06 May 00:21 | 1h 24m |
| 14 May 22:11 | 15 May 00:07 | 1h 57m |
| 19 May 15:00 | 19 May 15:23 | 22m (fastest ever) |
| 08 Jul 00:01 | 08 Jul 08:39 | 8h 38m |
| 14 Jul 20:37 | 14 Jul 22:42 | 2h 05m |
| 15 Jul 08:02 | 15 Jul 08:41 | 39m |
| 19 Jul 20:22 | 20 Jul 08:10 | 11h 47m |

Not one fresh boot has ever connected within 60 seconds on this machine. The overnight figures overstate it — Modern Standby pauses the VM, so sleep time doesn't count. Awake-time to connect is roughly 20 minutes to 2 hours.

Practical consequence: leaving the machine awake and plugged in, then reopening Cowork an hour later, works reliably. That's a usable workaround, and it also means anyone reporting "it randomly started working" is probably adopting a VM booted much earlier.

2. The guest is spinning at 100% CPU, not hanging or starving — this looks like a virtual timer problem

During the silent phase I sampled the guest's resource use:

• vmmem sits at a steady ~100% of one vCPU
• working set is 7 MB out of a 4096 MB allocation
• host had 2–4 GB RAM free at the time

So it is executing flat out while touching almost no memory, indefinitely, and then completes correctly. That rules out I/O stalls (would be near-zero CPU) and memory starvation (host wasn't under pressure). It's the signature of a busy-wait: thousands of small kernel delay/calibration loops each taking orders of magnitude longer than intended, which is what you'd expect if the virtualized ARM generic timer is being read or delivered incorrectly under Hyper-V on this SoC.

Corroborating evidence from the guest console log on one occasion where userspace did come up: ordinary operations ran 10–100× slow (a update-ca-certificates --fresh that normally takes ~3s took 27.7s; mount of a 9p share took 6s; the smol-bin mount once took 9m 35s). The whole guest was living on a slow clock, not just one boot stage.

Control experiment on the same machine: WSL2 Ubuntu boots in seconds — same hypervisor, same VirtualMachinePlatform, same hv-socket/9p plumbing, same Windows build. Microsoft's kernel ships Hyper-V clock enlightenments; the Cowork guest kernel presumably isn't getting the same timer path here. That points squarely at the guest image rather than the host, and would explain why this cluster of reports is specific to Snapdragon X machines.

3. Separate bug: coworkd identifies the session disk positionally and can crash-loop forever

Distinct from the slow boot. On 16 Jul the guest booted fine but Linux enumerated the SCSI disks in a different order — the updater found smol-bin at /dev/sdc1 instead of the usual /dev/sdb1. coworkd then treated /dev/sdc (which is the smol-bin disk, attached ReadOnly: true by the host) as the session disk and tried to format it:

[hyperv] found session disk at /dev/sdc
[coworkd] formatting session disk /dev/sdc with ext4
[coworkd] could not mount session disk: failed to format session disk: exit status 1: mke2fs 1.46.5 (30-Dec-2021)
/dev/sdc: Read-only file system while setting up superblock

coworkd treats that as fatal and restarts — and looped this way for 9+ hours (14:21 to 23:15) until the VM was killed. Unlike the slow boot, this never self-heals, because the enumeration doesn't change within a VM's lifetime. Selecting the session disk by label/UUID/serial rather than by device node would fix it.

Worth noting this log is the most useful diagnostic in the whole stack and I don't think it's widely known: C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log is the guest's own console output (coworkd writes to /dev/vport0p0, which the host service pipes to that file). If it's silent, the guest hasn't reached userspace yet; if it's looping on Read-only file system, you've hit the bug above.

Suggested fixes, in priority order

1. Guest kernel timer handling on Snapdragon X — the root cause. Nothing user-side can touch it; the kernel cmdline is hard-coded in cowork-svc.exe (initrd=\%s root=/dev/sda1 rootfstype=ext4 rw panic=10) and the image is a signed bundle.
2. Don't hard-fail at 60s. The constant is 6e4 ms in app.asar with no env or config override. Since the VM keeps booting in the background anyway, an async "workspace still starting, we'll notify you" state — or simply a configurable timeout — would turn this from "completely broken" into "slow but usable" for every affected machine.
3. Select the session disk by label/UUID, not /dev/sdX.

Environment

• ASUS Vivobook S 14 (S3407QA), Snapdragon X X1-26-100 (Qualcomm Oryon, 8 cores), 15.6 GB RAM
• Windows 11 Home ARM64, build 26200
• Claude Desktop 1.24012.1.0 → 1.24012.9.0 (arm64, MSIX)
• VM bundle 6d1538ba6fecc4e5c5583993c4b30bb1875f0f5a (unchanged across app updates; a fresh bundle re-download on 12 Jul changed nothing)
• VM config: 2 vCPU, 4096 MB, AllowOvercommit: true

Things that are NOT the cause (tested on this machine, so nobody else needs to)

• Windows 11 Pro is not required. vmms is absent on Home, but Cowork calls the HCS API directly and never touches it — VM create/start/modify all return hr=0x0. Don't buy Pro for this.
• Reinstalling the VM bundle — same image hash, verified no change.
• Memory Integrity / VBS, third-party hypervisors (none installed), firmware and Windows updates, disk space, reboots.
• Antivirus — Malwarebytes' own RTP log shows the VM bundle paths and vmwp.exe are excluded, not scanned.
• HNS/networking — Get-HnsNetwork returns zero networks, but the control channel is an hv-socket, not the NAT network, so that's a red herring for this symptom.

Two follow-ups after reading back through this thread.

@CarlKnox's Intel x64 report is the same mechanism. A guest that completed ~10 minutes after add_plan9_shares, long past the 60s timeout, with the UI never reconciling — that is exactly the late-connection pattern above, independently observed on non-ARM hardware. So the timeout-vs-reality mismatch looks cross-platform, while the magnitude is what's Snapdragon-specific (10 minutes there vs 22 minutes to 2 hours here). That distinction matters for triage: fixing the timeout handling helps everyone, fixing the guest timer behaviour is what makes Snapdragon machines usable.

A warning about the CoworkVMService restart workaround in this thread: under the model above it's counterproductive, and I'd suggest people stop recommending it. Stopping the service tears down the compute system, so it kills any VM that was quietly making progress toward connecting — and the suggested ~2 minute wait afterwards is nowhere near long enough for a fresh guest to boot on affected hardware. @ohgodhsiang already reported it made no difference. The opposite approach is what actually works: let the first attempt "fail", leave the VM running, keep the machine awake (Modern Standby pauses the VM, so sleep time doesn't count), and reopen Cowork later — it adopts the now-ready VM instantly.

Readiness can be checked without guessing from the UI, which shows the same "still starting" state whether the guest is 30 seconds or 90 minutes away:

Select-String "C:\ProgramData\Claude\Logs\cowork-service.log" -Pattern "sdk-daemon is ready" | Select-Object -Last 1

A timestamp later than your boot attempt means the guest is up.

Correction to my previous comment, plus a third failure mode I hadn't identified.

I said the CoworkVMService restart workaround should stop being recommended. That was too broad and I was wrong about it. It fixes a real failure — just not the slow-boot one. Both things are true:

• Slow-boot case: restarting the service destroys a VM that is still making progress toward connecting, and the suggested ~2 minute wait is far too short. Counterproductive there.
• Service-stopped case (below): restarting the service is exactly the right fix, and @sekedus's steps work.

Mode C: the service idle-stops and the app never recovers.

CoworkVMService shuts down when its last client disconnects — the log line is:

[Server] Session hecto:...\Roaming\Claude has no active connections, idle timeout starts

Quitting or restarting Claude Desktop triggers this. The service exits and tears down any running VM with it (so a VM you were deliberately letting boot in the background dies silently — no VM stopped line is written, because the process that would log it is gone).

On the next launch, the app tries to reach the service's named pipe and fails, once per second, indefinitely:

[warn] [vm-client] Event resubscribe failed: Error: connect ENOENT \\.\pipe\cowork-vm-service

It never surfaces this to the user. The UI shows the same "workspace still starting" / timeout messaging as every other failure, so it is indistinguishable from the guest-boot problem — and no amount of waiting or retrying will fix it, because no VM is ever created.

Fix, and it needs no admin rights:

Start-Service CoworkVMService

The pipe reappears and the app reconnects within a second or two ([Server] Event subscriber connected). Then open Cowork to actually boot a VM.

Two suggestions:

1. The app should detect ENOENT on \\.\pipe\cowork-vm-service and either start the service or tell the user to — rather than retrying silently forever behind a generic timeout message. This alone would resolve a chunk of the "nothing works, tried everything" reports in these threads.
2. Worth checking whether the service's idle shutdown should be suppressed while a compute system is still running. Right now, quitting the app kills a guest that may be 90 minutes into a 2-hour boot.

Diagnosing these separately matters, because the right action is opposite in each case: for Mode C, restart the service; for a slow boot, do not touch it and just wait.

Outcome update, and two findings that change how this should be triaged.

1. A fresh guest boot finally succeeded — and the workspace still did not start.

VM created 15:49:37, sdk-daemon is ready! at 16:29:49 — 40 minutes, machine kept awake throughout. The guest came up properly: Plan9 share mounted, 85 CA certs installed, API reachability passed, coworkd: connected, waiting for commands. So the boot really is a finite wait, not a hang.

But the post-connect SDK install never completes. The app copies a single 259 MB claude binary (v2.1.219) host→guest over the 9p mount, with a 30-second budget:

16:30:12 [postConnect] Installing SDK: version=2.1.219
16:30:42 [startVM] Post-connect setup failed on already-connected fast path: Error: request timed out after 30s
16:31:14 [postConnect] Installing SDK: version=2.1.219      <- restarts from zero
16:31:44 ...timed out after 30s

That repeated for over an hour. It is a livelock: each timeout restarts the copy, so no attempt can ever finish. The VM boot survives its own timeout only by accident — the app gives up but leaves the VM running, so the guest finishes later and a subsequent attempt adopts it. The SDK install has no such escape hatch.

Measurements during a live attempt (window verified against log timestamps, 17:26:18→17:26:48):

| Metric | Value | Meaning |
|---|---|---|
| vmmem working set | flat 19 MB | guest pulls in no data |
| vmmem CPU | ~90–137 % | guest pegs a full vCPU |
| vmwp CPU | 0.0 % | host-side 9p reads never served |

The vmwp reading is the decisive one. If 259 MB were crossing the mount, the VM worker process would be busy serving those reads. At a flat 0 %, no file data moves at all — the guest burns a core somewhere before issuing a single read. This is the same execution-speed problem as the boot phase, one layer up, not a slow file copy.

Consequence for triage: raising the 60s VM timeout alone would not fix these machines. They would simply fail 30 seconds later, at a step whose retry discards all progress. Suggestions:

1. Give the post-connect SDK install the same treatment — a longer or adaptive budget, and make it resumable/idempotent so retries build on prior progress instead of restarting.
2. Consider not copying 259 MB over 9p on every workspace start — cache it in the session disk or the guest image.

2. The Desktop Cowork tab silently falls back to a remote x86_64 sandbox when the local VM fails — which is almost certainly why some people report Cowork "working" while their VM is plainly broken.

While the local VM above was still failing, the Claude Desktop Cowork tab (not a browser session) ran echo hello successfully. uname -a in that sandbox returned:

Linux vm 6.18.5 #1 SMP PREEMPT_DYNAMIC @0 x86_64 x86_64 x86_64 GNU/Linux

x86_64 — on a Snapdragon laptop whose local guest image is smol-bin.arm64.vhdx. At the same moment (17:26:48 / 17:27:36 / 17:28:55) the local VM was still logging SDK-install timeouts with its guest console silent. The two cannot be the same sandbox. Further probing of the working sandbox:

• mount | grep -E '9p|virtiofs|plan9' → no 9p mounts
• /mnt/ contains only user-data; no /mnt/.virtiofs-root/shared
• nproc = 2, RAM = 8023 MB (the local VM is configured 2 vCPU / 4096 MB)
• no /sys/class/dmi/id/* at all

So it is a remote container-style sandbox with no access to the local filesystem. Two implications worth stating explicitly in this thread:

• "It started working" reports may not mean the VM was fixed. Anyone confirming a fix should check uname -m — if it says x86_64 on an ARM machine, the local VM is still broken and the fallback served the command. Several "fixed for me" confirmations in these threads may be this.
• The fallback is silent. Nothing in the UI indicates that execution moved off-device. Users working with confidential material would reasonably assume the local VM is still running their code, when in fact the files they hand the sandbox are leaving the machine. Even a small indicator would be worth having.
• The local VM is not redundant. Its whole point is the 9p mount of the host filesystem: code running against the user's real files in place. The remote sandbox requires upload/download through /mnt/user-data, and sends the data off-machine — which matters for anyone working with confidential documents, and rules out offline use entirely.