Windows: native updater resolves install root via HOME while launcher/installer use USERPROFILE - claude update reports success but running binary never updates

Resolved 💬 3 comments Opened Jun 4, 2026 by sixeyes Closed Jun 8, 2026

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 set HOME)
  • 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

  1. Native install in February 2026 placed the binary at C:\Users\<user>\.local\bin\claude.exe (2.1.69) with C:\Users\<user>\.local\share\claude\versions\2.1.69.
  2. Background auto-update ran faithfully for four months — into G:\HomeDir\.local\share\claude\versions\ (e.g. 2.1.160 on 2026-06-02, 2.1.162 on 2026-06-04) and G:\HomeDir\.local\bin\claude.exe.
  3. The launched binary at C:\Users\<user>\.local\bin\claude.exe was never touched. User ran 2.1.69 for four months with no indication anything was wrong.
  4. Running claude update manually from the stale binary prints:

``
Current version: 2.1.69
...
Successfully updated from 2.1.69 to version 2.1.162
`
but
claude --version 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

  1. Inconsistent path resolution — installer/launcher resolve the install root via USERPROFILE; the updater resolves it via HOME. The same product disagrees with itself about where it lives. (Notably, the config dir ~/.claude resolved to USERPROFILE on this machine, so config and updater disagree too.)
  2. False success reportclaude update claims "Successfully updated from X to Y" without verifying that the binary it was launched from (or the one on PATH) actually changed.
  3. 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 update should 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

  1. On Windows, set a machine-wide HOME to anything other than %USERPROFILE% (e.g. setx /M HOME G:\SomeDir).
  2. Install Claude Code via the native installer; note the binary lands under %USERPROFILE%\.local\bin.
  3. Run claude update (or wait for auto-update).
  4. Observe: success message, new version under %HOME%\.local\share\claude\versions\, but claude --version unchanged.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗