VS Code extension: long-lived claude.exe hosts keep all stdio MCP servers running indefinitely, accumulating hundreds of child processes

Environment: Windows 11 Pro (10.0.22631), VS Code with the Claude Code extension, several workspaces open concurrently, MCP servers configured via a plugin (5 stdio servers per session, each a Python launcher that spawns one backend child).

Observed: Each Claude Code extension host (claude.exe) keeps every stdio MCP server it spawned running for its own full lifetime, with no idle teardown. On a workstation where windows stay open for days, this compounds: a census on 2026-07-28 found 12 claude.exe processes under 6 live Code.exe parents, the oldest started 7 days prior, together pinning 52 MCP launcher processes plus 52 backend children - roughly 200 Python processes once transitive children are counted. All of these belong to sessions that are idle, some for days.

Separately, a census taken earlier the same day, before a window reload, found on the order of 60 claude.exe processes - far more than the open windows could account for - and the reload dropped that to 14. So stale hosts also appear to accumulate between reloads and only get cleared when one happens; steady-state, every one of those hosts holds its full MCP process set.

Expected: Some lifecycle bound on MCP subprocesses for idle sessions - e.g. tearing down stdio servers after a session has been idle for a configurable period and respawning on demand, and/or ensuring superseded extension hosts exit promptly on window reload.

Impact: Hundreds of resident processes and their memory on developer machines with multi-day uptimes. Users generally have no idea an idle window from last week is holding 10+ processes.

What we've ruled out on our side: Our MCP launcher already implements reap-on-parent-death (if claude.exe dies, the launcher and its backend exit; verified working). That handles crashed/killed hosts but can't help here, because the hosts never die. We also considered a GC that kills stale hosts, but process-tree evidence can't distinguish an abandoned host from an active window in another workspace, so there's no safe kill signal from the outside - which is why we think the fix belongs in the host's own lifecycle management.