Windows MSIX: session cards can never be saved when %APPDATA%\Claude contains a reparse point — one-line manifest fix (RoamingAppData\Claude missing from FileSystemWriteVirtualization exclusions)

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?

On the Windows MSIX build of Claude Desktop, session cards can never be saved when anything under %APPDATA%\Claude is a directory symlink or junction. Every save fails with a spurious EEXIST on a .tmp file that does not exist on disk, and each reload of a past conversation dies with "Remote Control disconnected".

The failing call is the exclusive create, not the rename. writeSessionToDisk writes local_<id>.json.tmp with flag: 'wx' (O_EXCL / CREATE_NEW) before renaming it over the card, and it is that create which fails. Because no card is ever written, sessions created while broken exist only in app memory, disappear from the session list on exit, and their web cards can never reconnect.

Root cause: %APPDATA%\Claude is subject to MSIX AppData write virtualization, and reparse points inside a virtualized tree are the documented failure case. The package manifest already uses flexible virtualization and already excludes two other paths, but never excludes its own Roaming folder.

This is not a duplicate of #32533 / #54883 / #57633 / #48362. All four of those fail at the atomic rename() with EXDEV, and all four were closed (one as "invalid") without the cause being identified. This one never reaches the rename — the exclusive create fails first, with a spurious EEXIST. The copyFile fallback independently proposed in three of them patches a step this case never gets to, which is also why it would not have closed this out.

Conversely, the fix proposed here resolves all five: removing the virtualized layer eliminates the cross-device rename and the spurious exclusive-create failure. Note also that the manifest already excludes the LocalAppData copy of Claude-3p, while #54883 reports this same failure against the RoamingAppData copy — the exclusion approach is already accepted in this package, the list is just missing its Roaming entries. Exact strings are in the Additional Information section.

What Should Happen?

Session cards should be written successfully, so that past conversations reload and remote-control sessions reconnect, regardless of whether %APPDATA%\Claude\claude-code-sessions is a real directory or a reparse point.

Concretely, AppxManifest.xml should add one more ExcludedDirectory to the FileSystemWriteVirtualization list it already ships:

<desktop6:FileSystemWriteVirtualization>
  <desktop6:ExcludedDirectories>
    <!-- already present -->
    <desktop6:ExcludedDirectory Name="$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF"/>
    <desktop6:ExcludedDirectory Name="$(KnownFolder:LocalAppData)\Claude-3p"/>
    <!-- MISSING - add this -->
    <desktop6:ExcludedDirectory Name="$(KnownFolder:RoamingAppData)\Claude"/>
  </desktop6:ExcludedDirectories>
</desktop6:FileSystemWriteVirtualization>

That one line also removes the EXDEV rename failure reported in #32533, #54883, #57633 and #48362.

Error Messages/Logs

# %APPDATA%\Claude\logs\main.log — hundreds per day, zero cards written
[error] Failed to save session local_<id>: EEXIST: file already exists, open
'C:\Users\<user>\AppData\Roaming\Claude\claude-code-sessions\<acct>\<org>\local_<id>.json.tmp'
{ errno: -4075, code: 'EEXIST', syscall: 'open', ... at async j.writeSessionToDisk (...) }

# No .tmp file exists on disk. The EEXIST is spurious.

# Minimal reproduction of the same failure, outside the app:
# O_EXCL create through a reparse point under %APPDATA%\Claude
node -e "require('fs').writeFileSync(process.env.APPDATA+'\\Claude\\claude-code-sessions\\probe.tmp','x',{flag:'wx'})"
#   -> EEXIST   (0 of 10 attempts succeed)
# Identical link one directory over, %APPDATA%\ClaudeZZ
#   -> succeeds (10 of 10)

Steps to Reproduce

1. Install Claude Desktop from the MSIX package (Claude_pzs8sxrjxfjjc) on Windows 11.
2. Quit Claude Desktop completely from the tray.
3. Replace %APPDATA%\Claude\claude-code-sessions with a directory symlink or junction pointing anywhere else — another local folder on the same drive is enough, a network/cloud path is not required:

``
mklink /D "%APPDATA%\Claude\claude-code-sessions" "C:\some\other\local\folder"
``

1. Start Claude Desktop and use a Code session normally.
2. Watch %APPDATA%\Claude\logs\main.log: every session save fails with the EEXIST above, and no local_*.json is ever written to the target folder.
3. Quit and reopen Claude Desktop. Sessions created in step 4 are gone from the list; reloading one reports "Remote Control disconnected".

Isolation already done — the following were each ruled out by measurement, so they are not the cause: antivirus (Defender real-time + behaviour monitoring off, Malwarebytes stopped), Controlled Folder Access (disabled), DENY ACEs (none present), fsutil symlink evaluation (L2L/L2R enabled), path case, nesting depth, link type (junction and symlink both fail), and target volume (local C: target fails too). The same link created one directory over, at %APPDATA%\ClaudeZZ or under %TEMP%, passes the identical write pattern 10/10 — which points at the virtualized %APPDATA%\Claude tree specifically, not at the filesystem or the link.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop pre-MSIX Squirrel build (before ~2026-02-10)

Claude Code Version

2.1.219 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

On the regression answer. This began with the move from the Squirrel .exe installer to MSIX, around 2026-02-10. #48362 independently records that switching back to the Win32/Squirrel installer resolves it, which is consistent with a packaging-layer cause rather than an application-logic one.

Not terminal-specific. The Terminal/Shell dropdown above is answered
Windows Terminal because that is the host shell on this machine, but the failing
sessions are spawned by the Claude Desktop app itself, not from any terminal. The
bug reproduces regardless of shell.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.9.0, MSIX, Claude_pzs8sxrjxfjjc, SignatureKind=Developer (sideloaded from Anthropic, not Store) |
| Claude Code | 2.1.219 |
| OS | Windows 11 Pro, build 26200, x64 |
| Session registry | %APPDATA%\Claude\claude-code-sessions\<accountUuid>\<orgUuid>\ |
| Setup | that registry folder was a directory symlink to another location, to share session cards between machines |

The one-line fix

AppxManifest.xml for 1.24012.9.0 already declares the unvirtualizedResources restricted capability, already disables registry virtualization, and already excludes two directories from FileSystemWriteVirtualization:

KnownFolder:LocalAppData  \Microsoft\Office\16.0\WEF     <- already excluded
KnownFolder:LocalAppData  \Claude-3p                     <- already excluded
KnownFolder:RoamingAppData\Claude                        <- MISSING, session registry lives here
KnownFolder:RoamingAppData\Claude-3p                     <- MISSING, this is what #54883 hits

The session registry lives under the RoamingAppData copy, which is never excluded. Adding it alongside the existing two removes the virtualized layer from that path and fixes this report as well as the EXDEV variants in #32533, #54883, #57633 and #48362.

The exclusion list is already the accepted fix here — it is simply incomplete. The second existing entry excludes the LocalAppData copy of Claude-3p. Issue #54883 reports this exact failure against the RoamingAppData copy of the very same component — same problem, one known-folder over, and not excluded. So the packaging already acknowledges that these directories must bypass write virtualization; the list just does not cover Roaming. Adding the two missing Roaming entries is consistent with the manifest's own existing design rather than a new approach.

This is broader than symlink users. #57633 and #54883 involve no reparse points at all — they hit the plain MSIX VFS boundary, where %APPDATA%\Claude\ is redirected to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\. A reparse point (this report) is one way to trigger the failure; simply having the redirect in play is another. Both are removed by the same exclusion.

Why the repeatedly-proposed copyFile fallback has not settled it. #32533, #54883 and #57633 each independently propose catching EXDEV and falling back to copyFile + unlink. That would fix those three, but not this report — here the failure is a spurious EEXIST at the exclusive create, before any rename is attempted, so there is no EXDEV to catch. Patching each call site chases symptoms across the codebase; the manifest exclusion removes the cause for all of them at once.

Impact

Silent, total loss of session persistence with no user-facing error. Sessions appear to work normally during the run and are simply gone on restart, so it presents as data loss rather than as a save failure, which is why it keeps being reported from different angles.

Affected users are not limited to those who link or redirect %APPDATA%\Claude to share session cards across machines. As #57633 and #54883 show, the plain MSIX VFS redirect is enough on its own.