[BUG]

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?

Failed to start Claude's workspace
VM service not running. The service failed to start.
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

The error is 100% consistent across all attempts — cowork-svc.exe fails at the same point every time. This
is a bug in the service itself: it's calling a Windows package API to get its own executable path, but
that API fails when running as LocalSystem (which doesn't have MSIX package identity context).

This is a bug Anthropic needs to fix — reinstalling the same version won't help since it's a code issue in
cowork-svc.exe, not a corrupted install.

Certain:

• The service fails consistently at "signature verification initialization"
• The inner error is "failed to get service executable path: The system cannot find the path specified."

(Windows error 3)

• It runs as LocalSystem
• HCS/HCN initialize fine, so virtualization is not the problem
• Service type is 528

Uncertain:

• What specific Windows API is being called to get the executable path — could be GetModuleFileName, a

package identity API, QueryServiceConfig, or something custom

• Whether 528 is actually a "packaged service" flag — I may have that wrong
• Whether LocalSystem context is actually the cause, or if it's something else entirely like:
• A Windows version compatibility issue
• An AppLocker/Defender policy blocking it
• The service's own internal path logic looking somewhere that doesn't exist
• A package registration mismatch specific to Windows Store apps

What Should Happen?

The fix needed in cowork-svc.exe:

Root cause: The service calls a Windows API (likely GetModuleFileName or a package identity API like
GetCurrentPackageFullName) to get its own executable path for signature verification. These APIs return
error 3 ("path not found") when the calling process has no MSIX package identity — which is the case when
running as a Windows service under LocalSystem.

Instead of using a package-identity-dependent API to resolve the executable path,
the service should use a package-identity-independent method:

// Instead of using GetCurrentPackageFullName or GetApplicationUserModelId
// which require package identity context, use:
// GetModuleFileName(NULL, path, size) → gets the actual .exe path directly
// or
// QueryFullProcessImageName → works regardless of package identity

Specifically, for a Windows service running as LocalSystem, the correct approach is:

• Use GetModuleFileName(NULL, ...) — returns the path of the current process's .exe directly, no package

identity needed

• Or skip signature verification entirely when running in service context (since the service was installed

by the legitimate app anyway)

For the bug report, include:

• The service is type 528 (MSIX packaged service) but runs as LocalSystem which has no package identity
• The failure is at the signature verification step, before the VM does anything
• HCS/HCN initialize successfully, so the virtualization stack is not the issue
• The fix is to use GetModuleFileName(NULL, ...) or a non-package-identity path resolution method

Error Messages/Logs

Steps to Reproduce

1. Install Claude desktop app (Windows Store, v1.1.7714.0) on Windows with WSL2

▎ 2. Launch the app
▎ 3. Workspace fails to start with "VM service not running. The service failed to start."
▎ 4. CoworkVMService is registered but fails immediately on every start attempt with the error above

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.1.7714 (3bd6f6) 2026-03-19T14:50:53.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_