Codex App: app-owned @playwright/mcp can leave Google Chrome Helper running until app restart

Resolved 💬 2 comments Opened Mar 16, 2026 by DMontgomery40 Closed Apr 6, 2026

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

26.311.21342

What subscription do you have?

Pro.

What platform is your computer?

Darwin 25.0.0 arm64 arm

What issue are you seeing?

Codex desktop appears able to leave an app-owned Playwright MCP Chrome subtree running after browser automation work is no longer obviously active.

The visible symptom was a stubborn Google Chrome Helper process in Activity Monitor with non-trivial CPU/GPU usage. I mostly use Brave, so this stood out immediately.

Force Quit on the helper itself did not make it stay dead, because it was only a child process. The helper belonged to this parent chain:

Codex.app app-server
-> npm exec @playwright/mcp@latest
-> node .../playwright-mcp
-> /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --user-data-dir=/Users/davidmontgomery/Library/Caches/ms-playwright/mcp-chrome ...
-> Google Chrome Helper --type=gpu-process ...

The specific helper I inspected was:

/Applications/Google Chrome.app/Contents/Frameworks/Google Chrome Framework.framework/Versions/145.0.7632.162/Helpers/Google Chrome Helper.app/Contents/MacOS/Google Chrome Helper --type=gpu-process --disable-breakpad --user-data-dir=/Users/davidmontgomery/Library/Caches/ms-playwright/mcp-chrome ...

The parent browser process was:

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome ... --user-data-dir=/Users/davidmontgomery/Library/Caches/ms-playwright/mcp-chrome --remote-debugging-port=50278 about:blank

And that browser process was parented by:

node /Users/davidmontgomery/.npm/_npx/9833c18b2d85bc59/node_modules/.bin/playwright-mcp

which in turn was parented by:

npm exec @playwright/mcp@latest

which in turn was parented by:

/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

Restarting Codex made the stuck Chrome helper disappear immediately.

So this does not look like “Chrome happened to be open”; it looks like an app-owned @playwright/mcp worker held onto Chrome children or failed to clean them up.

What steps can reproduce the bug?

I do not yet have a minimal deterministic repro, but this was the observed sequence on my machine:

  1. Configure the Codex desktop app with the stdio Playwright MCP server in ~/.codex/config.toml:
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]
enabled = true
  1. Use Codex desktop normally with Playwright/browser tool calls during a session.
  2. Later, inspect Activity Monitor.
  3. Observe a Google Chrome Helper process still running with CPU/GPU activity even though there is no obvious active Chrome task.
  4. Attempt to Force Quit the helper process from Activity Monitor.
  5. Observe that killing the helper alone does not resolve the problem because the parent Google Chrome / playwright-mcp / Codex.app chain is still alive.
  6. Restart Codex.
  7. Observe that the helper disappears immediately after the app restart.

A representative process snapshot before restart looked like this:

63505 62876 ?? /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
67410 63505 ?? npm exec @playwright/mcp@latest
67687 67410 ?? node /Users/davidmontgomery/.npm/_npx/9833c18b2d85bc59/node_modules/.bin/playwright-mcp
47037 49192 ?? /Applications/Google Chrome.app/Contents/MacOS/Google Chrome ... --user-data-dir=/Users/davidmontgomery/Library/Caches/ms-playwright/mcp-chrome --remote-debugging-port=50278 about:blank
55387 47037 ?? /Applications/Google Chrome.app/.../Google Chrome Helper --type=gpu-process --user-data-dir=/Users/davidmontgomery/Library/Caches/ms-playwright/mcp-chrome ...

One more important detail: this machine also had other Playwright servers launched from terminal sessions (claude and codex --yolo), but the stuck Chrome helper above was specifically from the no-TTY process tree parented by Codex.app.

What is the expected behavior?

If Codex owns a Playwright MCP worker, it should fully clean up the Chrome subtree it launched when that browser session is no longer needed.

More specifically:

  • old app-owned @playwright/mcp workers should not leave Chrome / Chrome Helper children behind
  • killing or restarting the relevant app-owned MCP session should not require a full Codex app restart to clear the Chrome helper
  • if Codex recreates MCP sessions, the previous Playwright/Chrome subtree should be reaped cleanly

Additional information

I checked the configured Playwright MCP server and the cached package version on disk. On this machine the Codex app is launching:

@playwright/mcp 0.0.68
playwright-core 1.59.0-alpha-1771104257000

Relevant existing issues I reviewed before filing:

  • #12491 broad app-side MCP child-process leak / non-reaping
  • #13680 app recreates stdio MCP sessions on focus (Windows)
  • #13138 browser MCP transport drops and require app restart

I’m filing this separately because the user-visible symptom here is very specific and easy to recognize:

  • a persistent Google Chrome Helper / GPU process
  • backed by ms-playwright/mcp-chrome
  • parented by Codex desktop’s own @playwright/mcp server
  • cleared by restarting Codex

So even if the root cause overlaps with the broader MCP lifecycle issues above, this looks like a concrete Playwright/Codex-app cleanup bug worth tracking explicitly.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗