MCP utility process crash

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The shared MCP utility process (mcp-process) crashes with a V8 OOM when an MCP server returns a very large tool response, and after the automatic restart the open window never reconnects to any MCP server — every subsequent tool call fails with “Timed out waiting for connection to ” until the window is manually reloaded.

Two distinct issues:

  1. OOM crash on large MCP responses. A LangSmith remote MCP server (streamableHttp, https://eu.api.smith.langchain.com/mcp) returned a multi-MB JSON tool result (fetch_runs on a large trace; a surviving call measured 1.8 MB, the crashing ones were larger). The utility process died with:

    [64092:0722/102433.335794:ERROR:electron/shell/common/node_bindings.cc:185] OOM error in V8: Zone Allocation failed - process out of memory
    [McpProcess] utility process crashed pid=64092 code=5 reason=crashed

    The GC trace shows only ~34 MB of ~48 MB heap in use at death, so this is a single oversized zone allocation (parsing/serializing one huge JSON string), not gradual heap exhaustion. Reproduced 3 times (2026-07-21 14:51:02, 2026-07-22 10:16:16, 2026-07-22 10:24:33), each exactly when the large tool call was in flight. The in-flight call returns “Error: Aborted.” to the agent.

  2. No reconnect after crash. The utility process auto-restarts within ~1s and initializes fine (ipcReady/initDone), but the window’s MCP connections are never re-established. All MCP tool calls — including to unrelated healthy servers (PostHog, Linear) — then fail with “Timed out waiting for connection to …” indefinitely. Only a window reload restores MCP. Logs after restart show the new process sitting at phase=after_init_done with no connect attempts until reload.

Crash 1 takes down all MCP servers because they share one utility process; bug 2 turns a transient crash into a permanently broken MCP session.

Version: Cursor 3.12.17 (dd27f0c4), macOS 15.x (darwin 25.3.0), Apple Silicon.
Relevant logs: logs//mcpprocess.log and main.log (“[UtilityProcess type: mcp-process …] crashed with code 5”).

Steps to Reproduce

  1. Add a remote streamableHttp MCP server that can return very large tool results (e.g. LangSmith: { “mcpServers”: { “LangSmith”: { “url”: “https://eu.api.smith.langchain.com/mcp” } } }).
  2. In an agent chat, call a tool that returns a multi-MB JSON payload (e.g. LangSmith fetch_runs with a trace_id of a large trace — its server ignores the max_chars_per_page parameter and returns the full trace).
  3. Observe the tool call fail with “Error: Aborted.” and mcpprocess.log show “OOM error in V8: Zone Allocation failed” followed by “utility process crashed … code 5”.
  4. Call any MCP tool on any server (even a different, healthy one) — every call now fails with “Timed out waiting for connection to ”.
  5. Reload the window — MCP works again until the next large response crashes it.

Expected Behavior

  • Large MCP tool responses should be size-capped or streamed to disk by the utility process instead of OOM-crashing it (agent-side truncation to a file already exists, so capping the transport read seems consistent). There should be a way to increase the memory because 40MB is super small.
  • A crash in one server’s response handling shouldn’t take down all MCP servers.
  • After the utility process auto-restarts, existing windows should re-establish their MCP server connections automatically instead of timing out forever until a manual window reload.

Operating System

MacOS

Version Information

Version: 3.12.17
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Not a model issue

Does this stop you from using Cursor

No - Cursor works, but with this issue

8

Hey @sciem13
Both halves are genuine bugs on our side:

  1. OOM crash on a large tool response. The shared MCP process reads the entire tool result into memory with no size cap, so a single multi-MB payload (like your LangSmith fetch_runs on a big trace) can OOM it. And right now a crash takes down all your MCP servers at once, not just the one that returned the oversized payload.
  2. No auto-reconnect after the crash. Once the process restarts, existing windows don’t re-establish their server connections, so every tool call - even to healthy servers like PostHog/Linear - fails with “Timed out waiting for connection to …” until you reload.

Workaround for now: when MCP wedges after a crash, run Developer: Reload Window (Cmd+Shift+P) to re-establish the connections until the next oversized response.

I’ve reported both the OOM-on-large-response and the failure-to-reconnect to our team, along with your suggestions (size-cap/stream large responses, contain a crash to a single server, and auto-reconnect after restart). I’ll follow up here as they’re addressed.

One practical mitigation in the meantime: since that LangSmith server ignores max_chars_per_page and returns the full trace, scoping fetch_runs to a smaller trace_id (or a narrower query) should keep responses under the size that triggers the crash.

9

Thanks, I am working around that for the time being, but it is frustrating. I think few Mbs shouldn’t crash the process.