[BUG] [Cowork] Win10 19045 MSIX 3P: Claude-3p unvirtualize exclude ignored; HCS/VirtioFS miss LocalCache bundle/SDK

Status Open
Reported on v2.1.229
Maintainer reply None cached
Activity 3 comments · opened Aug 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported with this verified combination (Win10 19045 + Desktop 1.30096.1 + 3P Claude-3p exclude ignored + CoworkVMService already running)
  • [x] This is a single bug report
  • [x] I am using the latest Claude Desktop MSIX currently installed on this machine: 1.30096.1.0

Related but not the same:

  • #52540 #56542 #66778 (MSIX path split / junction refuse / SDK not verified after VHDX bypass)
  • #85693 (3P + 19045 exclude theory; author later blamed a missing service). This host already has CoworkVMService Running/Auto/LocalSystem and still fails.

What's Wrong?

Claude Desktop Cowork Workspace never starts on Windows 10 22H2 build 19045 + MSIX + Developer Mode 3P.

Anthropic's own AppxManifest.xml excludes $(KnownFolder:LocalAppData)\Claude-3p from filesystem write virtualization so 3P userData is supposed to be the real %LOCALAPPDATA%\Claude-3p. That exclude uses virtualization:FileSystemWriteVirtualization (Microsoft min OS 20348) and virtualization is in IgnorableNamespaces. The package does not include desktop6:FileSystemWriteVirtualization (min OS 18362).

On build 19045 < 20348 the exclude is silently ignored.

  • Electron/CCD write the VM bundle + SDK into Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\
  • CoworkVMService / HCS / VirtioFS open C:\Users\<user>\AppData\Local\Claude-3p\, which does not contain vm_bundles or claude-code-vm

The in-app probe checks LocalCache\Roaming\Claude-3p (absent) and logs Filesystem not virtualized while live data is under LocalCache\Local\Claude-3p.

This is not a Hyper-V / volume-redirect / EFS / gateway-auth failure. Local junctions are product-refused. Copying only vm_bundles only advances to the next error. We have stopped local workarounds and are waiting for a vendor fix.

What Should Happen?

Writes to %LOCALAPPDATA%\Claude-3p should land on the real directory (as the manifest comment states), or CoworkVMService / HCS / VirtioFS should resolve the MSIX LocalCache path. Workspace should start without the user copying VHDX/SDK trees or planting junctions.

Suggested fix:

  1. Ship desktop6:FileSystemWriteVirtualization so Win10 18362–20347 actually unvirtualizes Claude-3p.
  2. And/or teach cowork-svc / HCS / VirtioFS to use the package LocalCache path.
  3. Probe LocalCache\Local\Claude-3p, not LocalCache\Roaming\Claude-3p.

Error Messages/Logs

[MSIX] Filesystem not virtualized — ...\LocalCache\Roaming\Claude-3p absent (likely Squirrel upgrade)

failed to set VHDX path: VHDX file not found: C:\Users\<user>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx

configure: path C:\Users\<user>\AppData\Local\Claude-3p\vm_bundles is a symlink or junction, refusing to open

RPC error -1: SDK version 2.1.229 not verified at /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Claude-3p/claude-code-vm/2.1.229/.verified

.verified exists in LocalCache (64-hex marker). The guest looks at the real Local path via VirtioFS, where it is absent.

At the SDK-verify failure, VM network was CONNECTED and API REACHABLE.

Steps to Reproduce

  1. Windows 10 22H2 build 19045 (or any build < 20348).
  2. Install Claude Desktop MSIX 1.30096.1 (Claude_pzs8sxrjxfjjc).
  3. Enable Developer Mode 3P (deploymentMode=3p). This remaps userData to %LOCALAPPDATA%\Claude-3p.
  4. Confirm CoworkVMService is Running / Auto / LocalSystem, hypervisor present.
  5. Start a Cowork Workspace.
  6. Observe VHDX lookup on the real Local path while files were written to Package LocalCache.
  7. Optional: a physical copy of only vm_bundles to the real Local path lets the VM boot, then fails at VirtioFS .verified for claude-code-vm\2.1.229.
  8. A directory junction is rejected by configure (symlink or junction, refusing to open).

Is this a regression?

I don't know

Last Working Version

Unknown. Cowork Workspace has not successfully started on this host under 1.26832.0 or 1.30096.1.

Claude Code Version

Claude Desktop 1.30096.1.0 MSIX
CCD / VM SDK requested and provisioned: 2.1.229 (normal upgrade from 2.1.227)

Claude Model

Other

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Package: Claude_1.30096.1.0_x64__pzs8sxrjxfjjc
Manifest comment (verbatim): "3P userData lives in LocalAppData; exclude so devirtualizeMsixPath/showItemInFolder see the real path"
Capability unvirtualizedResources is present; it is not sufficient on 19045 without the desktop6 FS virtualization element.

Microsoft docs:

AppX install + package data are on C:. Files are not EFS-encrypted. We will not continue local filesystem hacks.

Official in-app diagnostic path: Help → Troubleshooting → Generate Diagnostic Report. Can attach the exported bundle if maintainers want it.

View original on GitHub ↗

3 Comments

waleymachinery-ship-it · 2 months ago

Official in-app diagnostic has been generated (Help → Troubleshooting → Generate Diagnostic Report → Export to file).

  • Bundle ID: 133e8cfc-01bf-433e-93f6-7716a08bfeb4
  • File: claude-diagnostic-133e8cfc-20260814-0635.zip
  • Created: 2026-08-14T06:35:38.887Z
  • App: 1.30096.1 MSIX, OS 10.0.19045, deploymentMode=3p, inferenceProvider=gateway
  • inferenceGatewayApiKey is redacted in the bundle
  • cowork-vm-log.txt still shows: failed to set VHDX path: VHDX file not found: <home>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx

Happy to upload the zip if a maintainer wants the full scrubbed bundle.

tenfinnvo · 1 month ago

Can confirm the issue. Using a third-party inference requires developer mode, which ultimately causes the folder mismatch. Any file created by Claude, including it's memories, cannot be subsequently read by it because it's looking for the files in the wrong place.
The VM and .verified files can be manually copied to make the VM start up, but this does not help with memories or direct file work. The issue is old and remains unresolved.

roshanm039-ctrl · 1 month ago

I independently reproduced a Cowork startup failure on my Windows 10 system.

Environment:

  • Windows 10 Pro 22H2, build 19045
  • Claude Desktop 1.49585.0.0 (MSIX)
  • Developer Mode / 3P mode
  • inferenceProvider: gateway
  • CoworkVMService is installed and running as LocalSystem

Observed error:

failed to set VHDX path: VHDX file not found:
C:\Users\<user>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx

However, the actual rootfs.vhdx exists at:

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx

The Claude Desktop diagnostic logs repeatedly show that the VM startup process attempts to use the first path, while the VM bundle is present under the MSIX LocalCache path.

I also verified that Hyper-V, Virtual Machine Platform, HNS, and the required VM service are enabled/running. This is therefore not simply a case of the Windows virtualization components being disabled.

I generated and submitted the official Claude Desktop Diagnostic Report to Anthropic.

Diagnostic Report Reference ID:
f6008240-a39f-472d-b5f1-d8f254ec454e

Anthropic Support confirmed that the diagnostic report has been received and is available in their system for investigation.

I am posting this as independent reproduction evidence from my own Windows 10 19045 system. Please let me know if the engineering team needs the diagnostic report reference or any additional logs.