[Bug] MCP Servers Spawn Per-Workspace - Causes Process Explosion and ~10 GB Idle RAM

Product: Antigravity IDE (Windows)
Language Server: v1.19.4
Severity: Performance

TL;DR

Each workspace spawns its own independent set of all configured MCP servers. With 4 workspaces × 9 MCP servers × 2 processes each (npx wrapper + server) = 72 node.js processes consuming ~4.5 GB at idle. These processes are never cleaned up — not on workspace close, not on config change, not on IDE restart.

Observations

Through systematic profiling (Get-Process, Get-CimInstance Win32_Process), the following was measured on a fresh boot:

Process inventory at idle (no user interaction):

Component Count RAM
Antigravity (Electron renderers) 31 6.3 GB
language_server_windows_x64 4 4.4 GB
node.exe (MCP servers) 64 4.5 GB
Total IDE footprint ~100 ~15 GB

MCP duplication pattern (4 workspaces, 9 servers):

Server Instances Expected
@modelcontextprotocol/server-memory 16 2
@upstash/context7-mcp 8 2
mcp-server-docker 8 2
mcp-server-ssh 8 2
server-sequential-thinking 8 2
server-puppeteer 8 2
firecrawl-mcp (disabled in config) 8 0

Lifecycle failures observed:

  1. Close workspace window → MCP child processes persist
  2. Reopen same workspace → new MCP processes spawn alongside orphans → process count went from 64 → 160
  3. Set "disabled": true in config → existing processes unaffected
  4. Full IDE restart → session restore re-spawns MCP set; orphans remain

Only workaround: Stop-Process -Name node -Force followed by IDE relaunch. This reduced idle RAM from 18 GB → 11.7 GB.

Reproduction

  1. Configure 5+ MCP servers in mcp_config.json
  2. Open 3+ workspace windows
  3. Check Get-Process -Name node | Measure-Object
  4. Expected: ~N_servers × 2. Actual: N_workspaces × N_servers × 2
  5. Close a workspace → verify node count unchanged
  6. Disable an MCP server in config → verify its processes persist
  7. Reopen workspace → verify additive process spawning

Suggested Fixes

  1. Shared MCP process pool — one instance per server serving all workspaces, not per-workspace isolation
  2. Lifecycle binding — workspace close should SIGTERM its child processes
  3. Config reactivity — toggling disabled should kill/spawn the corresponding server
  4. Startup cleanup — detect orphaned node processes from prior sessions on launch
  5. Direct invocation — invoke server binaries from npm cache instead of npx -y wrappers to halve process count

Measured on Windows 11, 40 GB RAM, i5-12500H. Happy to provide diagnostic scripts or additional profiling data if helpful.

Linking this to my earlier report on the terminal popup issue: Terminals Popping Up After Update

That one got fixed in v1.19.6 (shell fallback was spawning visible cmd.exe windows for MCP init). While profiling this new issue I noticed the underlying problem goes deeper — the MCP subsystem doesn’t just have a shell pathing issue, it fundamentally lacks lifecycle management. Processes aren’t cleaned up on workspace close, config changes don’t propagate to running instances, and the per-workspace isolation means process count scales multiplicatively instead of linearly.

Both issues live in the same area of the codebase — figured it’s worth connecting the dots for the team.