[BUG] Native installer does not add ~/.local/bin to PATH on Pop!_OS, despite reporting success

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Running the official native installer (curl -fsSL https://claude.ai/install.sh | bash) completes successfully and prints "✅ Installation complete!", but does not add ~/.local/bin to PATH via ~/.bashrc or any other shell startup file. As a result, claude is not resolvable in any terminal session after install, including new terminals.

I confirmed:

• The binary is correctly downloaded, verified, and placed at ~/.local/share/claude/versions/<version> (executable, correct architecture, runs fine when invoked by full path).
• The symlink at ~/.local/bin/claude is correctly created and points to the right binary.
• ~/.bashrc was not modified by the installer at all — grep -n "PATH" ~/.bashrc and grep -n "local/bin" ~/.bashrc both returned nothing before I added the export line manually.
• ~/.bashrc itself is a completely stock, unmodified Debian/Ubuntu default (verified line by line) — nothing unusual that would explain a shell-detection failure.
• I have installed Claude Code via this same native installer on other Linux distributions previously without this problem, so this does not appear to be a universal failure of the installer's shell-integration step.

I inspected install.sh directly. It contains no PATH/rc-file logic itself — it downloads the binary, verifies its checksum, then delegates all shell integration to the binary's own subcommand ("$binary_path" install). So the bug is very likely inside that compiled subcommand's shell-detection logic, not in the public shell script.

I also have Claude Desktop (.deb package) installed on the same machine and initially suspected interference, but ruled it out: Desktop and the CLI installer use entirely separate binaries and installation paths, and nothing in install.sh references or checks for Desktop's presence.

What Should Happen?

After the installer reports "Installation complete," claude should be resolvable in a new terminal session without any manual PATH edits. If the install subcommand's shell-detection logic can't determine where to add the PATH entry, it should say so explicitly (e.g. "Could not detect shell config file, add this to your PATH manually: ...") rather than reporting unconditional success while silently skipping that step.

Error Messages/Logs

Steps to Reproduce

1. Fresh Pop!_OS 24.04 LTS system, stock ~/.bashrc (unmodified Debian/Ubuntu default).
2. Run: curl -fsSL https://claude.ai/install.sh | bash
3. Script completes and prints "✅ Installation complete!"
4. Open a new terminal (also tried source ~/.bashrc and hash -r in the same terminal — neither helped, because the PATH entry was never added in the first place).
5. Run: claude --version
6. Result: claude: command not found

Verification steps that isolated the cause:

• ls -la ~/.local/bin/claude → symlink exists, points to ~/.local/share/claude/versions/2.1.212
• ls -la ~/.local/share/claude/versions/2.1.212 → file exists, -rwxr-xr-x, 264096568 bytes
• /home/renato/.local/share/claude/versions/2.1.212 --version → "2.1.212 (Claude Code)" (binary itself works fine)
• echo $PATH → no ~/.local/bin entry present
• grep -n "PATH" ~/.bashrc and grep -n "local/bin" ~/.bashrc → both empty, before manual fix
• Manually running echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc immediately fixed the issue

Claude Model

Other

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.212

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Relevant excerpt from install.sh confirming the shell script itself has no PATH logic:

chmod +x "$binary_path"
echo "Setting up Claude Code..."
"$binary_path" install ${TARGET:+"$TARGET"} || install_code=$?

All shell/PATH integration is delegated to the compiled install subcommand, which is not open source, so I can't inspect its detection logic directly. Happy to run additional diagnostics if a maintainer wants specific output.