Skip to content

fix: stdio MCP child process leak causing unbounded memory growth #19469

Closed
#19753
Closed
fix: stdio MCP child process leak causing unbounded memory growth#19469
#19753
Labels
bugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) servers

Description

@luohoa97
luohoa97
opened on Apr 25, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.416.11627

What subscription do you have?

Plus

What platform is your computer?

Linux 6.19.10-300.fc44.x86_64 x86_64 unknown

What issue are you seeing?

Long-running Codex sessions using stdio MCP servers leak child processes.

Observed behavior:

stdio MCP servers are repeatedly spawned during normal usage
previous MCP child processes are not cleaned up
process count continuously increases over time
no automatic cleanup occurs
restarting/killing Codex reaps the processes

This behavior is consistent with previously reported MCP lifecycle leaks in Codex (CLI, Desktop, and extensions), where stdio MCP processes accumulate instead of being reaped.

What steps can reproduce the bug?

Configure one or more stdio MCP servers (e.g. Playwright, Git MCP, etc.)
Start Codex Desktop
Open and switch between chats repeatedly
Monitor process count:
watch -n 2 -t 'date +"%T"; pgrep -fc "mcp|playwright|chrome-devtools|codex"'
Observe:
process count increases continuously
no decrease occurs over time

What is the expected behavior?

stdio MCP child processes should be cleaned up after session/tool lifecycle ends
process count should remain bounded
memory usage should remain stable

Actual behavior
MCP child processes accumulate indefinitely
process count increases with continued usage
no cleanup occurs until Codex is terminated

Additional information

Evidence
Process tree shows multiple duplicated MCP server processes under the same Codex app-server
Repeated instances of:
@playwright/mcp
git-mcp-server
shadcn mcp
context7 MCP
next-devtools MCP
Video evidence attached:
Shows real-time process count increasing while opening chats
Timestamp included
Sensitive content redacted

This appears related to existing MCP lifecycle issues where processes are spawned but not reaped
Behavior matches prior reports of unbounded MCP process growth and memory usage
Known issue affecting codex-cli 0.120.0 and related builds ()
Code credit:
commit 498aac6 (@RedesignedRobot)
Co-authored with @codex

bug.mp4

Activity

  1. luohoa97
    added
    appIssues related to the Codex desktop app
    on Apr 25, 2026
  2. github-actions
    added
    bugSomething isn't working
    mcpIssues related to the use of model context protocol (MCP) servers
    app-serverIssues involving app server protocol or interfaces
    on Apr 25, 2026

  3. github-actions commented on Apr 25, 2026

    @github-actions
    github-actionsbot
    on Apr 25, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. luohoa97 commented on Apr 25, 2026

    @luohoa97
    luohoa97
    on Apr 25, 2026
    Author

    This is not a duplicate, this is a dedicated issue for the patch

  5. etraut-openai
    removed
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Apr 25, 2026

  6. Attys-syttA commented on Apr 26, 2026

    @Attys-syttA
    Attys-syttA
    on Apr 26, 2026

    I can confirm a very similar pattern on Windows with the VS Code Codex extension/app-server.

    Environment:

    • Windows 11
    • VS Code Codex extension
    • Active host process: codex.exe app-server
    • stdio MCP servers configured: Serena, @modelcontextprotocol/server-filesystem, xcodebuildmcp

    Observed behavior:

    • Multiple stdio MCP roots appeared under the same active codex.exe app-server.
    • In one session, Serena, filesystem MCP, and xcodebuildmcp each reached 2-3 parallel root processes.
    • While manually stopping the newest Serena branch, one extra filesystem MCP root and one extra xcodebuildmcp root also appeared.
    • Cleanup only stabilized after stopping full descendant branches, not just the leaf process.

    Example process roots under the same codex.exe app-server:

    • Serena: uvx.exe 25344, uvx.exe 25788, later uvx.exe 28980
    • filesystem MCP: cmd.exe 24664, cmd.exe 25724, cmd.exe 28972
    • xcodebuildmcp: cmd.exe 24868, cmd.exe 25756, cmd.exe 28964

    After explicitly stopping the younger full process branches, the state returned to one root per stdio MCP:

    • Serena: uvx.exe 25344
    • filesystem MCP: cmd.exe 24664
    • xcodebuildmcp: cmd.exe 24868

    This matches the issue description: stdio MCP child processes appear to accumulate under the app-server lifecycle instead of being consistently reaped. The local workaround was full-branch cleanup plus re-check, but the durable fix likely belongs in the Codex app-server / stdio MCP lifecycle handling.

  7. luohoa97 commented on Apr 27, 2026

    @luohoa97
    luohoa97
    on Apr 27, 2026
    Author

    If any developers are seeing this, please build this new change and test if it fixes it. My platform isn't supported. Thanks.

  8. etraut-openai
    closed this as completedin 4e0cf94on Apr 28, 2026
  9. pull
    added a commit that references this issue on Apr 28, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    4e0cf94
  10. Oreoxp
    added a commit that references this issue on May 7, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    0271447
  11. wangjiecloud
    added a commit that references this issue on Jun 27, 2026

    Terminate stdio MCP servers on shutdown to avoid process leaks (opena…

    1052008

  12. helen010969-sys commented on Jul 29, 2026

    @helen010969-sys
    helen010969-sys
    on Jul 29, 2026

    Windows reproduction with @lottiefiles/creator-mcp 0.1.3

    I reproduced a closely related stdio MCP lifecycle failure in Codex Desktop on Windows.

    Environment:

    • Windows 11 Home 10.0.26200 build 26200
    • Codex Desktop package 26.721.4979.0
    • Node.js v24.15.0
    • npm 11.12.1
    • @lottiefiles/creator-mcp 0.1.3

    Reproduction:

    1. Configure the MCP server with:
      npx -y @lottiefiles/creator-mcp@latest
    2. Open LottieFiles Creator in the browser and enable MCP.
    3. In one Codex Desktop task, call get_rules, then get_api_doc pages 1–4, then run_script.
    4. Inspect the codex app-server child process tree after the calls.

    Observed:

    • Separate tool calls left multiple npx -> creator-mcp process chains owned by the Codex app-server.
    • Before run_script, 12 creator-mcp-related node processes were present.
    • run_script failed with the bridge reported unavailable.
    • Running all required calls sequentially inside one orchestration call instead ended with "Transport closed" before the write.
    • No Creator scene or draft was created.
    • Killing only the exact creator-mcp process chains returned the count to zero.

    Expected:

    • One Codex session should reuse one stdio MCP process/transport for all tools from the same server.
    • get_rules, get_api_doc and run_script should use the same live transport.
    • Child processes should be reaped after the tool/session lifecycle ends.

    This looks related to the existing stdio MCP process lifecycle defect, but adds a native Windows reproduction where duplicated server chains also prevent a stateful browser-bridge MCP from completing a write operation.

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

    bugSomething isn't workingmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions