Windows Store (MSIX) install: bundled Claude Code can never update - anti-tamper check flags MSIX AppData virtualization as a plant (PlantDetectedError)
## Environment
- Claude Desktop: 1.26832.0.0, Microsoft Store install (MSIX package
Claude_pzs8sxrjxfjjc). Also reproduced on the previous build 1.25927.0.0. - OS: Windows 11 Pro, build 10.0.26200
- Bundled Claude Code: stuck at 2.1.217 (current release at time of writing: 2.1.224)
Summary
On a Microsoft Store install, the Desktop app's embedded Claude Code updater ("CCD") fails on every launch with PlantDetectedError and permanently falls back to the last successfully installed version (2.1.217 on this machine). The failure has repeated on every attempt since at least 2026-08-05 and survives app updates. There is no user-visible error; the only symptom is that Code sessions silently run an increasingly outdated version.
The cause appears to be a conflict between the updater's junction/plant detection and MSIX AppData virtualization, which is present on every Store install by design.
Details
MSIX packages virtualize %APPDATA%. Writes by the app to:
C:\Users\<user>\AppData\Roaming\Claude\...
are redirected by Windows to the package container:
C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\...
When CCD downloads a new Claude Code version, its anti-tamper check resolves the target directory AppData\Roaming\Claude\claude-code\<version>, sees the substitute-name redirect created by the OS-level virtualization, classifies it as a planted junction, and aborts:
2026-08-07 18:14:08 [error] [CCD] Download attempt 3/3 failed [PlantDetectedError]:
Private dir leaf redirects (junction/substitute-name plant):
C:\Users\ixs\AppData\Roaming\Claude\claude-code\2.1.222
All 3 download attempts fail identically, the version directory is left behind empty, and the app falls back to 2.1.217. The profile directory now looks like this:
claude-code\2.1.217 -> claude.exe present (in use)
claude-code\2.1.221 -> EMPTY (failed 2026-08-05, app build 1.25927.0.0)
claude-code\2.1.222 -> EMPTY (failed 2026-08-07, app build 1.26832.0.0)
Note the updater already knows it is running from a Store package:
2026-08-07 16:21:28 [info] [updater] MSIX detected: windowsStore=true, appPathMatch=true,
source=windowsStore, exe=C:\Program Files\WindowsApps\Claude_1.26832.0...
so the plant check and the MSIX detection are drawing opposite conclusions about the same redirect.
Full stack trace (from Roaming\Claude\logs\main.log)
2026-08-05 01:54:07 [error] [CCD] Download attempt 1/3 failed [PlantDetectedError]:
Private dir leaf redirects (junction/substitute-name plant):
C:\Users\ixs\AppData\Roaming\Claude\claude-code\2.1.221
at $n (...\app.asar\.vite\build\index.chunk-CK51t2rJ.js:12:14339)
at async er (...\app.asar\.vite\build\index.chunk-CK51t2rJ.js:12:14921)
at async Object.tr (...\app.asar\.vite\build\index.chunk-CK51t2rJ.js:12:15304)
at async ae.downloadBinaryForTarget (...\app.asar\.vite\build\index2.chunk-B-Og44Xu.js:1:11030)
at async ae.prepareForTarget (...\app.asar\.vite\build\index2.chunk-B-Og44Xu.js:1:14711)
at async ae.prepare (...\app.asar\.vite\build\index2.chunk-B-Og44Xu.js:1:22030)
at async Object.prepare (...\app.asar\.vite\build\index.chunk-4MCuNsI1.js:78:39416)
at async ...\app.asar\.vite\build\index.chunk-CeSX0peY.js:1:155192
at async Session.<anonymous> (node:electron/js2c/browser_init:2:119861)
name: 'PlantDetectedError'
Steps to reproduce
- Install Claude Desktop from the Microsoft Store on Windows 11.
- Launch the app and start any Claude Code session.
- Watch
AppData\Roaming\Claude\logs\main.log(or the merged view underLocalCache\Roaming): every launch logs 3/3 failed CCD download attempts withPlantDetectedError. claude-code\<new-version>directories accumulate empty; the session keeps running the old binary.
Expected behavior
The updater should recognize the MSIX VFS redirect as legitimate on Store installs (it already logs windowsStore=true) and either resolve the real LocalCache path before the leaf-redirect check or exempt the package-virtualized profile from junction plant detection.
Additional notes
- Because the check fails identically every launch, Store installs are effectively version-pinned forever; the gap to current will keep widening.
- Easy to misdiagnose: a standalone
claude.exeon PATH answersclaude --versionwith the current version while Desktop sessions actually run the stale binary. Verifying requires checking the parent process chain of a running session. - MSIX layering also means processes inside the container see a merged
Roaming\Claudeview, while outside processes see only a thin outer layer, which may affect any fix that copies profile files.
3 Comments
Confirming this on
1.26832.0.0x64 MSIX (Claude_pzs8sxrjxfjjc) — bundled Claude Code has been unable to update here since Aug 6.claude-code\2.1.222andclaude-code-vm\2.1.222are both 0 bytes,.sdk-versionis still pinned at2.1.219, and[CCD] Falling back to installed version: 2.1.219fires on every start.This issue has no comments yet, but its title is the most accurate framing of the root cause I've seen — the anti-tamper check flagging MSIX AppData virtualization itself. Cross-linking where the evidence has accumulated so people find it:
app.asar, so all these reports are one shared check with many callers, not separate bugs. Also documents two undocumented call sites (auditlogger silently dropping entries,SkillsPlugin).Six distinct subsystems are now blocked by this one guard.
Resolved here by app build
1.28929.0(previously1.26832.0). Since this thread is otherwise quiet and its title is the most accurate framing of the root cause, recording the answer to the question this issue implicitly asks — which build fixes it.The bundled Claude Code updated successfully for the first time since Aug 6:
.sdk-versionadvanced off2.1.219(pinned since Jul 25), both2.1.227installs carry.verified, and the 0-byte2.1.221/2.1.222directories are gone. NoPlantDetectedErrorsince.The check was corrected rather than removed —
"junction/substitute-name plant"still appears 2× in the newapp.asar, same as the old build, butgetVMStorageSubpathnow resolves through to the MSIXLocalCachebacking store instead of flagging the redirect.Full timeline and verification in #84199. No maintainer response arrived on any of the four threads, so anyone still blocked should check Settings for the update rather than reinstalling.
I am seeing what appears to be the same MSIX AppData virtualization false positive in a separate, user-visible component: the Cowork VM SDK updater.
My environment:
Claude_pzs8sxrjxfjjc1.30096.5(6e1346)2026-08-14T21:58:49.000Z1.28929.02.1.2222.1.227The distinction from the original report in this issue is:
Roaming\Claude\claude-codeClaudeCodeManager-VMunderLocal\Claude-3p\claude-code-vmAll three Cowork VM SDK installation attempts fail with:
The logical target:
canonicalizes to:
Claude Desktop simultaneously logs that it recognizes the Store package:
Unlike the regular Code updater failure, this prevents Cowork from starting and continuously displays “Failed to start Claude’s workspace.” The regular Windows Claude Code binary downloads successfully, so this does not appear to be a general network failure.
The Cowork-specific report in #84841 is currently closed, but the problem remains reproducible after the application updated to
1.30096.5.Could the Cowork VM SDK path be included in the investigation and fix for this issue, or could #84841 be reopened and linked here?