Codex startup sub-agent will restart a bunch of mcp, but it will not be automatically cleared after closing the sub-agent. #12976

Activity

1. TripQi

   added

   bugSomething isn't workingSomething isn't working

   on Feb 27, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Feb 27, 2026
3. github-actions commented on Feb 27, 2026

   

   github-actionsbot

   on Feb 27, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Add automatic lifecycle cleanup for completed/idle sub-agents (and unused MCP clients) #12335
   • Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491
   • MCP servers eat up memory when multi-tasking in Codex App #11324
   • Codex CLI multi-agent spawns duplicate Serena MCP instances instead of sharing one connection #12333

   Powered by Codex Action
4. etraut-openai commented on Feb 27, 2026

   

   etraut-openai

   on Feb 27, 2026

   Contributor

   More actions

   When you say "not be automatically cleared", do you mean that the MCP servers are not shut down?

   And what do you mean by "startup sub-agent"?
5. etraut-openai

   marked Add automatic lifecycle cleanup for completed/idle sub-agents (and unused MCP clients) #12335 as a duplicate of this issue on Mar 3, 2026
6. CE0Alex commented on Mar 4, 2026

   

   CE0Alex

   on Mar 4, 2026

   More actions

   Repro confirmation on codex-cli 0.107.0 (WSL/Linux), same core symptom: after sub-agents are closed, many MCP subprocesses can remain alive under the root Codex process.

   Environment

   • Codex CLI: 0.107.0
   • Platform: WSL/Linux
   • Multi-agent enabled with:
     • agents.max_threads = 8
     • features.multi_agent = true
   • Enabled stdio MCPs include:
     • context7, gcloud, gcp-observability, google-analytics, google-workspace, metricool

   Repro

   1. Run an 8-lane sub-agent wave (spawn 8 agents, wait for completion).
   2. Call close_agent for all agent IDs.
   3. Immediately inspect children under the root Codex PID.

   Observed

   Immediately after close_agent calls completed, the root Codex PID still had many direct MCP launcher children (example snapshot had 49
   direct children):

   • 8x context7-mcp
   • 8x gcloud-mcp
   • 8x observability-mcp
   • 8x analytics-mcp
   • 8x workspace-mcp
   • 8x mcp-metricool
   • plus systemd-inhibit

   These were still attached to the same active Codex parent process, not reparented zombies from a dead parent.

   Important distinction

   I understand duplicate MCP instances while agents are active may be by design (#12333, per-agent MCP config isolation).
   The issue here is lifecycle after close: close_agent did not promptly tear down associated MCP subprocesses.

   Expected

   After close_agent (or shortly after with a deterministic timeout), MCP subprocesses associated with those closed sub-agents should be released automatically.

   Request

   Can you confirm intended teardown semantics for close_agent in current builds, and whether this is expected to be fixed in a release after 0.107.0?
7. leonsong09 commented on Mar 28, 2026

   

   leonsong09

   on Mar 28, 2026

   More actions

   I pushed a narrow Windows teardown fix branch here:
   https://github.com/openai/codex/compare/main...leonsong09:fix/windows-stdio-mcp-teardown?expand=1

   Scope:

   • keep a real Windows stdio RMCP process guard
   • kill the spawned Windows stdio process tree on drop/refresh
   • add RMCP + core regressions for teardown

   This does not try to change MCP instance sharing/pooling across active subagents; it only addresses lifecycle cleanup for stale Windows stdio stacks.
8. leonsong09 commented on Mar 29, 2026

   

   leonsong09

   on Mar 29, 2026

   More actions

   I filed a more detailed follow-up report here:

   • Detailed Windows stdio MCP teardown report with ready patch branch #16144

   That report keeps the scope narrow to Windows stdio MCP teardown / lifecycle cleanup, includes a ready compare branch, and documents the regression coverage I validated locally.

   Ready compare branch:

   • https://github.com/openai/codex/compare/main...leonsong09:fix/windows-stdio-mcp-teardown?expand=1
9. etraut-openai

   closed this as completedin 4e0cf94on Apr 28, 2026
10. pull

    added a commit that references this issue on Apr 28, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    ...

    This issue will close once commit 4e0cf94 is merged into the 'main' branch.

    4e0cf94
11. Oreoxp

    added a commit that references this issue on May 7, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    ...

    This issue will close once commit 0271447 is merged into the 'main' branch.

    0271447
12. wangjiecloud

    added a commit that references this issue on Jun 27, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    ...

    This issue will close once commit 1052008 is merged into the 'main' branch.

    1052008