[BUG] [Cowork] Windows 10 MSIX: Claude-3p write-virtualization exclusion only declared for Build 20348+ — silently ignored, causing the LocalCache/real-path split

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?

```markdown
The shipped AppxManifest.xml **does** declare that Claude-3p` must be excluded from filesystem
write virtualization — but only in the form that requires a newer OS build. On Windows 10 that
declaration is discarded without any error, and that is the root cause of the AppData path split
already reported several times as a symptom.

Relevant manifest lines (Claude Desktop 1.26832.0.0):

 13: IgnorableNamespaces="uap uap3 uap4 uap5 desktop2 desktop6 virtualization"
 25: <desktop6:RegistryWriteVirtualization>disabled</desktop6:RegistryWriteVirtualization>
 26: <virtualization:RegistryWriteVirtualization>
 27:   <virtualization:ExcludedKeys> ... browser NativeMessagingHosts keys ...
 39: </virtualization:RegistryWriteVirtualization>
 42: <virtualization:FileSystemWriteVirtualization>
 43:   <virtualization:ExcludedDirectories>
 46:     <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-3p</virtualization:ExcludedDirectory>
 48: </virtualization:FileSystemWriteVirtualization>
 74: <rescap:Capability Name="unvirtualizedResources" />

Note the asymmetry between the two resource types:

| resource | legacy declaration (desktop6:) | flexible declaration (virtualization:) |
|---|---|---|
| registry | present (line 25) | present (lines 26–39) |
| filesystem | missing | present (lines 42–48) |

Minimum supported builds differ:

• virtualization:FileSystemWriteVirtualization — Build 20348

(docs)

• desktop6:FileSystemWriteVirtualization — Windows 10 1903, Build 18362

(docs)

Because line 13 lists virtualization as ignorable, Build 19045 drops lines 42–48 with no error,
warning or log entry. Write virtualization therefore stays enabled for Claude-3p, and the two
sides of Cowork end up looking at different directories while using the same path string:

• the app resolves its data directory as os.homedir() + AppData\Local\Claude-3p, and its writes

are transparently redirected into
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p

• the same unredirected string is handed to cowork-svc, which runs as LocalSystem and is not

subject to the per-user redirection, so it opens an empty directory

On Windows 11 the exclusion applies and the split appears mirrored (#66778: provisioning lands
in the real path while the service reads the package path), which is consistent with the same
assumption being made in the opposite direction. Either way the two sides disagree.

Everything else on the failing host is healthy: HypervisorPlatform enabled, vmms /
vmcompute / hns all running, CoworkVMService registered and Running, and the bundle fully
downloaded in the package path (rootfs.vhdx ~8.1 GB, sessiondata.vhdx, smol-bin.vhdx,
vmlinuz, initrd, plus the .verified marker for exactly the SDK version the VM asks for).
Only the path disagreement stops the VM.

Suggested fix

Add the legacy fallback next to the registry one that is already present — mirroring what the
manifest already does for the registry:

<desktop6:FileSystemWriteVirtualization>disabled</desktop6:FileSystemWriteVirtualization>

The desktop6 namespace is already declared on line 13, so this is additive. Newer builds keep
honouring the finer-grained virtualization: exclusions; older builds get the blanket opt-out
instead of silently getting nothing.

Worth considering independently: have the app resolve the bundle directory the same way the service
does, and fail loudly when the two disagree, instead of proceeding with a path one side cannot see.

````

What Should Happen?

```markdown
Claude-3p` should be unvirtualized on every OS version the app supports. Cowork is documented as
supporting Windows 10 and later, so the exclusion needs a declaration that Windows 10 honours.

Concretely: on Windows 10, app writes to %LOCALAPPDATA%\Claude-3p should land in the real
directory, cowork-svc should find the VM bundle and the claude-code-vm .verified marker at the
same location, and Cowork should start. Today the app and the service use an identical path string
and resolve it to two different directories.

````

Error Messages/Logs

`
# 1. Proof that write redirection is active for this directory on Build 19045.
#    Produced deliberately while probing: making the package LocalCache\Local\Claude-3p a junction
#    back to the real directory yields redirect -> junction -> redirect.

Error: ELOOP: too many symbolic links encountered, mkdir '<home>\AppData\Local\Claude-3p\logs'
    at mkdirSync (node:fs:1350:26)
    at Object.mkdirSync (node:electron/js2c/node_init:2:17291)
    at e.t.t.exports._createLogDirIfNotExist (app://\.vite\build\index.chunk-CWSnTt4v.js:7:46150)
  {
    errno: -4067,
    code: 'ELOOP',
    syscall: 'mkdir',
    path: '<drv>:\\Users\\<user>\\AppData\\Local\\Claude-3p\\logs'
  }

# 2. cowork-svc rejects reparse points, so no link-based workaround is possible.
#    Note the check is not uniform: claude-code-vm was traversed through a junction without
#    complaint, while Claude-3p and vm_bundles were rejected.

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

# 3. Earlier failure from the same split, before the service was running:

RPC error: SDK version 2.1.222 not verified at
/mnt/.virtiofs-root/.../Claude-3p/claude-code-vm/2.1.222/.verified
# The .verified file exists at the package LocalCache path and is absent from the real path.
`

Steps to Reproduce

`````markdown

1. Install the MSIX build of Claude Desktop on Windows 10 (Build 19045 reproduces).

1. Confirm the manifest declares the exclusion only in the newer form:

``powershell
Select-String -Path "$((Get-AppxPackage -Name Claude).InstallLocation)\AppxManifest.xml" -Pattern "FileSystemWriteVirtualization|ExcludedDirector"
``

Expected: matches for virtualization:FileSystemWriteVirtualization and
$(KnownFolder:LocalAppData)\Claude-3p, and no desktop6:FileSystemWriteVirtualization.

1. Confirm the OS build is below 20348:

``powershell
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion").CurrentBuildNumber
``

1. Open Cowork and let the VM bundle download to completion.

1. Compare the two locations:

``powershell
Test-Path "$env:LOCALAPPDATA\Claude-3p"
Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles"
``

Observed: the first is False, the second is True with the full bundle.

1. Cowork fails to start and the service reports the real path as missing or unusable.

1. For contrast, run the same package version on a host at Build 20348 or above: the exclusion

applies and the directories no longer disagree in this direction.

`````

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.26832.0.0 (x64 MSIX, Claude_1.26832.0.0_x64__pzs8sxrjxfjjc) — not the Claude Code CLI; this is a Claude Desktop / Cowork packaging defect

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Claude Desktop 1.26832.0.0, x64 MSIX (Claude_1.26832.0.0_x64__pzs8sxrjxfjjc), installed under

C:\Program Files\WindowsApps. Single Claude package registered, no Squirrel/.exe install present.

• Windows 10 Enterprise, Build 19045 (22H2).
• HypervisorPlatform Enabled; vmms Running/Automatic; vmcompute and hns Running.
• CoworkVMService registered, StartMode Auto, State Running, binary at

WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe.

• Managed deployment: per-machine provisioning followed by per-user registration.

Build correlation

The same package version on Windows Server 2022 (Build 20348, the documented minimum for
virtualization:FileSystemWriteVirtualization) behaves differently — the exclusion applies and the
Cowork machinery comes up. The failing host is 19045. This is the clearest signal that the gating
factor is the declaration's minimum build rather than anything host-specific.

Link-based workarounds do not work (measured)

| attempt | result |
|---|---|
| symlink at the real path | rejected by cowork-svc |
| junction at the real path (Claude-3p) | rejected |
| junction for claude-code-vm only | traversed fine, then rejected at vm_bundles |
| reverse junction (package LocalCache path -> real path) | app dies immediately with ELOOP |
| real copy of the bundle into the real path | works, but duplicates ~9.4 GB and goes stale on updates |

#62430 reports the same conclusion from a different angle: junctions do not work, hard links do.

Why this is not a duplicate

The following issues report the observable path split as a symptom: #36298, #52540, #56542, #62430,
#62937, #63633, #66778, #83703. Several were auto-closed as duplicates or as inactive, and the
underlying cause was never identified in any of them.

This report identifies the cause — a namespace / minimum-build gap in the shipped manifest that is
silently discarded because the namespace is listed as ignorable — and proposes a specific one-line
change. Closing it as a duplicate of a symptom report would lose that, and the symptom reports have
already been closed without a fix.

Impact

This blocks Cowork for every Windows 10 host in a managed fleet, with no user-side or
administrator-side remedy: the manifest cannot be amended without repackaging and re-signing the
vendor package, and there is no documented policy or registry setting to disable MSIX filesystem
write virtualization for an installed package.

````