Codex Desktop on Windows leaves Node/MCP helper processes alive until memory pressure makes PC unresponsive

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

• #29057
• #28980

Powered by Codex Action

Helper processes should be owned by session/subagent ids and reconciled after terminal states.

When spawning Node/MCP helpers, record owner session id, child agent id if any, command, pid, started_at, last heartbeat, and expected shutdown condition. A periodic reconciler can reap helpers whose owner is completed/failed/cancelled and report leaked helpers in doctor.

---

_Generated with ax._

Matching evidence from a Windows 11 host, Codex Desktop, observed during a host-memory incident:

• Snapshot at incident peak: one codex.exe app-server process (the desktop app's own long-lived server, child of the ChatGPT desktop app process) had 175 child node.exe/node_repl.exe processes, ~19 GB combined committed memory. No single child process was large — the mass was entirely in the count, invisible to a normal "top processes by memory" view.
• Shape: ~5 distinct sidecar types repeated across ~35 instances each (./mcp/server.bundle.mjs, ./mcp/server.cjs --stdio, ./mcp/server.mjs, ./mcp/server.mjs --stdio, plus one third-party MCP server's own server.js) — consistent with one full set spawned per session/thread and never reaped, not 175 distinct server types.
• Recurrence: killing the app-server tree (taskkill /F /T on the app-server PID) reaped all sidecars immediately, and the parent app (ChatGPT desktop) auto-respawned a clean app-server ~20 seconds later. Re-checked ~90 minutes later in the same session: the count had already climbed back to 110 children under a fresh app-server PID — so this isn't a one-time leak, it's continuous accumulation during normal use.
• Relief procedure (works today, no code change): identify the Codex app-server root process (its parent is the ChatGPT desktop app process, not a standalone Codex launcher), taskkill /F /T that PID. No need to quit the parent ChatGPT app — it respawns a clean app-server automatically.

Happy to share the exact process-tree snapshot (redacted) if useful for repro.

Additional reproduction: two peer threads coordinating one local tool-heavy workflow

I can reproduce the same class of issue on a substantially newer Windows Desktop build:

• Codex Desktop package: OpenAI.Codex_26.810.4967.0_x64__2p2nqsd0c76g0
• OS: Windows 11 x64
• Physical RAM: 48 GB
• Workload: local ComfyUI workflow validation; the external application itself is not believed to be causal

Trigger pattern

Two peer Codex threads were instructed to exchange findings and advance the same local ComfyUI video-generation test. Both threads repeatedly used local tools to inspect processes, submit or monitor jobs, check queue/history/logs, and validate outputs.

This created a feedback loop:

thread A runs/checks -> thread B analyzes/checks -> thread A retries/checks -> repeat

An audit of local rollout metadata after one Desktop start showed 282 top-level exec calls in roughly 80 minutes across five threads:

• primary benchmark thread: 103 calls
• related workflow/skill thread: 72 calls
• diagnostic thread: 70 calls
• secondary non-ComfyUI thread: 24 calls
• concurrent benchmark retest: 13 calls

The four ComfyUI-related threads accounted for 258/282 calls (91.5%). The earliest rapid growth began when two benchmark threads were active concurrently.

Process evidence

During the incident I observed a peak of approximately:

• 47 node_repl.exe processes
• approximately 947 threads across those helpers
• approximately 496 MB aggregate working set
• all helpers were direct children of the same long-lived codex.exe
• executable shape: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_repl.exe
• helper command lines contained no thread/session identifier

The important part was not the helpers' aggregate memory. Each helper had about 20 threads, so process/thread count and IPC/event-loop overhead grew substantially.

Creation-time correlation against rollout metadata linked surviving helpers to several active threads, but exact ownership was impossible because the process command line exposes no thread/session id.

Paging ruled out as the primary cause

After ComfyUI was idle:

• approximately 37 GB physical RAM was available
• current page-file use was only about 178 MB
• repeated Pages Output/sec and Page Writes/sec samples were zero
• Codex/ChatGPT process memory priority remained normal
• the main Codex process was mostly resident in physical memory

Despite that, the Desktop UI remained noticeably sluggish. Fully exiting and reopening Codex immediately restored responsiveness and removed the helpers.

This suggests the primary problem is helper lifecycle/process-pool reclamation and missing global backpressure, not Windows paging or the external ComfyUI process.

Why this trigger may be useful

This case does not require hundreds of projects or one very large child process. A small number of peer threads coordinating the same local task can multiply top-level tool executions quickly. If helper creation is scoped per execution cell/thread and reclamation is delayed, the creation rate can exceed the reap rate.

Even if retaining these helpers is intentional for resumable execution, the resulting unbounded process/thread growth and UI degradation appear to be a product bug.

Suggested fixes / diagnostics

• Keep the node_repl pool bounded globally and per workspace/thread.
• Reuse helpers for bounded tool-heavy workflows.
• Add idle expiration and deterministic teardown on completed, cancelled, superseded, or closed turns.
• Apply global backpressure when helper/process/thread counts exceed a safe limit.
• Attach owner thread/session id and execution-cell id to helper diagnostics.
• Add a Desktop diagnostic page or codex doctor output that maps helper PID -> owner -> lifecycle state.
• Add a Windows regression test that runs two peer threads repeatedly coordinating a tool-heavy local workflow and verifies that helper count returns to baseline.

As a local mitigation, I changed the workflow instructions to submit once and poll internally inside one bounded runner, resuming the same execution cell instead of creating a new top-level call for every status check. That reduces the trigger rate but does not fix helper reclamation in the Desktop runtime.

Additional reproducible evidence from Codex Desktop for Windows:

Environment

• Codex package: OpenAI.Codex_26.810.6296.0_x64__2p2nqsd0c76g0
• Windows 11 x64
• 32 GB physical RAM
• Desktop app running a ChatGPT-style, tool-enabled task

Reproduction and process lifecycle

I observed the Codex app-server process tree before and after successive tool calls.

1. Each tool-session/tool-call activation created a new node_repl.exe.
2. When local stdio MCP servers were enabled, the same activation also started another complete set of three local QBO MCP launchers/servers.
3. Previous helpers were not retired after the call completed.
4. Creation timestamps formed distinct waves under the same long-lived codex.exe app-server.

In the first sample there were five retained waves, including five instances of each configured MCP server and five node_repl.exe helpers. Cleanup terminated 42 leaked wrapper/runtime processes and recovered about 1 GB of available RAM.

After disabling the three optional local MCP servers and cleaning up, those MCP processes no longer recurred. However, node_repl.exe continued to accumulate. A later bounded retest found:

• node_repl.exe count: 17
• Combined working set: 174 MB
• Combined lifetime CPU: approximately 1 second
• Creation pattern: one process at a time, aligned with successive tool calls
• All were children of the same Codex app-server
• Each helper was idle after creation
• After targeted termination: 0 remained

A within-call “before/after” sample initially masked the leak because the new helper is created before the tool command begins. Comparing persistent counts and creation timestamps across calls exposed the one-per-call growth.

Configuration behavior

I attempted to disable the built-in helper using:

[mcp_servers.node_repl]
enabled = false

Codex later removed or ignored that setting. By contrast, enabled = false persisted and worked for the three ordinary local MCP server entries. This suggests the Desktop-managed node_repl lifecycle bypasses or overrides the normal MCP enablement path.

Expected

• A tool call should reuse an existing healthy helper or terminate the helper when its owning session completes.
• Desktop-managed node_repl.exe count should remain bounded.
• Disabling an optional helper should either be honored or rejected with an explicit validation error, not silently removed/ignored.

Current mitigation

Targeted PID-based cleanup restores performance, but the helpers return with later tool calls. Disabling unrelated optional MCP servers reduces the impact but does not solve the Desktop-managed node_repl leak.

This appears to narrow the trigger from general long-running/subagent use to the ChatGPT-style tool-session activation path on Windows.

Controlled reproduction: activation waves with partial cleanup

I reproduced this on Codex Desktop for Windows using package 26.810.6296.0 on Windows x64 build 26200.

A process-tree snapshot during normal tool-heavy use showed:

• 43 live Codex-managed node_repl.exe helpers
• approximately 421 MiB aggregate working set
• every helper was a direct child of the same live Codex app-server
• the oldest surviving helper had been retained for approximately 39 minutes
• creation times appeared in waves, commonly pairs and sometimes four helpers close together
• helper command lines contained no thread, session, or execution owner identifier

Controlled comparisons refined the trigger:

• A completed local shell inspection did not increase the persistent helper count.
• A completed GitHub connector request did not increase the persistent helper count.
• During roughly 90 seconds of passive observation, the count decreased from 45 to 43 to 37.
• Cleanup was not FIFO: an approximately 39-minute-old helper remained while some newer/intermediate helpers exited.

This confirms Codex-owned retention but does not support a strict “one new process for every individual command” rule. The evidence fits higher-level tool-host/session activation waves followed by partial, non-deterministic reclamation. Some cleanup exists, but it does not keep the population reliably bounded during regular use.

Suggested diagnostics/fix boundary:

• associate each helper with a thread/session/execution owner
• expose owner, last-used time, and expected shutdown condition in diagnostics
• bound the helper pool globally and per owner
• deterministically reap helpers when their owning execution, turn, or thread reaches a terminal state
• add a Windows regression test proving helper count returns to a bounded baseline after repeated tool-host activations

This report intentionally omits user paths, process IDs, workspace/repository names, exact timestamps, runtime hashes, and command history.

Update: recurrence on 26.814.5167 with no other agents active

Additional evidence from a newer Codex Desktop build:

• Codex package: OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0
• Windows 11 x64
• 32 GB physical RAM
• The user confirmed that no other Codex agents/tasks were active.

During a live slowdown investigation, the persistent node_repl.exe population was initially 1, then later measured at 32:

• aggregate working set: approximately 44 MB
• aggregate lifetime CPU: approximately 2.05 seconds
• all helpers were at BelowNormal priority
• creation times ranged across more than two hours
• most helpers were effectively idle

I terminated 31 stale helpers and temporarily retained the newest helper in case it belonged to the current tool runtime. Immediately afterward, two node_repl.exe processes were present again. Because the user confirmed there were no other active agents, I terminated every remaining helper and verified:

node_repl.exe remaining: 0
Codex-owned rg.exe remaining: 0

The foreground codex.exe app-server and its active code-mode host were left running.

This recurrence reinforces that helper cleanup remains non-deterministic and is not reliably tied to whether other agents are active. It also shows that helpers may appear again during the same foreground diagnostic task immediately after targeted cleanup.

Important causality distinction

The peak system slowdown in this particular incident was not caused primarily by the 32 idle helpers. A separate agent-owned recursive rg.exe search was still running, which amplified Microsoft Defender and OneDrive activity:

Before targeted cleanup:
  total CPU:             100%
  disk active time:      83%
  disk queue:             0
  Microsoft Defender:   ~4.25 cores
  OneDrive sync:        ~1.13 cores
  rg.exe:               ~0.50 core, ~570 MB working set

After stopping only rg.exe and its owning PowerShell process:
  total CPU:              24%
  disk active time:        0%
  disk queue:              0

No Voice Chat process or activity was identified as the cause.

So this observation contains two separate lifecycle defects/risks:

1. Codex can leave an agent-owned recursive search running after its useful work has ended, causing substantial secondary Defender/OneDrive load.
2. The Desktop-managed node_repl.exe pool still grows and respawns without a bounded, observable owner lifecycle, even when no other agents are active.

Suggested diagnostic improvement remains: expose helper/child PID -> owning task/turn/tool call -> last-used time -> expected shutdown condition, and reap all agent-owned subprocesses when their operation reaches a terminal state.