[Bug] stdio MCP server hangs on macOS when response > 8 KB (pipe buffer exhaustion)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When a stdio MCP server returns a response larger than ~8 KB, the MCP call hangs indefinitely in Cursor (shows “Running…” forever, never resolves). The MCP server process stays alive but is permanently blocked inside write() on its stdout.

Root cause (confirmed via macOS sample(1) profiler + lsof):
Cursor spawns stdio MCP servers with stdio: [“pipe”,“pipe”,…]. On macOS, anonymous pipes have a fixed 8 KB kernel send buffer (not configurable, unlike Linux). When the MCP server writes a response > 8 KB to stdout, the first 8 KB fills the kernel pipe buffer and the server’s write() syscall blocks waiting for Cursor to drain the pipe. Cursor’s Node.js stream (child.stdout.on(“data”, …)) is in paused mode by default and buffers up to readableHighWaterMark (16 KB) before emitting data — so it doesn’t drain the pipe in time. This causes a deadlock: the server is blocked writing, Cursor is waiting for the JSON-RPC response that will never arrive.

Isolation test: using a hand-rolled Python stdio MCP client (instead of Cursor) against the exact same server, a 22 KB response returns in 0.38s with zero issues. Cursor is the only variable.

Relevant code in cursor-mcp/dist/main.js:
this._process.stdout?.on(“data”, e => {
this._readBuffer.append(e);
this.processReadBuffer();
})
The stream is never put into flowing mode via resume(), so the pipe drains too slowly.

Steps to Reproduce

  1. Set up any stdio MCP server that returns a JSON response > 8 KB (e.g. a search/query tool that returns documents with full content)
  2. Call it from Cursor Agent
  3. Observe: the call shows “Running…” forever and never returns
  4. Check with ps aux | grep <mcp-server>: the process is alive but CPU=0%, blocked in write()
  5. Verify with macOS sample <pid>: the blocked thread stack shows _Py_read / write syscall permanently parked

Reliable repro: any MCP knowledge base search that returns > 8 KB of JSON content (e.g. search with 2+ results where each hit contains full document text) hangs 100% of the time.

Expected Behavior

The MCP tool call should return the result immediately. The stdio transport should not block when the response is larger than the macOS pipe buffer (8 KB).

Operating System

MacOS

Version Information

Version: 3.1.17
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Arch: arm64
macOS: 15.5 (24F74)

Additional Information

Suggested fix (one-liner in cursor-mcp/dist/main.js, after the process is spawned):
this._process.stdout?.resume();

This puts the Node.js readable stream into flowing mode so it continuously drains the pipe kernel buffer without waiting for readableHighWaterMark to be reached.

Workaround applied on MCP server side: strip large fields from the JSON response to keep it under 8 KB. This is fragile and loses data; the fix should be on the Cursor side.

This bug does NOT affect non-macOS systems (Linux pipes are configurable/larger), nor does it affect HTTP/SSE MCP transports. It is specific to stdio transport on macOS.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed breakdown with sample and lsof. That level of debugging really helps.

On the suggested fix, there’s one nuance. In Node.js, attaching a listener via stdout.on('data', ...) automatically switches the readable stream into flowing mode (docs: Stream | Node.js v25.9.0 Documentation), so an explicit resume() would be a no-op. readableHighWaterMark in flowing mode also doesn’t delay data events. It only affects when Node stops reading from the OS into its internal buffer. So the “Node-side pipe buffering” theory doesn’t quite add up on its own.

But the symptom (hang on large stdio MCP responses) could still be real for other reasons. For example, if the extension host event loop gets stuck under load, data events might not be handled quickly enough, and the 8 KB macOS pipe buffer could actually fill up. I want to validate that separately.

To move forward, can you share:

  1. A minimal repro. Which exact MCP server is it, or a mock server that reliably returns > 8 KB
  2. Does it reproduce on a clean profile with cursor --disable-extensions
  3. Logs from Output → MCP Logs right when it hangs
  4. Does the same happen via the CLI, using cursor-agent with the same mcp.json

If it doesn’t hang in the CLI, that’s a strong signal the issue is in the extension host event loop, not the transport.