[BUG] Cowork VM cannot start on Windows when the default Appx volume is a non-system drive (package data forced EFS)

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?

The Cowork Windows VM cannot start. The UI shows "Workspace unavailable", "still downloading", or "failed to start". Reinstalling the app does not help, and the logs only ever show UNKNOWN.

Root cause (verified): this machine's default Appx install volume is a non-system drive (D:\WindowsApps). Claude's package data is therefore redirected to D:\WpSystem\<SID>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\..., and Windows' APPX/Package-Identity subsystem forces EFS encryption ("Application Protected") on package data that lives on a non-system volume.

The VM bundle vm_bundles\claudevm.bundle sits inside that tree, which creates a two-way deadlock:

| State of the bundle folder | Result |
|---|---|
| EFS-encrypted (what Windows expects) | Hyper-V cannot create the session disk -> CreateVirtualDisk failed: 0x1772 (ERROR_FILE_ENCRYPTED) |
| encryption flag cleared (cipher /d /s) | APPX layer rejects access -> CreateVirtualDisk failed: 0x199 (ERROR_APPX_FILE_NOT_ENCRYPTED) |

Neither Win32 error is mapped by libuv, so Node surfaces both as code:'UNKNOWN', errno:-4094 - which is why every workaround appears to "change nothing".

Evidence

1. fs.copyFileSync() of the 8,195,670,016-byte rootfs.vhdx.tmp fails with UNKNOWN / errno -4094 / syscall copyfile - deterministically, not intermittently.
2. The hidden Win32 codes, recovered via .NET File.Copy: 0x80070199 ("The APPX file can not be accessed because it is not encrypted as expected") for a plaintext file, 0x80071770 ("The specified file could not be encrypted") for an encrypted one.
3. app.asar's landPhase:'copy' is only reachable after rename() has already failed with one of EXDEV/EPERM/UNKNOWN/EBADF - both primitives fail, not one.
4. The trigger is the volume, not this app. On the same machine: all 204 MSIX packages whose data is on C: have LocalCache Encrypted=False; all 16 packages whose data is redirected to D: (Claude, VS Code, WSL, Codex, OneDrive...) have Encrypted=True.

What fixes it: installing Claude so its package data lands on the system volume (set the default Appx volume to C:, uninstall, remove the D:\WpSystem\... folder, Add-AppxPackage -Volume <C:>). The same code path then logs [VHDX] Created dynamic VHDX and the VM boots normally - verified twice. See "Additional Information".

What Should Happen?

The Cowork VM should start, and Claude should be able to run commands on the machine.

Instead, the workspace never becomes available, and because both failure modes collapse into UNKNOWN the user gets no actionable signal at all - the app reports "Workspace unavailable" / "still downloading" / "failed to start" regardless of the real cause.

At minimum the app should surface the underlying Win32 error (0x80070199 / 0x80071770 / CreateVirtualDisk 0x1772 / 0x199) and tell the user that the VM bundle has to live on a volume where EFS is not mandated for package data.

Error Messages/Logs

From the app's own VM service log (C:\ProgramData\Claude\Logs\cowork-service.log) BEFORE the package data was moved to the system volume:

15:49:23  [Server] Warning: failed to create session disk: CreateVirtualDisk failed: 0x1772
          (err: Not all privileges or groups referenced are assigned to the caller.)
17:04:33  [Server] Warning: failed to create session disk: CreateVirtualDisk failed: 0x199
17:45:06  [Server] Warning: failed to create session disk: CreateVirtualDisk failed: 0x1772
17:45:56  [Server] Warning: failed to create session disk: CreateVirtualDisk failed: 0x1772
17:49:33  [Server] Warning: failed to create session disk: CreateVirtualDisk failed: 0x1772

The SAME code path AFTER moving the package data to C::

19:30:13  [VHDX] Created dynamic VHDX: ...\claudevm.bundle\sessiondata.vhdx
19:30:13  [Server] Configuration complete for S-1-5-21-...
19:30:13  [VM] StartVMWithBundle called (bundlePath=..., memoryGB=4, cpuCount=0)
19:30:13  [VM] Starting VM with config: ID=cowork-vm-5b172497, Memory=4096MB, CPUs=2

What the app shows instead, when decompressing the bundle cache:

[cache] rootfs.vhdx decompression from cache failed:
        UNKNOWN: unknown error, copyfile '...rootfs.vhdx.tmp' -> '...rootfs.vhdx'
        errno -4094, landPhase:'copy'

Reproduced OUTSIDE the app with fs.copyFileSync -> same UNKNOWN / errno -4094.
Raw Win32 codes recovered with .NET File.Copy:
  plaintext file in that folder -> 0x80070199  "The APPX file can not be accessed because it is not encrypted as expected."
  encrypted file in that folder -> 0x80071770  "The specified file could not be encrypted."

Steps to Reproduce

1. On Windows 11, set the default app-install volume to a NON-system drive:

Get-AppxDefaultVolume # -> D:\WindowsApps
(Settings > System > Storage > Advanced storage settings > Where new content is saved > "New apps will save to")

1. Install Claude Desktop (MSIX). Its package data is then redirected:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc
-> junction -> D:\WpSystem\<SID>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc

1. Confirm the bundle folder is EFS-encrypted:

cipher /c "C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle"
# -> "New files added to this directory will be encrypted."
# -> "E claudevm.bundle" Compatibility Level: Application Protected

1. Ask Claude to run any command on the machine (this starts the Cowork workspace).

-> UI shows "Workspace unavailable" / "still downloading" / "failed to start"
-> cowork-service.log shows: failed to create session disk: CreateVirtualDisk failed: 0x1772

1. Clear the encryption flag and retry:

cipher /d /s:"...\claudevm.bundle"
-> the same step now fails differently: CreateVirtualDisk failed: 0x199
-> the bundle copy step fails with UNKNOWN / errno -4094

1. Control: any MSIX package whose data lives on C: has LocalCache Encrypted=False and is unaffected.

1. Fix - put the package data back on the system volume:

# elevated
$cv = Get-AppxVolume | Where-Object { $_.IsSystemVolume }
Set-AppxDefaultVolume -Volume $cv
Get-AppxPackage Claude | ForEach-Object { Remove-AppxPackage -Package $_.PackageFullName }
Remove-Item 'D:\WpSystem\<SID>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc' -Recurse -Force
Add-AppxPackage -Path '<Claude.msix>' -Volume $cv
# -> the VM bundle is rebuilt and the VM boots

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.26454.2.0 (Claude Desktop MSIX; claude-code-vm 2.1.293)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Cross-machine control (same machine, all MSIX packages)

| package data location | LocalCache EFS attribute |
|---|---|
| 204 packages with data on C: | all Encrypted=False |
| 16 packages with data redirected to D: (Claude, VS Code, WSL, Codex, OneDrive...) | all Encrypted=True |

So the trigger is the volume, not this specific package.

Two relocation strategies tested and ruled out

1. Letting Windows redirect the package data to D: - produces the EFS deadlock above.
2. Keeping package data on C: but making vm_bundles an NTFS junction to D:\ClaudeVM\vm_bundles - the bundle download SUCCEEDS (the APPX layer accepts the junction), but VM start then wedges: the service stops immediately after setting the bundle paths and never reaches [[VHDX] Creating dynamic VHDX]], with no error logged. 5 of 5 attempts, vs 2 of 2 successes as soon as it was rolled back to a real C: directory.

There is no configuration option for the bundle path, so users with a small system drive have no supported way to relocate ~10 GB of VM images.

Related issues

• #83703 - same symptom (sessiondata.vhdx creation blocked by APPX LocalCache encryption vs Hyper-V's EFS incompatibility); does not identify the trigger.
• #25814 - MSIX container applies EFS encryption to the vm_bundles folder.

Environment

• Claude Desktop 2.26454.2.0 (MSIX, Developer-signed) - claude-code-vm 2.1.293
• Windows 11 10.0.26300.0, personal machine (not domain-joined, not MDM-managed)
• Default Appx volume: D:\WindowsApps (before fix)
• Disks: C: and D: on NVMe (Samsung 970 EVO Plus); E: on SATA HDD