Repository navigation
[Windows 26.818] MCP process-batch accumulation and incomplete cleanup still reproducible with 5 MCP servers #40579
Description
What version of the Codex App are you using (From “About Codex” dialog)?
OpenAI.Codex_26.818.8289.0
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26100.0, x64
What issue are you seeing?
Codex Desktop repeatedly launches complete or near-complete sets of configured stdio MCP servers during ordinary task activity. Older MCP process trees remain alive instead of being reclaimed, causing cmd.exe and node.exe processes and their memory usage to accumulate over the lifetime of the Desktop session.
The affected configuration contained five Node/npx-based MCP servers: Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools. Some were configured directly, while Playwright and Chrome DevTools were supplied by plugins, so the behavior does not appear specific to one MCP package.
The observed 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 start-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.exeprocesses - 34
node.exeprocesses - ~3.7 GB combined working-set memory
The same MCP server names occurred repeatedly across the batches. Completing or closing the visible task did not reclaim the older process trees. The wrappers also caused visible cmd.exe console-window flashes on Windows.
Disabling MCP entries in config.toml did not terminate already-running children. A full Codex Desktop tray exit/restart was required before the reduced MCP configuration took effect.
What steps can reproduce the bug?
- Start Codex Desktop on Windows with multiple stdio MCP servers configured. In my case these included Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools.
- Use Codex Desktop normally across multiple tasks/session activity while leaving the Desktop app running.
- Inspect the process tree of the active
codex.exe app-serverin Task Manager or PowerShell. - Observe multiple start-time batches containing repeated instances of the same MCP servers under
cmd.exe/npx.cmd/node.exe. - Complete or close the visible Codex task and inspect the process tree again.
- The older MCP process trees remain alive rather than being reclaimed.
- Disable manually configured MCP entries in
config.toml. - Observe that already-running MCP children remain alive.
- Fully exit Codex Desktop from the system tray and restart it.
- The stale processes from the previous app-server generation are finally removed.
In my observed incident, the live app-server process tree accumulated approximately 30 cmd.exe processes and 34 node.exe processes, using about 3.7 GB of combined working-set memory.
What is the expected behavior?
Codex Desktop should keep the number of MCP server processes bounded.
When an MCP connection manager/runtime generation is replaced, the previous MCP server set should be shut down and the complete Windows process tree should be reaped, including cmd.exe-wrapped node.exe grandchildren.
Completing tasks or disabling MCP servers should not leave stale MCP process trees alive.
Background MCP wrappers should also launch without visible cmd.exe console windows.
Additional information
This appears closely related to #32797, #34614, and #38825.
I am filing this as a separate current-build reproduction because the same process-batch accumulation and incomplete cleanup behavior is still reproducible on the newer Codex Desktop package OpenAI.Codex_26.818.8289.0.
Unlike #32797, which reports a much larger MCP configuration, my affected setup contained only five Node/npx-based MCP servers (Context7, Sequential Thinking, Memory, Playwright, and Chrome DevTools). Despite the smaller configuration, the live Codex app-server process tree still accumulated approximately 30 cmd.exe processes and 34 node.exe processes, using about 3.7 GB of combined working-set memory.
The processes appeared in distinct start-time batches, with the same MCP server names recurring across batches. Completing the visible task did not reclaim the older process trees. Disabling MCP entries in config.toml also did not terminate already-running children; a full Codex Desktop tray exit/restart was required before the reduced configuration took effect.
The bundled Codex version observed from the Desktop process was 0.149.0-alpha.4.3. A separate codex executable exists on my PATH, but it is not the Desktop-bundled binary and was not used as the Desktop version reported above.
I can provide a fresh sanitized process snapshot containing PID, PPID, process name, sanitized command line, start time, and working-set memory if useful for identifying which app-server/runtime generation owns each stale MCP process tree.
I have intentionally not attached my full config.toml for security reasons.
Activity
github-actions commentedon Aug 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xswt442-cmd commentedon Aug 25, 2026
Thanks for the pointer to #39982.
For comparison, this reproduction was observed on Codex Desktop package
OpenAI.Codex_26.818.8289.0on Windows. During ordinary task/session activity,complete or near-complete sets of configured stdio MCP servers appeared in
distinct process start-time batches.
The observed Windows process chain was:
codex.exe app-server -> cmd.exe -> npx.cmd -> cmd.exe -> node.exeThe live app-server process tree contained approximately 30
cmd.exeprocessesand 34
node.exeprocesses, with about 3.7 GB combined working-set memory,while the affected configuration contained five Node/npx-based MCP servers.
Completing the visible task did not reclaim the older process trees. Disabling
MCP entries in
config.tomlalso did not terminate already-running children.The stale processes remained until a full Codex Desktop tray exit/restart.
Visible
cmd.execonsole flashes were also observed during MCP launches.These are the observations from this Codex Desktop reproduction. I am adding
them here so maintainers can compare the process lifecycle and teardown behavior
with #39982 and determine whether they share the same underlying cause.
UweKeim commentedon Sep 6, 2026
I can confirm the same MCP process-batch accumulation and incomplete cleanup on substantially newer Codex Desktop builds. It has reproduced repeatedly on four consecutive days and returned after a full desktop restart and version update. The visible end-user failure is:
Environment
10.0.26200, Build2620026.901.6511.0with its embedded app-servercodex-cli 0.153.426.901.2854.0/ embeddedcodex-cli 0.153.026.901.4073.0/ embeddedcodex-cli 0.153.126.901.5280.0/ embeddedcodex-cli 0.153.4codex-cli 0.152.0is currently onPATH, but it is not the desktop-owned app-server process affected by these measurements.GPT 6 Astrawithxhighreasoning effort. The leak affects the shared desktop app-server across chats and does not appear specific to one model or conversation.Issue
Codex Desktop repeatedly accumulates complete local MCP and app-tools process suites that are not terminated after the corresponding thread or tool activity has finished. After several hours, the desktop becomes slow or globally unresponsive across chats and requests eventually expire while queued.
Across repeated incidents, 22 to 33 near-identical MCP/app-tools start groups accumulated below the single desktop-owned Codex app-server process. The descendant tree reached 427 to 525 processes, approximately 72,000 to 106,000 handles, and approximately 4,500 to 5,400 Windows threads.
The persisted queue database was empty during the original incident, so the visible error appears to refer to an internal or transient app-server queue rather than the persisted queue.
Selectively terminating only older duplicated MCP/app-tools subtrees immediately reduced process, handle, thread, and memory counts. Codex Desktop and its app-server remained alive, and the UI continued working without a desktop restart. During the first confirmed recovery, all three concurrently running Codex sessions continued successfully afterwards.
The workaround is temporary. Complete suites accumulate again, including after a full desktop restart and a desktop version update. On 2026-09-06 the process tree grew back to 427 processes and 22 duplicated start groups within approximately 4 hours 24 minutes of a fresh desktop app-server start.
Reproduction pattern
This has reproduced repeatedly on four consecutive days:
codex.exeapp-server process. New activity starts a broad suite of local MCP/app-tools child processes.App server request expired while queued.The exact accumulation rate depends on thread and tool activity. The consistently reproduced property is that old complete MCP/app-tools suites remain alive and accumulate below one long-running desktop app-server.
Expected behavior
Codex Desktop should reap MCP and plugin/app-tools child processes when their owning initialization, tool call, turn, or thread lifecycle no longer needs them. Starting or resuming additional chats must not leave complete older tool suites running indefinitely.
If an MCP startup fails, times out, or a child process does not exit normally, the app-server should terminate the abandoned subtree and release its handles. A problem in one MCP should not cause the shared desktop app-server to queue and expire unrelated requests across all chats.
Long-running Codex Desktop sessions should remain responsive without requiring periodic external process cleanup or a complete desktop restart.
Observed incident data
2026-09-03 — Desktop 26.901.2854.0 / embedded CLI 0.153.0
2026-09-04 — Desktop 26.901.4073.0 / embedded CLI 0.153.1
2026-09-05 — Desktop 26.901.5280.0 / embedded CLI 0.153.4
2026-09-06 — Desktop 26.901.5280.0 / embedded CLI 0.153.4
2026-09-06 after desktop restart/update — Desktop 26.901.6511.0 / embedded CLI 0.153.4
MCP configuration inventory at report preparation
chrome-devtools,codex_data_exchanger,devexpress,gmail_mail,net, andquick_uploader.Plugin inventory
The following 22 plugin package manifests were present in the local Codex plugin cache when this report was prepared. Cache presence does not prove that every package was enabled or invoked during an incident:
browser 26.901.51231chrome 26.901.51231codex-app-tools 0.1.3codex-security 0.1.23computer-use 26.901.51231deep-research-work 0.1.14documents 26.904.11930github 0.1.12-5f7cd798dc99gmail 0.1.10google-calendar 1.2.7openai-templates 0.1.1outlook-calendar 0.1.9outlook-email 0.1.8pdf 26.904.11930plugin-management 0.1.0presentations 26.904.11930sites 0.1.57spreadsheets 26.904.11930teams 0.1.9template-creator 26.904.11930unified-computer-use 26.901.51231visualize 1.0.29The duplicated process groups contained Codex app-tools/plugin runtimes in addition to user-configured MCP processes. This is why I am including the cache inventory, while explicitly not claiming that every cached plugin was active.
Skill inventory
chrome-devtools(disabled),frontend-design,m365-reply-defaults,playwright, andswitch-codex-account. One private workflow skill name is redacted.Other diagnostic observations
inProgress, eight of them approximately 13 hours to 13 days old, and 63 open spawn edges.inProgressturns and the same 63 open spawn edges.timeout waiting for child process to exitevents near the visible queue timeout.Working hypothesis
This is an inference from the repeated local measurements: starting or resuming threads appears to initialize a broad MCP/plugin suite, and completed, failed, or timed-out suites are not consistently reaped. The resulting process and handle accumulation eventually blocks the shared desktop app-server. The empty persisted queue suggests that the visible queue timeout concerns a transient internal queue.
This looks like the same underlying lifecycle problem described in this issue, now confirmed across newer Desktop and embedded CLI versions, with both user MCP and Codex app-tools/plugin processes present in the leaked suites. It may also be related to #28361, but I am adding the evidence here instead of opening or cross-posting duplicate reports.
yh2561692675-prog commentedon Sep 7, 2026
用途：作为现有 GitHub issue #40579 的补充评论，或通过 Codex
/反馈提交相关问题：#40579
标题：Windows Codex Desktop 26.901.6511.0 still launches MCP stdio servers in visible cmd.exe windows
环境：
问题描述：
使用 Codex 桌面应用运行多个本地任务时，黑色控制台窗口会频繁闪现，有时连续出现两个。任务本身不应停止；期望 MCP 和工具继续正常运行但完全不显示控制台窗口。
已验证：
cmd.exe <- codex.exe <- ChatGPT.exe <- explorer.exe
cmd.exe /d /s /c call ./scripts/launch_codex_app_tools_mcp.cmd ./server.mjs
期望行为：
Codex 桌面应用启动、重启或重连所有 MCP stdio 服务器时不创建可见控制台窗口，同时保持 MCP 功能不变。
建议修复：
Windows 客户端创建 MCP 子进程时使用 CREATE_NO_WINDOW 或等效的隐藏 STARTUPINFO；必须通过 .cmd 启动时，也请无窗口启动 cmd.exe。请同时覆盖内置 codex-app-tools MCP、用户配置的本地 stdio MCP，以及自动重连/重启路径。
补充说明：
用户不希望通过禁用 MCP、关闭插件或停止任务来规避该问题。
该问题在较新的 OpenAI.Codex 26.901.6511.0 上仍可复现；本机捕获到内置 codex-app-tools 通过 launch_codex_app_tools_mcp.cmd 启动，因此不仅影响手工配置的第三方 npx MCP。
jervaise commentedon Oct 5, 2026
Current Windows measurements for the process-batch / per-thread MCP footprint reported here, collected 2026-10-05. This adds evidence rather than opening a duplicate report.
Environment: desktop package
OpenAI.Codex_26.930.3930.0_x64, desktop-bundledcodex-cli 0.160.0, native Windows x64. The bundled executable was queried directly; the separate daemon binary is 0.157.1 and was excluded from the desktop process tree.The first desktop-root snapshot contained 381 processes:
Repeated command families included 16 Playwright MCP workers plus 16 retained npx runtimes, 17 Hindsight coding-agent MCP workers, 16 Jerv MCP workers, and 14 computer-use REPL runtimes. Most directly or indirectly descended from the same live desktop app-server. Start-time batches extended from 08:59 through 13:25 local time.
Memory definitions matter: the first tree totaled 14.22 GiB summed working sets and 10.76 GiB private commit. A later sample had 350 processes, 11.97 GiB summed working sets, and 3.87 GiB exclusive resident working set. Summed working sets double-count shared pages. These measurements do not establish 15 GiB of exclusively occupied physical RAM or a monotonic leak.
App inventory initially showed five active chats and sixteen idle chats, plus four not-loaded chats. This is not a one-to-one process ownership map. Idle status alone is insufficient to identify a safe shutdown candidate.
Source inspection at
rust-v0.160.0found:codex-rs/codex-mcp/src/connection_manager.rs:279-280,312-315: initialization iterates enabled MCP registrations; deferred startup depends onLazyWhenCachedand a previous manager.codex-rs/app-server/src/request_processors/thread_lifecycle.rs:56-61: unload eligibility requires both no subscribers and inactivity, then the grace delay. The official app-server documentation describes a 30-minute no-subscriber inactivity grace period.The standalone Jerv MCP exits cleanly on idle stdin EOF in a controlled installed-binary probe. Hindsight's two parentless ingestion workers were intentionally detached, had live bank leases and operation polling, and were preserved. These checks do not support attributing this footprint to a Hindsight or Jerv idle-EOF leak.
The confirmed issue here is the large multiplied local-tool footprint. Whether any specific retained desktop-owned pool is abandoned remains unverified because the observed process inventory does not expose connection/subscriber ownership. A supported idle-pool release control and process-to-thread ownership diagnostics would enable safe cleanup without restarting live work. Lazy startup or safe shared runtimes could reduce the baseline footprint.
Related integration improvement filed separately: https://github.com/mutmutco/Jerv-Hub/issues/1912 (Windows direct launcher to avoid a retained shell per Jerv MCP worker). Grace-period reference: https://learn.chatgpt.com/docs/app-server#unsubscribe-from-a-loaded-thread.
No conversations were deleted or archived, and no active agent or MCP process was terminated during collection.
UweKeim commentedon Oct 13, 2026
Are there any updates on this issue, or could someone from the team at least confirm that this is a known bug?
Every 4–6 hours, Codex Desktop becomes unresponsive. I then have to take a screenshot of my active threads, quit the app with Ctrl+Q, restart it, and use the screenshot to find and reopen each thread. In every thread, I have to manually ask: "Codex became unresponsive and had to be restarted. Please continue working."
Having to repeat this several times a day is very frustrating and keeps interrupting my work.
bfeller05 commentedon Oct 17, 2026
Still happening on Windows after updating to Codex 26.1013.4894.0 (Microsoft Store). About an hour of normal use led to 243 Codex-related processes: 211 node.exe (about 15 GB), 27 ChatGPT.exe (about 5 GB) and 4 codex.exe (about 2 GB). That's roughly 23 duplicate copies of each MCP server, plus 92 cua-repl/computer-use helpers, and they're never cleaned up when threads or subagents finish. Free RAM dropped to 2 GB of 32 GB. A full quit is the only thing that clears them. This didn't happen before the recent updates, even with many threads open. Settings: max_threads 16, computer use on.
zhugeshenren commentedon Oct 17, 2026
Seeing the same on Windows 11 Pro, Codex Desktop 26.1013.3656.0 (bundled codex-cli 0.163.0-alpha.10.2).
After extended use across chats and subagents, repeated sets of code-review, codex-app-tools and cua-repl processes remained under the same app-server.
Measured on 2026-10-17, before and after restarting only Codex:
bfeller05 commentedon Oct 17, 2026
Follow-up: on my PC, restarting Codex does not clear this. Even after fully quitting and reopening, the duplicate helper processes come back right away. After one restart it relaunched about 177 helper processes using about 13 GB, with the CPU at 100%. It comes back after every restart, so I don't have a workaround. Windows 11, Codex 26.1013.4894.0 (Microsoft Store), 32 GB RAM.
bfeller05 commentedon Oct 17, 2026
Additional measurements on October 17, 2026, with Codex Desktop 26.1013.4894.0 / core 0.163.0-alpha.10.2:
• 2:58 p.m. EDT: 177 Codex-related processes; 10.771 GiB private memory; 13.504 GiB summed working sets.
• 4:01 p.m. EDT: 306 processes; 18.015 GiB private memory; 18.432 GiB summed working sets.
These were normal-use snapshots, not a controlled idle test, so they don’t establish the cause or prove every helper is abandoned. No configuration changes were made between these measurements by the monitoring task. Please advise on a supported diagnostic or workaround.
alarbainvest commentedon Oct 17, 2026
Windows desktop: growing stdio MCP process sets and memory exhaustion
Environment: Windows, 16 GB physical RAM. Desktop 26.1013.40934 build 20770, production channel; its updater returned up_to_date on 2026-10-18. Bundled Codex CLI reported 0.163.0-alpha.10.2.
Observed independently:
Narrow qualification:
Mitigation already applied, NOT claimed as a fix:
Please investigate desktop/app-server ownership and disposal of per-thread MCP connections and Code Mode processes. Is retaining these sets after a completed turn expected while the desktop remains subscribed? Is there a supported bounded lifecycle/unload setting or a released fix? Completion of a turn may differ from thread unload; we need guidance that prevents unbounded accumulation without losing active work or adding a periodic process killer.
Expected: ordinary conversation reuse remains bounded and owned resources are released at the appropriate lifecycle boundary; active work remains intact.
Actual: repeated launch groups and worsening memory pressure; precise leak site and causal attribution remain unproven.