"'codex' not found" — but it works in my shell

T3 Code says your provider binary doesn't exist but your terminal disagrees. It's PATH inheritance — the fix on macOS, Windows and Linux.

Last reviewed · verified against the pingdotgg/t3code repo

text
'codex' not found

Meanwhile:

bash
$ codex --version
0.111.0

Both are true. This is a PATH inheritance problem, not a missing binary.

Why it happens#

Processes inherit their environment from their parent. Your terminal built a PATH by sourcing ~/.zshrc, ~/.bashrc or your profile. An application launched from the dock, Start menu or Spotlight never ran those files — it inherited a much shorter PATH from the desktop session.

So T3 Code, launched from the GUI, genuinely cannot see a binary your shell can.

This bites hardest when your provider CLI lives somewhere added by a shell profile:

  • nvm~/.nvm/versions/node/vX/bin
  • Homebrew on Apple Silicon/opt/homebrew/bin
  • Volta, mise, asdf, fnm, nodenv — all shim directories added by profile scripts
  • npm global prefix — anywhere non-default
  • Windows — installed after your current login session began

The one-command diagnosis#

Launch T3 Code from your terminal instead of the GUI:

bash
npx t3@latest

Works from the terminal but not from the dock? Confirmed PATH. Fix below. Fails from the terminal too? Different problem — see troubleshooting.

macOS#

Quickest: launch from the terminal#

If you don't mind a terminal window, npx t3@latest inherits your full shell environment and the problem disappears.

Proper: make the path visible system-wide#

Add the binary's directory to the system paths list:

bash
# find where it actually lives
which codex
# → /Users/you/.nvm/versions/node/v22.16.0/bin/codex

# make it visible to launchd-started apps
sudo sh -c 'echo "/Users/you/.nvm/versions/node/v22.16.0/bin" >> /etc/paths.d/codex'

Log out and back in.

Alternative: install to a stable prefix#

bash
npm config set prefix /usr/local
npm i -g @openai/codex

/usr/local/bin is on the default PATH, so GUI apps find it without extra work.

Windows#

Most likely: you haven't logged out since installing#

Windows applications get their environment as it was at login. Install something that modifies PATH and already-running processes — including your desktop shell — don't see it.

Sign out and back in, or reboot. This alone fixes most cases.

Check PATH actually contains it#

powershell
$env:PATH -split ';' | Select-String npm
where.exe codex

If npm's global directory is missing, add it:

powershell
[Environment]::SetEnvironmentVariable(
  "PATH",
  $env:PATH + ";$env:APPDATA\npm",
  "User"
)

Then sign out and back in.

Watch for stale shims#

If where.exe codex returns several paths, an old broken shim may be shadowing the good one. Remove the stale entry.

Linux#

Least affected, since desktop environments and shells usually share a PATH. When it does happen:

bash
which codex

Add the directory to ~/.profile (read at login) rather than ~/.bashrc (read per interactive shell), then log out and back in.

For systemd user services, set PATH explicitly — service units get a deliberately minimal environment:

ini
[Service]
Environment=PATH=/home/you/.local/bin:/usr/local/bin:/usr/bin

Linux setup guide →

Remote environments#

Over SSH the same problem appears in a different form: non-interactive SSH sessions get a shorter PATH than interactive ones, because version managers usually initialise behind an interactive-shell guard.

bash
ssh host 'echo $PATH'          # what T3 Code sees
ssh host 'bash -lc "echo $PATH"'  # what you see when you log in

If they differ, that's your answer. T3 Code does search Volta, asdf, mise, fnm, nodenv and nvm for remote environments, but a custom location still needs to be on the non-interactive PATH. Remote access →

Same fix for every provider#

The mechanism is identical for claude, cursor-agent and opencode. Substitute the binary name; everything else applies unchanged.

FAQ#

Why does T3 Code say codex is not found when it works in my terminal?#

Applications launched from a GUI don't source your shell profile, so PATH entries added by nvm, Homebrew, Volta or a custom npm prefix are missing. The binary exists; T3 Code just can't see it.

How do I fix the codex not found error on macOS?#

Either launch T3 Code from a terminal with npx t3@latest, or make the binary visible system-wide by symlinking it into /usr/local/bin or adding its directory under /etc/paths.d/.

How do I fix it on Windows?#

Sign out and back in after installing the CLI, since Windows applications inherit the environment from login time. If PATH still lacks npm's global directory, add %APPDATA%\npm to your user PATH.

Does this affect Claude Code and Cursor too?#

Yes, identically. Any provider binary installed somewhere your shell profile adds to PATH can be invisible to a GUI-launched application.