I was wiring up a CLI tool called steer on three Mac machines that run agent sessions, and before doing anything else I wanted to confirm it was actually installed on each one. So from my Linux box I ran the obvious check: ssh host "which steer" — which being the little command that tells you where a program lives, if it can find it. Empty output. Ran it on the second Mac. Empty. Third Mac. Empty.
Three for three, nothing. I sat there for a second and started drafting the bad news in my head: the tool isn’t reachable, this whole approach is dead, time to find another way.
Here’s the part that saved me from being wrong in public: I SSH’d into one of the Macs interactively — a real login, like sitting down at the keyboard — and typed which steer. It printed a path immediately. The tool was installed. It had been installed the entire time.
So what happened? When you run ssh host "some command", you get a non-interactive shell — it runs your one command and leaves, and it does not load the same startup files a normal login does. On macOS specifically, the directories where Homebrew and hand-installed tools live — /usr/local/bin and /opt/homebrew/bin — get added to your PATH by a mechanism (/etc/paths via a helper called path_helper) that only fires for login shells. Skip that step and those folders simply aren’t on the map. which searches the map, doesn’t find the tool, and shrugs.
The tool exists. which just wasn’t looking in the room it was standing in.
Think of it like calling someone’s landline, getting no answer, and concluding they moved out — when really they were home the whole time, just not by that phone. The absence of a signal on one channel isn’t proof of absence.
The fix I trust now is to check the filesystem directly instead of asking PATH’s opinion:
Three reliable ways to verify a macOS binary over SSH give me the detail
The bare check lies because the remote command runs in a non-login, non-interactive shell that never sourced /etc/paths:
# ❌ false negative — PATH is missing /opt/homebrew/bin and /usr/local/bin
ssh host "which steer"
# ✅ ask the filesystem, not PATH
ssh host "ls /opt/homebrew/bin/steer /usr/local/bin/steer 2>/dev/null"
# ✅ or force a login shell so path_helper runs
ssh host "bash -lc 'which steer'"
# ✅ or just fix PATH inline for the one command
ssh host "PATH=/opt/homebrew/bin:/usr/local/bin:\$PATH which steer"ls returns the actual path if the file is there and nothing if it isn’t — that’s a real existence test. bash -lc (the -l means “login”) makes the remote shell load the startup files, which restores the Homebrew directories to PATH. Any of the three turns “empty” back into a truthful answer.
The general trap is bigger than macOS. A lot of tools answer “can’t find it” and “doesn’t exist” with the exact same silence, and it’s on you to know which question you actually asked. which reports on PATH. It does not report on reality. When a check comes back empty and the stakes are “abandon the whole approach,” go one level down and ask the filesystem directly before you believe the verdict — especially when an agent is running the check and will faithfully report your false negative as fact.