[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Cowork sandbox unusable on Windows ARM64 — guest VM never reaches userspace within practical timeouts
Build: 1.4758.0.0, sideloaded developer-signed MSIX, ARM64 Windows. Single clean install verified (single registered package, all per-user AppData and C:\ProgramData\Claude deleted before reinstall, fresh reboot). User account Work, non-admin.
Symptom: every mcp__workspace__bash call returns Workspace still starting then Workspace unavailable.
Reproducible from a fully clean state (service stopped → bundle's unpacked artefacts deleted leaving only .zst archives and smol-bin.vhdx → service restarted → fresh extract triggered by client connect):

1. Host side is healthy. CoworkVMService runs as LocalSystem, signature-verifies, opens named pipe, accepts client. HcsCreateComputeSystem and HcsStartComputeSystem both return hr=0x0. HCS reports State: Running indefinitely.
2. Guest side never makes progress. On the most recent test (VM start 18:24:34, observation +15 minutes): zero console output, zero disk writes to rootfs.vhdx or sessiondata.vhdx since extraction. Kernel has not reached userspace at all.
3. Previous run with the same bundle eventually produced output at +31m29s post VM start (measured from cowork-service.log VM-start timestamp vs. first coworkd line on the guest console, normalised for a confirmed +1h host-vs-guest clock offset arising from the broken host-RPC time-sync that this same bug causes). Healthy reference is single-digit seconds. Likely an early-boot device-probe timeout in the kernel ARM64 build.
4. Even when the guest eventually does come up, sdk-daemon never connects. On the previous run, coworkd's bring-up sequence ran the in-VM updater (replacing sdk-daemon, sandbox-helper, srt-settings.json, cli-wrapper, and coworkd itself from smol-bin.vhdx), brought up tap0, and connected to host vsock port 1024 (visible from the host as [VNet] VM network connected). The guest console then went silent — no sdk-daemon line, no error. The host's RPC listener on vsock port 51234 never received any connection in the lifetime of the VM.
5. Host-side liveness checks fire at +60s (.auto_reinstall_attempted marker is written to the bundle dir exactly 60 seconds after each VM start). On this hardware that's ~30× too short and triggers an auto-recovery attempt long before the guest could possibly be ready.

Net effect: stacked bugs (slow guest boot + sdk-daemon RPC failure + under-provisioned host timeouts) that compound to make the sandbox completely unusable on this ARM64 build, with no apparent user-side workaround.
Logs available on request: cowork-service.log (~20 KB) and coworkd/user-<sid>.log (~3 KB from the previous run, 0 bytes from the latest re-extract). Reproduction: trivial — just run a bash tool call after install.

What Should Happen?

On a fresh install of Cowork for Windows on ARM64, calling the mcp__workspace__bash tool from a chat should produce a working Linux shell within a few seconds, the same way it does on Windows x64. Specifically: the guest Linux VM should boot to userspace in a small number of seconds, coworkd should run its first-time setup, sdk-daemon should launch and connect to the host service over hvsock port 51234, and a simple command like echo test should return test and exit successfully on the first or second tool call. Subsequent tool calls should reuse the same VM and return promptly. Instead, every tool call returns Workspace still starting followed by Workspace unavailable, and the VM never produces a usable sandbox in any reasonable amount of time.

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce
Environment required: a Windows on ARM64 device (the bug appears specific to the ARM64 build of Cowork; x64 reportedly works on the same network).

On a clean Windows ARM64 device, install Cowork via the sideloaded developer-signed MSIX package (build 1.4758.0.0 reproduces).
Sign into Cowork as a non-admin user account (Work in this report). Confirm Get-AppxPackage claude shows exactly one Cowork/Claude package and Get-Service CoworkVMService shows Running under LocalSystem.
Start a new chat in Cowork.
From the chat, ask Claude to run any shell command, e.g. "run echo test for me". This invokes the mcp__workspace__bash tool.
Observed: every call returns Workspace still starting for some seconds, then Workspace unavailable. The sandbox never becomes ready, even after waiting 30+ minutes. File-tools (Read/Write/Edit) work normally, only the Linux sandbox is affected.
Expected: the first call should return the command output (e.g. test) within a few seconds.

Verifying the underlying failure from the host's own logs (no special tooling required — these are read with regular Get-Content):

Open C:\ProgramData\Claude\Logs\cowork-service.log. Confirm HcsCreateComputeSystem and HcsStartComputeSystem both return hr=0x0 and [VM] VM started successfully is logged. Confirm subsequent HcsGetComputeSystemProperties calls report "State":"Running". Confirm the line [RPC] Server started, waiting for sdk-daemon connection on port 51234 is logged but never followed by any line indicating a connection on that port.
Open C:\ProgramData\Claude\Logs\coworkd\user-S-<sid>.log (the in-VM serial console, captured by the host service via named pipe). On a fresh re-extract test, this file remains 0 bytes for many minutes despite the VM being in State: Running — i.e. the guest is producing no console output at all, indicating the kernel has not reached userspace.
Inspect the bundle directory at C:\Users\<user>\AppData\Local\Packages\Claude_<hash>\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle. Confirm .auto_reinstall_attempted exists with a LastWriteTime exactly 60 seconds after the host's [VM] VM started successfully timestamp — the host's auto-recovery timeout fires far earlier than the guest could plausibly come up.
Confirm reproducibility from a clean state (rules out per-install corruption): stop the service, delete rootfs.vhdx, sessiondata.vhdx, initrd, vmlinuz, and .auto_reinstall_attempted from the bundle directory (leaving only the *.zst archives and smol-bin.vhdx), restart the service, then trigger a bash tool call from a chat. The bundle re-extracts from the .zst archives and the same failure recurs identically.

Minimal command sequence to reproduce step 10 in admin PowerShell:
powershellStop-Service CoworkVMService -Force
$bundle = "C:\Users\Work\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle"
Remove-Item "$bundle\rootfs.vhdx","$bundle\sessiondata.vhdx","$bundle\initrd","$bundle\vmlinuz","$bundle\.auto_reinstall_attempted" -Force -ErrorAction SilentlyContinue
Clear-Content "C:\ProgramData\Claude\Logs\cowork-service.log"
Clear-Content "C:\ProgramData\Claude\Logs\coworkd\user-S-1-5-*.log" -ErrorAction SilentlyContinue
Start-Service CoworkVMService

Then relaunch Cowork from system tray and request a bash tool call from a chat.

Observe identical failure pattern: same 0-byte guest console log, same +60s auto-reinstall marker, same RPC silence on hvsock port 51234.

Both cowork-service.log and coworkd\user-S-<sid>.log are small (~20 KB and 0–3 KB respectively) and can be attached in full as supporting evidence.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Cowork 1.4758.0.0 (ARM64)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_