[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
- Clean install Windows 11 Pro 25H2 (Build 26200)
- Enable full Hyper-V via
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All - Reboot
- Install Claude Desktop (latest from claude.ai/download)
- Open Cowork → select folder
- 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.vhdxviaNew-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.exeappears 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.logonly 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
- Add diagnostic logging to
cowork-svc.exe— the current failure mode is a black box. - Surface the actual HCS/Hyper-V error (if any) from inside the service binary to
cowork_vm_node.log. - 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
6 Comments
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_attemptedflag file that caused the app to skip the fullconfigureRPC flow and fall back toisGuestConnectedinstead — which silently fails when no VM is running, producing the "VM service not running" error even though the service itself was healthy.Fix:
How I diagnosed it:
Watching
cowork-service.loglive while clicking Cowork revealed the app was sendingisGuestConnectedinstead ofconfigure— meaning it thought a VM was already running. The.auto_reinstall_attemptedflag (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 basicGet-ChildItem— you needGet-ChildItem -Forceto 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.
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 permittederror on the finalrename()call after the download completes. The app downloadsrootfs.vhdxto 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:
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:
TEMP/TMPtoC:\ClaudeTemp— MSIX sandbox ignores user env vars, kept using its own temp pathAppData\Roaming\Claude\vm_bundles\claudevm.bundletoC:\ClaudeTemp\claudevm.bundle— sandbox bypasses the symlink entirely, writes through its virtualized Roaming layerAppData\Roaming\ClaudetoC:\ClaudeTemp\AppData— same resultLocalCache\Roaming\Claude\wvm-temp) — TEMP redirect worked and the sandbox picked it up, but destination still resolves through a different virtualized volumeNone of these work because the MSIX container virtualizes
AppData\Roamingwrites 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
EXDEVand 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.Having the same issue
Issue solved with app update 2.1.85
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:
The MSIX app container lacked Local Activation permission. Fix applied:
PsExec64.exe -i -s regedit.exe) to open regedit as SYSTEMHKLM\SOFTWARE\Classes\AppID\{15C20B67-12E7-4BB6-92BB-7AFF07997402}(was TrustedInstaller)ALL APPLICATION PACKAGES(S-1-15-2-1) toLaunchPermissionwith Local Launch + Local Activation (AccessMask 3) via PowerShell scriptResult: 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 CoworkVMServicemanually (admin PS) | 1066 || Fix DCOM 10016 LaunchPermission | 10016 gone, still 1066 |
|
Restart-Service vmcomputebefore starting | 1066 |cowork_vm_node.log pattern (identical to OP)
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\andD:\WindowsApps\. The service PathName points to C:\, whileapp.asarstack 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.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.