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

Status Closed — not planned
Maintainer reply None cached
Activity 3 comments · opened Mar 6, 2026 · 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. EXDEV — fs.rename() fails across the MSIX VFS boundary when moving downloaded VM files.
  2. Service crash — CoworkVMService 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 ↗