Cowork VM service not running on Windows 10 Pro (version 22H2 (OS Build 19045.6937))
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?
Environment
| Property | Value |
|----------|-------|
| OS | Windows 10 Pro |
| Claude Desktop version | 1.1.3647 |
| Subscription | Pro |
| Hyper-V | Enabled (confirmed via Get-WindowsOptionalFeature) |
| Hyper-V Services | Hyper-V Virtual Machine Management: Running, Hyper-V Host Compute Service: Running |
| VPN | None |
| Architecture | x64 |
| Installation method | Standard installer, run as Administrator |
Cowork consistently fails with:
"Failed to start Claude's workspace — VM service not running. The service failed to start."
Cowork has never successfully completed initialization on this system despite multiple reinstalls, Hyper-V enabling, and manual service start attempts.
Root Cause Analysis
Three interrelated issues identified through diagnostic investigation:
Issue 1: CoworkVMService startup type set to Manual (not Automatic)
CoworkVMService is installed with StartupType: Manual, so it does not start on boot. Attempting to reconfigure via PowerShell fails:
Set-Service CoworkVMService -StartupType Automatic
Set-Service: Service 'Claude (CoworkVMService)' cannot be configured due to the following error: Access is denied.
Registry workaround attempted:
reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 2 /f
Registry write succeeded but service still fails to start after reboot.
Issue 2: WinNAT rule not created on startup
Get-NetNat returns empty after every system start. The app creates the HNS network (cowork-vm-nat) but does NOT create the corresponding WinNAT rule. Without NAT, the VM has no route to the internet and cannot reach api.anthropic.com.
Manually creating the NAT rule:
New-NetNat -Name "cowork-vm-nat" -InternalIPInterfaceAddressPrefix "172.16.0.0/24"
Returns Store: Local — does not persist across reboots.
Issue 3: vEthernet (cowork-vm-nat) adapter never persists
The virtual network adapter required for IP forwarding does not exist at startup:
Set-NetIPInterface -InterfaceAlias "vEthernet (cowork-vm-nat)" -Forwarding Enabled
Set-NetIPInterface: No MSFT_NetIPInterface objects found with property 'InterfaceAlias' equal to 'vEthernet (cowork-vm-nat)'.
The adapter appears to require the VM service to be running before it is created — creating a circular dependency: service needs adapter, adapter needs service.
What Should Happen?
Cowork should start successfully and reach api.anthropic.com on Windows 10 Pro with Hyper-V enabled and Claude Desktop installed as Administrator.
Specifically:
- CoworkVMService should be set to Automatic startup during installation
- The installer should create both the HNS network AND the corresponding WinNAT rule on startup
- IP forwarding should be enabled on vEthernet (cowork-vm-nat) automatically
- These networking rules should persist across reboots without manual PowerShell intervention
Error Messages/Logs
From %APPDATA%\Claude\logs\cowork_vm_node.log:
2026-02-19 14:04:22 [info] [VM] Loading vmClient (TypeScript) module...
2026-02-19 14:04:22 [info] [VM] Module loaded successfully
2026-02-19 14:04:22 [info] [warm] Fetching VM hash for version 1.1.3647
2026-02-19 14:04:22 [info] [warm] VM hash for version 1.1.3647: fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:04:22 [info] [warm] All warm files already exist for SHA fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:39:32 [info] [Bundle:status] rootfs.vhdx version mismatch: have=0ae58222a1f34cf74c74ce47cc717a82a4eb0f25, want=fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:39:32 [info] [VM] Loading vmClient (TypeScript) module...
2026-02-19 14:39:32 [info] [VM] Module loaded successfully
2026-02-19 14:39:32 [info] [Bundle:status] rootfs.vhdx version mismatch: have=0ae58222a1f34cf74c74ce47cc717a82a4eb0f25, want=fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:39:32 [info] [Bundle:status] rootfs.vhdx version mismatch: have=0ae58222a1f34cf74c74ce47cc717a82a4eb0f25, want=fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:39:32 [info] [downloadVM] Deleting old rootfs.vhdx and cache to free disk space
2026-02-19 14:39:32 [info] [warm] Promoting warm file rootfs.vhdx from C:\Users\guinw\AppData\Roaming\Claude\vm_bundles\warm\fb30784dadb34104626c8cf6d8f90dd47cd393cc\rootfs.vhdx.zst
2026-02-19 14:42:00 [info] [warm] rootfs.vhdx checksum validated
2026-02-19 14:42:00 [info] [warm] rootfs.vhdx promotion completed in 147886ms
2026-02-19 14:42:00 [info] [downloadVM] Promoted rootfs.vhdx from warm bundle
2026-02-19 14:42:00 [info] [Bundle:status] vmlinuz version mismatch: have=0ae58222a1f34cf74c74ce47cc717a82a4eb0f25, want=fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:42:00 [info] [downloadVM] Deleting old vmlinuz and cache to free disk space
2026-02-19 14:42:00 [info] [warm] Promoting warm file vmlinuz from C:\Users\guinw\AppData\Roaming\Claude\vm_bundles\warm\fb30784dadb34104626c8cf6d8f90dd47cd393cc\vmlinuz.zst
2026-02-19 14:42:01 [info] [warm] vmlinuz checksum validated
2026-02-19 14:42:01 [info] [warm] vmlinuz promotion completed in 318ms
2026-02-19 14:42:01 [info] [downloadVM] Promoted vmlinuz from warm bundle
2026-02-19 14:42:00 [info] [Bundle:status] initrd version mismatch: have=0ae58222a1f34cf74c74ce47cc717a82a4eb0f25, want=fb30784dadb34104626c8cf6d8f90dd47cd393cc
2026-02-19 14:42:01 [info] [downloadVM] Deleting old initrd and cache to free disk space
2026-02-19 14:42:01 [info] [warm] Promoting warm file initrd from C:\Users\guinw\AppData\Roaming\Claude\vm_bundles\warm\fb30784dadb34104626c8cf6d8f90dd47cd393cc\initrd.zst
2026-02-19 14:42:04 [info] [warm] initrd checksum validated
2026-02-19 14:42:04 [info] [warm] initrd promotion completed in 3720ms
2026-02-19 14:42:04 [info] [downloadVM] Promoted initrd from warm bundle
2026-02-19 14:42:04 [info] All files ready in C:\Users\guinw\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-02-19 15:01:00 [info] [VM] Loading vmClient (TypeScript) module...
2026-02-19 15:01:00 [info] [VM] Module loaded successfully
Note: Log terminates after "Module loaded successfully" with no network status entries.
Expected entries (VM Network status: CONNECTED, API reachability: REACHABLE) never appear.Steps to Reproduce
- Install Claude Desktop on Windows 10 Pro using standard installer run as Administrator
- Enable Hyper-V via optionalfeatures
- Restart computer
- Open Claude Desktop
- Click Cowork tab
- Observe: "Failed to start Claude's workspace — VM service not running"
Suggested Fix - The installer should:
- Set CoworkVMService StartupType to Automatic (not Manual) with appropriate permissions
- Create the WinNAT rule (New-NetNat) as part of VM initialization, not just the HNS network
- Enable IP forwarding on vEthernet (cowork-vm-nat) during VM startup sequence
- Ensure these networking components are recreated persistently on each boot, not just on first run
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
n/a
Claude Code Version
1.1.3647
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
What Was Tried
- Full uninstall and reinstall as Administrator
- Enabled Hyper-V (Virtual Machine Management and Host Compute services confirmed Running)
- Manually started CoworkVMService via Start-Service CoworkVMService — works temporarily
- Attempted Set-Service CoworkVMService -StartupType Automatic — Access Denied
- Registry edit to set StartupType to Automatic (0x2) — wrote successfully, did not persist behavior
- Manually created WinNAT rule via New-NetNat — created successfully but Store: Local, does not persist
- Attempted IP forwarding on vEthernet adapter — adapter does not exist at startup
- No VPN present
- Confirmed not Windows ARM64
Related Issues
#25155 — Windows 10 Pro Hyper-V NAT routing (identical root cause)
#24945 — Cowork VM boots but API unreachable on Windows
#24918 — Windows 11 Home Hyper-V/WSL2 issue
#25136 — Windows 11 Pro yukonSilver unsupported + CoworkVMService access denied
13 Comments
Windows version 22H2 (OS Build 19045.6937)
Are there any logs in Event Viewer for the CoworkVM Service? That'll be where any issues with the service end up if it's crashing (which is what it sounds like)
Environment: Windows 10 Pro Build 19045 – Additional Diagnostic Report
System Configuration:
Virtualization Status – Complete Verification:
Extensive Troubleshooting Completed:
Persistent Error in Logs:
Analysis:
The
status=unsupportederror originates from a server-side feature flag (GrowthBook) that is explicitly rejectingyukonSilverVM provisioning on win32/x64 platform, despite all hardware requirements and OS specifications meeting documented compatibility standards.No local configuration, BIOS setting, service restart, or driver installation can override a server-side platform support decision. This is identical to the pattern reported in issues #25136, #25155, #25205, #25692, and others – all with identical hardware and Hyper-V configurations.
Key Finding:
The system is not rejecting Cowork; Cowork is rejecting the system based on a server-side decision, not a hardware/OS compatibility issue.
Request:
Please investigate why Windows 10 Pro (build 19045) with fully functional Hyper-V is marked as unsupported when all documented requirements are met.
Found the Event Viewer logs. The error is:
CoworkVMService is failing at network creation — HcnCreateNetwork cannot reach the RPC server.
This explains why the cowork_vm_node.log always terminates after 'Module loaded successfully' with no network status entries following. The VM never gets past virtual network initialization
Confirming my Event Viewer logs show HcnCreateNetwork failing with RPC server unavailable (hr=0x800706ba) — so on my system there is both a local HCN/RPC failure and likely the server-side yukonSilver rejection you identified. Windows 10 Pro 22H2 Build 19045.6937, Intel i7. Neither issue is resolvable through local configuration.
@buzzfair Ah that's a helpful error, appears to be a common issue with certain VPN software like PIA. Are you running any VPNs?
Nope, I'm not running any VPNs.
Same on Windows 11. This workaround solved a problem for me. It's not ideal, but better than doing it manually:
$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-WindowStyle Hidden -Command
"if ((Get-Service CoworkVMService).Status -ne 'Running') { Start-Service CoworkVMService }""$trigger = New-ScheduledTaskTrigger -RepetitionInterval (New-TimeSpan -Minutes 1) -Once -At (Get-Date)
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
Register-ScheduledTask -TaskName "CoworkVMServiceMonitor" -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest -User "SYSTEM"
I couldn't do it via services.msc even in the Admin mode.
Thanks for the heads up on the watchdog. Unfortunately the scheduled task workaround didn't resolve the issue on Windows 10 Pro ~ due to the underlying HCN/RPC failure, and that the service crashes on every restart attempt before network initialization completes.
This is useful data for Anthropic and for other Windows 10 users who try the same workaround.
In some cases, restarting the Claude service in services.msc helps. Perhaps this would work on Windows 10 Pro, too?
<img width="2014" height="1482" alt="Image" src="https://github.com/user-attachments/assets/0d3c4f95-3c48-439b-ad97-282682dc7ac5" />
Unbelievably this worked. Can't thank you enough for your simple fix. It did the trick!
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.