[BUG] CoworkVMService fails to start — "signature verification initialization failed" — Root cause: Windows "Where new apps save to" setting pointing to non-C: drive

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?

✅ SOLUTION FOUND

Root cause: Windows "Where new content is saved" setting (Settings → System → Storage → Advanced storage settings → Where new content is saved) was set to a secondary drive (E:). This causes MSIX app package data to be stored via symlinks under %LOCALAPPDATA%\Packages\ that point to E:\WpSystem\.... The Cowork VM service runs as LocalSystem and cannot resolve those symlinks, so it fails with "failed to get service executable path" before it can even start.

Fix:

1. Go to Settings → System → Storage → Advanced storage settings → Where new content is saved
2. Change "New apps will save to" back to C:
3. Uninstall Claude: Get-AppxPackage *claude* | Remove-AppxPackage
4. Delete leftover package directory: Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force
5. Reinstall Claude from https://claude.ai/download
6. Restart computer
7. Open Claude → Cowork tab → it works!

---

What's Wrong?

CoworkVMService consistently fails to start on Windows 11 Pro. After 12+ hours of extensive debugging, we identified the root cause and multiple cascading bugs.

Primary Error: signature verification initialization failed

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

The service loads HCS/HCN DLLs successfully but crashes during signature verification because it cannot resolve its own executable path. This happens because the MSIX package data is stored via symlinks on a non-system drive that LocalSystem cannot access.

Secondary Bug: EXDEV cross-device link not permitted

[error] [download] VM download failed: EXDEV: cross-device link not permitted, rename 'C:\Users\<user>\AppData\Local\Temp\wvm-XXXXX\rootfs.vhdx' -> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

The VM bundle download uses fs.rename() which fails across MSIX sandbox boundaries. Fix suggestion: use fs.copyFile() + fs.unlink() instead of fs.rename().

Additional issues encountered

1. DCOM 10016 Permission Error — CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54} had corrupted permissions. Fixed manually via PsExec as SYSTEM.
2. EFS "Protected Application" encryption — Files inside the MSIX package show as EFS encrypted. Hyper-V HCS cannot open these encrypted VHDXs.
3. CoworkVMService not registered in StateRepository — The service is declared in AppxManifest.xml but does not appear in the StateRepository cache.
4. Interactive mode workaround works — Running cowork-svc.exe directly (not as a Windows service) bypasses the signature verification crash.

Environment

• OS: Windows 11 Pro 24H2 (Build 26100)
• Claude Desktop: v1.1.6679.0 → v1.1.7053.0
• Critical setting: "Where new apps save to" was set to E: drive

Steps Tried (summary)

| # | Action | Result |
|---|--------|--------|
| 1–19 | Multiple reinstalls, WSL/Hyper-V fixes, DISM, EFS, DCOM, VMware removal, etc. | No fix |
| 20 | Change "Where new apps save to" from E: to C: | ✅ FIXED EVERYTHING |

Suggested Fixes for Anthropic

1. EXDEV bug: Use fs.copyFile() + fs.unlink() instead of fs.rename() for cross-device moves
2. Storage location: Document that "Where new apps save to" must be C:, or fix the service to handle MSIX symlinks on non-system drives
3. Signature verification: Handle path resolution failure gracefully in service mode (as done in interactive mode)
4. EFS on VHDXs: Ensure VHDX files are not encrypted with "Protected Application" EFS
5. MaxVersionTested: Update from 10.0.22621.0 to 10.0.26100.0 for Windows 11 24H2/25H2 support
6. Error messaging: Add a check for non-C: app storage location and display a helpful error message

Related Issues

#30584, #25911, #25476, #30179, #29941, #27801, #28231, #25505

Claude Model

Claude Opus 4.6

Platform

Windows 11 Pro 24H2 → 25H2

Claude Code Version

1.1.7053.0

What Should Happen?

The CoworkVMService should either:

1. Handle MSIX symlinks on non-system drives correctly, OR
2. Display a clear error message telling the user to change the app storage location to C:

Additionally:

• The VM bundle download should use fs.copyFile() + fs.unlink() instead of fs.rename() to avoid EXDEV errors across device boundaries
• VHDX files should not be encrypted with "Protected Application" EFS
• The service should handle path resolution failures gracefully (as already done in interactive mode)

Error Messages/Logs

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

Secondary error (VM download):
[error] [download] VM download failed: EXDEV: cross-device link not permitted, rename 'C:\Users\<user>\AppData\Local\Temp\wvm-XXXXX\rootfs.vhdx' -> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

EFS error (when trying to decrypt VHDXs):
O arquivo especificado está criptografado e o usuário não pode descriptografá-lo. (0x80071772)

Interactive mode (working):
Running CoworkVMService in interactive/debug mode
[Server] WARNING: Could not get service executable path: The system cannot find the path specified.
[Server] WARNING: Client signature verification is DISABLED
[Server] Starting named pipe server on \\.\pipe\cowork-vm-service
[Server] Named pipe server listening

Steps to Reproduce

1. Install Claude Desktop on Windows 11 with "Where new apps save to" set to a non-C: drive (e.g., E:)
2. Open Claude → navigate to the Cowork tab
3. Observe CoworkVMService fails to start with "signature verification initialization failed"

Root cause: MSIX package data is stored via symlinks on the non-system drive. The CoworkVMService runs as LocalSystem and cannot resolve these symlinks, causing it to fail to find its own executable path.

Fix: Change "Where new apps save to" back to C: (Settings → System → Storage → Advanced storage settings → Where new content is saved), then do a clean reinstall of Claude.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.1.7053.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_