Resolve the most common Warp problem for iOS developers: brew, fastlane, pod, or node reported as 'command not found'. A focused troubleshooting guide covering PATH, shell startup files, and Apple Silicon quirks.
When Warp says command not found for brew, fastlane, pod, or node, it almost never means the tool is broken. It means your shell cannot find the tool's binary on your PATH.
PATH is the list of directories your shell searches for commands. If the directory containing the binary is not listed, the shell gives up and reports the command as missing.
This is a shell and environment issue, not a Warp bug. The same misconfiguration would fail in any terminal.
The good news is that it is almost always fixable in a few minutes once you know where your shell reads its configuration and where your tools actually live.
Before touching PATH, confirm the binary exists. Try which fastlane or which brew; if the command is not found, use a direct check like ls on the expected install location.
For Homebrew on Apple Silicon, the binary lives at /opt/homebrew/bin/brew. On Intel Macs it is at /usr/local/bin/brew.
For Ruby gems like Fastlane and CocoaPods, the location depends on your Ruby: system Ruby, Homebrew Ruby, or a version manager like rbenv each install gems in different places. Knowing the real path tells you exactly what PATH entry is missing.
If the tool genuinely is not installed, install it first. If it is installed but not found, this is a PATH problem and the next steps apply.
Run echo $PATH in Warp and read the list of directories. Check whether the directory holding your missing binary appears.
A very common finding on Apple Silicon is that /opt/homebrew/bin is absent, which makes brew and everything installed through it invisible. Similarly, a version manager's shims directory may be missing.
Compare this with another terminal if you have one. If the tool works in Terminal.app but not Warp, the difference is which startup file each launched shell read.
This inspection step tells you precisely which directory you need to add and confirms whether the problem is PATH at all.
For Homebrew, the official fix is to add its shell environment line to your profile. On Apple Silicon that means adding eval "$(/opt/homebrew/bin/brew shellenv)" to your .zprofile (or .zshrc), then opening a new Warp session.
For a Ruby version manager like rbenv, add its init line, typically eval "$(rbenv init - zsh)", to your .zshrc so its shims are on PATH. That is what makes fastlane and pod resolve correctly.
The key detail is choosing the correct file. macOS zsh reads .zprofile for login shells and .zshrc for interactive shells; putting the line in the right one ensures Warp picks it up.
After editing, either open a new Warp tab or run source on the file. Then re-run which brew to confirm the fix.
Sometimes a tool works in one terminal and not another purely because of login versus non-login shell behavior. Different terminals launch shells differently, so a PATH line in the wrong file loads inconsistently.
The robust fix is to make sure your essential PATH and tool initialization lines are loaded for interactive shells, which is what you use day to day. Placing Homebrew's shellenv in .zprofile and tool inits in .zshrc is a reliable pattern.
If you maintain a heavily customized dotfiles setup, check that no early return or conditional is skipping the section that sets PATH. A stray guard can silently drop your tools.
Once your startup files are consistent, Warp and every other terminal will resolve the same commands, which is the state you want.
On Apple Silicon, a subtler variant appears: the tool is found but fails, or two copies exist for different architectures. If you ever ran under Rosetta, you may have both an Intel Homebrew in /usr/local and an ARM Homebrew in /opt/homebrew.
This leads to confusing situations where brew works but installs the wrong-architecture binaries, which then error at runtime. Decide on one architecture, standardize on it, and make sure PATH prefers that Homebrew.
Check your terminal is not launched under Rosetta unless you specifically need it. Running arch in Warp tells you the current architecture.
For iOS developers this matters most for Ruby gems with native extensions used by Fastlane and CocoaPods, which are sensitive to architecture mismatches.
After applying the fix, verify with a fresh Warp session. Run which and a version check for each previously missing tool: brew --version, fastlane --version, pod --version, node --version.
Seeing correct output in a new session, not just the one where you sourced the file, confirms the change is persistent. That new-session test is the one people skip and then get surprised later.
To prevent recurrence, keep your PATH and tool-init lines in one clearly commented place in your dotfiles. Avoid scattering PATH edits across multiple files where they can conflict.
If you use Warp Workflows, you can even save a small diagnostic that echoes PATH and checks each tool, so the next time something goes missing you triage it in one click.
Occasionally command not found points at a genuinely uninstalled or broken tool rather than PATH. If which finds nothing anywhere and the expected install directory is empty, reinstall the tool.
For gem-based tools, a broken Ruby environment can be the cause; confirm ruby -v and gem environment look sane before blaming Warp. Reinstalling gems under the correct Ruby often resolves it.
Remember the boundary: none of this is Warp compiling or signing anything. Warp is only trying to locate and run a binary, exactly like any terminal would.
Once PATH and your tool installations are consistent, this error disappears, and your git, Fastlane, and package-manager commands run reliably in Warp again.
When command not found appears, running through a short mental checklist beats guessing. It usually pinpoints the cause in under a minute.
First, is the tool actually installed? Use which and, if that fails, check the expected install directory directly. Second, is that directory on your PATH? Run echo $PATH and look for it.
Third, did you edit the right startup file, and did you open a fresh shell afterward? Changes to .zprofile or .zshrc only affect new sessions. Fourth, on Apple Silicon, are you in the architecture you expect? Run arch to rule out a stray Rosetta shell.
If all four check out and the command still is not found, the problem is likely a broken tool installation rather than PATH, and a clean reinstall under the correct Ruby or Homebrew is the fix. Working the list in order keeps you from changing three things at once and never learning which one mattered.
The two terminals likely launched shells that read different startup files, so your PATH edit is only in one of them. Add Homebrew's shellenv line to .zprofile (and tool inits to .zshrc) so every terminal, including Warp, picks it up.
On Apple Silicon it is at /opt/homebrew, and on Intel Macs at /usr/local. If brew is 'command not found', the corresponding bin directory is probably missing from your PATH.
Changes apply to new shells. Open a new Warp tab or run source on the file. Also confirm you edited the file your interactive shell actually reads, since login and non-login shells differ.
Yes. If you have both Intel and ARM Homebrew installations, or you launched the shell under Rosetta, tools can be found but misbehave. Standardize on one architecture and make sure PATH prefers the correct Homebrew.
No. It is a shell environment issue that would occur in any terminal. Warp only searches your PATH for the binary; fixing PATH or the tool's installation resolves it.