Windows: codex mcp-server / app-server and their child MCP servers are never reaped (accumulate to hundreds over time)

Summary

On Windows, using Codex through its MCP-server path (codex mcp-server, which a host like Claude Code launches) leaks processes: every request spawns a new codex app-server, which in turn spawns the MCP servers from ~/.codex/config.toml — and none of them are reaped when the request/session ends. Over a few days of normal use they accumulate into the hundreds and noticeably degrade the machine.

codex exec (one-shot) does not have this problem — it spawns the same children but cleans them up on normal exit. The leak is specific to the persistent mcp-server/app-server path on Windows.

Environment

• OS: Windows 11
• codex-cli: 0.139.0 (model gpt-5.5)
• Configured MCP servers in ~/.codex/config.toml: playwright, comfyui, node_repl (any configured stdio MCP servers reproduce this)

Observed behavior (controlled A/B, measured with Get-CimInstance Win32_Process)

• Fresh reboot baseline: 1 codex mcp-server, 0 child MCP processes.
• One request through the MCP server: +1 codex app-server, and +1 of each configured MCP server (each as a cmd → npx → node chain). After the request completes, none of these exit.
• After a few days / many sessions: ~800+ lingering node / cmd / codex processes. Parent analysis: only ~3 were true orphans; ~835 still had live parents — piled up under 2 long-lived codex app-server instances (52–56h old), i.e. children accumulating under persistent app-servers rather than being cleaned up.

Contrast: codex exec is clean

Running the equivalent work via codex exec --ephemeral ... - spawns the same MCP children during the run, but all of them return to baseline on normal exit (verified). So the runtime can tear them down — the persistent mcp-server/app-server path on Windows doesn't.

Possibly related

codex app-server daemon <...> reports: app-server daemon lifecycle is only supported on Unix platforms. This suggests Windows app-server lifecycle management is less complete, which may be why child trees aren't reaped on Windows.

Repro

1. On Windows, configure one or more stdio MCP servers in ~/.codex/config.toml.
2. Drive Codex through codex mcp-server (e.g. via an MCP host) and issue several requests.
3. Watch codex.exe, node.exe, and the MCP server processes via Task Manager / Get-CimInstance Win32_Process — they accumulate and never exit.

Impact

Resource exhaustion (hundreds of processes / multiple GB) over long-lived sessions on Windows.

Suggested direction

Reap each app-server and its child MCP process tree when the request/session ends (or on mcp-server shutdown), including a Windows tree-kill (e.g. taskkill /pid <pid> /t /f) since Windows does not cascade-terminate child processes on parent exit.

_(Searched existing issues for duplicates; didn't find an obvious match.)_