Type node -v in your own terminal and you get a version back without a hitch. Ask the Antigravity agent to "run the tests," and it stops dead on node: command not found. The same goes for python, pnpm, bun, gh—each one reported as missing. The first time this happened to me, I assumed my install was broken and went as far as reinstalling. But the cause has nothing to do with the install. The shell the agent spawns and the shell you type into every day are looking at different PATH values.
Once you understand the mechanism, this mismatch is almost always a one-shot fix. Let's walk through it.
First, isolate the symptom
Have the agent run these two lines in its terminal:
echo $PATH
which node || echo "node not on PATH"The PATH shown here will be noticeably shorter than what you see when you run echo $PATH in your normal terminal—/usr/local/bin or ~/.nvm/... will be missing. If you can confirm that, the cause is almost certainly PATH inheritance. If node is on PATH but still won't run, that's a different problem (permissions, a broken symlink) and outside the scope of this article.
If you want one more layer of certainty, ask the shell itself what mode it started in. Have the agent run:
case $- in *i*) echo "interactive";; *) echo "NON-interactive";; esacIf it answers NON-interactive, you're squarely in the PATH-inheritance case described below.
Why only the agent has a short PATH
The key is which mode the shell started in. When you open a terminal yourself, the shell starts as an interactive login shell and reads ~/.zshrc or ~/.bash_profile. Version managers like nvm, pyenv, asdf, and rbenv make node or python available by rewriting PATH inside those init files.
The shell the agent spawns to run a command, on the other hand, is usually non-interactive and non-login. On top of that, the top of ~/.zshrc often carries a guard like this:
# A common pattern at the top of .zshrc
[[ $- == *i* ]] || return # bail out if this is not an interactive shellWith that one line, a non-interactive shell never reaches the nvm initialization (source ~/.nvm/nvm.sh) and exits without ever adding node to PATH. The result: the node that's visible to you is invisible to the agent.
For reference, here's which file zsh reads in which mode—it's the map you need when choosing where to put things:
~/.zshenv— read first, every single time, regardless of interactive/login state~/.zprofile— read only for login shells~/.zshrc— read only for interactive shells~/.zlogin— read only for login shells, after~/.zshrc
The agent's shell, in many setups, effectively picks up only ~/.zshenv.
Fix 1: Move PATH setup to a file that always loads
The most reliable approach is to place your version manager's initialization where it's read regardless of whether the shell is interactive. For zsh that's ~/.zshenv; for bash, ~/.profile. If you use nvm, move the block you had in ~/.zshrc over to ~/.zshenv:
# ~/.zshenv (loaded for both interactive and non-interactive shells)
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"Do the same for pyenv—put the PATH addition and eval "$(pyenv init -)" in ~/.zshenv so pyenv works in the agent's shell too. If the only issue is that Homebrew on Apple Silicon (/opt/homebrew/bin) isn't visible, a single line in ~/.zshenv often does it:
export PATH="/opt/homebrew/bin:$PATH"One caveat: ~/.zshenv is evaluated before the PATH macOS assembles via /etc/paths. As long as you always keep the existing $PATH on the tail end—PATH="...:$PATH"—you avoid accidentally clobbering system defaults like /usr/bin. And don't cram heavy work (initializers that call eval repeatedly) into ~/.zshenv, since it runs on every command invocation and will slow things down. Move only the minimum that touches PATH.
Fix 2: Pass environment variables from the editor
If you'd rather not touch your shell init files, Antigravity (which follows the VS Code settings structure) lets you hand environment variables to the agent's terminal explicitly. Add this to settings.json:
{
// inherit the login shell environment into the integrated terminal
"terminal.integrated.inheritEnv": true,
// explicitly supply the missing PATH (use osx / linux / windows as appropriate)
"terminal.integrated.env.osx": {
"PATH": "${env:HOME}/.nvm/versions/node/v22.11.0/bin:/opt/homebrew/bin:${env:PATH}"
}
}inheritEnv set to true sometimes still doesn't reach the agent's subprocesses, so for certainty, padding env.osx with the real path as above is the safer bet. Note that the node path changes every time you bump the version. Rather than hard-coding a fixed version, loading nvm itself via Fix 1 is easier to maintain.
Fix 3: Set nvm's "default" alias
Even after you can load nvm from ~/.zshenv, node won't be active unless a version is selected, because nvm use doesn't run in a non-interactive shell. Pin a default:
nvm alias default 22 # automatically select the v22 line at startupWhen you want a different version per project, drop a .nvmrc (containing 22, say) at the repo root. That also makes it easy to have the agent run a single nvm use first.
Fix 4: Spell out the commands in AGENTS.md
The environment is sorted by now, but as one more safeguard, documenting your command assumptions in the repo's AGENTS.md cuts down on the agent's trial and error:
## Dev commands
- Use pnpm as the package manager (not npm / yarn)
- Run tests: `pnpm test`
- Type check: `pnpm typecheck`
- node version follows .nvmrc (v22 line)After I added these few lines to the repositories I maintain as an indie developer, I saw a visible drop in incidents where the agent mixed up npm and pnpm and generated a duplicate lockfile. Fixing the environment and stating it in docs are both worth doing—not one or the other. Since AGENTS.md is a precondition the agent reads every time, writing the commands you don't want it to use in the negative form removes even more hesitation.
What to watch for on Windows / WSL
The same symptom gains an extra layer when you pair Windows with WSL. If the editor itself runs on the Windows side while the agent's shell launches on the WSL (Linux) side, what gets read is not the Windows PATH but WSL's ~/.profile or ~/.bashrc. In that case, the file to patch isn't terminal.integrated.env.windows—it's the WSL-side init file. You can also get crosstalk from trying to call Windows executables (like node.exe) from inside WSL, so decide up front which side's node you intend to use. If you're standardizing on Linux, the most straightforward route is to reinstall nvm inside the WSL shell and write the loader into ~/.profile.
Confirm the fix actually took
After you change a setting, restart the agent before you verify. A leftover old shell session won't pick up the ~/.zshenv you just fixed, and it's easy to conclude "still broken." Once restarted, have the agent run:
which node && node -v
which python3 && python3 --versionIf both return a path and a version, you're done. If which node resolves but node -v errors, it's either an unset nvm default (Fix 3) or a .nvmrc pointing at a version you haven't installed—run nvm install 22 once to disambiguate.
Preventing a recurrence
Let me sum up the cause in one line: you wrote your PATH setup in a place that only interactive shells read. Put version manager initialization in ~/.zshenv / ~/.profile, and the interactive cosmetics (prompt, completion, aliases) in ~/.zshrc. Splitting placement by role keeps you from hitting the same trouble in cron and CI, not just the agent.
When the agent stalls, it's tempting to suspect the AI. But more often than not, your environment simply isn't visible to the agent correctly. Have it run echo $PATH once—that, I've found, is the shortest path through this class of problem.