Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop leaks stale local MCP wrapper processes after session shutdown [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#17115•Fetched 2026-04-09 08:02:08
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
kingtistelkingtistel
Participants
github-actions[bot]github-actions[bot]kingtistelkingtistel
Timeline (top)
labeled ×3commented ×1unlabeled ×1

Error Message

  • Failed to kill MCP process group ... No such process (os error 3)

Code Example

[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"]
RAW_BUFFERClick to expand / collapse

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.

extent analysis

TL;DR

The most likely fix for the issue of stale local MCP wrapper processes being left behind after session/thread shutdown in Codex Desktop is to implement a more robust process cleanup mechanism.

Guidance

  • Review the Codex Desktop code to ensure that it properly terminates and cleans up MCP wrapper processes when a session/thread is shut down.
  • Investigate the Failed to kill MCP process group ... No such process (os error 3) error and determine why the process group is not being properly killed.
  • Consider implementing a timeout or retry mechanism to ensure that MCP wrapper processes are properly cleaned up after a certain period of time.
  • Use tools like ps to monitor and verify that MCP wrapper processes are being properly terminated and cleaned up.

Example

No specific code example can be provided without access to the Codex Desktop codebase, but a general example of how to properly clean up processes in a Node.js environment might look like this:

const { spawn } = require('child_process');

// Spawn a new process
const process = spawn('command', ['arg1', 'arg2']);

// When the session/thread is shut down, kill the process
process.kill();

Notes

The issue seems to be related to incomplete cleanup of MCP wrapper processes, and a more robust cleanup mechanism is needed to ensure that these processes are properly terminated and cleaned up.

Recommendation

Apply a workaround by manually killing the stale MCP wrapper processes using a tool like ps and kill, until a more robust cleanup mechanism can be implemented in the Codex Desktop code.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt issue#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING