Local stdio MCP server subprocesses leak indefinitely across session lifetime

Summary

Local stdio MCP servers (e.g. a Python-based Outlook COM automation server, a Python-based personal-finance server) accumulate duplicate subprocesses over the life of a long-running session instead of reusing/terminating the existing connection. Left unchecked, this grows unbounded.

Environment

• Windows 11, Claude Code CLI (both an interactive terminal session and a remote/mobile-triggered session were affected)
• Two local stdio MCP servers configured via claude mcp add, both invoking python.exe <script>.py directly (not npx/node)

Observed behavior

Auditing running processes found 124 stray claude.exe/python.exe processes across two long-lived sessions:

• One remote/mobile session, alive ~30 hours, had accumulated 106 stray processes (roughly one new pair of MCP subprocesses every ~2 hours of session activity).
• A second, actively-used local session accumulated 18 stray processes over a few hours in the same conversation.

For each affected claude.exe session process, every reconnect to a configured local stdio MCP server (context reload / compaction / new tool-call batch, as best I can infer — I don't have insight into the harness internals) spawned a new python.exe subprocess for that MCP server, while the previous subprocess for the same server was left running under the same parent claude.exe, never terminated. This happened identically for two unrelated MCP servers configured in the same project, so it does not appear specific to one server's implementation.

Only the most-recently-spawned subprocess per server was actually live/functional; older ones were fully idle (confirmed via CPU sampling — 0% usage over a 5s window) but still resident, holding OS handles (in this case, a live Outlook COM registration) indefinitely.

Impact

• Unbounded process/handle growth over a session's lifetime, worse the longer a session stays open (e.g., a persistent remote/mobile-triggered session).
• Each stray subprocess held a live COM registration to a desktop application (Outlook), which could plausibly interfere with that application's state if enough accumulate.
• No user-facing signal that this is happening — discovered only by manually auditing Win32_Process via PowerShell after an unrelated tool call started failing.

Expected behavior

Reconnecting to a local stdio MCP server should either reuse the existing subprocess if still alive, or terminate the previous subprocess before/after spawning a replacement — not leave it running indefinitely.

Workaround

Manually identifying and killing stale subprocesses (matched by session-of-origin liveness and keeping only the newest subprocess per server per session). Not a fix — new stray processes continue to accumulate as the session keeps running.