Windows 26.715: duplicate MCP suites accumulate per session; termination misses cmd.exe/node.exe grandchildren (Job Object pattern exists in-repo but unused on MCP spawn path)

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

• #33946
• #33531
• #34251
• #34410
• #33401

Powered by Codex Action

Reviewed the suggested issues. #33946, #33531, and #34251 overlap with Mode A of this report (retained or duplicated MCP stacks per session or subagent; #34251 is the same build and identifies the thread/resume trigger). Not closing as duplicate because this report additionally documents Mode B, which none of them cover: on Windows, termination only reaches the direct cmd.exe child, so npx-launched node.exe grandchildren and git.exe helpers survive with dead PPIDs. It also includes a root-cause pointer and a suggested fix: apply the Job Object KILL_ON_JOB_CLOSE pattern that already exists in windows-sandbox-rs to the MCP and git spawn paths, and explicitly shut down replaced connection managers. If maintainers prefer to consolidate, the Mode B analysis can be folded into #33946 or #34251.

Confirmed source-level RED/GREEN for Windows Mode B (root exited first)

I ran a bounded source-only regression test against official Codex commit 61a44880a85d2fd0d8770908dea5733495e571c8 on Windows 11 x64. The installed Codex app, Windows settings, services, and user configuration were not modified.

STOCK RED

The test used the public RmcpClient and LocalStdioServerLauncher path. A PowerShell STDIO root process created a long-lived child, registered both PIDs, and then exited normally. The test held exact non-inheritable process handles, confirmed that the root had exited and the child was still alive, and then called client.shutdown().

With the stock launcher, shutdown did not terminate the surviving child:

process <sanitized-pid> still running after shutdown

The local nextest profile automatically retried the single issued RED command, so the same failure ran twice. This is one reproducible product case, not two distinct occurrences. Both synthetic children were removed by the test guard.

Minimal candidate fix

On Windows only, wrap the existing Tokio command at the common STDIO launch point with the already-used process-wrap 9.0.1 primitives:

let mut command = process_wrap::tokio::CommandWrap::from(command);
command
    .wrap(process_wrap::tokio::JobObject)
    .wrap(process_wrap::tokio::KillOnDrop);

process-wrap::JobObject starts the root suspended, assigns it to a KILL_ON_JOB_CLOSE Job Object, and resumes it only after assignment. This closes the spawn-to-assignment race without adding a second custom Win32 Job implementation.

GREEN and compatibility evidence

• Same root-exited-first regression: 1/1 PASS (1.138 s).
• Full codex-rmcp-client project suite: 114/114 PASS; 5 platform/inapplicable cases skipped by the existing suite.
• cargo clippy --fix --tests -p codex-rmcp-client: completed.
• Rust formatting check: exit 0.
• Current configured local STDIO MCP canary through the patched launcher: 8/8 PASS, initialization + tools/list + graceful shutdown:
• figma_framelink: 2 tools
• firecrawl: 26 tools
• github: 43 tools
• morph: 2 tools
• node_repl: 3 tools
• shadcn: 7 tools
• tavily: 2 tools
• valyu: 11 tools
• Before cleanup, no executable process from the nonce test root and no synthetic sleep child remained.
• The entire throwaway source/build/tool/log directory was then removed.

Scope and limitations

This confirms the Mode B containment defect and the candidate fix for the exact Windows source contour: a descendant that outlives the STDIO root is retained by stock shutdown and is terminated by Job Object containment.

It does not prove that Desktop releases thread/session ownership correctly, and it does not fix Mode A by itself (duplicate MCP suites retained because their owning managers/tasks remain alive). That remains a separate lifecycle layer, related to #33368 and #34658.

The canary covers the eight STDIO MCP server types configured in this environment, including wrapper-based and direct executables. It does not claim compatibility with every possible third-party server, explicit breakaway request, or out-of-job broker.

Per the repository contribution policy, I am sharing the RED/GREEN evidence and minimal design here rather than opening an unsolicited PR. If this approach aligns with the intended fix, I can provide the full regression test and focused patch if invited.

Post-reboot real Desktop route readback

I completed a full Windows reboot and a fresh Codex Desktop launch using the locally tested Job-at-create candidate build described above.

Verified on 2026-07-27 (Europe/Moscow):

• Windows booted at 06:47:16.
• Codex Desktop remained 26.721.4979.0; its bundled stock CLI SHA-256 remained 39E9E041EA33AC34AAD9578ADFE660C5C7A6DC8F82620B77623960F9352A6EF3.
• The Desktop-owned app-server started at 06:50:35 from the candidate patched binary.
• The running image SHA-256 was 587A638A481753FA87B2DAB774EF90D28D32B87EFA75A023ED1443160CA70C83, exactly matching the previously tested build.
• No stock app-server was running under the Desktop parent.
• A real post-reboot STDIO MCP request completed successfully.
• At 07:33:25 the same patched app-server was still alive and responsive.
• No app-server process predated the Windows boot.
• One additional app-server was excluded from orphan classification because its separate node server.js parent was still alive.

Current resource snapshot (scope warning): the Desktop app-server owned 58 direct child processes and about 1.6 GiB private memory. These children had a live owner at the snapshot, so this is not evidence that they are orphaned. It also does not show that Mode A/task-retention accumulation is fixed.

Conclusion: real Desktop launch, reboot persistence, image identity, and live STDIO-MCP compatibility are confirmed for the narrow Mode B Job Object candidate. This still does not prove SYSTEM_FIXED, Desktop thread/session release correctness, or cleanup of every real MCP tree after a natural owner release. Those remain separate lifecycle evidence requirements.

Independent Mode A reproduction on Codex Desktop 26.721.4979.0 (Windows)

I captured a real Desktop occurrence on 2026-07-29 (Europe/Riga). This is evidence for Mode A in this issue: repeated MCP workers remained direct children of a still-live Desktop-owned codex.exe app-server. It is not a Mode B/dead-PPID case.

Environment and version boundary

• Windows x64, version 25H2, build 26200.8655.
• Codex Desktop Microsoft Store package: 26.721.4979.0.
• PATH CLI was 0.144.6 during the incident and has since been updated to 0.146.0; the Desktop package remains 26.721.4979.0. I am therefore not treating the standalone CLI update as proof that the Desktop runtime changed.
• 64 GiB system RAM; NVIDIA RTX 5080.

Before restarting Codex Desktop

The live Desktop app-server subtree had accumulated:

• 105 processes
• 5.65 GiB aggregate working set
• 4.15 GiB aggregate private memory
• 2,394 threads
• 23,647 handles

The subtree included 61 node processes and 33 node_repl processes. Exact duplicate command-line groups were:

• 33 identical node_repl.exe workers
• 30 identical node ./mcp/server.cjs --stdio workers
• 30 identical node ./mcp/server.mjs --stdio workers

These workers were direct children of the still-running app-server, so descendant containment alone would not reclaim them while the owner continues retaining the connections/tasks.

Windows Error Reporting also recorded RADAR_PRE_LEAK_64 for codex.exe at 17:55:33 local time.

At the same time there was no hardware saturation that explained the severe interactive lag:

• CPU: about 7.9% average, 11.45% maximum during a quiet sample
• Disk active time: about 1.9% average; queue about 0.02
• About 40 GiB RAM remained available
• GPU: about 4–7%, normal temperature/power state
• No recent WHEA, disk, or display-driver errors were found in the checked window

The whole system had reached 421 processes and 8,978 threads.

Restart A/B result

I restarted only Codex Desktop; Windows, hardware, configuration, and the working task data were not changed.

Immediately after the restart, the new app-server subtree was:

• 10 processes
• 0.60–0.62 GiB aggregate memory
• 247–251 threads
• Fresh worker baseline: 2 node_repl + 2 server.cjs + 2 server.mjs

The counts stayed stable during an 8-second verification sample. Whole-system counts dropped to 312 processes and 6,693 threads, with about 43.7 GiB RAM available. This strongly localizes the accumulated load to the Codex Desktop lifecycle rather than the GPU or storage.

Current follow-up and limits

After the standalone CLI update, a current readback still shows Desktop package 26.721.4979.0. The currently live app-server has 4 direct children in each of the three worker categories. I am not classifying that small current count as a leak because legitimate active ownership has not yet been excluded; a bounded task/create/resume/close test is still needed.

The exact accumulation trigger is also not yet proven. During one observation window, ordinary research/tool calls did not continuously increase the post-restart baseline, which suggests task creation/resume/subagent or internal-task lifecycle may be involved, but that remains an inference.

Operator-reported historical context: the same progressive whole-PC lag happened before a GPU upgrade and was initially attributed to the older GPU. Upgrading to the RTX 5080 delayed the visible onset, but the same symptom eventually returned. There is no pre-upgrade process capture, so this is historical corroboration only, not instrumented proof.

Conclusion: this independently reproduces the live-owner/direct-child retention layer (Mode A) on Desktop 26.721.4979.0. It does not test or invalidate the Mode B Job Object work, and it does not yet prove that the MCP runtime-refresh changes in CLI 0.146.0 fix Desktop thread/session cleanup.

Follow-up: bounded create / idle / archive lifecycle test on Desktop 26.721.11231.0

Follow-up to my independent Mode A capture. This closes the specific gap noted there: “a bounded task/create/resume/close test is still needed.”

Environment and method

• Windows x64; Codex Desktop Microsoft Store package 26.721.11231.0.
• Standalone Codex CLI 0.146.0 (not treated as proof of the Desktop runtime behavior).
• Same live Desktop-owned codex.exe app-server throughout the test.
• Read-only process observation; no MCP/plugin configuration changes and no forced process termination.
• Two disposable same-directory task forks. Each controlled turn completed normally, and cleanup was requested only through the Codex task archive lifecycle.

Baseline

The app-server tree initially had 13 processes and nine MCP workers:

• 3 × node_repl.exe
• 3 × node ./mcp/server.cjs --stdio
• 3 × node ./mcp/server.mjs --stdio

Aggregate baseline was 710.1 MB working set, 503.8 MB private memory, 297 threads, and 3,175 handles.

Repeated lifecycle result

Test 1

1. Creating a same-directory fork, before sending it an MCP request, immediately added one complete three-process MCP suite (12 MCP workers total).
2. The test turn invoked node_repl once, completed successfully, and the task reached idle; the MCP call and final response were both recorded as completed.
3. All three newly created PIDs remained alive before archive.
4. Immediately after archiving that task, all three new PIDs were gone.
5. They remained gone after 30- and 60-second checks, while all nine baseline MCP PIDs remained alive.

Test 2

1. A second fork again added exactly one complete MCP suite.
2. Its controlled MCP call and final response completed, and the task reached idle.
3. The task was deliberately left completed/idle without archive. All three new PIDs were still alive after both 30 and 60 seconds.
4. Archiving the task immediately removed all three new PIDs, while all nine baseline PIDs remained alive.

Reactivation control

• Unarchiving the second task without starting a new turn created no MCP processes.
• I then sent a turn explicitly instructing the agent to use no tools. The turn completed with no tool marker, but starting that turn nevertheless created the full node_repl + server.cjs + server.mjs suite.
• Archiving the task again immediately removed those three PIDs.

The final app-server tree returned to 13 processes and the original nine MCP workers; no test PID remained.

Interpretation

This narrows Mode A on the current Desktop build:

1. MCP startup is eager at task/turn runtime initialization, not lazy on the first actual MCP tool call. A no-tool turn still starts every configured MCP server.
2. A completed final response plus idle task state is not a runtime-cleanup signal; the suite remained alive for the full bounded 60-second observation.
3. Explicit task archive does invoke selective cleanup: in both repetitions it terminated exactly the newly created three-process suite without affecting the nine pre-existing workers.
4. Therefore, for these direct children, the termination path works when the lifecycle calls it. The accumulating Mode A behavior is consistent with eager per-turn runtime creation plus completed threads remaining loaded/unarchived, rather than an inability to terminate the direct children once shutdown is invoked.
5. This does not test or invalidate the separate Mode B/grandchild containment problem described in the issue.

A robust fix would likely need lazy per-server startup or a shared/ref-counted MCP runtime, plus deterministic release when the final owning thread/subagent/tool/background activity is gone. Exposing runtime-to-thread ownership in diagnostics would also make safe cleanup verifiable.

Limits

• The bounded idle observation was 60 seconds; I did not wait for the longer documented idle-unload interval.
• The nine pre-existing workers were intentionally not attributed, archived, or killed because the public task/process surfaces did not prove their owners.
• This test did not cover subagents, pending approvals, elicitation, or background terminal work.

Current Windows Desktop reproduction: completed subagents retain live-owner npx MCP trees on 26.803

I reproduced the Mode A / subagent lifecycle gap on a newer Windows Desktop build than the current reports in this issue.

Environment

• Windows x64
• Codex Desktop Microsoft Store package: 26.803.5235.0
• Desktop app-server session metadata version: 0.147.0-alpha.6.5
• One live ChatGPT.exe -> codex.exe app-server hierarchy throughout the observation
• Two globally configured STDIO MCP servers:
• cmd.exe /d /s /c "npx -y figma-console-mcp@latest"
• cmd.exe /d /s /c "npx -y figma-developer-mcp --stdio"
• Read-only investigation: no processes were killed and no configuration was modified.

Snapshot

• 76 total node.exe processes used about 4.38 GB working set.
• 70 of them belonged to the two Figma MCP servers: 35 logical MCP instances, each represented by two Node processes plus cmd.exe wrappers.
• Every one of those 35 instances remained rooted under the same live Desktop app-server:

``text
ChatGPT.exe
-> codex.exe app-server
-> cmd.exe
-> node.exe (npx)
-> cmd.exe
-> node.exe (actual MCP server)
``

• These are therefore not OS orphans with a dead parent; they are retained lifecycle/logical orphans.

Session/subagent correlation

I matched each direct MCP launcher creation time against local Codex session metadata:

• 26 of 35 logical MCP instances matched a session start within 8 seconds.
• 19 matched native subagent sessions.
• 18 matched sessions whose rollout already contained task_complete.
• 15 of those completed-session matches were subagents.

That leaves at least 18 logical MCP instances / 36 Node processes still alive after their owning session recorded completion, including 15 instances / 30 Node processes from completed subagents.

One representative subagent started both configured MCP servers at 11:26:53, recorded task_complete at 12:40:10, and both complete process trees were still alive after 13:00. At the same time, the Desktop task list exposed only 9 loaded local tasks (6 idle, 3 active) while 35 logical Figma MCP instances were alive.

Interpretation

This fills the subagent gap noted in the bounded idle/archive test above: on this build, completed native subagent sessions can retain their eager per-session MCP runtimes indefinitely under the live app-server. It is Mode A; this observation does not depend on, or demonstrate, the separate dead-PPID/grandchild Mode B.

Expected behavior is for subagent completion/unload to release its MCP manager and deterministically terminate the whole Windows wrapper tree, unless an explicit shared runtime still has an active reference. A runtime-to-thread/subagent ownership diagnostic would also make safe cleanup and regression testing much easier.

Follow-up with an all-local-STDIO validation on Codex Desktop 26.803.41515 (Windows), extending this beyond Node/npx:

Configured servers:

• bundled node_repl.exe
• fastctx.exe serve
• npx -y figma-console-mcp@latest
• npx -y figma-developer-mcp --stdio

A completed subagent rollout started at 11:26:52.135 local time. One root for each configured server was created 875–960 ms later (node_repl, fastctx, figma-dev, figma-console); this was the only rollout start in a ±2 s window. The rollout's final task_complete was 12:40:10.650. After a grace period, all four roots/trees were still alive. The figma-console tree later exited on its own, but node_repl, fastctx, and figma-dev were still alive at 13:44. A controlled FastCtx call changed I/O counters only on the current task's newer FastCtx instance; the older candidate instance showed no activity.

A later process census under the same live Desktop app-server found 34 direct node_repl roots, 34 direct fastctx roots, 17 direct figma-console roots, and 25 direct figma-dev roots. These counts include active runtimes and are not themselves a stale-process count, but they confirm the duplication affects all four local STDIO MCP implementations, not only Node.

The missing observability/join key is important:

• state_5.sqlite persists thread metadata, but the completed candidate's thread_spawn_edges.status was still open.
• logs_2.sqlite records MCP tool calls with thread_id and the app-server process_uuid, but MCP launcher/stderr records have no stable child PID ↔ thread/runtime mapping (often thread_id = NULL).
• Representative processes from all four MCP types had no injected thread/session/agent/owner/runtime environment variable.
• All direct MCP roots share the same app-server PPID, so OS parentage cannot identify the logical owner.

Suggested lifecycle/diagnostic additions:

1. Give every MCP runtime generation a unique mcp_runtime_id, associated with thread_id (and optionally turn/agent ID).
2. Inject those IDs into the spawned process environment and log server_name, root child PID, app-server process UUID, launch time, shutdown request, EOF, and exit.
3. Explicitly close the runtime when its owner lease ends, and place the entire Windows process tree in a kill-on-close Job Object.
4. If exposing last activity, track protocol RX/TX, tools/call start/finish, and in-flight count. Idle time alone must not authorize killing; require an absent/terminal owner lease, zero in-flight requests, and a grace period.

This would make stale-process classification deterministic instead of relying on start-time correlation.

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.

Reproduction on Codex Desktop 26.818: MCP process multiplication and cleanup failure

I can reproduce the same MCP process multiplication and cleanup failure on a
newer native Windows Codex Desktop build.

Environment at the time of the incident

• Windows 11 Home, native Windows workspace, build 26100, x64
• Codex Desktop package: OpenAI.Codex_26.818.8289.0
• Bundled Codex observed from the Desktop process: 0.149.0-alpha.4.3
• The separate codex on PATH is not the Desktop binary and should not be

used as the Desktop version.

• Subscription: Plus

Configured stdio MCP servers

The affected setup contained five Node/npx-based MCP servers:

• Context7
• Sequential Thinking
• Memory
• Playwright
• Chrome DevTools

Some were configured directly and Playwright/Chrome DevTools were supplied by
plugins. The behavior therefore did not appear specific to one MCP package.

Observed behavior

Codex Desktop repeatedly launched complete or near-complete MCP suites during
ordinary task activity. The Windows process chain was:

codex.exe app-server
  -> cmd.exe /c npx ...
     -> npx.cmd
        -> cmd.exe /d /s /c ...
           -> node.exe

The child processes appeared in distinct time batches: one around 13:56 and
several more around 15:56-15:59. A process-tree snapshot attributable to the
live Codex app-server contained approximately:

• 30 cmd.exe processes
• 34 node.exe processes
• about 3.7 GB combined working-set memory

The same MCP server names occurred repeatedly across the batches. Closing or
completing the visible task did not reclaim the old process trees. The wrappers
also caused visible cmd.exe console flashes on Windows.

Disabling MCP entries in config.toml did not terminate already-running
children. A full tray exit/restart was required before the reduced MCP config
took effect. After disabling the manual MCP entries, residual Context7
processes from the old app-server generation remained until that full exit.

Expected behavior

• Reuse one bounded MCP server set where possible.
• Shut down the previous set before or when replacing an MCP connection

manager.

• Reap the complete Windows process tree, including cmd.exe-wrapped Node

grandchildren.

• Launch background MCP wrappers without visible console windows.
• Apply MCP enable/disable changes without leaving stale children alive.

This looks consistent with both failure modes described in #34614: repeated
connection-manager generations and incomplete teardown of the Windows
cmd.exe -> node.exe process tree. It also appears related to the newer
high-volume reproduction in #38825.

I can provide a sanitized PID/PPID/start-time snapshot if a fresh capture is
useful. I have not attached config.toml for security reasons.

Additional affected Windows user report — possibly the same process-lifecycle leak, although the exact child-process mix has not yet been captured.

Environment / workload

• Windows 11
• AMD Ryzen 9 7950X3D (16 cores / 32 threads, liquid cooled)
• 64 GB RAM
• Codex Desktop used for local web-development projects
• No other substantial applications need to be running for the symptom to occur

User-visible symptom

While Codex Desktop is open and has been working on web projects, the entire machine becomes noticeably sluggish: mouse movement/input stutters, and even basic browser page scrolling becomes choppy. The degradation persists while Codex remains open and system responsiveness returns when Codex is fully exited.

The user specifically suspects local/dev-server or helper processes are being left running instead of being torn down between work/session activity. This has not yet been confirmed by a process-tree capture, so I am adding it here as a matching field report rather than claiming the same root cause.

The hardware has ample CPU headroom, so the system-wide input/UI degradation is significant and reproducible enough to make normal desktop use difficult while Codex is open.

If useful, we can collect a sanitized node.exe / cmd.exe / git.exe process count and PPID snapshot during the next affected state.