MCP stdio reconnect leaks server processes (old process never terminated; 144 orphaned node processes OOM'd a 128 GB server) #4794

Summary

On Linux (2.5.2), stdio MCP servers are leaked on reconnect: when the client decides a server is unavailable and schedules a reconnect, the previous server process is not terminated and keeps running for hours. Combined with a double-spawn at session start, long-running sessions accumulate many copies of every MCP server. On our 128 GB server this grew to 144 node processes (~0.9 GB RSS each) and triggered a global OOM that killed unrelated services.

Evidence

Client log (~/.kimi-code/logs/kimi-code.log, two concurrent sessions):

• mcp server reconnect scheduled — 1589 events; mcp server unavailable ... closed unexpectedly — 178 events.
• At session start the same server is spawned twice, 3 ms apart (jira-easy-mcp, stderr timestamps 07:25:10.012 and 07:25:10.015). mcp.json has 9 unique servers, no duplicates.
• ~5 minutes after session start, all 9 servers are declared closed unexpectedly within a 16-second window (mass recycle), and reconnect attempts start spawning replacements.
• Processes declared closed unexpectedly remain running: the two jira-easy-mcp instances from 07:25:10 were still alive 5+ hours later (ps verified, still children of the live session). The client apparently closes the stdio pipes but never signals/kills the child; the servers also don't exit on stdin EOF.
• The churn rate correlates with MCP tool usage: during an active agent session new server generations appear every few minutes (pids 6606 → 172071 → 233766 → 285988 for the same session within ~40 min).
• journalctl on 2026-11-09: kernel OOM killer, 124 GB anonymous memory, page cache at 0; victims included the user's systemd manager and an unrelated task queue daemon.

Expected behavior

1. One process per configured MCP server per session (no double spawn at init).
2. On reconnect, terminate the previous server process (ideally its process group) before spawning a replacement.
3. On client exit (including crash/SIGKILL where possible via pipe close), the server process must not outlive the session — stdio servers should exit on stdin EOF (this part is also on server implementations, but the client should enforce it with a kill).

Environment

• Kimi Code CLI 2.5.2 (2026-11-06), installed via official script
• Ubuntu server, Linux x86_64, 128 GB RAM
• MCP servers: local-coder, jira-easy-mcp, google-docs-mcp, chrome-devtools-mcp, codex-security (plugin), github, confluence, postgres, agent-memory

Happy to provide the full client log or run diagnostics builds.