Plugin installs fail on Windows in 1.25927.0 - MSIX filesystem virtualization detected as a junction plant

Summary

After updating to 1.25927.0 on Windows 11, every plugin install fails — both the "+" upload panel and installing from a git marketplace. A guard rejects the plugin store directory as a junction/substitute-name redirect. That directory is not a reparse point. What it actually detects is the app's own MSIX filesystem virtualization, so the check appears to misfire against a stock packaged install.

Plugin installs worked on the previous build, 1.24012.11, on the same machine with the same directory layout.

Error

[warn] [LocalPlugins] RPM install-after-upload failed (non-fatal) for <plugin>@My Uploads:
J [PlantDetectedError]: Private dir leaf redirects (junction/substitute-name plant):
C:\Users\<USER>\AppData\Roaming\Claude\local-agent-mode-sessions\<ACCT>\<ORG>\rpm

Labelled non-fatal, but the install does not complete: the plugin never enters rpm\manifest.json and never appears in the plugins list. If the plugin declares an MCP server, that server may still connect via another path — so it can surface under Connectors while the plugin itself is not installed, which reads as "my plugin turned into a connector".

The named path is not a reparse point

Verified three ways, on the exact path in the error:

| Check | Result |
|---|---|
| Get-Item -Force | Attributes: Directory; LinkType empty; Target empty |
| fsutil reparsepoint query "<path>" | Error: 4390 — not a reparse point |
| cmd /c dir /al on the parent | File Not Found — no links present |

No ancestor of the path is a link either. No script on the machine created one — greps for mklink, New-Item -ItemType SymbolicLink and Junction found only references, never creation.

What it appears to be detecting

The two paths below are the same storage. fsutil file queryfileid returns an identical file ID for both:

C:\Users\<USER>\AppData\Roaming\Claude\...
C:\Users\<USER>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\...

The app logs the mechanism itself at startup:

[MSIX] Filesystem virtualization active — ...LocalCache\Roaming\Claude exists

So a path opened as ...\AppData\Roaming\Claude\... resolves back under a different final name. The guard appears to read that name difference as a planted substitute-name.

This is inferred from the file-ID match plus the app's own log line — the guard itself is minified in app.asar, so its comparison logic was not read directly.

Corroborating symptom: a file written by a process inside the package to %LOCALAPPDATA%\Something\ lands at ...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Something\ and is not visible at the requested path in Explorer. Same redirection, observed independently.

Timing points at the update, not at the disk

From main.log:

2026-08-05 14:42:25  [updater] Version changed since last launch: 1.24012.11 -> 1.25927.0
2026-08-05 14:42:31  first PlantDetectedError

Six seconds apart. Zero occurrences in retained logs from 26/07 to 04/08. A plugin installed successfully at 2026-08-04 18:21:38 under 1.24012.11, with MSIX virtualization already active that day.

Both install routes fail

• Upload via the "+" Personal plugins panel — fails.
• Install from a git marketplace — also fails, identical error and path. Adding the marketplace succeeds (that only registers a source); installing from it does not.

So the guard sits on the step that writes into the plugin store, which both routes share.

Blast radius

• Broken: all plugin installs and updates, and RemotePluginManager periodic store sync — both abort at the same guard.
• Working: already-installed plugins continue to load; MCP servers declared directly in claude_desktop_config.json still start normally.
• Skills are the sharpest loss — plugins are their only delivery mechanism, so no new skill can be added at all. MCP servers have a workaround; skills do not.

Plugin-count readings oscillate 0 → 12 → 10 → 12 during sync, which reads alarmingly like plugin loss and is not.

Environment

• Windows 11 Pro 26200
• Claude desktop app, MSIX-packaged (Claude_pzs8sxrjxfjjc)
• 1.25927.0 — broken. 1.24012.11 — worked.
• 12 plugins installed and loading normally throughout

Expected

A stock MSIX install's own virtualized store should not be classified as a planted junction.

Suggested direction

Resolve the final path before the plant check, or exempt the package's own LocalCache root, so the app's own virtualization is not treated as a redirect. If the check is meant to catch a user-planted link, fsutil reparsepoint query returning 4390 on the flagged path suggests the current signal is the resolved-name difference rather than an actual reparse point.