[BUG] Cowork Windows: EXDEV cross-device rename + signature verification failure (two independent bugs)

Resolved 💬 3 comments Opened Mar 6, 2026 by AriaRoba Closed Mar 9, 2026

Environment

  • OS: Windows 11 Pro x64 Build 26200.7922 (25H2)
  • CPU: Intel Core i5-12600K
  • Claude Desktop: v1.1.5368 (MSIX install, Claude_1.1.5368.0_x64__pzs8sxrjxfjjc)
  • Plan: Pro | Hyper-V: Enabled | SignatureKind: Developer

Summary

Cowork fails to start due to two independent bugs:

  1. EXDEVfs.rename() fails across the MSIX VFS boundary when moving downloaded VM files.
  2. Service crashCoworkVMService crashes during signature verification, unable to resolve its own path within WindowsApps.

Both must be fixed for Cowork to work on MSIX-packaged installations.

---

Bug 1: EXDEV — cross-device link not permitted

Error

EXDEV: cross-device link not permitted, rename
'C:\Users\<user>\AppData\Local\Temp\wvm-XXXXXX\rootfs.vhdx' ->
'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Root cause

Claude Desktop runs inside the MSIX container. Writes to %APPDATA%\Claude\ are redirected by MSIX VFS to ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\. The download code writes rootfs.vhdx to %TEMP% (real FS), then calls fs.rename() targeting a VFS-virtualized path. The kernel sees them as different filesystems → EXDEV.

Note: If the system-level TEMP (used by LocalSystem) points to a different drive (e.g., RAMDisk), a second EXDEV occurs at service level. Restoring machine TEMP/TMP to C:\Windows\Temp fixes that, but NOT the MSIX VFS EXDEV.

Suggested fix

Implement a copy + unlink fallback when fs.rename() returns EXDEV (standard in fs-extra). Or write temp files directly into the VFS-virtualized path. Or add %APPDATA%\Claude\vm_bundles to ExcludedDirectories in the AppxManifest.

User workaround (verified working)

Remove-Item "...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles" -Recurse -Force
New-Item -ItemType Directory -Path "C:\Claude_vm_bundles\claudevm.bundle" -Force
New-Item -ItemType Junction `
  -Path "...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles" `
  -Target "C:\Claude_vm_bundles"

After this, cowork_vm_node.log reports All files ready.

---

Bug 2: CoworkVMService signature verification failure

Error (from C:\ProgramData\Claude\Logs\cowork-service.log)

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

Root cause

The service runs as LocalSystem with ImagePath inside the MSIX package (C:\Program Files\WindowsApps\...\cowork-svc.exe). It loads HCS/HCN DLLs successfully but crashes when trying to resolve its own executable path for signature verification. The file exists, SYSTEM has FullControl, Authenticode signature is valid — but path resolution fails within the WindowsApps context.

Related

Same as #29941. 100% reproducible on every Start-Service attempt.

Suggested fix

Use GetModuleFileName() or read ImagePath from registry (HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService) as fallback.

---

Reproduction

  1. Install Claude Desktop v1.1.5368 via MSIX on Windows 11 Pro x64.
  2. Enable Hyper-V. Open Claude Desktop → Cowork tab.
  3. Observe EXDEV error (Bug 1).
  4. Apply junction workaround → retry → observe "VM service not running" (Bug 2).

Logs

| Log | Path |
|-----|------|
| VM | %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\cowork_vm_node.log |
| Service | C:\ProgramData\Claude\Logs\cowork-service.log |
| Windows | Event Viewer → System → Event ID 7024 |

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗