[BUG] Auto-updater rewrites ~/.local/bin/claude as self-referential relative symlink → ELOOP (recurrence of #45260, on 2.1.152)

Resolved 💬 2 comments Opened May 27, 2026 by jphein Closed May 31, 2026

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

  1. Linux, standalone (native) installer — binaries under ~/.local/share/claude/versions/, active version exposed via ~/.local/bin/claude symlink.
  2. Have a newer version pre-downloaded (mine: 2.1.152 downloaded the prior evening).
  3. Launch claude, triggering the updater to activate the new version.
  4. The activation rewrites ~/.local/bin/claude to claude/versions/<version> (relative, self-referential).
  5. Any subsequent claude call — or any script resolving claude on PATH — fails with ELOOP.

Timeline evidence on my machine:

  • ~/.local/share/claude/versions/2.1.152 binary mtime: 2026-05-26 18:10 (downloaded fine).
  • ~/.local/bin/claude symlink mtime AND ~/.local/state/claude/locks mtime: 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

View original on GitHub ↗

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