MCP Server Race Condition Causes Infinite Process Spawning on Windows (Cursor 2.0.34)

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor 2.0.34 spawns duplicate MCP client instances during initialization, causing infinite recursive process spawning with Node.js-based MCP servers on Windows 11. Within seconds, thousands of npx.exe and cmd.exe processes spawn, rendering the system unusable. This is a REGRESSION - it did NOT occur in Cursor 1.7 and started immediately after updating to 2.0.34.

Steps to Reproduce

  1. Install Node.js via Volta (or any Node version manager) on Windows 11
  2. Configure a Node.js-based MCP server in ~/.cursor/mcp.json:
    {
    “mcp-cli-exec”: {
    “command”: “npx”,
    “args”: [“-y”, “mcp-cli-exec”]
    }
    }
  3. Launch Cursor (may work initially)
  4. Close and reopen Cursor
  5. Within seconds, dozens of npx.exe and cmd.exe processes spawn recursively, growing into the thousands until memory is exhausted
  6. System will eventually become unresponsive; requires multiple PowerShell Get-Process npx | Stop-Process and Get-Process cmd | Stop-Process calls to stop.

Workarounds attempted (ALL FAILED):

  • Using absolute path to npx.exe
  • Using cmd /c npx -y mcp-cli-exec
  • Installing package globally and calling directly
  • All fail because the race condition occurs at Cursor’s level

Expected Behavior

Cursor should spawn a single MCP client instance per configured server. The MCP server should start once and remain stable across Cursor restarts.

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.34 (user setup)
VSCode Version: 1.99.3
Commit: 43fd7d8fe20374ba1dd5ffc9fce937444fbac10c
Date: 2025-10-29T06:51:29.202Z (15 hrs ago)
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

N/A - This is an MCP infrastructure bug, not an AI model issue

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

ROOT CAUSE: Race condition in Cursor’s MCP client initialization. Cursor spawns multiple clients concurrently before the first completes connection.

SCOPE:

  • Affects: All Node.js-based MCP servers on Windows
  • Does NOT affect: Python-based MCP servers (2 processes sometimes, but not recursive), HTTP-based MCP servers, Cursor 1.7

IMPACT: Two development machines (work + personal) almost crashed - repeatable

SUGGESTED FIX: Add synchronization to MCP client initialization to ensure only one CreateClient action proceeds at a time, or check for existing client BEFORE spawning the stdio process.

In case it helps…
MCP user-mcpCLIExec.log:
2025-10-29 17:12:40.150 [info] Handling CreateClient action
2025-10-29 17:12:40.150 [info] Starting new stdio process with command: npx -y mcp-cli-exec
2025-10-29 17:12:40.150 [info] Handling CreateClient action
2025-10-29 17:12:40.150 [info] Starting new stdio process with command: npx -y mcp-cli-exec
2025-10-29 17:12:40.325 [info] Handling ListOfferings action, server stored: false
2025-10-29 17:12:40.325 [error] No server info found
2025-10-29 17:12:40.330 [info] Handling ListOfferings action, server stored: false
2025-10-29 17:12:40.330 [error] No server info found
2025-10-29 17:12:40.836 [error] mcp-cli-exec v1.0.7 running on stdio

2025-10-29 17:12:40.840 [info] Successfully connected to stdio server
2025-10-29 17:12:40.840 [info] Storing stdio client user-mcpCLIExec
2025-10-29 17:12:40.840 [info] CreateClient completed, server stored: true
2025-10-29 17:12:40.955 [info] Handling ListOfferings action, server stored: true
2025-10-29 17:12:40.955 [info] Connected to stdio server, fetching offerings
2025-10-29 17:12:40.955 [info] Found 2 tools, 0 prompts, and 0 resources
2025-10-29 17:12:41.003 [error] mcp-cli-exec v1.0.7 running on stdio

2025-10-29 17:12:41.006 [info] Successfully connected to stdio server
2025-10-29 17:12:41.006 [info] A second client was created while connecting, discarding it.
2025-10-29 17:12:41.006 [info] CreateClient completed, server stored: true
2025-10-29 17:12:41.121 [info] Handling ListOfferings action, server stored: true
2025-10-29 17:12:41.121 [info] Connected to stdio server, fetching offerings
2025-10-29 17:12:41.122 [info] Found 2 tools, 0 prompts, and 0 resources
2025-10-29 17:12:41.249 [info] Handling ListOfferings action, server stored: true
2025-10-29 17:12:41.249 [info] Connected to stdio server, fetching offerings
2025-10-29 17:12:41.249 [info] Handling ListOfferings action, server stored: true
2025-10-29 17:12:41.249 [info] Connected to stdio server, fetching offerings
2025-10-29 17:12:41.250 [info] Found 2 tools, 0 prompts, and 0 resources
2025-10-29 17:12:41.250 [info] Found 2 tools, 0 prompts, and 0 resources

Does this stop you from using Cursor

Yes - Cursor is unusable

2

Hey, thanks for the report. I’ll pass it to the team.

4

In case it helps, I got a temporary hack to work using a simple PowerShell wrapper script.

npx-wrapper.ps1

param(
    [Parameter(ValueFromRemainingArguments = $true)]
    [string] $Args
)

& npx @Args

exit $LASTEXITCODE

Then configure the npx MCP server like this:

“obsidian-volta”: {
“command”: “pwsh”,
“args”: [
“-NoLogo”,
“-NoProfile”,
“-ExecutionPolicy”,
“Bypass”,
“-File”,
“C:\path\to\npx-wrapper.ps1”,
“-y”,
“mcp-obsidian”,
“C:\Obsidian\MainVault”
]
}

1 Like
5

I’m not sure what’s happening but I have a DCR / Oauth protected MCP server for my work and we started getting BLOWN UP by Cursor DCR requests and it created thousands of clients (several people have our MCP server in cursor I guess). I had to disable Cursor from our DCR flow even for paying customers. I hope this can be addressed soon.

1 Like