← All guides and comparisons

Fix

MCP error -32000
“Connection closed” on Windows.

“MCP error -32000: Connection closed” can mean the MCP server your client started exited before it finished saying hello. On Windows, one possible cause is a command shim that the client cannot launch directly. Here is what to check.

Last checked 2026-10-22 against MCPProxy v0.71.1 and the sources linked below.

One possible fix: wrap npx in cmd /c

On Windows, tools such as npx may be installed as command shims. If your client cannot launch the shim directly, try starting it through cmd /c. This is one possible fix, not a diagnosis of every -32000 error (Start Debugging, 2026-06, MCPcat guide).

Before, in your client’s MCP config:

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "C:\\Users\\you\\notes"]
}

After:

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

Restart the client after you change the file.

Other common causes

The error is raised when the child process dies early, so the real reason is almost always in the server’s own output.

  • The command is not found. The client’s environment may not have the same PATH as your terminal. Use the full path to the program.
  • The server crashes on startup. A missing API key or environment variable is typical. Run the exact command in a terminal and read the error.
  • The server writes logs to stdout. MCP uses stdout for its messages, so a stray banner or pip install line breaks the connection. Logs belong on stderr.
  • A slow first start. The first run downloads a package or a model and takes longer than the client waits. Run the command once by hand to warm the cache.

A way out: let MCPProxy start the servers

Instead of every client starting its own copy of every stdio server, add the server to MCPProxy once. Clients then connect to MCPProxy over HTTP, so there is no npx line in any client’s config to get wrong.

  1. Install MCPProxy with the Windows installer from the download page, and start it.

  2. Add the server in the Web UI, or from a terminal:

    mcpproxy upstream add fs -- npx -y @modelcontextprotocol/server-filesystem C:\Users\you\notes
  3. With the default settings a new server is held in quarantine. Review and approve it in the Web UI before its tools become usable.

  4. Connect your client: mcpproxy connect claude-code (or cursor, codex, opencode). See one setup for every client.

What changes:

  • One process, started in one place. For ordinary stdio servers, MCPProxy wraps the configured command in the selected user shell. Its Windows default is cmd /c, but SHELL or ComSpec can select another shell, and Docker launches have separate handling. This behavior is verified in the source; this guide has not been tested on a Windows machine. If a command still fails, give its full path or configure cmd with /c explicitly.

  • A clearer error in MCPProxy. If the process cannot start, exits before it says hello, or never answers, MCPProxy names the problem and includes the last lines of the server’s stderr. The codes are MCPX_STDIO_SPAWN_ENOENT (command not found), MCPX_STDIO_EXIT_BEFORE_INITIALIZE (exited early, usually a missing key or argument) and MCPX_STDIO_HANDSHAKE_TIMEOUT (no reply within 30 seconds, often stdout pollution).

  • Logs and checks in one place.

    mcpproxy upstream logs --server fs --tail 100
    mcpproxy doctor

What this does not fix

  • A server that crashes on startup will still crash. MCPProxy makes the reason visible. It cannot repair the server.
  • Remote HTTP servers have different failure causes (network, sign-in). For OAuth problems see MCP OAuth connection expired.
  • Every Windows setup is different. If a server that runs fine in a terminal still fails to start under MCPProxy, please open an issue with the output of mcpproxy doctor.