Skip to content

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

Open
Open
[Windows 26.707] Codex Desktop retains five MCP/Node process batches (147 node.exe, 13.9 GiB)#32797
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformancewindows-osIssues related to Codex on Windows systems

Description

@wherewolf87
wherewolf87
opened on Jul 13, 2026

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

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    mcpIssues related to the use of model context protocol (MCP) servers
    performance
    on Jul 13, 2026

  2. github-actions commented on Jul 13, 2026

    @github-actions
    github-actionsbot
    on Jul 13, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. wherewolf87
    changed the title [-][Windows 26.707] Codex Desktop spawns three MCP/Node process pools within minutes (83 node.exe, 7.74 GiB)[/-] [+][Windows 26.707] Codex Desktop retains five MCP/Node process batches (147 node.exe, 13.9 GiB)[/+] on Jul 13, 2026

  4. onovich commented on Jul 22, 2026

    @onovich
    onovich
    on Jul 22, 2026

    I can confirm the same MCP/Node lifecycle family on Codex Desktop for Windows 26.715.4045.0.

    In one process snapshot, a single live codex.exe app-server retained 21 distinct three-process runtime clusters, for 63 processes in total:

    • 21 × node_repl.exe
    • 21 × node.exe ./mcp/server.mjs
    • 21 × node.exe ./scripts/start-mcp.mjs

    All 63 processes were direct children of the same live app-server. They were therefore not OS-orphaned processes; they appeared to be logically retained per-thread or per-session runtime pools.

    The clusters had tightly grouped creation timestamps and working directories associated with two workspaces that had no visible active turn at the time of inspection. Their count did not return to baseline automatically after turns completed or tasks were switched.

    Task Manager rounded most of them to 0% CPU, but retained runtime pools still consume memory and handles and cause additional process enumeration and endpoint-security/Defender inspection.

    During cleanup, I intentionally excluded 17 other Codex-owned Node processes because their active ownership could not be proven. Only the 21 verified clusters were removed, and the live Codex app-server plus protected active runtimes remained healthy.

    This supports the lifecycle concerns in #21984 and #20883:

    • MCP servers should start lazily where possible.
    • Inactive threads should dispose their MCP pools after a bounded idle timeout.
    • Threads in the same workspace should reuse a bounded pool.
    • Superseded pools should be reaped reliably.
    • Codex should expose a safe “restart/dispose inactive runtimes” command.

    No private workspace names, paths, prompts or thread IDs are included.

  5. onovich commented on Jul 22, 2026

    @onovich
    onovich
    on Jul 22, 2026

    I published an independent, Windows-first temporary workaround for retained Codex MCP/Node/CLI/CMD process trees:

    https://github.com/onovich/fix-codex-lag.skill

    FixCodexLag groups processes by their actual parent tree and stable identity instead of terminating them by executable name. A group is eligible for cleanup only when at least two independent ownership/lifecycle proofs show that its owning Codex task has ended.

    Before termination, it previews the exact tree and revalidates PID, start time, image, command identity, protected membership, and tree shape. Active, shared, or ambiguously owned groups are preserved.

    This is not an upstream fix, and high process count or memory usage alone is not treated as proof that a group is stale.

  6. bbingz commented on Jul 24, 2026

    @bbingz
    bbingz
    on Jul 24, 2026

    Analysis (community)

    Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

    Observed (from issue + public residual signal)

    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 Windo

    Root-cause hypothesis

    Long-thread / multi-session desktop retains process pools and multi-GB heaps; may combine MCP unreaped children + history retention + renderer growth.

    High-level fix outline (not a PR)

    • Memory budget per thread; unload inactive sessions.
    • Reap helpers; bound concurrent MCP batches (Windows reports of five batches).
    • Fail-first: long-thread fixture + process/memory snapshot assertions.

    Related

    #33582, #32797, #12491 — cross-link rather than fork.

    Questions for maintainers

    1. Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
    2. Preferred residual anchor issue if several open threads describe the same mechanism?
    3. If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

    Happy to refine with more measurements or code pointers. No unsolicited PR from me.

  7. bbingz commented on Jul 24, 2026

    @bbingz
    bbingz
    on Jul 24, 2026

    Analysis (community)

    Residual analysis for #32797 (Windows Desktop retains multiple MCP/Node process batches) — invitation-only. Distinct from macOS growth (#33582) and from WMI/taskkill storm mega-threads. No unsolicited PR.

    Deterministic evidence (code + cross-platform lifecycle)

    Code (5dd992acd3):

    • MCP child handling in tests uses Tokio Child + kill_on_drop(true) with explicit “not a guarantee” commentary (codex-rs/mcp-server/tests/common/mcp_process.rs ≈L39–L82).
    • Production path is codex-mcp connection manager + app-server message processing; Windows Desktop additionally layers Node helpers for extension/app-server bridging (process tree often shows multiple node + codex pairs — as reported on this issue).
    • Local non-Windows host still shows high codex_mcp::connection_manager TRACE (1745 rows under codex-cli 0.146.0-alpha.6), evidence that MCP connect/disconnect is frequent even without Windows Desktop — Windows multi-batch retention is the sharper failure mode of the same lifecycle gap.

    Root-cause hypothesis

    On Windows Desktop, MCP/Node helper batches are spawned per workspace/session without a strict “one manager, join-all-on-close” policy. When sessions end or folders switch, children can remain, stacking Node+MCP batches until RAM/CPU suffer. This is a process supervision residual, not Defender/WMI storm pathology.

    High-level fix outline (not a PR)

    1. Single connection-manager owner per Desktop window; never stack unmanaged batches per folder switch.
    2. On session/folder close: kill process group + wait (Windows Job Object if needed).
    3. UI/doctor: show live MCP helper count; warn above threshold.
    4. Fail-first Windows CI: open N folders with mock MCP; close; assert helper count returns to baseline.

    Questions for maintainers

    1. Should Windows Job Objects wrap MCP helper trees?
    2. Preferred residual anchor between [Windows 26.707] Codex Desktop retains five MCP/Node process batches (147 node.exe, 13.9 GiB) #32797 (Windows batches) and Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491 (GUI reaping)?
    3. Would an invited PR for Job Object + join-on-close tests be useful?

    No unsolicited PR from me.

  8. SergeyPomelov commented on Aug 16, 2026

    @SergeyPomelov
    SergeyPomelov
    on Aug 16, 2026

    Reproduced on Windows with ChatGPT/Codex Desktop 26.810.7004.0 the best flagship vibecoded application.
    Task Manager showed 253 ChatGPT processes using 8.1 GB RAM. Shortly afterward, there were 139 node.exe processes using 12.5 GB, mostly repeated MCP servers such as GitLab, Jira, Confluence, and Chrome DevTools.

  9. mvpereira-git commented on Aug 17, 2026

    @mvpereira-git
    mvpereira-git
    on Aug 17, 2026 – with ChatGPT Codex Connector

    I reproduced the same Windows/App failure mode with a process-level inventory and traced the current ownership model on upstream main.

    Reproduction evidence

    On Codex Desktop 26.810.52044, one app-server accumulated 15 complete MCP suites:

    • 305 Node processes plus 15 Python processes
    • about 15.29 GiB combined working set on a 15.61 GiB host
    • exactly 15 copies of each of 20 Node command signatures
    • 15 Python processes were Cloud SQL/IAP tunnel descendants
    • 300 Node processes used the configured Node 24.18.1 runtime from one canonical installation; this was not duplicate installations on disk
    • each completed tool-execution cell correlated with another full suite, and earlier suites remained alive

    After disabling command/STDIO servers, four consecutive execution samples stayed at zero local MCP Node processes and zero tunnel processes. This isolates eager per-session startup/retention as the multiplier.

    Current upstream topology

    On openai/codex@cd8dc1e9b6dd24d335f4fcb26546f36d045fd59a:

    • core/src/session/session.rs creates a separate Arc<McpRuntime> for each Session
    • core/src/state/service.rs stores that runtime in per-session services
    • codex-mcp/src/runtime.rs explicitly describes mutable MCP state for one Codex thread
    • root threads are eager; cached subagents are lazy only until first MCP use
    • connection_manager.rs reuses a prior generation only inside the same runtime, not across sessions

    PR #19753 added explicit teardown and process-tree cleanup. It did not change per-session ownership or add cross-session reuse. That explains why later Windows reports can still show N live suites while N runtimes remain loaded.

    Proposed smallest upstream direction

    A host-owned STDIO connection pool in ThreadManager/the shared MCP manager, keyed per server by the existing exact McpServerConnectionIdentity, rather than a global singleton by server name.

    Required properties:

    1. single-flight acquisition: N identical sessions create one backend tree
    2. per-session leases/views for tool filtering, timeout, approvals, and events
    3. exact isolation across command/args/env/cwd/auth/plugin identity
    4. last-lease or host shutdown terminates the full process tree
    5. refresh/crash cannot fan out into N replacements
    6. elicitation/review events route to the session owning the active call; ambiguous spontaneous elicitation fails closed

    A mutex around STDIO startup alone is insufficient because later sessions would not own the original stdin/stdout pipes.

    Regression contract

    The process-level acceptance test should open N root/subagent sessions with the same identity, make concurrent tool calls, assert one full tree, close N-1 leases and retain it, then close the last lease and return to zero. A differing env/cwd/auth identity must create a distinct tree. The same test needs Windows coverage because the process cleanup test added with #19753 was Unix-only.

    Related prior work: #15258 explored a ThreadManager STDIO pool and #15257 addressed per-session elicitation routing, but neither landed.

    Per docs/contributing.md, external PRs require an explicit invitation. Does this pooling direction align with the maintainers' intended solution? If so, please invite mvpereira-git to submit a focused PR with the failing regression test first.

  10. mvpereira-git commented on Aug 17, 2026

    @mvpereira-git
    mvpereira-git
    on Aug 17, 2026 – with ChatGPT Codex Connector

    I completed the focused implementation described above and rebased it onto current openai/codex@3666a46ea.

    Candidate: mvpereira-git/codex@81111731a

    Implemented invariants:

    • process-wide pool for compatible local STDIO MCP connections, owned by the shared McpManager
    • exact connection identity isolation (transport/args/env/cwd/auth/environment/protocol/catalog limit)
    • single-flight acquisition without holding a Tokio mutex across awaits
    • per-session views retain independent filters, timeouts, approvals, event channels, and elicitation routing
    • last-lease shutdown; earlier session closure does not terminate a connection still leased elsewhere
    • hard refresh can replace one identity without redirecting existing sessions
    • no pooling for HTTP MCPs

    Observed checks on Windows after rebasing:

    • just test -p codex-mcp: 184/184 passed
    • app-server process test compatible_thread_roots_share_one_stdio_server_process: passed; two thread roots retained the same STDIO server PID
    • just fmt: passed
    • just fix -p codex-mcp -p codex-core -p codex-app-server: passed after removing an await-under-mutex finding

    I have not opened a PR because docs/contributing.md requires an explicit maintainer invitation. If this direction is acceptable, please invite mvpereira-git; the branch is ready for review.

  11. thanhnx15-png commented on Aug 18, 2026

    @thanhnx15-png
    thanhnx15-png
    on Aug 18, 2026

    I can reproduce this on Windows with Codex Desktop 26.814.5167.0 and the bundled browser/CUA node_repl MCP (runtime reported as 26.814.41407).

    Observed after repeated chat turns:

    • 9 idle node_repl.exe processes
    • about 140.5 MB working set for node_repl.exe
    • 2 child node.exe workers adding about 76.1 MB
    • about 216.6 MB total for the CUA Node process group
    • most processes near zero CPU and still attached to the same Codex app-server

    The count increases by roughly one node_repl.exe per turn that uses the browser integration, instead of returning to a bounded baseline. Disabling the node_repl MCP stops the accumulation but removes browser/Chrome tools.

    This appears consistent with the per-session MCP ownership described above. A host-owned STDIO pool with per-session leases, last-lease shutdown, and Windows process-tree reaping would address the observed behavior. Please correlate this with the candidate pooling implementation mentioned in the latest comment. No private paths, usernames, PIDs, or credentials are included here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformancewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions