Spawn narrow — turn off the MCP you don't need

The night before this, the same job took my whole Hetzner box down. Silent — no alerts, no SSH, no ping — until a hardware reboot from Hetzner's panel brought it back the next morning. How an uncapped machine dies quietly from swap thrashing is a story of its own. This one is about the small, app-level cause I found when I dug in.

I'd set pks brain extract running across ~6,700 sessions. It builds an AI summary per session by spawning one Claude worker at a time. While it ran, I watched the machine — and memory just kept climbing.

It climbed. 30 GB in one process family, 600+ processes, and it came back every time we cleaned up. The easy explanation was "the extract leaks." It was wrong.

The learning

The extract was well-behaved — the Claude workers sat flat at ~9 GB. What grew was something else entirely: every spawned worker loaded the project's .mcp.json on startup and launched an Aspire MCP server it never needed. That MCP server fired a nuget search that hangs in our devcontainer and turns into a zombie. One leak per worker. Thousands of workers = thousands of hung processes.

The point: an extract worker reads JSON and writes markdown. It needs zero tools. But it inherited my entire MCP stack, because that was the default — and the default is tuned for my interactive dev session, not for a batch worker that runs a thousand times.

The fix was one line on how we spawn Claude:

claude --print --strict-mcp-config   # ignore .mcp.json entirely — load zero MCP servers

With --strict-mcp-config the worker ignores .mcp.json completely. My interactive Aspire MCP stayed in the config for my own work — only the batch workers skip it. The proof landed immediately:

✓ leak-free · 15.8GB used · claude 32/9.6GB · aspire 0 · aspire-managed 0

32 workers running at a flat ~9.6 GB, and zero Aspire processes. The rest of the run — 41 minutes — held flat.

What I took away

Every MCP server costs memory and startup per Claude. On one interactive session you never feel it. But the moment you spawn Claude programmatically — in a loop, in a batch, one worker per item — that cost multiplies by your worker count, and an MCP server that's just slightly wrong in that particular environment becomes a leak that scales with your load.

So: when you spawn a Claude for one narrow job, give it only what the job actually needs. For a worker that just reads and writes files, the right number of MCP servers is zero. Spawn narrow.

(And then there's the other layer: even a well-behaved app shouldn't be able to take down a whole machine. That's the host's job to prevent — with per-container memory limits. That's the host-level story from that night.)