openai / openai/codex

[Windows Codex app] Local stdio MCP servers are repeatedly spawned and not reaped within a single task

Open
#38,754 22 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug mcp performance windows-os
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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

Codex app: 26.810.6296.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Within one Codex task, each new turn/tool environment starts another full
set of local tool processes without terminating previous instances.

Observed after restart:

  • qq_mail_mcp: 6 logical MCP instances / 12 Python processes
  • node_repl.exe: 6 instances
  • all instances share the same codex.exe app-server parent
  • creation timestamps increase sequentially within the same task

With cua-driver enabled, each leaked mcp --direct instance also creates a
full-screen Cua.AgentCursorOverlay. At 12-14 instances, the Windows cursor
stutters severely. Restarting Codex clears the processes and restores smooth
cursor movement. Disabling cua-driver prevents those overlay processes but
other stdio MCP instances still accumulate.

What steps can reproduce the bug?
  1. On Windows, configure at least one local stdio MCP server in Codex. In my case, I had:

    • qq_mail_mcp
    • cua-driver using mcp --direct
  2. Fully exit and restart the Codex desktop app so that no old MCP child processes remain.

  3. Open a single Codex task. Do not create additional tasks.

  4. Send several consecutive messages in the same task that require tool-enabled turns, for example asking Codex to run a read-only PowerShell command.

  5. After each turn, inspect the child processes of codex.exe in Task Manager or PowerShell.

  6. Observe that every new turn/tool environment starts another instance of each configured stdio MCP server, while the instances created by previous turns remain running.

  7. After six turns in one task, I observed:

    • 6 logical qq_mail_mcp instances (12 Python processes because each instance has a launcher and runtime child)
    • 6 node_repl.exe instances
    • All instances had the same codex.exe app-server parent.
  8. When cua-driver mcp --direct was enabled, every leaked Cua instance also created a visible full-screen Cua.AgentCursorOverlay covering the dual-monitor virtual desktop.

  9. After approximately 12-14 accumulated Cua instances, the Windows mouse cursor started stuttering severely in normal applications.

  10. Fully exiting and restarting Codex removed all accumulated child processes and immediately restored smooth cursor movement. Disabling the Cua MCP prevented its overlay processes from returning, but other stdio MCP instances continued to accumulate.

What is the expected behavior?

Codex should reuse the existing stdio MCP connection within the same task, or terminate the previous MCP child process when its tool/session context is disposed.

Additional information

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue on Windows with a local stdio MCP server, then trace how each consecutive tool-enabled turn creates and disposes its MCP session. Done means the existing stdio connection is reused within one task or prior child processes are terminated, verified by checking codex.exe children after several turns in Task Manager or PowerShell.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
devtools, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
58/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.