[BUG] Local `.mcpb` extension install fails on MSIX build with "Private dir leaf redirects (junction/substitute-name plant)" — no actual reparse point present

Same check, different call sites — and I think this pins down the mechanism, including why no reparse point is ever found.

Environment: Claude Desktop 1.25927.0.0, arm64 MSIX (Claude_pzs8sxrjxfjjc), Windows 11 Pro 25H2 build 26200. So it is not x64-specific. Feature affected here is Cowork, not extension install — same guard though.

Why there is no reparse point: there genuinely isn't one

MSIX AppData virtualization is a filter-driver bind mapping. It is invisible to Get-Item -Force (Attributes = Directory, no ReparsePoint flag), invisible to fsutil reparsepoint query and to dir /AL — but it is visible to GetFinalPathNameByHandle. Measured from a plain, non-packaged PowerShell process:

| input path | resolved final path |
|---|---|
| C:\Users\<u>\AppData\Roaming | same |
| C:\Users\<u>\AppData\Roaming\Claude | same |
| …\Roaming\Claude\local-agent-mode-sessions | same |
| …\Roaming\Claude\pending-uploads | \\?\C:\Users\<u>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\pending-uploads |
| …\local-agent-mode-sessions\<space>\<project>\local_<GUID>\.claude | \\?\…\LocalCache\Roaming\Claude\…\local_<GUID>\.claude |

The parents resolve to themselves and only the leaf redirects — which is literally what the error message describes. fsutil file queryfileid returns the identical file ID (0x…01710000000026b3) for both %APPDATA%\Claude and …\LocalCache\Roaming\Claude: one object reachable under two names.

Minimal demonstration:

Add-Type -TypeDefinition @"
using System;using System.Runtime.InteropServices;using System.Text;
public class FP {
 [DllImport("kernel32.dll",SetLastError=true,CharSet=CharSet.Unicode)]
 public static extern IntPtr CreateFileW(string n,uint a,uint s,IntPtr sa,uint c,uint f,IntPtr t);
 [DllImport("kernel32.dll",SetLastError=true,CharSet=CharSet.Unicode)]
 public static extern uint GetFinalPathNameByHandleW(IntPtr h,StringBuilder b,uint c,uint f);
 public static string Final(string p){
   IntPtr h=CreateFileW(p,0,7,IntPtr.Zero,3,0x02000000,IntPtr.Zero);
   var b=new StringBuilder(1024); GetFinalPathNameByHandleW(h,b,1024,0); return b.ToString(); }
}
"@
[FP]::Final("$env:APPDATA\Claude\pending-uploads")

This also covers the "target folder doesn't exist yet" case

A directory created fresh at %APPDATA%\Claude\zz-test by a non-packaged process immediately resolves to …\LocalCache\Roaming\Claude\zz-test. So the redirect is not a leftover of anything the user did, and there is no user-side fix — deleting the folder and letting the app recreate it reproduces the identical state. (Also relevant to #48362, where a manually planted junction was tried as a workaround and did not change the resolved path.)

Impact is wider than extension install

Same guard, four call sites. Counts from a single main.log over 29 hours, 1160 occurrences total:

| count | log entry | path | severity |
|---:|---|---|---|
| 1120 | [audit] logger init failed — dropping entries | …\local-agent-mode-sessions\<space>\<project>\local_<GUID> | audit entries silently dropped in every session |
| 16 | Session initialization failed for local_<GUID> | …\local_<GUID>\.claude | fatal — the conversation is permanently unusable |
| 18 | (same guard) | …\<space>\<project>\rpm | plugin directory |
| 6 | Failed to save pasted file | …\Claude\pending-uploads | pasting a file into chat fails |

The fatal one surfaces in the UI as the generic "Something went wrong / You can restart the conversation from an earlier message" panel; Try again reproduces it every time and the conversation cannot be recovered.

2026-08-06 14:29:54 [error] Session initialization failed for local_<GUID>:
Private dir leaf redirects (junction/substitute-name plant):
C:\Users\<u>\AppData\Roaming\Claude\local-agent-mode-sessions\<space>\<project>\local_<GUID>\.claude
{ name: 'PlantDetectedError', code: undefined,
  stack: 'PlantDetectedError: …
    at $n (…\app.asar\.vite\build\index.chunk-CK51t2rJ.js:12:14339)
    at async er (…\index.chunk-CK51t2rJ.js:12:14674)
    at async Object.tr (…\index.chunk-CK51t2rJ.js:12:15304)' }

Regression window

| time | event |
|---|---|
| 2026-08-05 08:16:02 | first log line referencing Claude_1.25927.0.0_arm64 (update applied) |
| 2026-08-05 10:56:07 | first PlantDetectedError, on …\Claude\pending-uploads |

Zero occurrences in any earlier log file, covering 1.18286 → 1.24012.11.0. Last known good version is therefore 1.24012.11.0.

Suggested fix

Resolve the expected path through the same API before comparing, instead of comparing a raw path string against a resolved one — or treat the package's own …\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\… prefix as equivalent to %APPDATA%\Claude\…. On an MSIX build every path this guard protects redirects unconditionally, so as written it can only produce false positives there.

One warning worth adding for anyone who hits this: Cowork session data physically lives inside the package's LocalCache, so "reinstall the app" is both ineffective (Windows builds are MSIX-only now, per the deployment docs) and destructive — uninstalling the MSIX deletes the session history.

Hit this exact error today — same Claude Desktop version (1.25927.0.0), same Package Family Name (Claude_pzs8sxrjxfjjc), same "no reparse point anywhere in the chain" result you found. Wanted to share the root cause, since I think I tracked down what's actually happening.

The real, physical backing store for Claude's private data is not at the literal %APPDATA%\Claude path — it's at:

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

I confirmed this directly: that path contains all the live app data (Claude Extensions, logs, everything), while the literal %APPDATA%\Claude path — as seen by any process without the app's MSIX package identity (Explorer, a manually-opened PowerShell/cmd window) — is effectively empty. This is Windows' standard MSIX/Desktop Bridge AppData compatibility redirect: any process carrying the package's identity token gets its access to the legacy path silently redirected to that LocalCache location by a filesystem filter driver. No on-disk reparse point is involved, which is exactly why nobody can find one — the virtualization happens at the filter-driver level based on process identity, not a reparse tag.

The PlantDetectedError check appears to resolve a private directory's final/real path and compare it against the path it expected, throwing if they diverge — presumably meant to catch an actual malicious pre-planted junction. It can't distinguish that from Windows' own legitimate MSIX redirect, since both produce the same symptom: resolved path ≠ requested path.

This also matches #68688's "[MSIX] Filesystem virtualization active" log line — I think these are the same underlying issue surfacing through two different code paths (a silent no-op there, a hard-thrown PlantDetectedError here).

Additional data point: I hit the identical error via a second, unrelated trigger — pasting a file directly into a chat message, which fails the same way against a different private directory (pending-uploads). So this isn't specific to .mcpb/extension installs — it's a general failure of whatever check validates Claude Desktop's private directories on MSIX builds. Also worth noting: two extensions installed successfully for me on this exact same app version three days before this became consistently reproducible, so this may be non-deterministic rather than a hard 100%-of-the-time failure, or there was a state change in between (I don't have visibility into what).

Suggested fix direction: have the safety check account for the known MSIX package-identity redirect (e.g., treat the LocalCache\Packages backing path as a valid resolved target) rather than treating any resolved-path divergence as an attack.

Same false positive on the same build, but hitting a different code path: the Cowork sandbox VM fails to start entirely.

Environment:

• Claude Desktop 1.25927.0.0, MSIX package Claude_pzs8sxrjxfjjc, install location C:\Program Files\WindowsApps\Claude_1.25927.0.0_x64__pzs8sxrjxfjjc
• Windows 11 x64

Symptom: Every Cowork session reports "Workspace unavailable. The isolated Linux environment failed to start." The user-facing error claims a network problem, but the logs show the same plant check firing:

%APPDATA%\Claude\logs\main.log:

[error] [ClaudeCodeManager-VM] Download attempt 3/3 failed J [PlantDetectedError]:
Private dir leaf redirects (junction/substitute-name plant):
C:\Users\<user>\AppData\Roaming\Claude\claude-code-vm\2.1.221
    at async ae.downloadBinaryForTarget (...)
[error] [ClaudeCodeManager-VM] All download attempts failed

%APPDATA%\Claude\logs\cowork_vm_node.log:

[error] [VM:steps] download_and_sdk_prepare failed (3054ms): Download failed.
Check your internet connection and try again.

Evidence it's a false positive:

1. fsutil reparsepoint query on ...\claude-code-vm\2.1.221 returns "not a reparse point"; Get-Item -Force shows no LinkType on any path component from C:\Users down to the leaf.
2. Network is fine (HEAD request to claude.ai returns 200 from the same machine).
3. GetFinalPathNameByHandle on the flagged directory resolves to

C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-vm\2.1.221
— i.e. the check is flagging MSIX filesystem virtualization's own redirect of %APPDATA%, not an attacker-controlled junction. This seems structural for any MSIX install of this build (possibly related to #68688).

1. Regression window: Claude Code binary 2.1.219 downloaded fine on Jul 24; downloads of 2.1.221 have failed since ~Aug 3, so the strict check appears to have been introduced with a recent app update.

Impact: All shell-dependent Cowork features are unavailable; file tools still work. No user-side workaround found — the redirect is inherent to MSIX virtualization, so the check will fire on every retry.

Suggested fix: whitelist the package's own LocalCache\Roaming redirect (compare against the virtualized final path, not the logical %APPDATA% path) before treating a substitute name as a plant.

Hitting the same false positive today, on a Kapture Directory install specifically (community MCP extension for browser automation).

Environment: Claude Desktop 1.26832.0.0, MSIX package Claude_pzs8sxrjxfjjc (x64), Windows 11 Pro.

Symptom:

Failed to install extension
The extension could not be installed due to the following error: Private dir leaf redirects
(junction/substitute-name plant): C:\Users\<user>\AppData\Roaming\Claude\Claude Extensions

Confirmed same false positive: checked every path component from C:\Users\<user> down through ...\AppData\Roaming\Claude\Claude Extensions with Get-Item -Force and fsutil reparsepoint query — no reparse point anywhere in the chain. The real backing store resolves to ...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\Claude Extensions, which already holds 3 successfully-installed extensions (filesystem, pdf-server-mcp, desktopcommandermcp) — so this isn't a hard 100%-of-the-time failure, consistent with @freemanjc's note above.

Notable data point: confirms the bug is still present on 1.26832.0.0, a build newer than the 1.25927.0.0 referenced above — so whatever regression introduced this hasn't been fixed as of this version.

Workaround found (Code tab only): Kapture's MCP server (npx -y kapture-mcp@latest bridge) can be registered directly via Claude Code's own mcpServers config instead of going through the Directory installer, which sidesteps this guard entirely. No equivalent workaround exists for the Chat tab — the current Claude Desktop build no longer exposes a manual mcpServers config to route around the Directory installer.

Same error after eliminating every possible junction in the chain. My profile was originally on D:\Users\rhyss with C:\Users\rhyss as a directory junction to it (%APPDATA% resolved through the junction). Suspecting the junction as the cause, I did a full profile migration: robocopied the profile to real storage at C:\Users\rhyss, removed the junction entirely, and updated HKLM\...\ProfileList\<SID>\ProfileImagePath to point at C: directly. Confirmed via Get-Item -Force that no reparse point exists anywhere in the path chain post-migration.

Retried the install — identical error, now referencing the fully real path:

Failed to install extension
The extension could not be installed due to the following error: Private dir leaf redirects (junction/substitute-name plant): C:\Users\rhyss\AppData\Roaming\Claude\Claude Extensions

The target folder doesn't exist prior to the failed install attempt (confirmed via Get-Item ... -ErrorAction SilentlyContinue returning nothing). This rules out junctions entirely as a cause on my end — whatever's triggering the "leaf redirects" check, it's a false positive independent of any actual reparse point in the resolved path.

Following @machdat's comment above reporting the Cowork VM variant of this same guard — I have the same failure, plus evidence that every report of this error across the tracker is one single check, and two call sites not yet documented anywhere.

Environment: Claude Desktop 1.26832.0.0 x64 MSIX (Claude_pzs8sxrjxfjjc), Windows 11 Home 26200, personal non-domain machine — i.e. the same build @ProxyLandLLC confirmed on, newer than the 1.25927.0.0 this issue was filed against.

These are not separate bugs — the string is defined once in the shipped bundle

I searched the packaged application code for the error text:

C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc\app\resources\app.asar   (37.8 MB)
matches for "junction/substitute-name plant":  2

Two matches in the entire 37.8 MB bundle. Whether that's one definition plus a duplicate across chunks, every subsystem below is funnelling into the same check — so this is one guard with many callers, not a family of independent bugs. Consolidating them under one fix should be safe.

Call sites confirmed so far, across this tracker and my own logs:

| Subsystem | Symptom | Reported in |
|---|---|---|
| .mcpb extension install | install fails, visible error | this issue |
| plugin install | install fails | #84249 |
| CCD (bundled binary update) | Claude Code can never update | #84865 |
| ClaudeCodeManager-VM | Cowork VM won't start | #84841 (closed), @machdat above |
| SkillsPlugin | new below | — |
| audit | new below | — |

New call site 1 — the audit logger fails to initialize and discards entries

[error] [audit] logger init failed — dropping entries
  { storageDir: '%APPDATA%\Claude\local-agent-mode-sessions\<session>\<sub>\local_<id>',
    error: 'Private dir leaf redirects (junction/substitute-name plant): <same path>' }

2,320 occurrences in my log, and all 2,320 carry this same plant error — no other cause of audit-logger init failure appears at all. It was the largest single bucket on Aug 10 (1,146), rivalling the SDK download failures (1,188).

The wording is the concern: entries are not queued or retried, they are dropped. On MSIX installs the audit log is currently not being written, and the only trace is a line in main.log. Nothing surfaces to the user. Whatever this log exists for — support diagnostics, enterprise accountability — it is silently absent on this install class, which makes it a different severity from a failed install the user can see and retry.

New call site 2 — built-in skills can't be written to disk

[warn] [SkillsPlugin] Failed to write built-in skill "explain-usage":
  Private dir leaf redirects (junction/substitute-name plant):
  %APPDATA%\Claude\local-agent-mode-sessions\skills-plugin\<id>

Logged at warn, no user-facing error — the skill simply isn't there.

Status note

The VM-SDK variant (#84841) was closed as completed on 2026-08-10 18:44 UTC with no referenced fix; it reproduced on my machine 4 minutes 26 seconds later and 214 more times in the following 2h52m, continuing past local midnight. I don't think that closure should be read as this class of bug being resolved — this issue and #84865 are still the live ones.

Daily PlantDetectedError counts here since onset: Aug 7 — 1,336 · Aug 8 — 380 · Aug 9 — 476 · Aug 10 — 2,446.

I have no view on the right fix; @machdat's suggestion above (compare the resolved final path against the package's own LocalCache\Roaming redirect before treating a substitute name as a plant) matches what the evidence shows.