The install directory is not on your PATH
Both the npm global bin and the standalone installer put claude somewhere the shell has to be told about. On Linux and macOS that is usually ~/.local/bin, which plenty of default profiles never add.
Claude Code fix: The shell answers command not found when you run claude
This message is from your shell, not from Claude Code. It says the binary is not on the PATH of the process that tried to run it, and that process is not always the terminal you installed from.
claude: command not found
Printed by your shell, not the CLI.
Diagnosis
Both the npm global bin and the standalone installer put claude somewhere the shell has to be told about. On Linux and macOS that is usually ~/.local/bin, which plenty of default profiles never add.
Anything started by systemd, launchd or a Windows service inherits a minimal environment and never reads .bashrc or .zshrc. The same machine then runs the CLI by hand and fails to spawn it from the service, which reads as an install problem and is not one.
The binary is claude.exe, and an npm install leaves a claude.cmd shim instead. A lookup that tries only the bare name finds neither, which is why a resolver has to try all three spellings before it gives up.
Check
| Run this | What a good answer looks like |
|---|---|
command -v claude | Prints an absolute path when the shell can find it and nothing at all when it cannot. Run it in the shell that failed rather than in a fresh one, because a new shell may have picked up a profile change the old one predates. |
ls -l ~/.local/bin/claude | Answers the other half: whether the binary exists and is unreachable, or was never installed. A symlink here is normal. |
claude doctor | Once it runs at all, this checks the installation rather than the path to it, which keeps a genuine install problem from being mistaken for a PATH one. |
Every command here has been run on a real machine. Termdeck answers the same questions for every machine you have connected, without opening a terminal on any of them.
Fix
Append export PATH="$HOME/.local/bin:$PATH" to the profile your shell actually reads, then open a new terminal. A shell that is already open keeps the PATH it started with.
Where a service does the spawning, an absolute path removes the question entirely. Termdeck takes TERMDECK_CLAUDE_EXE for this, and resolves in the order override, ~/.local/bin, the standalone install, then PATH.
A service picks up an environment change when it restarts and not a moment before. Fixing the profile and leaving the unit running fixes nothing until then.
Not this
A second install puts the binary in the directory it is already in. If the first one worked, nothing about the PATH that could not find it has changed.
Root has a different PATH again, usually a shorter one. It turns a missing binary into a missing binary owned by the wrong user, and any files it does create are then owned by root.
FAQ
A service starts with a minimal environment and does not read your shell profile, so the directory your terminal adds is missing. The same machine finds the binary one way and not the other.
On Linux and macOS it lands in a user bin directory, most often ~/.local/bin. On Windows it is claude.exe, or a claude.cmd shim when it came from npm.
Usually not. Check whether the file exists before reinstalling, because a binary that is present but unreachable is a PATH problem and a reinstall simply repeats it.
The shape is identical and only the names change. Each engine has its own install directory and its own override variable, and a service still has its own PATH.
Claude Code, Codex and Grok in one browser console