›_ Codex Issues
Codex Issues / #32694

[App/Windows] MCP/plugin subprocess groups scale linearly with active task runtimes

Open 💬 3 comments Opened Jul 13, 2026 by loraldx
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Codex Desktop 26.707.8168.0 on Windows 11, enabled MCP/plugin subprocess groups appear to be launched separately for each active task runtime. Process count and memory usage therefore grow roughly linearly with runtime count instead of being pooled, deduplicated, or stopped when no longer needed.

Related to #20867, but this report isolates the per-runtime subprocess fan-out rather than browser MCP startup alone.

Sanitized observation

With approximately 6 active task runtimes and 5 enabled MCP/plugin services:

  • 36 node.exe processes
  • approximately 1.99 GB combined working set
  • 12 Playwright-related processes, approximately 861 MB
  • 12 server.mjs processes, approximately 564 MB
  • 6 server.bundle processes, approximately 320 MB
  • 6 server.cjs processes, approximately 244 MB

The repeated process groups tracked the number of active runtimes. Disabling unused plugins prevented new groups from being started, but existing groups remained until the desktop application was fully quit.

No raw command lines, local paths, account identifiers, task contents, or configuration secrets are included in this report.

Steps to reproduce

  1. Enable several MCP/plugin services in Codex Desktop.
  2. Start multiple tasks or agent runtimes in the desktop application.
  3. Observe node.exe child processes after each runtime becomes active.
  4. Close or finish tasks without fully quitting Codex.
  5. Compare process groups and aggregate working set with the number of active runtimes.

Actual behavior

Each runtime appears to receive its own MCP/plugin subprocess group. Multiple groups remain resident and can consume gigabytes of memory in an ordinary multi-task session.

Expected behavior

  • Share or pool stateless MCP services where safe.
  • Deduplicate equivalent subprocess configurations.
  • Start services lazily when a tool is first used.
  • Reliably terminate runtime-owned subprocesses when the runtime ends.
  • Expose ownership and lifecycle information in diagnostics.

Environment

  • Codex Desktop: 26.707.8168.0
  • OS: Windows 11 x64
  • WSL2 workspaces are used, but the observed child processes are Windows node.exe processes.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32154
  • #31499

Powered by Codex Action

tnt2ray · 1 month ago

I can reproduce this on Linux, with additional evidence that the MCP subprocess fan-out is caused by eager plugin/tool initialization rather than actual tool usage.

Environment:

  • Debian GNU/Linux 13, x86_64
  • Codex CLI / App Server 0.144.1
  • Codex Desktop client 26.707.72221
  • build-ios-apps plugin 0.1.2
  • xcodebuildmcp 2.6.2
  • 1 vCPU / 1.9 GiB RAM

The build-ios-apps plugin started XcodeBuildMCP even though Xcode and iOS Simulator cannot run on Linux.

I scanned all active and archived rollout JSONL files:

  • Actual mcp__XcodeBuildMCP__* calls: 0
  • build-ios-apps skill reads/triggers: 0

The affected runtimes were performing unrelated work such as Markdown import, SQL concurrency review, release review, and Linux SSH diagnostics.

Codex logs show the MCP being started during runtime initialization:

thread_spawn
→ session_init
→ session_init.mcp_manager_init
→ new{server_name=xcodebuildmcp}
→ start_server_task

The server is then queried while Codex builds the global tool list:

build_skills_and_plugins:list_all_tools
server_name=xcodebuildmcp
tool_count=44

Six concurrent process trees were observed:

codex app-server
└─ npm exec xcodebuildmcp@latest mcp
   └─ sh -c xcodebuildmcp mcp
      └─ node .../xcodebuildmcp mcp

Together they consumed approximately 1.2 GiB on a 1.9 GiB host. The machine entered sustained memory/swap pressure, systemd-journald repeatedly logged Under memory pressure, flushing caches, I/O wait reached 57%, and SSH became unresponsive.

There is also an uninstall lifecycle problem:

codex plugin remove build-ios-apps@openai-curated-remote --json

reported success and briefly removed the cache. Existing MCP processes had to be killed manually. The running App Server later recreated the plugin cache and started XcodeBuildMCP again. During later unrelated turns, new instances continued appearing.

This appears to confirm the per-runtime fan-out reported here and adds:

  1. Missing OS/platform compatibility gating.
  2. Eager MCP startup despite zero tool calls.
  3. Plugin cache/runtime state being recreated after CLI uninstall.
  4. Existing MCP children surviving plugin removal.

This also appears related to #32997, where killing duplicate MCP processes is only a temporary workaround.

clear-er · 1 month ago

Windows controlled A/B: Build iOS Apps configured enabled=false spawned seven XcodeBuildMCP trees in a new unrelated thread

I can reproduce the same eager per-runtime MCP fan-out on Windows with a controlled Build iOS Apps / XcodeBuildMCP A/B. This isolates one bundled plugin on an unsupported host and does not depend on historical threads, subagents, or an iOS-related prompt.

Environment
  • Windows 11 Pro 25H2, build 26200.8875, x64, 16 logical processors
  • Codex Desktop 26.707.72221
  • Windows MSIX package OpenAI.Codex 26.707.9981.0, x64
  • Plugin build-ios-apps@openai-curated; previously observed cache version 0.1.2
  • OneDrive remained paused throughout the controlled snapshots to remove unrelated filesystem activity as a confounder
Configuration state

The installed plugin had this user-level configuration:

[plugins."build-ios-apps@openai-curated"]
enabled = false

The current Codex config schema recognizes plugin-level enabled and also provides a more explicit per-plugin MCP overlay whose enabled = false is documented in the schema as skipping server initialization. I did not add or test the server-specific overlay, so this report distinguishes the observed plugin-level state from that untested control.

Reproduction conditions
  1. Restart Windows and keep OneDrive paused.
  2. Before launching Codex, verify that no node.exe, codex.exe, ChatGPT.exe, or XcodeBuildMCP process is present.
  3. Launch Codex into a completely new thread. Do not reopen historical threads.
  4. Send only a minimal no-tool instruction. Do not request iOS, Xcode, Simulator, MCP, or plugin work.
  5. Capture the process tree and memory totals.
  6. Uninstall Build iOS Apps through the supported Codex plugin UI.
  7. Fully quit and restart Codex, open another new thread, and capture the same counters.

No reproduction was rerun after this controlled sequence.

Controlled A/B results

| Snapshot (Australia/Sydney) | State | Node processes | Node private / working | XcodeBuildMCP Node processes | OneDrive CPU sample |
| --- | --- | ---: | ---: | ---: | ---: |
| 2026-07-16 00:00:13 | Clean baseline; Codex not running | 0 | 0 / 0 GB | 0 | 0% |
| 2026-07-16 00:08:12 | Plugin installed; config reported false; new unrelated thread | 35 | 2.064 / 2.371 GB | 14 | 0% |
| 2026-07-16 00:20:23 | Plugin uninstalled; Codex fully restarted; new thread | 21 | 0.741 / 0.919 GB | 0 | 0% |

The dedicated XcodeBuildMCP CSV contained 14 matching Node rows: seven npx launcher nodes and seven xcodebuildmcp worker nodes. Together they used approximately 1,356.3 MiB private memory and 1,320.0 MiB working set. This is consistent with the approximately 1.323 GB drop in total Node private memory between the installed and post-uninstall snapshots.

Sanitized command patterns:

node.exe ... npx-cli.js -y xcodebuildmcp@latest mcp
node.exe ...\xcodebuildmcp\build\cli.js mcp

Sanitized ancestry:

node.exe (xcodebuildmcp worker)
  <- cmd.exe
  <- node.exe (npx launcher)
  <- cmd.exe
  <- codex.exe app-server
  <- ChatGPT.exe

All 14 matching Node rows descended from the Codex app-server. The remaining 21 Node processes were classified only heuristically as other MCP-related processes and are not claimed as part of this bug.

Actual behaviour
  • An Xcode/iOS-oriented plugin launched on Windows, where Xcode and Simulator are unavailable.
  • Startup occurred in a brand-new unrelated thread without an iOS, Xcode, Simulator, plugin, or MCP request.
  • The plugin-level config state was enabled = false, yet seven launcher/worker trees appeared.
  • Supported uninstall plus a full Codex restart reduced XcodeBuildMCP to zero.
Expected behaviour
  • A plugin configured enabled = false should not initialize its bundled MCP server.
  • An Xcode-focused integration should be platform-gated or fail closed on Windows.
  • Opening an unrelated new thread should not eagerly create seven equivalent MCP launcher/worker trees and approximately 1.3 GiB of matching Node memory.
  • If the server-specific overlay is the required control, Desktop and documentation should clearly surface that distinction and migrate or reject ineffective plugin-level state rather than silently retaining it.
Workaround

Uninstalling Build iOS Apps through the supported plugin UI and fully restarting Codex removed all matching XcodeBuildMCP processes in this controlled test.

Scope limitation

This evidence does not claim that Codex, Build iOS Apps, or XcodeBuildMCP caused a separate Windows kernel-pool problem. It establishes only plugin lifecycle, platform-gating, configuration-enforcement, process fan-out, and user-mode memory impact. It also does not attribute a defect to the upstream XcodeBuildMCP package.

Related reports: #33343 (unsupported Linux host; closed in favour of this issue), #28443 (per-plugin false ignored), #32942 (restored-task Xcode policy bypass), #17574 (XcodeBuildMCP helper lifecycle), and #32154 (eager per-chat MCP startup on Windows/WSL2).

All paths, usernames, process IDs, account identifiers, task contents, and unrelated command lines are omitted or generalized. No raw PoolMon or full process inventory is attached.