[BUG] Bash/PowerShell tool writes under %LOCALAPPDATA% can be silently virtualized — visible only to the writing process tree, absent on real disk

Environment

• Claude Code CLI 2.1.220 inside the Claude Desktop app lineage, Windows 11 Pro 10.0.26200
• Writer: an interactive desktop session using its Bash and PowerShell tools
• Readers: (a) Claude sessions spawned independently by Windows Task Scheduler, (b) Windows Explorer (human check)

Observed

A ~1 GB directory tree (Playwright Chromium builds, 611 files) was copied via the session's Bash tool to %LOCALAPPDATA%\<app-dir>\browsers\. Read-back from BOTH Bash and PowerShell tool contexts in that session (and its process tree) showed the tree complete — 611 files, correct sizes. Two independent Task-Scheduler-spawned sessions ~30 minutes apart saw only a sibling profile\ directory at the same absolute path — no browsers\ at all. A human Explorer check confirmed the Task-Scheduler view is the real disk: browsers\ did not exist; the writes lived only in the writing process tree's sandbox view.

The selectivity — why this is worse than blanket redirection

In the same session and location class, some writes DID land on real disk: the profile\ directory (written by a Playwright child process) and pip's site-packages installs were real; the cp-mirrored tree was not. The virtualization boundary is selective and undocumented — there is no error, no warning, and no way for the session to detect it from inside, since its own reads are served from the same sandbox view that absorbed the writes.

Expected

Either writes land on real disk, or the write fails/warns. A silent per-process-tree overlay breaks any workflow where an agent installs software or stages files for another process to consume.

Impact

Any file an agent writes for consumption outside the app's process tree — scheduled-task inputs, installed tooling, browser binaries, anything under AppData — may be an illusion that survives in-session verification. We now require out-of-process-tree verification (a Task-Scheduler-context listing or a human file-manager check) before relying on such writes.

Repro (as observed)

1. From a desktop-app-lineage session, Bash-copy a large directory tree into %LOCALAPPDATA%\<any-dir>\.
2. Verify in-session via Bash ls/find and PowerShell Get-ChildItem — tree present.
3. From a Task-Scheduler-spawned process (Claude session or plain script), list the same absolute path — tree absent.
4. Confirm with Explorer — tree absent on real disk.

Probable mechanism (related issues)

The desktop app is MSIX-packaged, and MSIX AppData virtualization redirecting writes into the package container is established in #25579 (userData at LocalCache, invisible at documented path), #39029 (luafv filesystem filter + AppData virtualization split), #48362 (EXDEV inside the MSIX sandbox), and #63633 (bundle writes redirected into the container). None of those cover this failure mode: agent tool writes silently and selectively virtualized, with in-session read-back showing them intact — data invisibility to other process trees rather than an error surface.