[BUG] Cowork: "VM service not running" — CoworkVMService exits with code 1066 on clean Win11 Pro 25H2, all dependencies verified functional

Status Fixed / completed
Maintainer reply None cached
Activity 6 comments · opened Mar 20, 2026 · closed Mar 28, 2026

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?

CoworkVMService starts briefly (2–5 seconds) then terminates with service-specific exit code 1066 ("Incorrect function"). Every external dependency — Hyper-V, HCS API, VM creation, networking — has been independently verified functional. The failure is inside cowork-svc.exe itself, which logs nothing diagnostic before exiting.

This is not a DCOM permission issue (ALL APPLICATION PACKAGES already has AccessMask 11), not a missing feature issue (full Hyper-V stack enabled), and not a stale state issue (full wipe + reinstall reproduces identically).

Environment

| Component | Value |
|---|---|
| Claude Desktop | v1.1.7714.0 (MSIX) |
| Windows | 11 Pro 25H2, Build 26200 |
| CPU | (Intel, VT-x enabled) |
| Hyper-V | Full stack enabled (all 6 features) |
| vmms service | Running, Automatic |
| vmcompute service | Running, Manual |
| WSL2 | Functional (Ubuntu, Version 2) |
| Default Switch | Up, 172.27.64.1/20 |
| VM bundle | Fully downloaded, checksums validated |

Enabled Hyper-V Features (all confirmed Enabled)

  • Microsoft-Hyper-V
  • Microsoft-Hyper-V-All
  • Microsoft-Hyper-V-Tools-All
  • Microsoft-Hyper-V-Management-PowerShell
  • Microsoft-Hyper-V-Hypervisor
  • Microsoft-Hyper-V-Services
  • VirtualMachinePlatform
  • HypervisorPlatform

What Should Happen?

Expected Behaviour

CoworkVMService should start, create a Hyper-V VM using the downloaded bundle, and provide a functional workspace.

Actual Behaviour

Service starts, runs for 2–5 seconds, then exits with code 1066. No VM is ever created. No diagnostic information is logged by the service binary.

Error Messages/Logs

### Service Control Manager (System Event Log, ID 7024)
 

The Claude service terminated with the following service-specific error:
Incorrect function.

 
Occurs on every attempt. Timestamps span March 17–20, 2026 — dozens of occurrences.
 
### cowork_vm_node.log (complete pattern — never progresses beyond this)
 

[info] [VM] Loading vmClient (TypeScript) module...
[info] [VM] Module loaded successfully

 
No further entries. No error, no VM creation attempt, no network status.
 
### main.log
 

[error] Sentry caught: {
  eventId: '...',
  type: 'Error',
  value: 'VM service not running. The service failed to start.',
  stack: undefined
}

 
Repeats every ~60 seconds. No stack trace.
 
### DCOM Event 10016 (present but likely unrelated)
 

CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
APPID {15C20B67-12E7-4BB6-92BB-7AFF07997402}

 
Investigation shows ALL APPLICATION PACKAGES (S-1-15-2-1) already has AccessMask 11 (Local Launch + Local Activation) on this APPID. The DCOM errors in the event log are also triggered by `MicrosoftWindows.Client.WebExperience` (Widgets), not exclusively by Claude.
 
### CoworkVMService Details
 

Name     : CoworkVMService
State    : Stopped
ExitCode : 1066
PathName : "C:\Program Files\WindowsApps\Claude_1.1.7714.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
StartName: LocalSystem

 
### VM Bundle (intact, checksums validated)
 

initrd            175,549,736 bytes
initrd.zst        171,552,961 bytes
rootfs.vhdx     9,252,634,624 bytes
rootfs.vhdx.zst 2,326,875,206 bytes
vmlinuz            14,965,128 bytes
vmlinuz.zst        14,710,568 bytes

 
`smol-bin.x64.vhdx` (37,748,736 bytes) present in app resources directory.
 
### HCS API Verification
 

# VM creation works
New-VM -Name "test" -MemoryStartupBytes 256MB -Generation 2 -NoVHD  # succeeds
# WSL2 works (same HCS infrastructure)
wsl -d Ubuntu -e echo "works"  # succeeds
# HCS compute systems accessible
Get-ComputeProcess  # returns results
# hcsdiag functional
hcsdiag list  # returns results

 
### HCS DLLs Present
 

computecore.dll    — 1,009,056 bytes, ver 10.0.26100.7920
computenetwork.dll — 131,072 bytes,   ver 10.0.26100.1

Steps to Reproduce

  1. Clean install Windows 11 Pro 25H2 (Build 26200)
  2. Enable full Hyper-V via Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
  3. Reboot
  4. Install Claude Desktop (latest from claude.ai/download)
  5. Open Cowork → select folder
  6. Observe: "Failed to start Claude's workspace — VM service not running"

Also reproduced after:

  • Full uninstall + reinstall of Claude Desktop
  • Complete deletion of %APPDATA%\Claude\vm_bundles (forces re-download)
  • Removal of stale HCS compute systems via Stop-ComputeProcess
  • Manual creation of sessiondata.vhdx via New-VHD
  • Running Claude Desktop as Administrator

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.1.7714.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

What Was Ruled Out

| Hypothesis | Test | Result |
|---|---|---|
| Missing Hyper-V features | Checked all 8 features | All Enabled |
| DCOM permission block | Inspected LaunchPermission DACL | ALL APPLICATION PACKAGES already has correct access |
| Missing sessiondata.vhdx | Created manually via New-VHD | Service still crashes |
| Stale HCS compute system | Found and removed CmService VM in SavedAsTemplate state | Service still crashes |
| Corrupt VM bundle | Full deletion + re-download | Service still crashes |
| Stale state files | Nuclear wipe of vm_bundles, claude-code-vm, all HCS processes, all Hyper-V VMs | Service still crashes |
| Insufficient privileges | Ran Claude Desktop as Administrator; started service manually from admin PowerShell | Service starts but still crashes within 5 seconds |
| Missing network infrastructure | Verified Default Switch (172.27.64.1/20) and WSL adapter both Up | Networking is fine |
| HCS API unavailable | Created and destroyed a Gen2 VM via PowerShell; ran WSL2 | HCS works perfectly |
| Application crash | Checked WER, Crashpad, Application Event Log | No crash dumps — service exits intentionally |
| yukonSilver config rejection | Searched all JSON configs for "yukon" | No remnants after reinstall |

Additional Notes

  • The service binary cannot be executed outside its MSIX sandbox (Access Denied even as admin), making external debugging impossible.
  • cowork-svc.exe appears to exit intentionally (no crash dump, no WER entry) with a service-specific error code, but logs absolutely nothing about why.
  • The cowork_vm_node.log only records the TypeScript module loading — the native service binary has no visible logging channel.
  • This persists across multiple Claude Desktop versions (at minimum 1.1.7203 through 1.1.7714).

Request

  1. Add diagnostic logging to cowork-svc.exe — the current failure mode is a black box.
  2. Surface the actual HCS/Hyper-V error (if any) from inside the service binary to cowork_vm_node.log.
  3. Clarify whether exit code 1066 maps to a specific internal failure condition.

Related Issues

  • #30179 — DCOM 10016 blocks CoworkVMService (Win11 Home→Pro upgrade)
  • #27801 — VM service not running, persists after reboot
  • #25206 — VM starts then crashes within 5 minutes (Win11 Pro, Hyper-V)
  • #27010 — VM service not running on Windows 10 Pro
  • #24918 — Cannot connect to Claude API from workspace (Win11 Home)
  • #25136 — yukonSilver marked as unsupported + CoworkVMService access denied

View original on GitHub ↗

6 Comments

mohsinmshabbir · 6 months ago

Workaround that resolved this for me — Windows 11 Pro 25H2, Claude Desktop v1.1.8629

After extensive log analysis, the issue in my case was a stale .auto_reinstall_attempted flag file that caused the app to skip the full configure RPC flow and fall back to isGuestConnected instead — which silently fails when no VM is running, producing the "VM service not running" error even though the service itself was healthy.

Fix:

# 1. Stop everything
Stop-Service CoworkVMService -Force
Get-Process | Where-Object {$_.Name -like "*cowork*" -or $_.Name -like "*claude*"} | Stop-Process -Force -ErrorAction SilentlyContinue
Start-Sleep -Seconds 3

# 2. Delete the flag that blocks recovery
Remove-Item "$env:APPDATA\Claude\vm_bundles\claudevm.bundle\.auto_reinstall_attempted" -Force

# 3. Reopen Claude Desktop and go straight to Cowork

How I diagnosed it:

Watching cowork-service.log live while clicking Cowork revealed the app was sending isGuestConnected instead of configure — meaning it thought a VM was already running. The .auto_reinstall_attempted flag (a hidden dotfile, invisible without -Force) was preventing the app from retrying the proper startup flow.

Note: This file starts with . so it won't show up in Explorer or basic Get-ChildItem — you need Get-ChildItem -Force to see it. That's likely why it's been overlooked.

This may not be the root cause for everyone, but if standard steps (Hyper-V check, reinstall workspace, manual service start) haven't worked, this is worth trying.

KronLemonade · 6 months ago

Spent a few hours doing deep diagnostics on this and wanted to share what I found in case it helps narrow down the fix.

Environment: i7-9900k, Windows 11 Pro 25H2 Build 26200, Claude Desktop v1.1.8629, AppData on C:, Claude MSIX installed to F:\WindowsApps

Root cause: The failure is an EXDEV: cross-device link not permitted error on the final rename() call after the download completes. The app downloads rootfs.vhdx to a temp directory, validates the checksum, then tries to atomically rename it to the destination — but the two paths are on different filesystem volumes from the OS perspective due to MSIX virtualization.

The exact paths from the log:

src:  C:\Users\<username>\AppData\Local\Temp\wvm-xxxxx\rootfs.vhdx
dest: C:\Users\<username>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx

The destination resolves through the MSIX filesystem virtualization layer, which puts it on a different logical volume than the temp path regardless of what drive letter both appear to be on.

What I tried:

  • Redirected TEMP/TMP to C:\ClaudeTemp — MSIX sandbox ignores user env vars, kept using its own temp path
  • Symlinked AppData\Roaming\Claude\vm_bundles\claudevm.bundle to C:\ClaudeTemp\claudevm.bundle — sandbox bypasses the symlink entirely, writes through its virtualized Roaming layer
  • Symlinked the entire AppData\Roaming\Claude to C:\ClaudeTemp\AppData — same result
  • Redirected TEMP to inside the MSIX sandbox path (LocalCache\Roaming\Claude\wvm-temp) — TEMP redirect worked and the sandbox picked it up, but destination still resolves through a different virtualized volume

None of these work because the MSIX container virtualizes AppData\Roaming writes to its own volume, and no amount of external path manipulation can bridge that gap.

The fix: The app needs to handle cross-device rename gracefully — catch EXDEV and fall back to a copy-then-delete instead of an atomic rename. This is a one-liner in Node.js and would resolve the issue entirely for MSIX installs where the WindowsApps volume differs from the system drive.

flyboy85749 · 6 months ago

Having the same issue

Ghostw1re · 6 months ago

Issue solved with app update 2.1.85

homershie · 6 months ago

Same issue here. Adding my environment and findings — notably a DCOM 10016 fix that resolved the permission error but did NOT fix the 1066 crash.

Environment

| Component | Value |
|---|---|
| OS | Windows 11 Pro 25H2 (Build 26200) |
| Claude Desktop | v1.1.9493.0 (MSIX) |
| CPU | Intel, VT-x enabled |
| Hyper-V | Full stack enabled (vmms: Running, vmcompute: Running) |
| Docker Desktop | Installed (tested with it stopped) |
| VPN | Installed (tested with it disconnected) |
| CoworkVMService ExitCode | 1066 |
| VM bundle | Fully downloaded, all files present |

DCOM 10016 — Fixed, but 1066 persists

Before troubleshooting, Event Log showed DCOM 10016 errors with the same CLSID/APPID:

CLSID: {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
APPID: {15C20B67-12E7-4BB6-92BB-7AFF07997402} (PerAppRuntimeBroker)

The MSIX app container lacked Local Activation permission. Fix applied:

  1. Used PsExec (PsExec64.exe -i -s regedit.exe) to open regedit as SYSTEM
  2. Took ownership of HKLM\SOFTWARE\Classes\AppID\{15C20B67-12E7-4BB6-92BB-7AFF07997402} (was TrustedInstaller)
  3. Granted Administrators full control
  4. Added ALL APPLICATION PACKAGES (S-1-15-2-1) to LaunchPermission with Local Launch + Local Activation (AccessMask 3) via PowerShell script

Result: DCOM 10016 errors stopped completely, but CoworkVMService still exits with code 1066. The service crashes at the same point described in this issue — after "Configuring Windows VM service..." with no further diagnostic output.

What was tried (all failed)

| Action | Result |
|---|---|
| Clear cache and restart | 1066 |
| Delete vm_bundles, force re-download | 1066 |
| Full uninstall + reinstall Claude Desktop | 1066 |
| Stop Docker Desktop + disconnect VPN before launch | 1066 |
| Start-Service CoworkVMService manually (admin PS) | 1066 |
| Fix DCOM 10016 LaunchPermission | 10016 gone, still 1066 |
| Restart-Service vmcompute before starting | 1066 |

cowork_vm_node.log pattern (identical to OP)

[info] [VM:steps] load_swift_api completed (0ms)
[info] [Callbacks] VM event callbacks initialized
[info] [VM:start] smol-bin.x64.vhdx copied successfully
[info] [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: VM service not running. The service failed to start.

No further entries from cowork-svc.exe. Confirming this is the same black box described in the OP.

Additional note

My system previously had the default Windows Apps install path changed to D:\ drive. Claude Desktop's MSIX package installs files to both C:\Program Files\WindowsApps\ and D:\WindowsApps\. The service PathName points to C:\, while app.asar stack traces reference D:\. Unclear if this C/D split contributes to the 1066 failure, but worth investigating.

+1 on the OP's request for diagnostic logging in cowork-svc.exe.

github-actions[bot] · 6 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.