Codex App starts a full local MCP process stack per opened chat/thread, causing memory and process growth #20980

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

26.429.30905

What subscription do you have?

ChatGPT Pro ($100/month)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Opening a second/old Codex App chat appears to initialize another full local stdio MCP process stack and keep it alive after returning to the original chat. This causes process count and memory usage to grow even when no MCP tools are used directly in that opened chat.

Observed after a fresh Codex restart:

Baseline after restart:
Codex + descendants: 98 processes
Working set: ~5.14 GB
Direct app-server children: mostly 2 instances per MCP server, chrome-devtools 3

After opening one old Codex chat and returning to the original chat:
Codex + descendants: 142 processes
Working set: ~7.46 GB
Direct app-server children: mostly 3 instances per MCP server, chrome-devtools 4

Delta from just opening another chat:
+44 processes
+~2.33 GB working set
+1 local MCP stack

This was measured from the Windows process tree under the Codex app/core process. The process growth was visible in node.exe, python.exe, uv.exe/uvx.exe, cmd.exe, and MCP-specific processes.

Examples from the before/after measurement:

node.exe      24 -> 36
python.exe    16 -> 24
uv.exe         8 -> 12
cmd.exe       22 -> 33

MCP role grouping after opening the old chat:

MCP: chrome-devtools   16 processes   ~951 MB
MCP: firebase          12 processes   ~720 MB
MCP: yfinance          15 processes   ~708 MB
MCP: shadcn            12 processes   ~679 MB
MCP: markitdown        15 processes   ~679 MB
MCP: postman           12 processes   ~640 MB
MCP: context7          12 processes   ~560 MB
MCP: avanza            15 processes   ~492 MB
MCP: excel             15 processes   ~443 MB
MCP: tauri              6 processes   ~205 MB

This feels like MCP servers are scoped to each chat/thread/session runtime rather than shared at the Codex app level, or old chat runtimes are not being torn down promptly.

What steps can reproduce the bug?

1. Configure multiple local stdio MCP servers in %USERPROFILE%\.codex\config.toml.
2. Fully restart the Codex desktop app.
3. In the first Codex chat/thread, measure the process tree under the Codex app/core process.
4. Open one older Codex chat/thread from the Codex app UI.
5. Return to the original chat/thread.
6. Measure the process tree again.

Actual result: opening the older chat adds another local MCP stack. In my case the process tree grew from 98 processes / ~5.14 GB to 142 processes / ~7.46 GB.

The relevant MCP config, with secrets redacted, is:

[mcp_servers.chrome_devtools]
command = "npx"
args = [
  "--registry",
  "https://registry.npmjs.org",
  "chrome-devtools-mcp@0.17.1",
  "--browser-url=http://127.0.0.1:9222"
]

[mcp_servers.markitdown]
command = "uvx"
args = [ "markitdown-mcp" ]
enabled = true

[mcp_servers.excel]
command = "uvx"
args = [ "excel-mcp-server", "stdio" ]

[mcp_servers.shadcn]
command = "npx"
args = [ "shadcn@latest", "mcp" ]

[mcp_servers.zotero]
command = "uvx"
args = [ "--upgrade", "zotero-mcp", "--transport", "stdio" ]
enabled = false

[mcp_servers.notion]
url = "https://mcp.notion.com/mcp"
enabled = false

[mcp_servers.postman]
command = "npx"
args = [ "@postman/postman-mcp-server", "--minimal" ]
enabled = true

[mcp_servers.context7]
command = "npx"
args = [ "-y", "@upstash/context7-mcp", "--api-key", "[REDACTED]" ]

[mcp_servers.firebase]
command = "npx"
args = [ "-y", "firebase-tools@latest", "mcp" ]

[mcp_servers.tauri_mcp_server]
command = "mcp-server-tauri"
enabled = true

[mcp_servers.yfinance]
command = "uvx"
args = [ "--with", "tabulate", "yfmcp@latest" ]

[mcp_servers.avanza]
command = "uvx"
args = [ "--prerelease=allow", "avanza-mcp==1.3.0" ]

What is the expected behavior?

I would expect local MCP servers to either be shared at the Codex app/app-server level when possible, or for inactive chat/thread runtimes to tear down their stdio MCP processes promptly when the user leaves the thread.

At minimum, opening an old chat and returning should not permanently increase the app's baseline by another full MCP stack (~2.3 GB on my machine) unless that chat remains actively running work that needs those tools.

Additional information

Machine/environment:

Codex App version from About Codex dialog: 26.429.30905
Windows package version from Get-AppxPackage: 26.429.3425.0
Platform field: Microsoft Windows NT 10.0.26200.0 x64
Windows edition/build: Microsoft Windows 11 Home, version 10.0.26200, build 26200
Physical RAM: 31.2 GB

Related issues I found before filing:

• Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491 reported large numbers of Codex/node processes and high RSS/swap usage from unreaped Codex workers/MCP child processes.
• Codex startup sub-agent will restart a bunch of mcp, but it will not be automatically cleared after closing the sub-agent. #12976 reported Windows-specific MCP child processes remaining after subagents closed.
• Codex CLI 0.112.0: long-lived multi-agent sessions accumulate duplicate stdio MCP stacks instead of returning to a bounded baseline #14233 reported long-lived sessions accumulating repeated stdio MCP stacks.
• Codex Desktop repeatedly starts full MCP stacks for new sessions/subagents, causing severe slowdown and memory pressure #18333 described Codex Desktop starting full MCP stacks for new sessions/subagents and memory pressure increasing.

I also saw PR #19753, "Terminate stdio MCP servers on shutdown to avoid process leaks", merged Apr 28 2026. My current observation is on Codex App 26.429.30905 after a fresh restart. This may be different from shutdown leaks: the extra MCP stack is created simply by opening another existing chat/thread and does not disappear immediately after returning to the original chat.

The main user-visible impact is that browsing between old chats can grow Codex from about 5 GB to 7.5 GB with one additional chat, and previously I observed about 11 GB after more chat/thread switching.