[BUG] Desktop app rejects UNC paths for its own private dirs (PLANT_UNC): Claude Code binary updates and session saving permanently broken on domain PCs with AppData Folder Redirection

Status Open
Reported on v2.1.293
Maintainer reply None cached
Activity 0 comments · opened Oct 9, 2026

Environment

  • Claude Desktop (Microsoft Store / MSIX) 2.26454.2.0 on Windows 11 Pro (build 26200)
  • Active Directory domain with a Folder Redirection GPO redirecting AppData\Roaming to a file server: \\fileserver\FolderRedirect\<username>
  • Affects every user on every PC in the organization with this (very common enterprise) GPO. Reproduced on multiple machines/users since ~mid-August 2026; still present today with the latest Desktop app.

Description

Since roughly mid-August 2026 the Desktop app refuses UNC paths for its private directories (the anti reparse-planting check, PlantDetectedError / PLANT_UNC). On machines where %APPDATA% legitimately is a UNC path because of the Folder Redirection GPO, this permanently breaks three things:

  1. Claude Code binary download/update — every download fails at mkdir into %APPDATA%\Claude\claude-code\<version> with PLANT_UNC. Users stay frozen on whatever binary is already cached, until a model raises the minimum version and the Code tab dies with claude_code_version_too_old. The version folders pile up as empty stubs (we currently have 20+ empty 2.1.xxx folders next to the one working binary).
  2. claude-code-vm prefetch — same failure on %APPDATA%\Claude\claude-code-vm\<version>.
  3. Session saving — every Code session fails to persist: writeSessionToDisk → ensureStorageDir on %APPDATA%\Claude\claude-code-sessions\... throws PLANT_UNC. Sessions are silently lost on every restart. This one has no workaround at all.

Note this is not the user picking a network folder as a workspace: it's the app's own internal storage, placed under roaming AppData, whose location is dictated by domain GPO and outside the user's control. Reinstalling changes nothing.

Log excerpts (%LOCALAPPDATA%\Claude\logs\main.log, 2026-10-09)

Binary download (3/3 attempts fail, every version):

[error] [CCD] Download attempt 3/3 failed at mkdir (PLANT_UNC) [PlantDetectedError]: Private dir chain refused pre-canonicalization (reparse plant?): \\fileserver\FolderRedirect\jdoe\AppData\Roaming\Claude\claude-code\2.1.293 — UNC path not allowed: \\fileserver\FolderRedirect\jdoe\AppData\Roaming\Claude\claude-code\2.1.293
[error] [ClaudeCodeManager-VM] Download attempt 3/3 failed at mkdir (PLANT_UNC) [PlantDetectedError]: Private dir chain refused pre-canonicalization (reparse plant?): \\fileserver\FolderRedirect\jdoe\AppData\Roaming\Claude\claude-code-vm\2.1.293 — UNC path not allowed: ...
[info]  [ClaudeCodeManager-VM] Prefetch of 2.1.293 not ready (download failed at mkdir: PLANT_UNC)

Session saving:

[error] Failed to save session local_60a55b5c-...: Private dir chain refused pre-canonicalization (reparse plant?): \\fileserver\FolderRedirect\jdoe\AppData\Roaming\Claude\claude-code-sessions\86c98bc5-...\b9ff7bc9-... — UNC path not allowed: ...
    at async e.ensureStorageDir (...index.chunk-CFhdElXw.js:1:1199335)
    at async e.writeSessionToDisk (...index.chunk-CFhdElXw.js:1:1220758)

Workaround we currently use (binary only)

The app refuses to download onto a UNC path but happily runs a binary that is already there. So we manually copy the standalone native CLI binary (installed via irm https://claude.ai/install.ps1 | iex, which lands on a local path) into %APPDATA%\Claude\claude-code\<version>\claude.exe and write a .verified file containing its lowercase sha256 next to it. The app accepts the marker and logs Using Claude Code binary at: ...\<version>\claude.exe. We re-run this for every new minimum version. There is no equivalent workaround for session saving.

Suggested fix

Store the app's machine-local private data — claude-code binaries, claude-code-vm, and claude-code-sessions — under %LOCALAPPDATA% instead of %APPDATA% (roaming), with a one-time migration. Roaming AppData is by definition subject to redirection/sync in domain environments; a 250 MB per-version binary and per-machine session state don't belong there anyway. Alternatively, the plant check could canonicalize and allowlist the user's own redirected profile path (SHGetKnownFolderPath(FOLDERID_RoamingAppData)), which is not attacker-controlled.

Related

  • #76251 (same root cause for Cowork/local-agent sessions on redirected AppData — closed as stale with no response)
  • #37754 (AppData redirected to a different drive letter)

View original on GitHub ↗