codex - 💡(How to fix) Fix Codex app appears to start duplicate MCP server processes across conversations

Component

Codex desktop app / MCP server lifecycle

What happened?

I noticed that the Codex app appears to start separate MCP server instances for different conversations, even when they are the same MCP servers with the same configuration.

Over time, these processes accumulate and duplicate each other.

On my home PC, I recently saw 14 instances each of four MCP servers, around 56 processes total.

I also checked my MacBook and saw a similar pattern:

• multiple serena MCP server processes;
• multiple context7 wrapper/server processes;
• multiple node_repl processes;
• multiple codex app-server --listen stdio:// processes.

The processes appeared to accumulate in batches as I worked with different sessions/conversations.

Expected behavior

If several conversations use the same MCP servers with the same configuration, Codex should ideally reuse a shared MCP runtime/server instance, or clean up inactive instances when the conversation that owns them is no longer active.

At minimum, old inactive MCP server processes should not accumulate indefinitely during long-running app usage.

Actual behavior

Repeated MCP server instances can remain running at the same time.

This creates extra memory/process overhead. It is not always immediately critical, but after long-running work it can become significant.

Why this matters

Many Codex users configure multiple MCP servers. If every active or previously opened conversation starts its own duplicate set, the number of background processes can grow quickly.

For example, 14 copies of 4 MCP servers becomes 56 processes. Even if each process is modest, the combined memory/process overhead adds up and can make the app feel heavier over time.

Possible direction

Potential approaches:

• shared MCP runtime across conversations when the server command/configuration is identical;
• reference-counted MCP process lifecycle;
• more aggressive cleanup of MCP servers attached to inactive/closed conversations;
• diagnostics in the app showing which MCP processes are running and which conversation owns them.

Related issues / discussion

Related broader discussion: https://github.com/openai/codex/discussions/22987

Related large-session performance issue: https://github.com/openai/codex/issues/22991

Environment

Observed on:

• Windows home PC, where I saw around 56 MCP-related processes in one case;
• macOS MacBook, where I saw repeated serena, context7, node_repl, and codex app-server --listen stdio:// processes.

I can provide exact OS/app versions and process-list snippets if helpful.