Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor version: 3.11.13
Operating system: macOS 26.5.1
Steps to reproduce:
Configure a local stdio-based MCP server (in my case, SDL-MCP) that performs meaningful cleanup work on shutdown (e.g., closing a database connection, stopping file watchers).
Use Cursor normally with the MCP server connected.
Either restart Cursor, or wait for Cursor to periodically reconnect the MCP session on its own (observed after ~5 minutes of idle/normal use).
Expected behavior: Cursor should wait for the previous MCP server process to fully exit or release its held resources before spawning a replacement process for the same server.
Actual behavior: Cursor sends stdin-end to the MCP server to initiate shutdown, then immediately attempts to spawn a replacement process before the original process’s cleanup completes. If the server’s cleanup takes more than roughly a second, the new process fails to acquire a resource (in my case a database file lock) still held by the still-shutting-down old process, and the connection fails.
Separately, on initial connection (cold start), Cursor sometimes spawns two connection attempts within 50-100ms of each other. The second correctly fails due to the server’s own single-instance protection, but Cursor then sends stdin-end to the first, already-successfully-connected process, killing a healthy connection.
Console errors (from Help > Toggle Developer Tools, MCP output panel):
21:04:56.461 stopped connection: user-sdl
21:04:56.464 connecting stdio for “sdl”
21:04:56.465 [sdl-mcp] Received stdin-end, shutting down gracefully…
21:04:57.076 PID file written (new instance starting)
21:04:57.122 Fatal error: LadybugDB initialization failed … Could not set lock on file … database file appears to be locked by another process
21:04:58.008 [sdl-mcp] Cleanup “watchers” completed in 1543ms
The final line shows the old process’s cleanup only completing ~1.5 seconds after Cursor already attempted to spawn the replacement.
Workaround: Toggling the MCP server off and back on in Settings → MCP forces a clean single spawn and restores the connection.
Request ID: [not applicable — this occurred in the MCP connection layer, not a chat/agent request, so no request ID was generated. Happy to provide one if this happens during an active agent session.]
Steps to Reproduce
See above
Expected Behavior
See above
Operating System
MacOS
Version Information
Version: 3.11.13
VS Code Extension API: 1.125.0
Commit: 3f21b08f0b436a07be29fbfe00b304fa15553350
Date: 2026-07-10T01:45:28.254Z
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.5.0
For AI issues: which model did you use?
Sonnet 5
For AI issues: add Request ID with privacy disabled
N/A
Additional Information
See above.
Does this stop you from using Cursor
No - Cursor works, but with this issue