[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
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\Roamingto 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:
- Claude Code binary download/update — every download fails at
mkdirinto%APPDATA%\Claude\claude-code\<version>withPLANT_UNC. Users stay frozen on whatever binary is already cached, until a model raises the minimum version and the Code tab dies withclaude_code_version_too_old. The version folders pile up as empty stubs (we currently have 20+ empty2.1.xxxfolders next to the one working binary). claude-code-vmprefetch — same failure on%APPDATA%\Claude\claude-code-vm\<version>.- Session saving — every Code session fails to persist:
writeSessionToDisk→ensureStorageDiron%APPDATA%\Claude\claude-code-sessions\...throwsPLANT_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)