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

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