claude-code - 💡(How to fix) Fix [BUG] Claude Desktop (Cowork): VM starts successfully but sdk-daemon never boots inside VM on Windows 11 Home — coworkd has no log activity since 2026-05-16 [1 comments, 2 participants]

Preflight Checklist

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

What's Wrong?

Note: This is a Claude Desktop (Cowork) bug, not Claude Code CLI. Anthropic's in-app Fin support directed me to file here as there appears to be no dedicated Claude Desktop issue tracker. Please redirect if there's a more appropriate place.

The Cowork sandbox VM fails to execute any shell/bash command. The host-side CoworkVMService starts the VM successfully (confirmed in cowork-service.log), but the in-VM sdk-daemon (which handles shell requests) never boots. Every sandbox call returns:

Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).

This has reproduced 100% across multiple Claude Desktop reinstalls, a manual delete of the entire VM bundle, both Hyper-V Windows features enabled, and several reboots. It's been broken since I first installed Cowork.

Key indicator: C:\ProgramData\Claude\Logs\coworkd\ has had no new log entries since 2026-05-16, meaning the in-VM daemon hasn't successfully booted in three days, even though the host-side log shows daily VM-start events.

What Should Happen?

The VM's sdk-daemon process should boot inside the VM after the VM kernel starts, and connect back to the host RPC server on vsock port 51234. Shell commands sent through Cowork should then execute inside the VM and return output.

I have empirical confirmation this CAN work — the May 16 coworkd log shows a fully healthy boot sequence ending in "[coworkd] connected, waiting for commands". The daemon just hasn't booted since then.

Error Messages/Logs

== Client-facing error ==
Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds).

== Host-side cowork-service.log (excerpt) ==
2026/05/19 09:36:12.041388 [HCS] Calling HcsCreateComputeSystem with id=cowork-vm-29cdef95
2026/05/19 09:36:12.079702 [HCS] HcsCreateComputeSystem returned: hr=0x0
2026/05/19 09:36:12.258687 [HVSock] Listening on port 51234
2026/05/19 09:36:12.258687 [RPC] Server started, waiting for sdk-daemon connection on port 51234
2026/05/19 09:36:12.649637 [VM] VM started successfully
[no further sdk-daemon connection event ever arrives]

== Earlier same-day — graceful shutdown rejected, force-killed ==
2026/05/19 09:24:05.667779 [VM] Graceful shutdown failed, forcing termination:
  HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032

(0x80070032 = ERROR_NOT_SUPPORTED. Graceful HCS shutdown is rejected; VM must be force-killed. I suspect this is leaving the VM bundle in a state coworkd can't boot from cleanly.)

== In-VM coworkd log directory — nothing since 2026-05-16 ==
C:\ProgramData\Claude\Logs\coworkd\ has no new files since 2026-05-16 19:05 UTC.
The final entries in that last file show a healthy boot:
  [rpc] connected successfully
  [rpc] ready event sent
  [coworkd] installed SDK binary v2.1.142 to /usr/local/bin/claude
  [coworkd] connected, waiting for commands

== VM bundle directory — auto_reinstall_attempted marker, stale source files ==
auto_reinstall_attempted   5/16/2026 12:52 PM   0 bytes
rootfs.vhdx                5/19/2026 9:14 AM    ~10 GB
rootfs.vhdx.zst            5/16/2026 12:51 PM   ~2.2 GB
smol-bin.vhdx              5/19/2026 10:09 AM   ~38 MB
sessiondata.vhdx           5/19/2026 10:08 AM   ~4 MB
(initrd / vmlinuz files all dated 5/16/2026)

The `auto_reinstall_attempted` marker suggests Claude Desktop detected this and tried to recover on May 16, but the recovery didn't succeed. Manual reinstall of Claude Desktop and manual deletion of the entire claudevm.bundle folder both failed to refresh the .zst source files. The resulting fresh-downloaded bundle still exhibits the same behavior.

Steps to Reproduce

1. Install Claude Desktop on Windows 11 Home (downloaded from claude.com/download)
2. Sign in and ensure Cowork is enabled
3. Open any conversation and attempt any shell/bash command (e.g., type "run echo hello in the sandbox")
4. After ~60 seconds the call returns: "Workspace unavailable. The isolated Linux environment failed to start (VM connection timeout after 60 seconds)."

This reproduces 100% of the time on my machine. It has reproduced on a fresh install, after a Windows reboot, after enabling both Virtual Machine Platform and Hypervisor Platform Windows features, after reinstalling Claude Desktop, and after manually deleting the entire C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\ folder to force a clean bundle download.

In every case: the host-side cowork-service.log shows the VM is created and started successfully, and the host RPC server begins listening on vsock port 51234. The in-VM sdk-daemon (coworkd) never connects back. The most recent activity in C:\ProgramData\Claude\Logs\coworkd\ is from 2026-05-16 — three days before this report. The auto_reinstall_attempted marker file inside the VM bundle suggests Claude Desktop self-detected and attempted recovery on 5/16 but didn't succeed.

I do not have a minimal CLI-style code example because this is a Claude Desktop / Cowork issue, not

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

N/A — this is a Claude Desktop / Cowork bug, not Claude Code CLI.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Re: filing against claude-code repo — Anthropic's in-app Fin support directed me here after declining to escalate to human Product Support. To my knowledge there is no public bug tracker for Claude Desktop. Please redirect if a better venue exists.

Re: Terminal/Shell selection above — this bug is not terminal-dependent. The bug is in Claude Desktop's Cowork VM (Hyper-V VM lifecycle), not in any shell. I selected the closest available option.

Diagnostic timeline:

1. Confirmed CPU virtualization enabled in firmware (Task Manager + systeminfo)
2. VirtualMachinePlatform Windows feature: enabled
3. HypervisorPlatform Windows feature was disabled; enabling it changed the error from "Request timed out: configure" to the current "VM connection timeout after 60 seconds" — partial progress but not a fix
4. vmcompute and hvhost services Running. vmms doesn't exist on Windows 11 Home (expected)
5. No conflicting hypervisor software running (no Docker Desktop, VirtualBox, VMware)
6. CoworkVMService is registered StartType Automatic. Runs but stops on its own and does not auto-restart
7. Manual Start-Service after each crash — VM starts per host log but sdk-daemon never connects
8. Deleted sessiondata.vhdx — no effect
9. Reinstalled Claude Desktop over the top — did not refresh the .zst source files in claudevm.bundle
10. Manually deleted the entire claudevm.bundle folder to force fresh download — files re-downloaded, behavior unchanged

Bundle directory state:

Name LastWriteTime Length auto_reinstall_attempted 5/16/2026 12:52 PM 0 bytes rootfs.vhdx 5/19/2026 9:14 AM ~10 GB rootfs.vhdx.zst 5/16/2026 12:51 PM ~2.2 GB smol-bin.vhdx 5/19/2026 10:09 AM ~38 MB sessiondata.vhdx 5/19/2026 10:08 AM ~4 MB

The auto_reinstall_attempted marker from 5/16 suggests Claude Desktop already self-detected this and tried to recover, but didn't succeed. Manual reinstall and manual bundle deletion don't refresh the .zst archives.

Happy to provide full unredacted logs, additional diagnostic output, or test results against a debug build. Thank you.