Codex App: app-owned @playwright/mcp can leave Google Chrome Helper running until app restart
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:
- 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
- Use Codex desktop normally with Playwright/browser tool calls during a session.
- Later, inspect Activity Monitor.
- Observe a
Google Chrome Helperprocess still running with CPU/GPU activity even though there is no obvious active Chrome task. - Attempt to Force Quit the helper process from Activity Monitor.
- Observe that killing the helper alone does not resolve the problem because the parent
Google Chrome/playwright-mcp/Codex.appchain is still alive. - Restart Codex.
- 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/mcpworkers 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:
#12491broad app-side MCP child-process leak / non-reaping#13680app recreates stdio MCP sessions on focus (Windows)#13138browser 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/mcpserver - 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Related Playwright cleanup signal from my side
@DMontgomery40 i think i hit the same family on my Mac.
My setup
26.311.21342 (build 993)Darwin 25.3.0, Apple Siliconplaywrightwas one of the MCPs in the larger buildup i was debuggingWhat happened on quit
After I discovered the bigger MCP pile, I quit Codex with Cmd+Q on
March 17, 2026.Most Codex child processes died, but I still had this smaller leftover set under
PID 1 / launchd:The old leftovers matched earlier Codex sessions from:
March 9, 2026March 14, 2026So on my side this was not only "Playwright/Chrome stays alive until app restart". At least once, part of the Playwright side escaped the quit path and became orphaned.
One nuance
Later, after I reopened Codex and closed it again, most of those leftovers finally disappeared.
So i would frame this as a nondeterministic cleanup bug or race, not a permanently stuck subtree every time.
#10710is why i suspect the lower-level stdio cleanup may already exist, and the remaining gap could be in the desktop app lifecycle around when the Playwright MCP manager actually gets dropped.