[BUG] Windows desktop (MSIX): writes to %LOCALAPPDATA% from Claude Code sessions are silently redirected to Packages\Claude_*\LocalCache

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 Claude Desktop app (MSIX build), commands that Claude Code sessions run (PowerShell or Bash tool calls) execute inside the app's package container. Windows' MSIX file-system write virtualization then **silently redirects their writes under `%LOCALAPPDATA%`** to `%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\…`.

Inside the session everything looks normal, and the file is at the expected path. **No process outside the package can see it:** Task Scheduler, a regular terminal, services, other apps. Reads of real files still work (the app's own `main.log` under `AppData\Local\Claude\Logs` is a real file), so this only bites on writes, which makes it very hard to notice.

How I hit it: a Claude Code session installed a script to `%LOCALAPPDATA%\claude-hacks\` and registered a scheduled task to run it. Task Scheduler reported `0x0` on every run, but nothing ever executed. PowerShell rejected the path because the file didn't exist outside the package.

Anything Claude Code writes to AppData on the Windows desktop app can end up invisible to the rest of the system: installers, config files, tool setup, caches.

### What Should Happen?

Commands run by Claude Code sessions should read and write the user's real filesystem, the same as when Claude Code runs in a normal terminal. For example, opt the package out of AppData write virtualization (`desktop6:FileSystemWriteVirtualization`), or run tool processes outside the package container. If it has to stay, it should be documented, because developer tooling assumes `%LOCALAPPDATA%` is the real path.

### Error Messages/Logs

```shell
# From the scheduled task (running outside the package):
The argument 'C:\Users\\AppData\Local\claude-hacks\claude-watchdog.ps1' to the -File parameter does not exist. Provide the path to an existing '.ps1' file as an argument to the -File parameter.

# Probe from a task outside the package, after a Claude Code session wrote %LOCALAPPDATA%\msix-probe\hello.txt:
real AppData path: False | LocalCache path: True
```

### Steps to Reproduce

1. In a Claude Code session in Claude Desktop on Windows, have Claude run:
```powershell
New-Item -ItemType Directory -Force "$env:LOCALAPPDATA\msix-probe" | Out-Null
Set-Content "$env:LOCALAPPDATA\msix-probe\hello.txt" 'hi'
Test-Path "$env:LOCALAPPDATA\msix-probe\hello.txt" # True
```
2. From a process **outside** Claude (I used a scheduled task; a PowerShell window not started from Claude should behave the same), run:
```powershell
Test-Path "$env:LOCALAPPDATA\msix-probe\hello.txt" # False
Test-Path "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\msix-probe\hello.txt" # True
```
3. Clean up: `Remove-Item -Recurse "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\msix-probe"`

### Claude Model

Opus

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.270 (Claude Desktop 1.52386.6, MSIX x64)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Other

### Additional Information

- Surface: the Code tab of Claude Desktop, with tool calls through PowerShell and Git Bash. Windows 11 Pro 10.0.26200.
- Workaround: write to a location that isn't redirected, such as `%USERPROFILE%\`. The profile root isn't redirected.
- Found while building a workaround for #89599: https://github.com/paperhurts/claude-hacks/pull/1