[BUG] Failed to start Claude's workspace

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?

Preflight Checklist

• [x] I have searched existing issues and this is related to but not a duplicate of #36801, #31703, #30179
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

What's Wrong?

CoworkVMService starts but immediately exits with error code 1066. The service log shows the root cause clearly:

Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

This occurs on every startup attempt. The service cannot resolve its own executable path, which causes signature verification to fail before any VM initialization occurs.

Environment

• OS: Windows 11 Home
• Claude Desktop version: 1.1.9310.0
• Hyper-V: Not available (Home edition)
• Windows Hypervisor Platform: Enabled
• Virtual Machine Platform: Enabled
• HyperVisorPresent: True
• vmcompute: Running
• HvHost: Running
• vmms: Not present (Home edition)

Service Registration

PathName: "C:\Program Files\WindowsApps\Claude_1.1.9310.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
State: Stopped
ExitCode: 1066
StartMode: Auto

cowork-service.log (repeated on every attempt)

Starting CoworkVMService as Windows service
Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] Initializing HCS DLLs...
Warning: failed to open service for recovery config: Access is denied.
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: []
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.

System Event Log (Event 7024, repeated)

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

cowork_vm_node.log

[VM] Loading vmClient (TypeScript) module...
[VM] Module loaded successfully
[VM:start] Beginning startup, bundlePath=...\claudevm.bundle
[VM:start] Bundle version: fb30784dadb34104626c8cf6d8f90dd47cd393cc
[VM:steps] download_and_sdk_prepare completed
[VM:steps] load_swift_api completed
[VM:start] Copying smol-bin.x64.vhdx to bundle...
[VM:start] smol-bin.x64.vhdx copied successfully
[VM:start] Configuring Windows VM service...
[VM:start] Startup failed: Error: VM service not running. The service failed to start.

Note: The stack trace in the node log references D:\WindowsApps\ while the service is registered at C:\Program Files\WindowsApps\ — possible path resolution mismatch.

What I've Tried

• Full computer reboot (multiple times)
• Cleared vm_bundles and claude-code-vm directories (clean re-download)
• Enabled HypervisorPlatform and VirtualMachinePlatform via PowerShell
• Granted SYSTEM and ALL APPLICATION PACKAGES full/RX permissions on the WindowsApps Claude directory via icacls and takeown
• Verified no conflicting NAT networks (Get-NetNat returns empty, Get-HnsNetwork returns empty)

None of these resolve the issue. The error is identical every time.

Root Cause Analysis

The service binary (cowork-svc.exe) attempts to verify its own signature at startup by resolving its executable path. Because it runs as SYSTEM outside the MSIX package activation context, the Win32 path resolution fails — the MSIX virtual filesystem is not mounted for SYSTEM, so GetModuleFileName or equivalent returns a path that doesn't exist from SYSTEM's perspective.

This appears to be the same root cause as #36801 and #30179 (DCOM 10016 / MSIX container isolation).

Expected Behavior

CoworkVMService should start successfully and create the VM. Signature verification should either be skipped when running as SYSTEM, or use the registry ImagePath value as the fallback path rather than a runtime path resolution call.

Suggested Fix

In cowork-svc.exe: fall back to argv[0] or the registry ImagePath for signature verification when the primary path resolution fails, rather than aborting startup entirely.

What Should Happen?

CoworkVMService should start successfully and create the VM. Signature verification should either be skipped when running as SYSTEM, or use the registry ImagePath value as the fallback path rather than a runtime path resolution call.

Error Messages/Logs

## cowork-service.log (repeated on every attempt)


Starting CoworkVMService as Windows service
Claude VM Service starting...
Waiting for configuration from app via 'configure' method...
[HCS] Initializing HCS DLLs...
Warning: failed to open service for recovery config: Access is denied.
[HCS] vmcompute.dll loaded successfully
[HCS] computecore.dll loaded successfully
[HCS] Procs initialized, HCS ready
[HCN] Initialized HCN API from computenetwork.dll
[HCN] EnumerateNetworks result: []
Service error: signature verification initialization failed: failed to get service executable path: The system cannot find the path specified.


## System Event Log (Event 7024, repeated)


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


## cowork_vm_node.log


[VM] Loading vmClient (TypeScript) module...
[VM] Module loaded successfully
[VM:start] Beginning startup, bundlePath=...\claudevm.bundle
[VM:start] Bundle version: fb30784dadb34104626c8cf6d8f90dd47cd393cc
[VM:steps] download_and_sdk_prepare completed
[VM:steps] load_swift_api completed
[VM:start] Copying smol-bin.x64.vhdx to bundle...
[VM:start] smol-bin.x64.vhdx copied successfully
[VM:start] Configuring Windows VM service...
[VM:start] Startup failed: Error: VM service not running. The service failed to start.

Steps to Reproduce

What I've Tried

• Full computer reboot (multiple times)
• Cleared vm_bundles and claude-code-vm directories (clean re-download)
• Enabled HypervisorPlatform and VirtualMachinePlatform via PowerShell
• Granted SYSTEM and ALL APPLICATION PACKAGES full/RX permissions on the WindowsApps Claude directory via icacls and takeown
• Verified no conflicting NAT networks (Get-NetNat returns empty, Get-HnsNetwork returns empty)

None of these resolve the issue. The error is identical every time.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.1.9310 (cb30ac) 2026-03-27T17:11:42.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_