Private Workers accumulate without cleanup, leaking MCP server processes and consuming 10+ GB RAM

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When Private Workers (local Cloud Agents) are enabled, Cursor spawns a new cursor-agent worker process each time the IDE starts or reconnects, but does not terminate previous workers for the same workspace/socket.

Each worker spawns the full set of globally configured MCP servers from ~/.cursor/mcp.json. Over several days this accumulates hundreds of processes.

On my machine (61 GB RAM, Linux/KDE Wayland) I observed:

75 concurrent cursor-agent worker processes
70 of them for the same workspace (/home/marco/dev/sereo/yuzu) sharing socket /tmp/cursor-agent-worker-c56b2d8e5a.sock
526 MCP-related child processes totaling ~12.3 GB RAM
Workers dating back to Jul 24 still running alongside new ones from Jul 28
Worker logs show Received shutdown signal, stopping bridge client… but processes do not exit
Only 6 socket files on disk, but 74 workers still running
Global MCP config (lean-ctx, ms-365-mcp-server, playwright-mcp, paymo-mcp, telegram-mcp, sherlock, GitKraken) amplifies the leak: each duplicate worker spawns all 7 servers plus npm exec wrappers for npx-based servers.

Steps to Reproduce

Enable Private Workers / local Cloud Agents in Cursor
Configure multiple MCP servers in global ~/.cursor/mcp.json (especially npx-based ones)
Open a workspace registered as a Private Worker (e.g. via Cloud Agents)
Use Cursor normally over several days — restart Cursor, reconnect after sleep/network changes, run Cloud Agent tasks
Check running processes:
pgrep -cf ‘cursor-agent.*worker start’
ps -eo rss,args --no-headers | awk ‘/ms-365-mcp-server|playwright-mcp|lean-ctx/ {n++} END {print n " MCP processes"}’
free -h
Observe worker count growing (dozens to 70+) while socket files remain few (one per workspace)
Check worker log at ~/.config/Cursor/User/globalStorage/anysphere.cursor-agent-worker/cursor-agent-worker-.log — multiple Starting worker API server entries on the same socket path without prior process exit

Expected Behavior

Starting a new Private Worker for a workspace should terminate the previous worker (and its MCP children) for that socket/workspace key before spawning a new one.

Operating System

Linux

Version Information

Version: 3.13.10
VS Code Extension API: 1.128.0
Commit: 4f02290ccd9304f0e6bf8ee85f6e9106f02ac1f0
Date: 2026-07-23T21:41:07.333Z
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: Linux x64 7.0.0-28-generic

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey there,
Thanks for the thorough writeup, ps output, and log line. Confirming this is a real bug on our end, not something you triggered in your config.

Two things are happening together:

  1. When a worker daemon is asked to shut down, it can hang instead of exiting cleanly — so its child MCP processes stay alive with it. That’s what your log line (Received shutdown signal, stopping bridge client... with no exit after it) is showing.
  2. When a fresh daemon is then started (workspace switch, .cursor/mcp.json edit, reconnect, weekly CLI update), it doesn’t force-kill the hung one first. Both keep running, and over days they stack.

I’ve reported this to our team with your setup and the process/log evidence. In the meantime the sweep you already found is the fastest recovery:

pkill -9 cursor-agent

Trimming ~/.cursor/mcp.json down to just the MCP servers you actually use will also reduce the impact per stuck daemon (each hung daemon carries a full copy of your global MCP config).

I’ll update here once the fix ships.