[BUG] Cowork on Windows 11 ARM64: bash sandbox has never worked — guest VM boots on the host but a usable shell is never delivered ("VM connection timeout after 60 seconds")

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?

On Windows 11 Pro ARM64, the Cowork Linux sandbox has never worked on this machine — no bash tool call has ever returned a result. Every attempt ends in "Workspace unavailable" / "VM connection timeout after 60 seconds." Chat and file tools work; only the Linux sandbox is affected. The failure is persistent, but it presents with different signatures at the log level across boots (detailed below).

The failure is guest-side and persistent. On failing boots:

• Host side is completely healthy. The service starts and verifies its signature, HcsCreateComputeSystem returns hr=0x0, HcsStartComputeSystem returns hr=0x0, the RPC server listens on hvsock port 51234, the virtual network listens on port 1024, VM started successfully, and the daemon console pipe connects.
• The guest produces zero console output. coworkd never writes a single line to the serial console. The in-VM log's most recent entry stays frozen at the last successful boot even after multiple new VM starts. The guest Linux kernel never reaches userspace.
• After the timeout the host force-terminates the VM: HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032.

Because the guest never reaches userspace, sdk-daemon never launches and never connects back to the host on port 51234 — hence the timeout.

Persistent failure with different signatures across boots (all on build 1.21459.3.0)

Cowork bash has never delivered a working shell on this machine. The guest-side failure has appeared in three forms:

• 2026-07-13 / 07-14 — guest boots, wrong disk formatted. The guest did reach userspace and coworkd ran, but the read-only smol-bin disk enumerated as /dev/sdc ([updater] found smol-bin device: /dev/sdc1) while coworkd assumed the writable session disk was /dev/sdc. It ran mkfs.ext4 against the read-only device and looped:

  [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:
  /dev/sdc: Read-only file system while setting up superblock

• 2026-07-15 06:59 — daemon reached idle but no usable shell. After a coworkd self-update, smol-bin enumerated as /dev/sdb1, leaving /dev/sdc as the genuine session disk. coworkd got further this time — session disk formatted + mounted, RPC connected, network up, connected, waiting for commands, SDK v2.1.209 installed — but Cowork still never produced a working shell in the UI (echo test never returned). The daemon idling at "waiting for commands" did not translate into a functioning bash tool.
• 2026-07-16 — guest never reaches userspace. Current state. Host starts the VM cleanly (multiple times), but the guest console is completely silent — no coworkd output at all. This persists across a full Windows restart.

The SCSI attachment order is fixed in the host config (0 = rootfs.vhdx RW, 1 = smol-bin.vhdx ReadOnly, 2 = sessiondata.vhdx RW), yet the guest's sd* assignment varies between boots (smol-bin seen on both sdc and sdb). This non-deterministic device enumeration is the likely cause of the wrong-disk failure, and points to a fragile/racy early-boot device-probe path on the ARM64 kernel build that may also underlie the no-console-output failure.

What Should Happen?

On every boot, the guest Linux VM should reach userspace within a few seconds, coworkd should identify the writable session disk reliably (by label/by-path rather than by kernel-assigned sd* name), sdk-daemon should launch and connect to the host on hvsock 51234, and a simple echo test bash call should return test — the same way it does on Windows x64.

Error Messages/Logs

**Host (`cowork-service.log`) — healthy start, but no sdk-daemon connection ever follows (2026-07-16):**

[VM] Boot mode: UEFI BootThis+VmbFs (ARM64)
[HCS] HcsCreateComputeSystem returned: hr=0x0
[HCS] HcsStartComputeSystem returned: hr=0x0
[RPC] Server started, waiting for sdk-daemon connection on port 51234
[VM] VM started successfully
[Console] Connected to daemon console pipe: \\.\pipe\cowork-daemon-console-cowork-vm-ecb60072
--- (no sdk-daemon connection; ~60s later) ---
[VM] Graceful shutdown failed, forcing termination: HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032

 
**Guest (`coworkd/user-*.log`) — last line is the previous day's successful boot; nothing written for any 2026-07-16 VM start:**

2026/07/15 07:02:12 [coworkd] connected, waiting for commands
2026/07/15 08:11:02 [coworkd] installed SDK binary v2.1.209 to /usr/local/bin/claude
--- (no further lines, despite multiple VM starts on 2026-07-16) ---

 
**Guest (`coworkd/user-*.log`) — wrong-disk loop (2026-07-13/14):**

[hyperv]  found session disk at /dev/sdc
[coworkd] formatting session disk /dev/sdc with ext4
[coworkd] could not mount session disk: ... /dev/sdc: Read-only file system while setting up superblock
[updater] found smol-bin device: /dev/sdc1      <-- read-only smol-bin also on sdc

 
**Guest (`coworkd/user-*.log`) — 2026-07-15, daemon reached idle (still no usable shell):**

[updater] found smol-bin device: /dev/sdb1      <-- smol-bin on sdb this time
[hyperv]  found session disk at /dev/sdc
[coworkd] session disk formatted successfully
[coworkd] session disk mounted successfully at /sessions
[rpc] connected successfully
[coworkd] connected, waiting for commands

Steps to Reproduce

1. Use a Windows 11 Pro ARM64 device with the ARM64 Claude Desktop build.
2. Open Cowork and ask Claude to run any shell command (e.g. "run echo test").
3. Observe the sandbox never becomes ready; the call returns "VM connection timeout after 60 seconds."
4. Inspect C:\ProgramData\Claude\Logs\cowork-service.log: HCS create/start both hr=0x0, VM started successfully, console pipe connected, but no sdk-daemon connection on port 51234, followed by forced termination.
5. Inspect C:\ProgramData\Claude\Logs\coworkd\user-*.log: on a failing boot the guest writes nothing (last entry predates the current VM start). On the wrong-disk failures, the guest instead loops on formatting session disk /dev/sdc → Read-only file system.

workd/user-*.log` available and attached.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Bundled with Claude Desktop 1.21459.3.0 (arm64) — package Claude_1.21459.3.0_arm64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• The Windows virtualization platform is healthy. wsl -d Ubuntu -e echo ok returns ok, Get-Service vmcompute is Running, and WSL2 (same HCS/Hyper-V layer) works. The failure is specific to the Cowork guest VM, not the host platform.
• A full Windows restart does not resolve it. The guest still produces no console output after a clean reboot.
• Host VM config on every attempt: Boot mode UEFI BootThis+VmbFs (ARM64), 4096 MB RAM, 2 CPUs, virtual network 172.16.10.0/24.
• Guest sd* device enumeration is non-deterministic across boots even though the host SCSI attachment order is fixed (smol-bin observed on both /dev/sdc and /dev/sdb). Suggests a racy early-boot device-probe path on the ARM64 kernel build.
• Suggested fixes: (1) make coworkd select the session disk by stable label/by-path rather than by sd* name (addresses the wrong-disk failure); (2) investigate why the ARM64 guest never reaches userspace / never emits console output on other boots, and increase or make adaptive the ~60s host-side connection timeout.
• User-reported timeline context (not a confirmed cause): two days before the current failures, the "Windows Subsystem for Linux" optional feature was re-enabled via optionalfeatures.exe (it was already installed) followed by a reboot. This is offered only as context — the wrong-disk enumeration failures predate that action (2026-07-13), and WSL functions normally after a subsequent reboot, so it does not appear to be the root cause.
• Full cowork-service.log and coworkd/user-*.log available and attached.

cowork-service.log

user-S-1-5-21-3763923170-1919100216-3048094212-1001.log