Codex Desktop leaks stale local MCP wrapper processes after session shutdown #17115

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

Version 26.325.31654 (1272)

What subscription do you have?

Business

What platform is your computer?

macOS 26.4 (build 25E246) Darwin 25.4.0 arm64 arm

What issue are you seeing?

What version of Codex is running?

Codex Desktop Version 26.325.31654 (1272)
CLI version: codex-cli 0.118.0

Which model were you using?

Primarily GPT-5.4 in Codex Desktop.

What issue are you seeing?

Codex Desktop appears to leave stale local MCP wrapper processes behind after session/thread shutdown.

I reproduced this with at least two local stdio MCP servers:

• a GitHub MCP wrapper launched through op run ... docker run ... github-mcp-server
• a Playwright MCP wrapper launched through npm exec @playwright/mcp@latest

Over time, stale wrapper processes accumulate under the Codex app-server parent process, even though the logs show the MCP session disconnecting and ending during shutdown.

I am attaching a sanitized local log excerpt with the shutdown/restart sequence and kill warnings.
codex-openai-codex-issue-log-excerpt.txt

What steps can reproduce the bug?

What steps can reproduce the bug?

1. Configure one or more local stdio MCP servers in ~/.codex/config.toml.
2. Start Codex Desktop.
3. Open/close threads or otherwise trigger repeated session/thread initialization and shutdown.
4. Inspect processes with ps.
5. Observe old MCP wrapper process pairs still running long after the corresponding session ended.

Example local config patterns:

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

[mcp_servers.github3]
command = "op"
args = ["run", "--no-masking", "--", "docker", "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "-e", "GITHUB_HOST", "ghcr.io/github/github-mcp-server"]

What is the expected behavior?

What is the expected behavior?

When a Codex Desktop session/thread shuts down, all local MCP wrapper processes associated with that session should be cleaned up.

Additional information

Additional information

This looks like incomplete cleanup.

codex-openai-codex-issue-log-excerpt.txt

From the logs, the observed lifecycle is:

• Codex thread/session shuts down
• MCP session logs server session disconnected
• MCP session logs server session ended
• later, a new thread/session starts and Codex starts a fresh MCP server

Example evidence from local logs:

• Shutting down Codex instance
• server session disconnected
• server session ended
• Failed to kill MCP process group ... No such process (os error 3)
• shortly after: starting server
• shortly after: session initialized

I also observed many long-lived local MCP wrapper process pairs still present after those shutdown/end events. This happened for both:

• the GitHub MCP wrapper chain
• the Playwright MCP wrapper chain

For the GitHub MCP wrapper, the outer wrapper processes remained even when there was no corresponding live backend container anymore, which strongly suggests stale leftovers rather than healthy active MCP instances.

Process evidence

Representative ps findings from the same machine showed many old MCP wrapper process pairs still attached to the Codex app-server parent process.

GitHub MCP wrapper examples:

• 7048 / 7174: op run --no-masking -- docker run ... github-mcp-server, running for almost 4 days
• 8882 / 8976: same pattern, running for more than 2 days
• 30087 / 30251: same pattern, still present after about 55 minutes
• 49370 / 49474: same pattern, still present after about 16 minutes

Playwright MCP wrapper examples:

• 7050 / 7146: npm exec @playwright/mcp@latest + child node ... playwright-mcp, running for almost 4 days
• 8883 / 8948: same pattern, running for more than 2 days
• 30089 / 30226: same pattern, still present after about 1 hour
• 49369 / 49421: same pattern, still present after about 30 minutes

These were not isolated one-off leftovers. Multiple old process pairs existed simultaneously for both MCP integrations.