claude install <version> reports success and a false Location when the launcher is not the installer's symlink
What's Wrong?
claude install <version> reports success, prints the requested version, and printsLocation: ~/.local/bin/claude — while leaving that launcher completely untouched — whenever~/.local/bin/claude is not the native installer's own symlink into ~/.local/share/claude/versions/.
Exit code is 0. Nothing in the output indicates the launcher was skipped. The Location: line is
actively false: it names a path that still runs a different build.
This is not the glibc 2.44 startup segfault (#89412 / #89427 / #89420). It is a separate defect in
the installer's reporting, and it is what makes recovery from that segfault silently fail.
Reproduction
Native install present, with several builds on disk:
~/.local/share/claude/versions/
├── 2.1.240
├── 2.1.241
└── 2.1.245
1. Make the launcher something other than the installer's symlink (a wrapper script — this is a
common shape for anyone who has ever hand-rolled the launcher, and is what a recovery attempt can
leave behind):
rm ~/.local/bin/claude
printf '#!/bin/sh\nexec %s "$@"\n' "$HOME/.local/share/claude/versions/2.1.245" > ~/.local/bin/claude
chmod +x ~/.local/bin/claude
2. Ask the installer for a different version:
~/.local/share/claude/versions/2.1.241 install 2.1.241
3. Observed output — exit code 0:
Checking installation status...
Installing Claude Code native build 2.1.241...
Setting up launcher and shell integration...
✔ Claude Code successfully installed!
Version: 2.1.241
Location: ~/.local/bin/claude
Next: Run claude --help to get started
4. Actual state afterwards — the launcher was never touched:
$ cat ~/.local/bin/claude
#!/bin/sh
exec /home/josh/.local/share/claude/versions/2.1.245 "$@"
$ claude --version
2.1.245 (Claude Code)
It claims to have installed 2.1.241 at ~/.local/bin/claude, and ~/.local/bin/claude runs
2.1.245.
Control (the same command works correctly in the other case)
With ~/.local/bin/claude as the installer's own symlink into versions/, the same command behaves
properly and repoints it:
$ readlink -f ~/.local/bin/claude
/home/josh/.local/share/claude/versions/2.1.245
$ claude install 2.1.241 # exit 0
$ readlink -f ~/.local/bin/claude
/home/josh/.local/share/claude/versions/2.1.241
$ claude --version
2.1.241 (Claude Code)
So the defect is specific to a launcher that is not the installer's symlink. Both runs report success
identically; only one of them did anything.
What Should Happen?
Either:
- Update the launcher at
Location:as the output claims, or - Fail loudly — non-zero exit and an explicit message that
~/.local/bin/claudealready exists,
is not installer-managed, and was left alone. Suggest --force.
At minimum, the Version: line should report what the launcher now runs, not what was requested,
and Location: should not name a path the installer declined to modify.
Why this matters
This turns a recoverable incident into an unrecoverable-looking one. During the 2.1.243 startup
segfault on glibc 2.44, the documented recovery is to install a known-good build. Doing exactly that
printed ✔ Claude Code successfully installed! Version: 2.1.241 and returned 0 — and every
subsequent claude invocation still ran 2.1.243 and still segfaulted:
06:02:50 ~/.local/share/claude/versions/2.1.241 install 2.1.241 ← reported success
06:03:01 claude --version ← still SIGSEGV in 2.1.243
The user reasonably concluded the pin had not worked, or that 2.1.241 was also broken. The only thing
that reveals the truth is readlink -f ~/.local/bin/claude, which nobody thinks to run when the
installer just said it succeeded. Recovery required deleting the launcher by hand and recreating the
symlink.
A silent skip is the worst option here precisely because the command is most often reached for when
the current build is broken.
Environment
| | |
|---|---|
| OS | CachyOS Linux (rolling) |
| Kernel | 7.2.0-1-cachyos |
| glibc | 2.44 |
| node | v26.7.0 |
| Arch | x86-64 |
| Claude Code | 2.1.245 installed; repro invoked via the 2.1.241 binary |
| Install type | native |
claude install --help offers only --force and -h; there is no flag that means "update the
launcher but do not reinstall", and no way to ask what the launcher currently points at.