›_ Codex Issues
Codex Issues / #12976

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

Resolved 💬 5 comments Opened Feb 27, 2026 by TripQi Closed Apr 28, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.106

What subscription do you have?

team

Which model were you using?

gpt-5.3-codex

What platform is your computer?

windows 10

What terminal emulator and version are you using (if applicable)?

Windows Terminal

What issue are you seeing?

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

<img width="699" height="239" alt="Image" src="https://github.com/user-attachments/assets/dd0dbce4-d94e-412a-a76d-ec0e74332105" />

What steps can reproduce the bug?

Let codex start the subagent

What is the expected behavior?

Many duplicate mcp processes appear

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 6 months ago

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

  • #12335
  • #12491
  • #11324
  • #12333

Powered by Codex Action

etraut-openai contributor · 6 months ago

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"?

CE0Alex · 5 months ago

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?

leonsong09 · 5 months ago

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.

leonsong09 · 5 months ago

I filed a more detailed follow-up report here:

  • #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: