[BUG] Auto-updater rewrites ~/.local/bin/claude as self-referential relative symlink → ELOOP (recurrence of #45260, on 2.1.152)
Preflight Checklist
- [x] I have searched existing issues
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
The standalone auto-updater rewrites ~/.local/bin/claude as a self-referential relative symlink when it activates a new version, producing an infinite symlink loop (OSError: [Errno 40] Too many levels of symbolic links). Every claude invocation after the update fails with command not found / ELOOP until the symlink is repaired by hand.
This is the same defect previously reported in #45260 (closed 2026-05-22 as stale/inactive, not fixed; the auto-close comment invited a fresh issue). I am re-filing with current evidence on 2.1.152.
Observed link after a version activation:
~/.local/bin/claude -> claude/versions/2.1.152
Because a relative symlink resolves against the directory the symlink lives in (~/.local/bin/), that target expands to ~/.local/bin/claude/versions/2.1.152 — and the first path component claude is the symlink itself, so resolution loops back through it indefinitely → ELOOP.
The correct target is the binary the updater had already downloaded to the right place:
~/.local/share/claude/versions/2.1.152 (239 MB, executable, present and runnable)
So the relative link should have been ../share/claude/versions/2.1.152 (or, more robustly, an absolute path). The ../share prefix is being dropped.
Note vs #45260: in that report the updater also wrote binaries into $CWD/claude/versions/. In my case the binary was placed correctly in ~/.local/share/claude/versions/ — only the symlink was written in the broken relative form. This indicates the broken-symlink defect is independent of the stray-directory defect and still present.
What Should Happen?
On version activation the updater should write ~/.local/bin/claude as an absolute path (/home/<user>/.local/share/claude/versions/<version>), or at minimum a correct relative path (../share/claude/versions/<version>) that does not collide with the symlink's own name.
Error Messages/Logs
$ claude
bash: claude: command not found
# realmwatch update script invoking claude in a subprocess:
OSError: [Errno 40] Too many levels of symbolic links: 'claude'
Steps to Reproduce
- Linux, standalone (native) installer — binaries under
~/.local/share/claude/versions/, active version exposed via~/.local/bin/claudesymlink. - Have a newer version pre-downloaded (mine: 2.1.152 downloaded the prior evening).
- Launch
claude, triggering the updater to activate the new version. - The activation rewrites
~/.local/bin/claudetoclaude/versions/<version>(relative, self-referential). - Any subsequent
claudecall — or any script resolvingclaudeon PATH — fails with ELOOP.
Timeline evidence on my machine:
~/.local/share/claude/versions/2.1.152binary mtime: 2026-05-26 18:10 (downloaded fine).~/.local/bin/claudesymlink mtime AND~/.local/state/claude/locksmtime: 2026-05-27 05:41 — same instant, i.e. the next launch's updater-lock activation is what wrote the broken link. An earlier launch on 2.1.150 worked; the 05:41 activation broke it.
Workaround
ln -sfn ~/.local/share/claude/versions/<version> ~/.local/bin/claude
(Absolute target is loop-immune, but is overwritten again on the next broken activation.)
Is this a regression?
Recurrence of #45260, which was closed inactive rather than fixed. Still reproduces on 2.1.152.
Claude Code Version
2.1.152
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux (kernel 6.17)
Terminal/Shell
bash
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗