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

**URL:** <https://discuss.ai.google.dev/t/bug-mcp-servers-spawn-per-workspace-causes-process-explosion-and-10-gb-idle-ram/129054>\
**Category:** Google Antigravity\
**Tags:** mcp\
**Created:** [March 6, 2026, 2:55am UTC](https://discuss.ai.google.dev/t/bug-mcp-servers-spawn-per-workspace-causes-process-explosion-and-10-gb-idle-ram/129054 "2026-03-06T02:55:10Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![NeoNerd](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/neonerd/32/98344_2.png) [@NeoNerd](https://discuss.ai.google.dev/u/NeoNerd)\
**Post date:** [March 6, 2026, 2:55am UTC](https://discuss.ai.google.dev/t/bug-mcp-servers-spawn-per-workspace-causes-process-explosion-and-10-gb-idle-ram/129054/1 "2026-03-06T02:55:10Z")

</div>

**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._

---

<div class="post-metadata">

**Author:** ![NeoNerd](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/neonerd/32/98344_2.png) [@NeoNerd](https://discuss.ai.google.dev/u/NeoNerd)\
**Post date:** [March 6, 2026, 3:07am UTC](https://discuss.ai.google.dev/t/bug-mcp-servers-spawn-per-workspace-causes-process-explosion-and-10-gb-idle-ram/129054/2 "2026-03-06T03:07:08Z")

</div>

Linking this to my earlier report on the terminal popup issue: [Terminals Popping Up After Update](https://discuss.ai.google.dev/t/terminals-popping-up-after-update/126844)

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.