Fixing spawn npx ENOENT When an Antigravity MCP Server Won't Start

You add an MCP server to Antigravity, and the agent log shows a single line — spawn npx ENOENT — while the server stays grayed out and never comes online. This was the very first wall I hit when wiring Figma MCP and Stripe MCP into my own dev setup. No matter how many times I re-read the config JSON, it was correct, yet the server still refused to start.

Here is the short version: this ENOENT is almost never a fault in the MCP server itself. It means Antigravity (a GUI app) can't find where npx lives — a PATH problem. The same command runs fine in your terminal, but fails when launched from the GUI. That asymmetry is the whole story.

As an indie developer who has been shipping apps since 2014, the mismatch between local tooling and GUI apps over PATH is something I have run into many times. Running the four Dolice Labs sites, I kept tripping on MCP setup in particular, so here is the diagnostic sequence I actually use.

Read the symptom correctly first

ENOENT stands for "Error NO ENTry" — the OS code returned when a requested executable cannot be found. In the MCP context, Antigravity tried to launch the program named in your config's command field (usually npx) and could not resolve its location.

The log looks like this:

[MCP] failed to start server "figma": spawn npx ENOENT
[MCP] server "stripe" exited with error: spawn npx ENOENT

The key insight: ENOENT does not mean "npx doesn't exist." It means "this process's PATH cannot find it." Before you go chasing a corrupted global install, suspect PATH first — it is the faster road.

Why it works in the terminal but fails from the GUI

On macOS, when you launch an app from the Dock or Spotlight, it starts via launchd. The environment it inherits is not the same one your login shell reads from ~/.zshrc or ~/.bashrc. So any PATH entries you added there for nvm, Homebrew, or asdf — the directories holding your node and npx — are not passed to a GUI-launched Antigravity process.

This bites hardest with nvm. Your npx lives somewhere deep like ~/.nvm/versions/node/v20.x/bin/. The terminal's shell puts that on PATH, so it works; but an app started by launchd carries little more than /usr/bin:/bin:/usr/sbin:/sbin and cannot find npx. That is the most common cause of spawn npx ENOENT.

Diagnose: confirm where npx actually lives

Before fixing anything, pin down where npx is on your machine. Run this in a terminal:

# Show every npx on PATH
which -a npx
 
# Where node itself lives
command -v node
 
# The PATH your current shell carries
echo "$PATH"

If which -a npx points under your home directory, like /Users/you/.nvm/versions/node/v20.11.0/bin/npx, that essentially confirms it: the GUI app cannot see that path. If instead it points somewhere standard like /usr/local/bin/npx or /opt/homebrew/bin/npx, suspect a different cause (Windows-specific behavior or a typo, both below).

Fix 1: use an absolute path for command

The most reliable fix is to replace npx in the command field with the absolute path you got from which -a npx.

{
  "mcpServers": {
    "figma": {
      "command": "/Users/you/.nvm/versions/node/v20.11.0/bin/npx",
      "args": ["-y", "figma-developer-mcp", "--stdio"]
    }
  }
}

This works immediately, but it has one weakness: bump your node version and the path changes, breaking it again. I use this for quick verification, and reach for Fix 2 or Fix 3 for servers I keep around.

Fix 2: supply PATH via env

Keep command as npx and add the node bin directory to PATH through env. This scopes the environment per server, which keeps things tidy.

{
  "mcpServers": {
    "stripe": {
      "command": "npx",
      "args": ["-y", "@stripe/mcp", "--tools=all"],
      "env": {
        "PATH": "/Users/you/.nvm/versions/node/v20.11.0/bin:/usr/local/bin:/usr/bin:/bin"
      }
    }
  }
}

One caveat: the env PATH overrides the existing one. Forget /usr/bin and /bin and you will lose basic commands like sh, turning this into a different error. Put the node bin first, but always include the standard directories too.

Fix 3: pin the environment with a wrapper script

If you want to stop editing paths every time you upgrade node, a thin wrapper script is the practical answer. It loads nvm, then execs npx.

#!/usr/bin/env bash
# ~/bin/mcp-npx.sh
# Wrapper that sources nvm before running npx
export NVM_DIR="$HOME/.nvm"
# shellcheck disable=SC1091
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
exec npx "$@"

Make it executable (chmod +x ~/bin/mcp-npx.sh) and point command at the script's absolute path.

{
  "mcpServers": {
    "figma": {
      "command": "/Users/you/bin/mcp-npx.sh",
      "args": ["-y", "figma-developer-mcp", "--stdio"]
    }
  }
}

Upgrade node and the script resolves nvm's current default version for you — no config edits needed. In a setup that juggles several MCP servers, I find this approach has the lowest maintenance cost by far.

Fix 4: reconsider your version manager

When it comes to GUI compatibility, tools like nvm that rewrite PATH dynamically through a shell function simply do not mesh well with GUI apps. If your work is GUI-centered and leans heavily on MCP, moving to Homebrew or Volta — where node sits at a fixed path — is a reasonable call.

# Homebrew puts a stable node at a fixed /opt/homebrew/bin/node
brew install node
 
# Volta exposes the same path through a shim
curl https://get.volta.sh | bash
volta install node

With node and npx at fixed paths, a GUI app has a better chance of resolving them from the standard PATH alone. You do not need to migrate an existing nvm-based project, but it is worth considering for a fresh environment.

Notes for Windows and WSL

When spawn npx ENOENT appears on native Windows, the cause is slightly different. On Windows, npx ships as npx.cmd, and writing just npx in command can fail to resolve the extension. Set command to npx.cmd, or use the cmd /c npx ... form, and it will start.

If you also run WSL, npx's location depends on whether Antigravity is running on the Windows side or the WSL side. To use node inside WSL, wrap the launch as wsl npx ..., or open Antigravity through a WSL remote connection so everything lines up. Mixing the two makes it hard to tell which PATH is in play, which complicates diagnosis.

Keep it from happening again

When you share MCP config in a repository, hardcoded absolute paths break for other people and other machines. The wrapper-script approach keeps things portable by absorbing the environment differences inside the script. For team work, bake a fixed node path into a devcontainer and open Antigravity within it for a stable result.

In my case I rotate between Figma MCP, Stripe MCP, and Google Workspace MCP daily, so I routed all of them through a single ~/bin/mcp-npx.sh. Just being free of re-editing config every time I bump node was worth the small setup cost. If this saves a little time for someone stuck at the same spot, I am glad.