“zsh: command not found” on macOS: Causes and Fixes

When the Terminal prints zsh: command not found: something, it means zsh looked through every directory on your PATH and didn’t find a program by that name. zsh has been the default shell since Catalina (10.15), so this is the macOS wording of the message. It comes down to five causes — here they are with the quickest check first, and the fix for each. Checked on macOS 26.5.2 (zsh 5.9).

First, read the message

The format is zsh:, a line number, command not found:, and the name it couldn’t find:

$ gti status
zsh: command not found: gti

To test whether a command exists without running it, use command -v. It prints the path and exits 0 if the command is found, or prints nothing and exits 1 if it isn’t:

$ command -v gti
$ echo $?
1

That one-line test tells you the shell genuinely can’t find it, before you start changing anything. (For the record, actually running a missing command exits with status 127 — a handy thing to check in scripts.)

It’s a typo

The most common cause and the easiest to rule out. gti for git, pyhton for python3, a stray capital letter — the shell matches names exactly. Check the spelling and confirm the correct name resolves:

$ command -v git
/usr/bin/git

If the right spelling prints a path like this, the original error was just the typo. If it still prints nothing, move on.

The tool isn’t installed

If the spelling is right and command -v still comes up empty, the program probably isn’t on your Mac. Plenty of commands people copy from Linux tutorials simply aren’t part of macOS — wget, tree, htop, watch. Install them with Homebrew:

brew install wget

If brew itself reports “command not found,” that’s the PATH case in the next section, not a missing install.

Installed, but not on your PATH

This is the one that catches Homebrew users. A program can be installed and still report “command not found” if the folder it lives in isn’t on your PATH. The tell is that the full path works while the bare name doesn’t:

$ /opt/homebrew/bin/wget --version   # full path — runs
GNU Wget 1.25.0 ...

$ wget --version                     # bare name — not found
zsh: command not found: wget

On Apple Silicon, Homebrew installs to /opt/homebrew/bin, which isn’t on the default PATH — so freshly installed tools are invisible by name until you add it. Fixing PATH the right way (and why ~/.zprofile is the file to use) is its own topic: see how to add to PATH on macOS. The short version is to add Homebrew’s shellenv line to ~/.zprofile and open a new Terminal window.

You just installed it — refresh the shell

zsh remembers where commands live in a hash table it builds when the shell starts. If you install something into a directory that’s already on your PATH, a Terminal window you had open beforehand can still say “command not found,” because it’s working from the old table. Rebuild it:

rehash

hash -r does the same thing. Or just open a new Terminal window, which starts with a fresh table. This only affects windows that were already open before you installed the command — a detail that makes the fix look random until you know it.

It’s a script in the current folder

Running a script by its bare name fails even when the file is right there in the folder, because zsh searches PATH and not the current directory. You point at it with ./, and the file has to be executable:

$ myscript.sh
zsh: command not found: myscript.sh

$ chmod +x myscript.sh
$ ./myscript.sh          # the ./ tells zsh where to look
hi

The ./ is the actual fix; chmod +x makes the file runnable if it wasn’t already. A useful signal: if adding ./ turns “command not found” into “permission denied,” the file just needs the execute bit.

In order of how often they’re the cause: a typo, a tool that was never installed, a folder missing from PATH, a shell that hasn’t rehashed, or a local script run without ./. Work down that list — command -v to test a name, echo $? to confirm the 127 — and one of the five will be it. Everything here was checked on macOS 26.5.2 with zsh 5.9.