MCP spawn ENOENT and npx Not Found: What the Error Actually Points At

spawn ENOENT means the client tried to launch something and the operating system could not find it.The missing target can be the command binary itself (npx,python3, a custom server) or a path inside the arguments. This is a runtime launch failure, not a config-format error — the JSON can be perfectly valid and the launch still fails. The right first move is to read which file the error names, then fix that target.

This page is cross-client runtime troubleshooting — the config schemas are covered by thecompatibility matrix; here the format is assumed correct and the launch is what fails. The rules below are observed runtime patterns matched against pasted error logs, not official client facts.

Symptoms this page covers

• Error: spawn npx ENOENT in the client’s MCP log.
• 'npx' is not recognized as an internal or external command on Windows.
• Executable not found on PATH or command not found.
• The server works when you run the same command in a terminal, but not from the client.

Possible causes, ordered by evidence strength

1. The binary is not on the PATH the client inherited (matches a known log pattern). GUI applications usually do not read your interactive shell profile, so a Node installed through a version manager (nvm, fnm, volta — each with its own directory layout) can be invisible to the client even thoughnpx works in your terminal. On Windows, the client likewise gets the system/user PATH, not your shell customizations.
2. The ENOENT target is a path in the args, not the command (documented false-positive boundary).The runtime.spawn-enoent rule matches the log pattern, but ENOENT can also come from a missing directory or file passed as an argument. Confirm the actual target in the error before editing the config — replacing npx with an absolute path does nothing when the missing file was an argument.
3. Windows npx vs npx.cmd (info-level boundary hint). Whether the .cmdsuffix is required depends on the client’s spawn implementation — it is not a universal fix. The doctor flags npx.cmd as a hint, not an error.
4. A missing -y flag stalls first runs (different failure, often confused). Without-y, npx waits for an install confirmation the client can never answer — the server hangs rather than fails with ENOENT. -ysolves the confirmation prompt; it does nothing for “npx not found”.
5. Wrong interpreter name (same family of problem). pythonvs python3 differs across platforms, and on Windowspython can resolve to a Store stub. The same PATH logic applies.

Reproduced with the production rules

Each block below is a fixture executed by this site’s verification suite through the same diagnosis engine as the homepage tool. The config is shown; the pasted error text is matched locally and never stored or echoed.

spawn ENOENT

Log line (synthetic example): Error: spawn npx ENOENT

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ]
    }
  }
}

npx not recognized (Windows)

Log line (synthetic example): 'npx' is not recognized as an internal or external command

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ]
    }
  }
}

Executable not found on PATH

Log line (synthetic example): Executable not found on PATH.

{
  "mcpServers": {
    "tools": {
      "command": "mybin",
      "args": []
    }
  }
}

Boundary: an ordinary “path” word is not a PATH problem

{
  "mcpServers": {
    "tools": {
      "command": "npx",
      "args": [
        "-y",
        "pkg"
      ]
    }
  }
}

Boundary: npx.cmd on Windows is a hint, not a verdict

{
  "mcpServers": {
    "tools": {
      "command": "npx.cmd",
      "args": [
        "-y",
        "pkg"
      ]
    }
  }
}

How to fix it

The commands below are for you to run on your own machine to verify PATH resolution — this website never executes anything. There is no single absolute npx path that fits every Node version manager; find yours first.

Windows

1. Find where npx actually lives: run where npx in a terminal. Note the full path (including any npx.cmd shim).
2. Compare with what the client sees: GUI apps inherit the system/user PATH from Windows, not your terminal’s session changes. If Node was just installed or the PATH was just edited, sign out/in or reboot so the new PATH reaches GUI processes.
3. If the client still cannot find it, put the full path in the config — for example "command": "C:\\Program Files\\nodejs\\npx.cmd" (adjust to the path where npx reported; version managers use their own directories).
4. If plain npx fails but the binary exists, test the explicit npx.cmd form — whether it is needed depends on the client’s spawn implementation.
5. Re-check the error target: if ENOENT names an argument path (a directory the server should read), fix that path instead of the command.

macOS / Linux

1. Find the binary: run which npx (or command -v npx) in a terminal.
2. Understand the gap: GUI apps launched from Finder, a dock, or a desktop launcher do not source .zshrc/.bashrc, so version-manager shims on your shell PATH are invisible to the client.
3. Put the absolute path from step 1 into the config’s command field, or install Node into a system location the GUI inherits. The exact path depends on your version manager — there is no universal one to copy.
4. On Linux, a bare custom executable may also need the execute bit (chmod +x) — the doctor reminds you of this but cannot inspect your filesystem.
5. Re-check the error target before assuming the command is the problem: a missing directory in args produces the same ENOENT family.

Verify inside your client

• Restart the client (fully quit first for desktop apps) and watch the server reach a running state.
• Open the client’s MCP log or output channel and confirm the ENOENT line is gone.
• Invoke one of the server’s tools end to end. A clean config plus a clean log plus a working tool call is the only complete verification.

What static checks cannot prove

The runtime rules on this page match patterns in a pasted error log; they cannot see your filesystem, your PATH, or whether a server actually started. runtime.spawn-enoent tells you the launch failed — it cannot tell you which file was missing until you read the error’s target, and a log line like “server not showing” is a low-confidence hint with several possible causes, never a single root cause. Likewise, a config that passes every static check is only schema-valid; runtime verification happens in your client, on your machine.

Frequently asked questions

Related:Claude Desktop MCP not showing on Windows(config-side causes),VS Code MCP server not showing(schema-side causes), thetop 5 MCP configuration errors, and theclient compatibility matrix.