[BUG] Cowork VM fails to start on Windows — sessiondata.vhdx creation blocked by mandatory APPX LocalCache encryption vs. Hyper-V's EFS incompatibility

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 4, 2026

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?

Cowork fails to start with:

Failed to start Claude's workspace — failed to set session disk path: session disk not found:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx

This persists across full reinstalls, reboots, and the app's own automatic "Auto-reinstalling workspace after startup failure" recovery path. Every other bundle asset (rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx) downloads/decompresses/copies successfully every time. sessiondata.vhdx specifically is never created — there is no log line anywhere showing an attempt to create it; the VM service simply reports it missing at startup.

What Should Happen?

The MSIX-packaged install's claudevm.bundle folder, at:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle

is marked by Windows with EFS encryption at "Application Protected" compatibility level (confirmed via cipher /c, all existing bundle files show the Encrypted attribute). This is enforced by the Windows APPX/Package Identity subsystem for this MSIX package's LocalCache, on a personal (non-domain-joined, non-MDM-managed) Windows 11 machine — i.e., it is Windows' own packaging behavior, not a third-party security product or enterprise policy.

Hyper-V's New-VHD (and by extension whatever internal API Claude Desktop uses to create the session disk) refuses to create a virtual disk inside an EFS-encrypted directory. This is a well-documented Hyper-V limitation, unrelated to this bug report but is the proximate trigger.

Error Messages/Logs

2026-08-04 09:04:17 [info] [VM:start] Configuring Windows VM service...

2026-08-04 09:04:18 [error] [VM:start] Startup failed: Error: failed to set session disk path: session disk not found: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\sessiondata.vhdx

2026-08-04 09:04:18 [info] [VM:start] Skipping auto-reinstall (already attempted once)

(Full cowork_vm_node.log and cipher /c / New-VHD transcripts available on request.)

Steps to Reproduce

Reproduction proving the conflict is bidirectional and structural:

Control test — New-VHD in a clean, unencrypted folder succeeds without issue:

New-Item -ItemType Directory -Path "C:\temp_vhd_test" -Force

New-VHD -Path "C:\temp_vhd_test\test.vhdx" -Dynamic -SizeBytes 10GB

Succeeds, full VHDX object returned

This rules out Hyper-V / Virtual Machine Platform / vmcompute / hns / vds being broken system-wide — all were confirmed enabled and running.

Folder is encrypted (baseline / before any change):

cipher /c "...\claudevm.bundle"

New files added to this directory will be encrypted.

E claudevm.bundle

Compatibility Level:

Application Protected

New-VHD targeting sessiondata.vhdx in this folder fails:

The system failed to create '...\sessiondata.vhdx': The specified file is encrypted and the user

does not have the ability to decrypt it. (0x80071772)

After clearing the "encrypt new files" flag on the folder (cipher /d /s:"...\claudevm.bundle" — folder-level flag successfully cleared, confirmed via cipher /c showing U claudevm.bundle): New-VHD now fails with a different, more specific error:

The system failed to create '...\test2.vhdx': The APPX file can not be accessed because it is

not encrypted as expected. (0x80070199)

0x80070199 = ERROR_APPX_FILE_NOT_ENCRYPTED. This confirms the Windows Package Identity/APPX subsystem actively requires this specific path to remain encrypted, and rejects the write once the encryption expectation is violated.

Re-encrypting the folder (cipher /e /s:"...\claudevm.bundle") restores the original (still-broken, but at least consistent/expected-by-Windows) state.

Conclusion: on this class of machine/install, there is no valid state for this folder — Windows' APPX packaging requires it encrypted; Hyper-V refuses to create a VHD inside it if it is encrypted. sessiondata.vhdx can never be created at this path via the MSIX-packaged install. This is not fixable by the end user via cipher, permissions, reinstalling, or rebooting.
Suggested Fix
Do not place sessiondata.vhdx (or any file requiring Hyper-V VHD creation) inside the MSIX package's Package Identity–protected LocalCache tree.
Either: (a) create the session disk in an unpackaged, non-virtualized writable location (e.g. %ProgramData%\Claude\vm_bundles or a location outside Packages\<PFN>\LocalCache) and reference it from the VM config, or (b) exclude this specific subfolder from the APPX-mandated encryption requirement if that's configurable via the MSIX manifest/capabilities.
Environment
OS: Windows 11, personal machine, not domain-joined / not MDM-managed
Install type: Microsoft Store / MSIX (C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\)
Claude Desktop version: 1.24012.11.0 (also reproduced on 1.24012.9.0)
Virtual Machine Platform: Enabled
Services vmcompute, hns: Running
Service vds: present, starts on demand
Steps to Reproduce
Install Claude Desktop via Microsoft Store (MSIX) on a Windows 11 Home/Pro personal machine.
Launch Cowork.
Observe rootfs.vhdx, vmlinuz, initrd, smol-bin.vhdx all materialize successfully in claudevm.bundle.
Observe startup fails at "Configuring Windows VM service..." with session disk not found: ...\sessiondata.vhdx.
Run cipher /c on the claudevm.bundle folder — observe Compatibility Level: Application Protected.
Attempt New-VHD inside that folder as Administrator — observe 0x80071772.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.24012.11

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

#29657 (rootfs.vhdx/sessiondata.vhdx missing, Windows 11 Home)
#40447 (New-VHD 0xC03A0014 virtual disk provider not found)
#24974 (sessiondata.vhdx not created)
#26258 (never-working install, 12GB vm_bundle)
#80429 (won't work on Windows 11 Home despite readiness check)
#25206 (VM crashes within 5 minutes, Win 11 Pro)
#32088 (VM fails after update, smol-bin.vhdx never downloaded)
This issue provides, for the first time in this family, a concrete reproducible root cause (APPX-mandated LocalCache encryption vs. Hyper-V's EFS restriction) rather than just the downstream symptom.

View original on GitHub ↗