MCP Process Leak / Orphaned Children on Restart

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Cursor restarts (either via “Developer: Reload Window” or an app update/crash), it fails to terminate managed MCP server processes. These processes persist as orphans, eventually being adopted by launchd (PID 1). Over multiple restarts, this results in a compounding “process pile-up” that consumes significant system memory and can lock ports (e.g., MongoDB’s 27017).

These cumulative orphan processes lead to significant memory pressure and resource exhaustion, eventually resulting in severe system degradation and instability.

Steps to Reproduce

  1. Configure any custom MCP server (e.g., a simple node or npx based server).
  2. Open Cursor and verify the MCP is running.
  3. Run the command: Developer: Reload Window multiple times.
  4. Check the system process table: ps -ef | grep <mcp-name>.
  5. Observed Result: Multiple instances of the MCP server are running; only the most recent set is responsive.
  6. Expected Result: Cursor should send a termination signal to all child MCP processes before exiting or reloading.

Expected Behavior

Upon a window reload or application exit, Cursor should gracefully terminate all child MCP processes (sending SIGTERM or SIGKILL) to ensure a clean environment for the new session.

Screenshots / Screen Recordings

Screenshot 2026-04-02 at 1.29.19 PM.png
Screenshot 2026-04-02 at 1.29.19 PM.png3354×1950 648 KB

Operating System

MacOS

Version Information

Version: 2.6.22 (Universal)
VSCode Version: 1.105.1
Commit: c6285feaba0ad62603f7c22e72f0a170dc8415a0
Date: 2026-03-27T15:59:31.561Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Evidence & Logs
I monitored the process tree using a recursive tracking script. The logs show PIDs jumping from “Active” (tethered to Cursor) to “Orphan” (tethered to PID 1) upon every reload.

Observed Process Growth:

Start: 7 Active, 0 Orphans

After 1st Restart: 7 Active, 7 Orphans

After 5th Restart: 7 Active, 42 Orphans

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like
6

Hi @Aniket_B,

This is a known issue. MCP server child processes are not properly terminated when you reload the window or restart Cursor, leading to the orphan pile-up you’re seeing.

Several other users have reported the same behavior:

Our team is aware of this. In the meantime, a few workarounds:

  1. Periodically kill orphaned processes manually:
pkill -f mongodb-mcp-server

  1. Fully quit and relaunch Cursor (Cmd+Q, then reopen) instead of using Developer: Reload Window when possible. A full quit is more likely to clean up child processes than a window reload.

  2. Some MCP server authors have added stdin close detection so the server shuts down when Cursor exits. There’s a gist with this approach if you want to apply it to custom servers.

Thanks for the detailed report and the process tracking data — it helps us prioritize the fix.