Skip to content

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

Open
Open
[App/Windows] MCP/plugin subprocess groups scale linearly with active task runtimes#32694
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) serversperformanceskillsIssues related to skillswindows-osIssues related to Codex on Windows systems

Description

@loraldx
loraldx
opened on Jul 13, 2026

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.

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
    skillsIssues related to skills
    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. tnt2ray commented on Jul 15, 2026

    @tnt2ray
    tnt2ray
    on Jul 15, 2026

    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.

  4. clear-er commented on Jul 15, 2026

    @clear-er
    clear-er
    on Jul 15, 2026 – with ChatGPT Codex Connector

    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.

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) serversperformanceskillsIssues related to skillswindows-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