Summary
Claude Code's own installer places the binary in ~/.local/bin. However, the shell snapshot mechanism writes a hardcoded export PATH=... at the end of the snapshot file that is sourced for every Bash tool invocation. This snapshot PATH is derived from the launch-time process environment — not from the user's shell config — so user-level PATH additions (including ~/.local/bin) are silently dropped.
The result: Claude Code warns at every startup that ~/.local/bin is not in PATH, even though the user is successfully running the binary that lives there.
Steps to reproduce
- Install Claude Code via the native installer (places binary in
~/.local/bin)
- Add
~/.local/bin to PATH in ~/.zshrc or ~/.zshenv (as the warning suggests)
- Restart Claude Code
- Warning persists — inspect
~/.claude/shell-snapshots/*.sh and note the final export PATH=... line does not include ~/.local/bin
Root cause
~/.claude/shell-snapshots/*.sh ends with a hardcoded export PATH= line appended by Claude Code after shell capture. This line overwrites the PATH set by the user's shell config (~/.zshrc, ~/.zshenv, ~/.zprofile). Only paths present in /etc/paths or /etc/paths.d/ (macOS system-level) survive, because path_helper runs before any user shell config.
Impact
- Users are told to fix their
~/.zshrc — but fixing it has no effect
- The only working fix is a system-wide
sudo tee /etc/paths.d/local-bin — an elevated change that should never be required for a user-space tool
- Every restart shows the warning, eroding trust in the install
Expected behavior
Either:
- The snapshot PATH generation should include
~/.local/bin when the installer placed the binary there, or
- The startup warning should be suppressed if the binary was successfully found and launched (i.e., it IS reachable via the user's PATH, just not via the snapshot PATH)
Environment
Summary
Claude Code's own installer places the binary in
~/.local/bin. However, the shell snapshot mechanism writes a hardcodedexport PATH=...at the end of the snapshot file that is sourced for every Bash tool invocation. This snapshot PATH is derived from the launch-time process environment — not from the user's shell config — so user-level PATH additions (including~/.local/bin) are silently dropped.The result: Claude Code warns at every startup that
~/.local/binis not in PATH, even though the user is successfully running the binary that lives there.Steps to reproduce
~/.local/bin)~/.local/binto PATH in~/.zshrcor~/.zshenv(as the warning suggests)~/.claude/shell-snapshots/*.shand note the finalexport PATH=...line does not include~/.local/binRoot cause
~/.claude/shell-snapshots/*.shends with a hardcodedexport PATH=line appended by Claude Code after shell capture. This line overwrites the PATH set by the user's shell config (~/.zshrc,~/.zshenv,~/.zprofile). Only paths present in/etc/pathsor/etc/paths.d/(macOS system-level) survive, becausepath_helperruns before any user shell config.Impact
~/.zshrc— but fixing it has no effectsudo tee /etc/paths.d/local-bin— an elevated change that should never be required for a user-space toolExpected behavior
Either:
~/.local/binwhen the installer placed the binary there, orEnvironment
CLAUDE_BASH_NO_LOGINcontext #28043, [DOCS] Guide: direnv (+ devbox) environment loading via hooks #42229