Error messages

Client closed

Client closed

An MCP server (Model Context Protocol: a separate program or web service that gives Cursor's agent extra tools) has a status dot in Cursor's MCP settings. When the connection dies, the dot goes red and older builds printed this beside it:

Client closed

Newer builds put it in the MCP log instead, as a line like this one from a March 2026 report:

2026-03-04 12:48:27.237 [info] Client closed for command

It's a very common MCP complaint on the Cursor forum. The main thread, opened in February 2025 on Cursor 0.46.3, had 25,939 views and 70 posts when we read it on September 26, 2026, and a dozen more topics carry "client closed" in the title.

What "Client closed" means

It means Cursor's side of the connection was shut. It doesn't say why. Going through the log pastes posted since late 2025, the Client closed for command line almost always comes right after some other error: "Authorization header is badly formatted", "unable to get issuer certificate", "Invalid URL protocol", a server that "does not support dynamic client registration". Each of those is the cause. The closed line is just Cursor tidying up.

For local servers there's a quieter version. A Cursor staffer explained one on December 1, 2025: Cursor launched the npx process "but doesn't get a response from the MCP server within ~60 seconds, then closes the client" with No server info found.

Where to read the real error

Cursor's MCP docs say to open the Output panel (Ctrl+Shift+U, or Cmd+Shift+U on a Mac) and pick "MCP Logs" from the dropdown. In January 2026 Cursor's support engineer added that a red server has an "Error - Show Output" link that jumps straight there.

The log didn't always help. Early in 2025 a local server's own error output went nowhere, and people in the big thread resorted to catching the process in Process Explorer to see why it died. A Cursor developer replied on May 25, 2025 that the next version (0.51) "will have stderr properly redirected to mcp output logs". So if you're on anything recent, the server's crash message should be in there.

Fixes for a local (command) server

• Run the exact command and args from your mcp.json in a terminal. If it fails there, fix that first. One user's servers came back after upgrading from Node 18.
• Use absolute paths. Cursor may not load the PATH your shell does, so version managers like nvm or fnm can leave it unable to find npx or node. Staff suggested installing the package globally and pointing command at the full path.
• Keep stdout clean. Staff said the server must send JSON-RPC (the message format MCP uses) "only to stdout, and logs to stderr (if logs go to stdout, it breaks the MCP protocol)". A startup banner printed to stdout is enough to break it.
• On Windows, the old workaround was "command": "cmd" with "/c", "npx", ... in args, because npx there is a batch file (npx.cmd) that needs cmd.exe to run it.

WSL used to be its own trap: Cursor ran stdio servers on the Windows side. Users in the thread reported that Cursor 0.50 started running them in the remote workspace (WSL or Remote SSH), so a plain npx command works again.

Fixes for a remote (URL) server

Here the line above Client closed is usually about authentication or certificates. Fix the header, token or sign-in it names, then toggle the server off and on in settings to reconnect.

If a local server that was working dies mid-session, don't wait for it. A Cursor staffer said on July 28, 2026 that a dead stdio server "otherwise only retries on a slow timer", and that toggling it off then on reconnects it immediately.