[Bug] All MCP server processes are orphaned after conversation ends — accumulate indefinitely, causing system memory exhaustion

Google Antigravity
,
1

Summary

Every MCP server configured via command + args (i.e., spawned as a child process) is never terminated when the conversation that spawned it ends. Processes accumulate with each new conversation and eventually exhaust system RAM and swap.

mongodb-mcp-server was the first to become visible due to its significantly higher per-process memory footprint (~65 MB vs ~2–3 MB for others), but the leak affects all npm-based MCP servers equally.

Environment

  • Antigravity: 1.22.2
  • VSCode OSS: 1.107.0 (Commit: 62335c71d47037adf0a8de54e250bb8ea6016b15)
  • Electron: 39.2.3
  • Chromium: 142.0.7444.175
  • Node.js (Electron): 22.21.1
  • Node.js (nvm, used for MCP spawn): v20.19.4
  • OS: Darwin arm64 24.6.0 (macOS, Apple Silicon)
  • Date of build: 2026-04-02

MCP Config (mcp_config.json)

All of the following servers are affected:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "/bin/bash",
      "args": ["-c", "source ~/.nvm/nvm.sh && npx -y @modelcontextprotocol/server-sequential-thinking"]
    },
    "shadcn": {
      "command": "/bin/bash",
      "args": ["-c", "source ~/.nvm/nvm.sh && npx shadcn@latest mcp"]
    },
    "bullmq-docs": {
      "command": "/bin/bash",
      "args": ["-c", "source ~/.nvm/nvm.sh && npx -y mcp-remote https://docs.bullmq.io/~gitbook/mcp"]
    },
    "context7": {
      "command": "/bin/bash",
      "args": ["-c", "source ~/.nvm/nvm.sh && npx -y @upstash/context7-mcp@latest"]
    },
    "mongodb-mcp-server": {
      "command": "/bin/bash",
      "args": ["-c", "source ~/.nvm/nvm.sh && npx -y mongodb-mcp-server"],
      "env": { "MDB_MCP_CONNECTION_STRING": "mongodb://localhost:27017/" }
    }
  }
}

Reproduction Steps

  1. Configure one or more MCP servers using command/args in your MCP config.
  2. Start multiple conversations over multiple days that use any MCP tool.
  3. Close those conversations normally (without restarting Antigravity).
  4. Check orphaned processes:
# Count all MCP-related orphans
pgrep -f "mongodb-mcp-server" | wc -l
pgrep -f "mcp-server-sequential-thinking" | wc -l
pgrep -f "context7-mcp" | wc -l
pgrep -f "mcp-remote" | wc -l

# Check system memory pressure
sysctl vm.swapusage
memory_pressure | grep "free percentage"

Observed Behavior

After ~11 days of normal usage (no full system restarts):

Process counts and memory per MCP server

MCP Server Orphan Count Avg. Memory/Process Total Memory
mongodb-mcp-server 1,706 ~65 MB ~14.4 GB
context7-mcp ~12/session ~2.5 MB moderate
mcp-remote (bullmq) ~12/session ~2.6 MB moderate
sequential-thinking ~4/session ~2.4 MB low
shadcn ~4/session ~2.4 MB low

mongodb-mcp-server dominated because it holds an active MongoDB connection pool in memory (~65 MB each vs. ~2–3 MB for stateless servers). The others were leaking at the same rate but flew under the radar due to their tiny footprint.

System state at peak

$ sysctl vm.swapusage
vm.swapusage: total = 39936.00M  used = 38782.81M  free = 1153.19M

$ memory_pressure | grep "free percentage"
System-wide memory free percentage: 34%

After force-killing all orphans:

$ sysctl vm.swapusage
vm.swapusage: total = 32768.00M  used = 11028.44M  free = 21739.56M

$ memory_pressure | grep "free percentage"
System-wide memory free percentage: 59%

Swap dropped by ~28 GB immediately.

Root Cause

Confirmed spawn chain

Each MCP server is spawned by Antigravity as:

Antigravity Helper (Plugin)
  └── /bin/bash -c "source ~/.nvm/nvm.sh && npx -y mongodb-mcp-server"
        └── npm exec mongodb-mcp-server
              └── node mongodb-mcp-server     ← actual MCP server

Verified via:

$ ps aux | grep "mongodb-mcp"
/bin/bash -c source ~/.nvm/nvm.sh && npx -y mongodb-mcp-server   ← PID 47543, PPID 1

PPID is 1 (launchd) — the original Antigravity parent already exited, leaving the bash+npm+node chain as orphans under launchd. This happens because:

  1. Antigravity spawns the MCP process when a conversation starts.
  2. When the conversation ends, Antigravity’s process (or the specific plugin handling it) exits without sending SIGTERM to the process group it spawned.
  3. Since the bash wrapper does not propagate signals to child processes by default, npm exec and the underlying node process continue running indefinitely.

Why only mongodb-mcp-server was noticed first

All MCP servers are leaking at the same rate (one set of processes per conversation). The difference is purely memory per process:

  • mongodb-mcp-server maintains a persistent MongoDB connection pool → ~65 MB/process
  • sequential-thinking, context7, bullmq are stateless → ~2–3 MB/process

With 1,706 orphans at 65 MB each = ~14 GB visible RAM pressure. The others, even with the same count, would only consume ~4 GB total — enough to go unnoticed longer.

Expected Behavior

When a conversation ends, Antigravity should send SIGTERM (and after a grace period, SIGKILL) to the process group of each MCP server it spawned for that session.

Suggested Fix

Option A — Kill the process group on session close (recommended)

Antigravity should track the PGID of each spawned MCP process and kill the entire process group on session teardown:

// On spawn:
const proc = spawn('/bin/bash', ['-c', cmd], { detached: true });
// On session close:
process.kill(-proc.pid, 'SIGTERM');

Using detached: true + negative PID kills the entire bash → npm → node chain.

Option B — Use exec in the bash wrapper to avoid intermediate shell

"args": ["-c", "exec npx -y mongodb-mcp-server"]

exec replaces the bash process with npx, making signal propagation direct. This alone does not fix the orphan issue but makes cleanup easier.

Option C — Periodic reaper

As a safety net, a background reaper in Antigravity that periodically checks for MCP processes not associated with any active session.

Workaround

# Kill all orphaned MCP processes
pkill -9 -f "mongodb-mcp-server"
pkill -9 -f "mcp-server-sequential-thinking"
pkill -9 -f "context7-mcp"
pkill -9 -f "mcp-remote"
pkill -9 -f "shadcn mcp"

Antigravity will re-spawn them on the next tool invocation.

Additional Notes

  • This issue affects any MCP server configured with command/args (i.e., all locally-spawned servers). Servers using serverUrl (HTTP-based, like stitch) are not affected.
  • On machines with ≤16 GB RAM, critical degradation can occur within hours of usage.
  • The leak is silent — no warnings are shown in Antigravity’s UI.