Symptom
Agent Host MCP server processes are never shut down for the lifetime of the agent host process. Every session that configures MCP servers spawns MCP server subprocesses, and when the session goes idle and is no longer being viewed, those subprocesses keep running. Over a long-lived window they accumulate without bound.
Observable effects:
- Orphaned MCP subprocesses pile up. Open several agent sessions that use MCP servers, then stop viewing them (close the tabs / switch away). The MCP server child processes for those idle sessions stay alive. Process count keeps climbing the more sessions you touch.
- Duplicate MCP servers. The same MCP server ends up running many times over — one (or more) copy per session you've opened, even though only one session is active.
- Memory / handle growth over time. A long-lived agent host process steadily grows its RSS and open-handle/socket count as idle sessions' MCP servers are retained.
- Worst on machines where MCP servers are heavy (language servers, DB connections, headless browsers, etc.), where each leaked server holds real resources.
Why it happens
Idle-session eviction in the agent host is currently disabled, so when a session loses its last subscriber we keep everything in memory — including the provider's live SDK session, which owns the running MCP servers. Nothing releases them until the whole agent host process exits.
Even before eviction was disabled, the eviction path only dropped the lightweight cached protocol state and never released the provider's SDK session, so MCP servers would have leaked regardless.
Repro
- Configure one or more MCP servers for Agent Host sessions.
- Open an agent session that starts those MCP servers; confirm the MCP server subprocess(es) are running.
- Open several more sessions (or the same session repeatedly), then close/stop viewing them so they go idle with no subscribers.
- Observe the MCP server subprocesses for the idle sessions are still alive, and the count grows with each session.
Expected
When a session goes idle and no client is subscribed to it, its MCP servers (and other per-session SDK resources) should be released and their processes shut down, while durable data is preserved so the session resumes losslessly on the next access.
Notes
This is the most user-observable part of a broader "idle sessions are never released from memory" problem (leaked SDK sessions, cached protocol state, per-session shells, etc.). A fix is in progress in #324854.
Symptom
Agent Host MCP server processes are never shut down for the lifetime of the agent host process. Every session that configures MCP servers spawns MCP server subprocesses, and when the session goes idle and is no longer being viewed, those subprocesses keep running. Over a long-lived window they accumulate without bound.
Observable effects:
Why it happens
Idle-session eviction in the agent host is currently disabled, so when a session loses its last subscriber we keep everything in memory — including the provider's live SDK session, which owns the running MCP servers. Nothing releases them until the whole agent host process exits.
Even before eviction was disabled, the eviction path only dropped the lightweight cached protocol state and never released the provider's SDK session, so MCP servers would have leaked regardless.
Repro
Expected
When a session goes idle and no client is subscribed to it, its MCP servers (and other per-session SDK resources) should be released and their processes shut down, while durable data is preserved so the session resumes losslessly on the next access.
Notes
This is the most user-observable part of a broader "idle sessions are never released from memory" problem (leaked SDK sessions, cached protocol state, per-session shells, etc.). A fix is in progress in #324854.