codex - 💡(How to fix) Fix Codex Desktop MCP Process Lifecycle Observation [3 comments, 4 participants]

Codex Desktop MCP Process Lifecycle Observation Date: 2026-05-04

Summary Codex Desktop on Windows accumulated duplicate MCP process groups over a long-running app session. The largest resource consumer was chrome-devtools-mcp, followed by context-mode.

The behavior looked like MCP server lifecycle/cleanup drift: old process groups remained alive across Codex runtime/session cycles, and some processes became detached from the current codex.exe app-server tree.

Environment OS: Windows workstation App: Codex Desktop Codex package path observed: C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\Codex.exe MCP servers involved: chrome-devtools, configured as cmd /c npx -y chrome-devtools-mcp@latest context-mode, configured as npx -y context-mode Evidence Initial process tree under codex.exe app-server:

node.exe: 110 processes, about 10 GB private memory cmd.exe: 88 processes repeated MCP groups: 22 each group had: 2 Node/CMD processes for chrome-devtools-mcp 1 chrome-devtools-mcp watchdog process 2 Node/CMD processes for context-mode After disabling and re-enabling the Chrome DevTools MCP in the Codex MCP settings UI:

codex.exe app-server changed from the old PID to a new PID active app-server descendants dropped to 19 processes active Node processes under the new app-server dropped to 7 about 3 old chrome-devtools-mcp Node processes remained active outside the new Codex app-server tree This suggests that toggling MCP settings can force a partial cleanup/restart of the app-server runtime, but some child processes can remain orphaned.

Operational Guidance Keep Chrome DevTools MCP disabled by default in this project. Use it only when DevTools-specific evidence is required:

console inspection network request inspection Lighthouse performance traces heap snapshots DevTools Protocol-specific debugging Use lighter tools by default:

Browser Use: navigation, clicking, screenshots, simple visual checks Playwright: reproducible browser tests, automated flows, screenshots, repeatable UI validation Draft Bug Report Title:

Codex Desktop accumulates duplicate MCP server processes and leaves orphaned node.exe processes on Windows Body:

What happened?

On Windows, a long-running Codex Desktop session accumulated many duplicate MCP server process groups under codex.exe app-server.

The main issue was not a single high-memory process, but repeated MCP process groups that were not cleaned up or reused across runtime/session cycles.

Observed process state

Codex Desktop package path:

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\Codex.exe

Configured MCP servers:

• chrome-devtools: cmd /c npx -y chrome-devtools-mcp@latest
• context-mode: npx -y context-mode

Before toggling MCP settings:

• node.exe: 110 processes under the Codex app-server tree
• cmd.exe: 88 processes under the Codex app-server tree
• total Node private memory: about 10 GB
• repeated MCP groups: 22

Each repeated group contained:

• 2 Node/CMD processes for chrome-devtools-mcp
• 1 chrome-devtools-mcp watchdog process
• 2 Node/CMD processes for context-mode

Creation times showed these groups accumulating across multiple moments over several days, not just within a single tool call.

Reproduction / trigger pattern

I did not confirm a minimal reproduction yet, but the pattern appears related to Codex Desktop runtime/session lifecycle:

1. Keep Codex Desktop open for a long-running session.
2. Have global MCP servers configured, especially chrome-devtools-mcp and context-mode.
3. Open/resume multiple chats or runtime sessions over time.
4. Observe repeated MCP process groups accumulating under codex.exe app-server.

Direct tool calls did not create a new group in one test:

• calling context-mode once did not increase node.exe count
• calling Chrome DevTools MCP list_pages once did not increase node.exe count

This suggests the duplication may happen on runtime/session creation or reload, not on each MCP tool invocation.

Cleanup behavior

After disabling and re-enabling Chrome DevTools MCP from the Codex MCP settings UI:

• the codex.exe app-server PID changed
• active descendants dropped significantly
• active Node processes under the new app-server dropped to 7
• some old chrome-devtools-mcp Node processes remained active outside the new Codex app-server tree, apparently orphaned

Expected behavior

Codex Desktop should either:

• reuse one MCP server instance per configured MCP when appropriate, or
• terminate MCP server process groups when their owning session/runtime is closed or replaced

It should not leave repeated node.exe/cmd.exe MCP process groups alive for stale sessions, and it should not leave orphaned MCP child processes after settings toggles or app-server reloads.

Impact

The duplicate MCP process groups consumed around 10 GB of private memory on the workstation and made Codex Desktop appear to be responsible for a very large process tree.

Workaround

Keeping Chrome DevTools MCP disabled by default reduces the process count and memory footprint substantially. Browser Use or Playwright are lighter alternatives for ordinary browser navigation, screenshots, and repeatable UI validation. Chrome DevTools MCP is still useful for DevTools-specific tasks such as console, network, Lighthouse, performance trace, and heap inspection