MCP Servers on Windows: npx.cmd, Paths and PowerShell Fixes

Table of Contents

• Error → cause → fix
• Where the config and logs are on Windows
• 1. npx: spawn ENOENT, spawn EINVAL and "not recognized"
• 2. Backslashes in JSON paths
• 3. Paths with spaces in "command"
• 4. Python, uv and the Microsoft Store stub
• 5. Docker Desktop isn't running
• 6. Environment variables that never arrive
• 7. PowerShell traps while you test
• 8. The client still has the old PATH
• Test the server outside the client
• FAQ

Most MCP setup guides are written on a Mac. Copy one of their configs to Windows and the server often doesn't start, with an error that doesn't say why. This post collects the Windows-only causes in one place. For the general version of the npx problem, see fixing spawn npx ENOENT.

Error → cause → fix

Where the config and logs are on Windows

• Claude Desktop config: %APPDATA%\Claude\claude_desktop_config.json
• Claude Desktop logs: %APPDATA%\Claude\logs\, with one mcp-server-NAME.log per server
• Cursor: %USERPROFILE%\.cursor\mcp.json
• VS Code: %APPDATA%\Code\User\mcp.json

To open a folder, press Win+R and paste the path, for example %APPDATA%\Claude\logs. The server's own error is almost always in its log file, so read that before you change anything.

1. npx: spawn ENOENT, spawn EINVAL and "not recognized"

Node installs npx on Windows as npx.cmd, a batch script. MCP clients start servers with Node's child_process.spawn and no shell, which only runs real executables. So the client looks for npx, finds no npx.exe, and logs spawn npx ENOENT.

Writing "command": "npx.cmd" doesn't fix it. Since the April 2024 Node security releases (CVE-2024-27980), Node won't start .cmd or .bat files without a shell and throws spawn EINVAL instead.

The fix that works in every client is to let cmd.exe start npx:

{
  "mcpServers": {
    "filesystem": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\me\\projects"]
    }
  }
}

The same goes for pnpm dlx, yarn dlx and bunx when they're installed as .cmd shims. uvx from the official uv installer is a real uvx.exe, so it doesn't need the wrapper.

Once you add cmd /c, the error changes. If Node isn't on the client's PATH, the spawn now succeeds (it started cmd), and the server log shows cmd's own message instead:

'npx' is not recognized as an internal or external command,
operable program or batch file.

That means the wrapper is right and Node is the problem. Check with where.exe npx in a new terminal, then see section 8.

2. Backslashes in JSON paths

In JSON, a backslash starts an escape sequence like \n. \U in C:\Users isn't a valid one, so the whole file fails to parse. Node's JSON parser, for example, reports this for "C:\Users\me\projects":

Bad escaped character in JSON at position 13 (line 1 column 14)

Clients react differently. Some show an error, some just start with no servers at all, because they couldn't read any of the file. Two ways to write the path:

"C:\\Users\\me\\projects"   // doubled backslashes
"C:/Users/me/projects"       // forward slashes, which Windows accepts too

JSON doesn't allow comments, so leave the // notes above out of your real file. Paste the file into any JSON validator before restarting the client.

3. Paths with spaces in "command"

If you point command at a full path, don't add quotes inside the string. Without a shell, nothing removes them, and Windows looks for a file whose name starts with a quote mark:

"command": "\"C:\\Program Files\\nodejs\\node.exe\""   // fails: ENOENT
"command": "C:\\Program Files\\nodejs\\node.exe"         // works

The same applies to items in args: each array item is passed as one argument, spaces included, so it needs no extra quotes.

4. Python, uv and the Microsoft Store stub

A fresh Windows install has a python.exe on PATH that isn't Python. It's an "app execution alias" that opens the Microsoft Store. When an MCP client starts it, it prints this to stderr and exits:

Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.

The client usually shows only that the server closed or disconnected, so look for this line in the server's log. Three fixes, best first:

1. Use uv, which manages its own Python: winget install astral-sh.uv, then "command": "uvx" for published servers or "command": "uv" with run --directory C:/path/to/project server.py for your own. My uv tutorial walks through it.
2. Point at the project's virtual environment: "command": "C:/path/to/project/.venv/Scripts/python.exe". Note Scripts, not bin as on Mac and Linux.
3. Install Python from python.org with "Add python.exe to PATH" ticked, and turn off the python.exe and python3.exe aliases under Settings → Apps → Advanced app settings → App execution aliases.

5. Docker Desktop isn't running

Servers started with "command": "docker" need the Docker engine. If Docker Desktop is installed but not running, docker starts fine and then fails. The message ends like this:

error during connect: ... open //./pipe/dockerDesktopLinuxEngine: The system cannot find the file specified.

Start Docker Desktop, wait until it says the engine is running, then restart the client. If you want it to always be ready, turn on "Start Docker Desktop when you sign in" in Docker's settings.

6. Environment variables that never arrive

You set GITHUB_TOKEN with setx or in System Properties, it shows up in a new terminal, but the server still says it's missing.

Two separate causes:

• The client was already running. A Windows program gets its environment when it starts. Quit it from the tray and open it again.
• The client doesn't pass it on. Clients built on the official MCP TypeScript SDK's stdio transport give the server only a short list of system variables by default: APPDATA, PATH, PATHEXT, TEMP, USERPROFILE, SYSTEMROOT and a few more. Everything else, your token included, has to be in the server's "env".

"github": {
  "command": "cmd",
  "args": ["/c", "npx", "-y", "@modelcontextprotocol/server-github"],
  "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..." }
}

The same applies to proxy settings: if you're behind a corporate proxy, put HTTPS_PROXY in "env" too, or npx can't download the package.

7. PowerShell traps while you test

Testing in a terminal is the right instinct. PowerShell adds two problems of its own.

"where npx" prints nothing

In PowerShell, where is an alias for Where-Object, not the Windows where.exe program. where npx runs a filter on empty input and prints nothing, which looks like "npx isn't installed". Use one of these instead:

where.exe npx
Get-Command npx

where npx works as expected in cmd.exe.

npx.ps1 cannot be loaded

Node also installs npx.ps1, and PowerShell prefers it to npx.cmd. With the default execution policy on Windows clients, running it fails:

npx : File C:\Program Files\nodejs\npx.ps1 cannot be loaded because running scripts is disabled on this system. For more information, see about_Execution_Policies at https:/go.microsoft.com/fwlink/?LinkID=135170.

This only affects your terminal, not MCP clients, which don't start servers through PowerShell. Either type npx.cmd in PowerShell, test in cmd.exe, or allow local scripts for your user:

Set-ExecutionPolicy -Scope CurrentUser RemoteSigned

8. The client still has the old PATH

Installers for Node, Python and uv add their folder to PATH, but only programs started afterwards see the change. Claude Desktop keeps running in the system tray when you close its window, so it can hold the old PATH for days.

1. Open a new terminal and run where.exe npx (or uvx, python, docker). If it finds nothing, the program isn't on PATH yet: reinstall it with the PATH option ticked.
2. If it's found, quit the client completely: right-click its tray icon and choose Quit. For Cursor and VS Code, close every window.
3. Open the client again.

With nvm-windows, also run nvm use with a version once, so the nodejs folder it puts on PATH actually points somewhere.

Test the server outside the client

Before you restart the client again, run the exact command from your config in cmd.exe:

cmd /c npx -y @modelcontextprotocol/server-filesystem C:\Users\me\projects

A working stdio server prints nothing, or a line to stderr, and then waits for input. That's correct: it's waiting for JSON-RPC. Press Ctrl+C to stop it. If it exits with an error instead, you've found the real problem. For servers that work here but not in the client, see MCP server works in the terminal but not in Claude Desktop.

To go further and call tools, MCP Playground Desktop runs on Windows and starts stdio servers the way a client does:

• Plain npx works. It starts .cmd scripts correctly, so you can check the server itself before getting the cmd /c wrapper right. Configs that already use cmd /c work too.
• Import reads %APPDATA%\Claude\claude_desktop_config.json, Cursor's and VS Code's files, so you don't retype anything.
• Missing programs get a clear message: "Couldn't find "uvx" on this computer." with the winget install astral-sh.uv command, instead of spawn uvx ENOENT.
• The Server stderr tab shows what the server printed, including the "Python was not found" line from the Store stub.

FAQ

Conclusion

On Windows, most MCP servers that won't start fall into one of these causes: npx without cmd /c, a single backslash, the Store python stub, Docker not running, a variable missing from "env", or a client that still has the old PATH. Read the server's log in %APPDATA%\Claude\logs first, then fix the one it points to.

To check a server works before you touch the client config again, get MCP Playground Desktop for Windows and Mac →