[Windows] Completed subagents leave STDIO MCP Node.js processes running (245 processes / 18 GB)

Start by tracing the MCP manager and subagent lifecycle around the session transcript’s task_complete event, then reproduce the issue with the provided PowerShell process-counting commands. Check whether each subagent’s STDIO MCP processes remains attached after completion; done means completed subagents no longer leave their Node process sets running or cause counts to grow.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.715.8383.0 (x64)

What subscription do you have?

Chatgpt pro

What platform is your computer?

Windows 11 Home, 64-bit, version 10.0.26200 (build 26200)

What issue are you seeing?

Node.js version

Node.js v24.15.0, installed at %ProgramFiles%\nodejs\node.exe
When a Codex task spawns subagents while multiple local STDIO MCP servers are enabled, each subagent starts its own copy of every enabled Node-based MCP server. After a subagent records task_complete, those MCP processes remain alive instead of being stopped.

The process count therefore grows approximately linearly with the number of subagents created during the lifetime of the Codex Desktop process. In the observed session, this reached 245 Node.js processes and approximately 18.3 GB of working-set memory.

What steps can reproduce the bug?

1. On Windows, enable several local Node-based STDIO MCP servers. My configuration included:
   • npx -y @cyanheads/pubmed-mcp-server@latest
   • npx -y clinicaltrialsgov-mcp-server@latest
   • a local cas_journal Node MCP server
   • Node-based MCP servers bundled with the Data Analytics, Sites, and OpenAI Developers plugins
2. Start Codex Desktop.
3. Run a task that creates multiple subagents.
4. Wait for the subagents to finish and record task_complete in their session transcripts.
5. Inspect the remaining Node processes and their command lines:

$nodes = Get-CimInstance Win32_Process |
    Where-Object Name -EQ 'node.exe'

$nodes |
    Group-Object CommandLine |
    Sort-Object Count -Descending |
    Select-Object Count, Name

$workingSet = Get-Process -Name node -ErrorAction SilentlyContinue |
    Measure-Object WorkingSet64 -Sum

[math]::Round($workingSet.Sum / 1GB, 2)

6. Observe that each new subagent adds another repeated set of MCP processes, but completing the subagent does not reduce the process count.

Expected behavior

When a subagent finishes, Codex should close or dispose of that subagent's STDIO MCP clients and terminate their child processes. Alternatively, MCP clients could be shared or pooled with a bounded lifetime across subagents.

The number of local MCP processes should not continue increasing after subagents complete.

Actual behavior

Each subagent created approximately eight Node processes:

Observed totals:

• 30 repeated MCP process sets × 8 Node processes = 240 Node processes attributable to Codex MCP initialization.
• 5 additional unrelated/orphaned tests/run_fixture_validators.js processes were present, resulting in 245 Node processes overall.
• Total Node working-set memory was approximately 18.3 GB.
• The count remained at 245 across repeated samples several minutes apart.

Evidence that completed subagents retain their MCP processes

• Codex Desktop's codex.exe process started at 09:23:19.
• MCP process sets were then created repeatedly from 09:23:57 through 10:19:05.
• Their creation timestamps closely matched the creation timestamps of subagent session files.
• 25 inspected subagent transcripts ended with an event_msg whose payload type was task_complete.
• The corresponding MCP process sets were still alive after those completion records.
• For one concrete example:
  • Subagent and its MCP processes started at 09:26:18.
  • The subagent recorded task_complete at 09:30:24.
  • Its CAS Journal MCP process was still alive when checked at 10:24:23.
• Process ancestry showed the MCP processes were direct or indirect descendants of Codex Desktop's codex.exe (some npx servers had intermediate cmd.exe and node.exe processes).

Process distribution at the time of capture

Why this does not appear to be a Node.js process-spawning issue

All 240 MCP-related Node processes followed the same Codex/subagent creation pattern and were launched as descendants of the active Codex Desktop process. Multiple independent MCP implementations remained alive in identical per-subagent groups. This points to the Codex session/MCP manager lifecycle rather than one MCP package spawning copies of itself.

I have not changed Node versions yet, because the multiplication is initiated by Codex when sessions/subagents are created. Testing with another supported Node version may still be useful as a secondary compatibility check.

Impact

• Hundreds of Node processes remain after the related subagent work is complete.
• Memory usage can grow into tens of gigabytes during multi-agent workflows.
• The machine becomes slow and may experience memory pressure or paging.
• Fully restarting Codex is currently the practical way to reset the accumulated MCP processes.

Additional context

The strongest current hypothesis is that each subagent initializes its own MCP manager, but the manager or its STDIO child processes are not disposed when the subagent reaches task_complete.

Additional information

No response