[Windows 26.707] Codex Desktop retains five MCP/Node process batches (147 node.exe, 13.9 GiB)

Environment

• Codex Desktop package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• Codex Desktop version: 26.707.8479.0
• Platform: Microsoft Windows NT 10.0.26200.0 x64
• Subscription: not programmatically verified during this diagnostic session
• App-server command shape: codex.exe app-server --analytics-default-enabled
• MCP configuration: 36 enabled entries in one parsed TOML table, consisting of 23 local stdio servers and 13 remote HTTP servers

Summary

Codex Desktop on Windows retained three distinct Codex-owned MCP/Node process batches under one long-lived app-server on package 26.707.8479.0. Their repeated launcher roles and creation-time clustering are consistent with multiple MCP process pools, although process evidence alone does not identify the internal manager, refresh, or session event that owned each batch. The three batches appeared within approximately three and a half minutes of app-server startup in a fresh post-reboot session.

The resulting Codex-owned process tree contained 83 node.exe, 3 node_repl.exe, and 54 cmd.exe launcher wrappers. The Node family alone held approximately 7.742 GiB working set and 6.837 GiB private memory.

This report deliberately distinguishes process-count accumulation from a proven single-process heap leak. The evidence shows repeated process pools and retained process memory.

Observed process ownership

The counted processes were direct or transitive descendants of the Codex Desktop app-server:

node.exe / node_repl.exe
  -> cmd.exe or direct stdio launcher
  -> codex.exe app-server
  -> ChatGPT.exe from the OpenAI.Codex Windows package

The diagnostic excluded:

• 7 live node.exe processes owned by a separately running Claude Code process
• 19 live node.exe processes whose original parent had already exited and therefore could not be attributed with certainty
• unrelated development processes

Current snapshot

The initial aggregate snapshot was collected during the diagnostic window between approximately 09:27 and 09:30 local time. The exact collector timestamp was not preserved for that first snapshot. A later follow-up snapshot below includes an exact timestamp and independently confirms continued growth.

Codex app-server start: 2026-07-13 09:02:12 local
Codex descendants:      193
Codex node.exe:          83
Codex node_repl.exe:      3
Codex cmd.exe:           54
Node working set:        7.742 GiB
Node private memory:     6.837 GiB

Of the 54 Codex-owned cmd.exe processes:

• 27 were npx MCP launcher wrappers
• 24 were direct MCP command wrappers
• 3 were other Codex command wrappers

Process-creation batches

The 86 Codex-owned Node-family processes formed three clear creation batches:

| Batch | First start | Last start | node.exe | node_repl.exe | Total |
|---|---|---|---:|---:|---:|
| 1 | 09:03:08 | 09:03:20 | 25 | 1 | 26 |
| 2 | 09:03:53 | 09:04:13 | 27 | 1 | 28 |
| 3 | 09:05:27 | 09:05:38 | 31 | 1 | 32 |

Representative public MCP launchers were duplicated across the batches:

• 3 Node launchers matching @playwright/mcp
• 3 Node launchers matching @magicuidesign/mcp
• 6 Node processes matching Context7, consistent with repeated npx wrapper plus server processes
• 6 Node processes matching shadcn, consistent with repeated npx wrapper plus server processes
• two local stdio server roles appeared exactly three times each; their machine-specific paths and names are omitted

Most of these MCP tools had not been deliberately invoked in the visible task. The process batches appeared during app/task initialization.

Steps that reproduced the behavior

1. Restart Windows.
2. Launch Codex Desktop with multiple enabled local stdio MCP entries in the normal global configuration.
3. Resume or open a Codex task.
4. Wait several minutes without deliberately invoking most configured MCP tools.
5. Enumerate the full child-process tree rooted at codex.exe app-server using Win32_Process.ParentProcessId.
6. Group node.exe and node_repl.exe descendants by creation time.
7. Observe three near-complete MCP/Node batches retained simultaneously.

Expected behavior

• Codex should maintain a bounded MCP process baseline.
• Multiple tasks, hidden/internal sessions, refreshes, or retries should reuse one appropriate MCP pool or shut down superseded pools promptly.
• Configured tools should remain available without eagerly duplicating every stdio process stack.
• Exiting or replacing an owning thread/session/manager should reap its complete Windows child-process tree.

Actual behavior

• One Desktop app-server retained three distinct MCP/Node process batches.
• Each batch included its own Node REPL and repeated public MCP launchers.
• The retained Node-family processes consumed about 7.74 GiB working memory shortly after startup.
• Task Manager also showed dozens of matching Windows Command Processor wrapper processes.

Exact-timestamp follow-up from the same app-server

At 2026-07-13T09:50:42.6070046-04:00, the original app-server was still running and had accumulated two additional Node-family batches:

Codex app-server start: 2026-07-13T09:02:12.242584-04:00
Codex descendants:      339
Codex node.exe:          147
Codex node_repl.exe:       5
Codex cmd.exe:            94
Node working set:         13.902 GiB
Node private memory:      12.084 GiB

All five retained Node-family creation batches at that timestamp were:

| Batch | First start | Last start | node.exe | node_repl.exe | Total |
|---|---|---|---:|---:|---:|
| 1 | 09:03:08.408892 | 09:03:20.970608 | 25 | 1 | 26 |
| 2 | 09:03:53.649176 | 09:04:13.691603 | 27 | 1 | 28 |
| 3 | 09:05:27.888742 | 09:05:38.997278 | 31 | 1 | 32 |
| 4 | 09:42:18.203629 | 09:42:30.947373 | 32 | 1 | 33 |
| 5 | 09:43:22.063936 | 09:43:35.322062 | 32 | 1 | 33 |

The trigger for batches 4 and 5 is not yet identified. Their timestamps do not support attributing them to the later reviewer-agent starts, so no such causal claim is made.

Related reports

• #31499
• #30753
• #20883
• #28361
• #29079

This is a current-build reproduction of Codex-owned MCP/Node process-batch accumulation in the same lifecycle family. It is not application project code and not Claude Code process ownership. Whether every batch corresponds to a separate internal MCP manager or refresh remains an implementation-level inference.

Privacy and diagnostic availability

No API keys, OAuth tokens, environment values, local usernames, workspace names, raw thread IDs, or private paths are included here. A more detailed sanitized process snapshot can be provided privately if a maintainer requests it.