[BUG] Native updater rewrites ~/.local/bin/claude as self-referential relative symlink → ELOOP on 2.1.201 (3rd recurrence of #45260, #62822)

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?

Third recurrence of the self-referential relative symlink defect, now on 2.1.201 (native/standalone installer, Linux). Prior reports: #45260 (closed not-planned/stale, not fixed) and #62822 (closed as duplicate of #45260). Both auto-close comments explicitly invited a fresh issue if still relevant — it is.

On version activation, ~/.local/bin/claude was rewritten as a relative, self-referential symlink:

~/.local/bin/claude -> claude/versions/2.1.201

A relative symlink resolves against the directory it lives in (~/.local/bin/), so the target expands to ~/.local/bin/claude/versions/2.1.201. The first path component claude is the symlink itself → resolution loops back through it indefinitely → ELOOP. Every claude invocation afterward fails until repaired by hand.

The binary was placed correctly:

~/.local/share/claude/versions/2.1.201   (251300664 bytes, ELF executable, present and runnable)

Only the symlink is wrong. Correct target is absolute (/home/<user>/.local/share/claude/versions/2.1.201) or, at minimum, ../share/claude/versions/2.1.201. The ../share prefix is being dropped — identical to the mechanism pinned in #45260/#62822, so the defect is still live two versions later.

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 a correct relative path (../share/claude/versions/<version>) that cannot collide with the symlink's own name.

Error Messages/Logs

$ claude -c
zsh: too many levels of symbolic links: claude

$ ~/.local/bin/claude
zsh: too many levels of symbolic links: /home/<user>/.local/bin/claude

$ ls -l ~/.local/bin/claude
lrwxrwxrwx. ... /home/<user>/.local/bin/claude -> claude/versions/2.1.201

Steps to Reproduce

1. Linux, standalone (native) installer — binaries under ~/.local/share/claude/versions/, active version exposed via ~/.local/bin/claude symlink.
2. "installMethod": "native", "autoUpdates": false (this is the on-launch activation path, not background auto-update).
3. Version activated to a newly downloaded build (2.1.201).
4. Result: ~/.local/bin/claude written as relative claude/versions/<version> → ELOOP on next invocation.

Additional Context / Observation

• Config: installMethod: native, autoUpdates: false. The broken link was written by the launcher's on-startup symlink-repair, not the background auto-updater — so the defect is not confined to the auto-update code path.
• At the time of breakage multiple claude sessions were running concurrently (several terminals). Not claimed as root cause — prior repros show plain single activation is sufficient — but flagged as a possible aggravating trigger for the torn symlink swap, given the per-version lock at ~/.local/state/claude/locks/<version>.lock exists to coordinate exactly this.
• Self-heals on the next clean single launch (which rewrites the link absolute), which is likely why it slips past CI and keeps recurring.

Manual repair (workaround)

ln -sfn ~/.local/share/claude/versions/<version> ~/.local/bin/claude

Environment

• OS: Fedora 43, Linux 7.0.12, zsh
• Claude Code: 2.1.201 (native install)
• Related: #45260, #62822 (both closed unfixed; this is the same defect on a newer version)