Detailed Windows stdio MCP teardown report with ready patch branch

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

Using an API-key-backed custom provider. Subscription tier does not seem relevant to the reproduction.

Which model were you using?

gpt-5.4

What platform is your computer?

Windows

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

Windows Terminal + PowerShell 7

What issue are you seeing?

On Windows, stdio MCP processes can remain alive after the corresponding MCP client lifecycle should already have ended.

More specifically:

• dropping a stdio MCP client may leave the launched Windows stdio process tree alive
• refreshing/replacing MCP servers may also leave the previous stdio MCP launcher tree alive
• over time, this can accumulate stale launcher / child / grandchild processes

I want to keep the scope narrow:

• this is not arguing that all active subagents should share one MCP instance
• this is not proposing MCP pooling / sharing changes
• this is specifically about Windows stdio MCP lifecycle teardown

What steps can reproduce the bug?

A minimal reproduction shape is:

1. Configure one or more stdio MCP servers
2. Start a Codex session that initializes those MCP servers
3. Trigger a lifecycle path that drops or replaces the MCP client

• for example MCP refresh / reconnect / replacement / teardown-related paths

1. Inspect the Windows process tree afterward
2. Observe that old stdio MCP launcher trees can remain alive

What is the expected behavior?

Once a stdio MCP client is dropped or replaced, the previously launched Windows stdio MCP process tree should be torn down promptly and deterministically.

Repeated refresh / replacement cycles should converge back to a bounded baseline instead of leaving stale Windows stdio MCP stacks behind.

Additional information

Related existing reports:

• #12976
• #14233

I already prepared a narrow patch branch focused only on teardown behavior:

• compare link:

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

The patch direction is intentionally small:

• implement best-effort Windows process-tree termination for stdio MCP teardown
• keep a real Windows process guard for stdio RMCP clients
• tear down the old Windows stdio tree on drop / refresh
• add regression coverage at:
• the rmcp-client layer
• the core MCP refresh / replacement layer

I validated that narrow patch locally with:

• cargo +stable-x86_64-pc-windows-msvc fmt --all --check
• cargo +stable-x86_64-pc-windows-msvc check -p codex-utils-pty -p codex-rmcp-client --tests --locked
• cargo +stable-x86_64-pc-windows-msvc check -p codex-core --tests --locked
• cargo +stable-x86_64-pc-windows-msvc test -p codex-rmcp-client --test windows_stdio_teardown -- --nocapture
• cargo +stable-x86_64-pc-windows-msvc test -p codex-rmcp-client --test resources -- --nocapture
• cargo +stable-x86_64-pc-windows-msvc test -p codex-core refresh_mcp_servers_is_deferred_until_next_turn -- --nocapture
• cargo +stable-x86_64-pc-windows-msvc test -p codex-core refresh_mcp_servers_reaps_previous_stdio_launcher_tree -- --nocapture

I could not open an upstream PR directly because the repository currently appears to restrict PR creation to collaborators, but the compare branch above is ready if maintainers want to review or cherry-pick from it.