[BUG] [Cowork] Win10 19045 MSIX 3P: Claude-3p unvirtualize exclude ignored; HCS/VirtioFS miss LocalCache bundle/SDK
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-3pexclude 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 containvm_bundlesorclaude-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:
- Ship
desktop6:FileSystemWriteVirtualizationso Win10 18362–20347 actually unvirtualizesClaude-3p. - And/or teach
cowork-svc/ HCS / VirtioFS to use the package LocalCache path. - Probe
LocalCache\Local\Claude-3p, notLocalCache\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
- Windows 10 22H2 build 19045 (or any build < 20348).
- Install Claude Desktop MSIX 1.30096.1 (
Claude_pzs8sxrjxfjjc). - Enable Developer Mode 3P (
deploymentMode=3p). This remaps userData to%LOCALAPPDATA%\Claude-3p. - Confirm CoworkVMService is Running / Auto / LocalSystem, hypervisor present.
- Start a Cowork Workspace.
- Observe VHDX lookup on the real Local path while files were written to Package LocalCache.
- Optional: a physical copy of only
vm_bundlesto the real Local path lets the VM boot, then fails at VirtioFS.verifiedforclaude-code-vm\2.1.229. - 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:
- https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-virtualization-filesystemwritevirtualization (min 20348)
- https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop6-filesystemwritevirtualization (min 18362)
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.
3 Comments
Official in-app diagnostic has been generated (Help → Troubleshooting → Generate Diagnostic Report → Export to file).
133e8cfc-01bf-433e-93f6-7716a08bfeb4claude-diagnostic-133e8cfc-20260814-0635.zipinferenceGatewayApiKeyis redacted in the bundlecowork-vm-log.txtstill shows:failed to set VHDX path: VHDX file not found: <home>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdxHappy to upload the zip if a maintainer wants the full scrubbed bundle.
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.
I independently reproduced a Cowork startup failure on my Windows 10 system.
Environment:
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.