[BUG] Windows MSIX desktop app: Claude Code sessions inherit AppData filesystem virtualization, so tools installed from inside a session (uv Python, uv tools, caches) land in the package LocalCache and are invisible or broken outside the app

Status Open
Reported on v2.1.260
Maintainer reply None cached
Activity 2 comments · opened Sep 9, 2026

What's Wrong?

The MSIX package Claude_pzs8sxrjxfjjc declares virtualization:FileSystemWriteVirtualization with only four excluded directories (…\Microsoft\Office\16.0\WEF, …\Claude-3p, …\Claude-Data, …\Claude\logs). Every descendant process of Claude.exe inherits that virtualization: the Claude Code CLI, its Bash/PowerShell tool shells, stdio MCP servers, and anything the user installs from a session.

Result: any write to %APPDATA% or %LOCALAPPDATA% made from inside a Claude Code session is silently redirected to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\{Roaming,Local}\…. The env vars still show the normal paths, Test-Path succeeds inside the session, but a normal terminal sees nothing.

Concrete impact on my machine (verified with a probe file and with a helper spawned outside the package via WMI):

  • uv python install 3.11 3.13 and uv tool install serena-agent, run from Claude Code sessions, put ~400 MB of interpreters and venvs only inside the package LocalCache. %APPDATA%\uv did not exist for the rest of the system.
  • uv's launcher shims in ~\.local\bin (a non-virtualized path) embed %APPDATA%\uv\python\cpython-3.13-windows-x86_64-none\python.exe. Outside the app they fail with uv trampoline failed to spawn Python child process: entity not found (os error 2). Inside the app they also fail (os error 3) because the minor-version directory is a junction whose target is the real, non-existent path.
  • The Serena MCP server registered in ~/.claude.json therefore only worked when launched by the desktop app; serena --version in a normal terminal failed with failed to canonicalize script path.
  • A user with pip, npm caches, cargo, dotnet tool, etc. would hit the same split-brain state without any error message.

What Should Happen?

Processes spawned for Claude Code sessions should see the same filesystem as the user's other terminals. Options:

  • Disable FileSystemWriteVirtualization (and RegistryWriteVirtualization) for the package, as most developer-tool MSIX packages do, or
  • Exclude %APPDATA% / %LOCALAPPDATA% broadly for child processes, or spawn the CLI through a non-virtualized broker (the package already ships an out-of-package service, cowork-svc.exe), or
  • At minimum, document the behaviour prominently and warn when a session writes under AppData.

Error Messages/Logs

Probe from inside a session (PowerShell tool):

wrote:    C:\Users\<user>\AppData\Roaming\uv\.virt-probe.txt
physical? C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\uv\.virt-probe.txt -> True

Same paths from a process created with Invoke-CimMethod Win32_Process Create (outside the package):

--- REAL C:\Users\<user>\AppData\Roaming\uv : (ABSENT)
--- REAL C:\Users\<user>\AppData\Local\uv : (ABSENT)
python3.13.exe : error: uv trampoline failed to spawn Python child process
  Caused by: entity not found (os error 2)
serena.exe : error: uv trampoline failed to canonicalize script path
uv.exe : No tools installed

Manifest excerpt (C:\Program Files\WindowsApps\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\AppxManifest.xml):

<virtualization:FileSystemWriteVirtualization>
  <virtualization:ExcludedDirectories>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Microsoft\Office\16.0\WEF</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-3p</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude-Data</virtualization:ExcludedDirectory>
    <virtualization:ExcludedDirectory>$(KnownFolder:LocalAppData)\Claude\logs</virtualization:ExcludedDirectory>
  </virtualization:ExcludedDirectories>
</virtualization:FileSystemWriteVirtualization>

Steps to Reproduce

  1. Install Claude Desktop from the Microsoft Store (MSIX) on Windows 11.
  2. In a Code-tab session, run New-Item "$env:APPDATA\probe.txt" (or uv python install 3.13).
  3. In a regular Windows Terminal: Test-Path "$env:APPDATA\probe.txt" → False. The file is at %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\probe.txt.

Claude Code Version

Desktop app 1.49585.0.0 (MSIX); bundled Claude Code 2.1.260.

Platform

Claude.ai subscription (OAuth) via the desktop app.

Operating System

Windows 11 Pro 10.0.26200.

Terminal/Shell

Desktop app Bash and PowerShell tools; reproduced in both.

Additional Information

Workaround I applied: pin tool state outside AppData with user env vars (UV_PYTHON_INSTALL_DIR, UV_TOOL_DIR → ~\.local\share\uv\…, UV_CACHE_DIR → ~\.cache\uv), reinstall, and delete the LocalCache copies. HKCU\Environment writes from inside a session are not virtualized, so the env vars took effect after an app restart.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗