Windows: native updater resolves install root via HOME while launcher/installer use USERPROFILE - claude update reports success but running binary never updates
Environment
- OS: Windows 11 Pro (10.0.26200)
- Install method: native installer (February 2026)
- Affected version: 2.1.69 (stuck); updater targets 2.1.162
- Key environment variable: machine-wide
HOME=G:\HomeDir(set for MKS Toolkit; same situation arises with Cygwin/MSYS2/corporate images that setHOME) USERPROFILE=C:\Users\<user>(standard)
Summary
On Windows machines where HOME is set and differs from USERPROFILE, the native auto-updater installs every update under %HOME%\.local\share\claude\, while the binary the user actually launches lives under %USERPROFILE%\.local\bin\claude.exe. The result is a permanent split-brain: updates "succeed" forever into a tree nothing runs from, and the launched binary stays frozen at its install-day version.
What happened
- Native install in February 2026 placed the binary at
C:\Users\<user>\.local\bin\claude.exe(2.1.69) withC:\Users\<user>\.local\share\claude\versions\2.1.69. - Background auto-update ran faithfully for four months — into
G:\HomeDir\.local\share\claude\versions\(e.g.2.1.160on 2026-06-02,2.1.162on 2026-06-04) andG:\HomeDir\.local\bin\claude.exe. - The launched binary at
C:\Users\<user>\.local\bin\claude.exewas never touched. User ran 2.1.69 for four months with no indication anything was wrong. - Running
claude updatemanually from the stale binary prints:
```
Current version: 2.1.69
...
Successfully updated from 2.1.69 to version 2.1.162
claude --version
but still reports **2.1.69** afterwards. Debug log shows where it actually went:`
``
[DEBUG] Checking for native installer update to version 2.1.162
[DEBUG] Force reinstalling native installer version 2.1.162
[DEBUG] Atomically installed binary to G:\HomeDir\.local\share\claude\versions\2.1.162
[DEBUG] Successfully updated to version 2.1.162
Three distinct defects
- Inconsistent path resolution — installer/launcher resolve the install root via
USERPROFILE; the updater resolves it viaHOME. The same product disagrees with itself about where it lives. (Notably, the config dir~/.clauderesolved toUSERPROFILEon this machine, so config and updater disagree too.) - False success report —
claude updateclaims "Successfully updated from X to Y" without verifying that the binary it was launched from (or the one onPATH) actually changed. - No drift detection — the running 2.1.69 binary happily coexisted for months alongside a 2.1.16x tree it had itself installed, without any warning like "you are running from a location the updater does not manage."
Expected
- Updater, installer, and launcher agree on a single install root regardless of
HOME. - If the updater installs to a location different from the running binary's location,
claude updateshould say so loudly instead of reporting success. claude doctor/ startup should detect that the running binary's path is not the updater's target path.
Repro
- On Windows, set a machine-wide
HOMEto anything other than%USERPROFILE%(e.g.setx /M HOME G:\SomeDir). - Install Claude Code via the native installer; note the binary lands under
%USERPROFILE%\.local\bin. - Run
claude update(or wait for auto-update). - Observe: success message, new version under
%HOME%\.local\share\claude\versions\, butclaude --versionunchanged.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗