Fix "spawn npx ENOENT" for MCP servers on Windows

Quick answer

1. In your MCP config, change "command": "npx" to "command": "cmd".
2. Put "/c" and "npx" at the start of args, before the rest of the arguments.
3. Save, then fully quit and reopen your client (not just a new chat).

// before: fails on Windows in some clients
{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-memory"]
}

// after
{
  "command": "cmd",
  "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-memory"]
}

Not every client needs this. The official MCP quickstart for Claude Desktop uses plain npx on Windows, and if your server already connects you should leave it alone. Use the wrapper when you see the error.

Why it happens

ENOENT means "no such file": the program that started your MCP server could not find the command you gave it. On Windows, npx is not a program (npx.exe) but a script launcher called npx.cmd. Many MCP clients start servers directly, with no shell in between, and a directly-started process cannot resolve npx to npx.cmd. Node's own documentation says that .bat and .cmd files are not executable on their own without a terminal and can only be run through cmd.exe (or by spawning with a shell).

You also cannot fix it by pointing at npx.cmd. Since the April 2024 Node.js security releases (CVE-2024-27980), starting a .cmd or .bat file without a shell fails with EINVAL on Node 18.20.2, 20.12.2 and later. So the reliable route is to start cmd.exe yourself, and let it run npx: cmd /c npx .... /c tells cmd to run the rest as a command and exit.

The MCP server READMEs use this pattern for Windows. The official Filesystem server README, for instance, has a Windows config that starts with "command": "cmd" and "/c", "npx". Users reported the same fix in Claude Code issue #3369, where a native-Windows setup showed MCP error -32000: Connection closed until the config was changed to cmd /c. A reply there said the cmd solutions fix it.

The fix, per client

Every client uses the same idea: command is cmd, and args begins with /c and npx. Each argument stays a separate string. The server here is the official Memory server; swap in your own package and arguments.

Claude Code

With the CLI, everything after -- is the command. Keep each word separate (do not wrap the whole command in one pair of quotes) and keep the --:

claude mcp add memory -- cmd /c npx -y @modelcontextprotocol/server-memory

To change an existing entry, remove it first (claude mcp remove memory) and add it again. Or add it from JSON, which keeps the arguments exactly as you write them:

claude mcp add-json memory '{"type":"stdio","command":"cmd","args":["/c","npx","-y","@modelcontextprotocol/server-memory"]}'

In a project .mcp.json file at the repository root, use the same command and args shape under mcpServers. Check the result with claude mcp get memory, which prints the command Claude Code will run, and claude mcp list.

A note on versions: Claude Code's current MCP docs say that executables on your PATH such as npx or uvx work as-is, and do not mention cmd /c. Users on native Windows have reported otherwise in issues #3369, #9594 and #68221 (the last one traces it to the EINVAL behaviour above). Some Claude Code versions have printed a warning that a Windows npx server needs the cmd /c wrapper. If plain npx connects for you, you do not need the wrapper.

Claude Desktop

Open the config from Settings, then Developer, then Edit Config. The file is %APPDATA%\Claude\claude_desktop_config.json on Windows.

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

Save the file, then completely quit Claude Desktop and reopen it; the MCP docs say it must restart to load the new configuration.

Cursor

Same shape in ~/.cursor/mcp.json (global) or .cursor/mcp.json (project). More in how to add an MCP server to Cursor, which also shows this wrapper in its troubleshooting section.

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

VS Code

VS Code uses a servers key (not mcpServers) in .vscode/mcp.json for a workspace, or in your user profile's mcp.json. Open either from the Command Palette with MCP: Open Workspace Folder MCP Configuration or MCP: Open User Configuration.

{
  "servers": {
    "memory": {
      "type": "stdio",
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-memory"]
    }
  }
}

Codex

Update Codex first. A fix merged on 16 November 2025 (pull request #3828, "resolve Windows MCP server execution for script-based tools") makes Codex resolve script launchers such as npx, pnpm and yarn through the Windows PATHEXT list, so a recent Codex may need no wrapper at all. If you still get the error on a current build, use the same shape in ~/.codex/config.toml:

[mcp_servers.memory]
command = "cmd"
args = ["/c", "npx", "-y", "@modelcontextprotocol/server-memory"]

Older Codex versions behaved differently. A 2025 issue on Codex 0.23 (#2555) reports cmd /c timing out with "request timed out", and another (#3385) describes using the full path to npx.cmd together with a larger startup_timeout_sec. Those are user reports against old releases, so try updating before using them. Full config details are in how to add an MCP server to Codex.

If it still fails: other causes

Node.js is not installed, or the client cannot see it

Open a new Command Prompt and run where node and where npx. If either prints nothing, install Node.js. If they work in your terminal but not in the client, the client was started before Node was on your PATH: quit it fully and reopen it, or sign out and back in.

The server runs fine by hand

Run the full command yourself, for example cmd /c npx -y @modelcontextprotocol/server-memory. A working MCP server starts and then waits silently for input (press Ctrl+C to stop it). If it prints an error and returns to the prompt, fix that error first; the client is only reporting it. Official servers need Node 24 or newer from v2 onward (see what changed in v2).

`${APPDATA}` or npm folder errors (Claude Desktop)

The MCP docs describe an ENOENT where the server log mentions ${APPDATA} in a path. The fix they give is to add the expanded value to the server's env, for example "APPDATA": "C:\\Users\\you\\AppData\\Roaming\\", and to make sure npm is installed globally, so that %APPDATA%\npm exists (npm install -g npm creates it).

The command is not an `.cmd` script at all

The wrapper is for launchers that are .cmd or .bat scripts, such as npx, npm, pnpm and yarn. A real .exe such as node.exe does not need it. Use an absolute path for your own scripts, since a relative one resolves against whatever folder the client was started from.

Backslashes in JSON

In JSON, a Windows path needs doubled backslashes, C:\\Users\\you\\projects, or forward slashes. A single backslash makes the file invalid or changes the path. In Codex's TOML file use single-quoted strings, 'C:\Users\you\projects', which TOML treats literally.

Still seeing "Connection closed"? That message covers many causes; work through Fix MCP error -32000 "Connection closed".

FAQ

Does this apply to WSL?

The cause is specific to launching .cmd scripts from native Windows. Inside WSL you run Linux versions of the tools, where npx is a normal executable. The issue above notes that the same setup worked in WSL2.

Do I need `cmd /c` for `uvx` or Python servers?

Not for the same reason. npx, npm, pnpm and yarn are the .cmd launchers. A server started with uvx or python is a different command, so only wrap it if you see an equivalent error.

Why not just use the full path to npx.cmd?

Since the CVE-2024-27980 hardening, Node refuses to start a .cmd file without a shell, and the failure is EINVAL rather than ENOENT. Going through cmd /c avoids the problem.