MCP Playwright & chrome-devtools doesn't work in Codex 5.1, GPT 5.1 Bug

[ArtAndrew]

What version of Codex is running?

0.58

What subscription do you have?

Plus Team

Which model were you using?

gpt 5, codex 5, codex 5.1, gpt 5.1

What platform is your computer?

Macos

What issue are you seeing?

• Subject: Issues using MCP Playwright & Chrome DevTools in Codex CLI (“browser already in use”, transport closed)

Hi Codex team,

I’m running Codex CLI with MCPs chrome-devtools and playwright enabled, and both browser tools are effectively unusable in this
environment due to how the browser instances are managed.

Environment (inside Codex CLI sandbox)

• OS: Linux (container) as root
• Sandbox: danger-full-access (FS), approval_policy=never
• Tools: chrome-devtools-mcp and playwright-mcp (Chromium)
• Cache dirs: ~/.cache/chrome-devtools-mcp/chrome-profile, ~/.cache/ms-playwright/mcp-chrome

Chrome DevTools MCP behavior

• First call: chrome-devtools/new_page with URL http://localhost:3000 returns:

  The browser is already running for /root/.cache/chrome-devtools-mcp/chrome-profile. Use --isolated to run multiple browser instances.

• Subsequent calls (list_pages, take_snapshot) either return the same “already running” message or:

  `tool call error: tool call failed for 'chrome-devtools/take_snapshot'

• From inside the agent I can see Chrome processes:

  • npm exec chrome-devtools-mcp@latest ...
  • /opt/google/chrome/chrome --user-data-dir=/root/.cache/chrome-devtools-mcp/chrome-profile ... --remote-debugging-pipe

• Attempts to clean up:

  • pkill -f chrome-devtools-mcp / pkill -f '/opt/google/chrome/chrome' results in execution error: Sandbox(Signal(15)) from the Codex
    harness; i.e. the agent cannot reliably stop the stale browser/MCP processes.

So the MCP server/browser can get into a state where it thinks a browser is already bound to that profile, but the agent has no way to
request a fresh --isolated instance or to reset the profile/process, and eventually the MCP transport closes.

Playwright MCP behavior

• browser_install works and reports no tabs.
• First navigation:

  • browser_navigate to http://localhost:3000 returns:

    Error: Browser is already in use for /root/.cache/ms-playwright/mcp-chrome, use --isolated to run multiple instances of the same
    browser

So the same pattern: the MCP Playwright wrapper is bound to a shared profile/instance under ~/.cache/ms-playwright/mcp-chrome and refuses
a new session, asking for --isolated, but the Codex CLI agent API does not expose a way to request --isolated or to force a reset.

Impact

• I cannot use either MCP to:
  • open pages,
  • take snapshots,
  • or run responsive checks — all UX/UI testing via MCP browsers is blocked by the “browser already in use” state.
• Because approval_policy=never, I also cannot ask the user to run manual cleanup commands outside the sandbox to kill the conflicting
  processes.

Suggested improvements

1. Let the Codex agent request an isolated MCP browser instance (e.g. option in the MCP tool schema that maps to --isolated), so
   concurrent runs or stale state don’t block usage.
2. Add automatic recovery in MCP servers:
   • if the transport drops (“Transport closed”), auto‑restart the underlying browser and clear any stale lock on the profile directory.
3. Make “browser already in use for …” recoverable:
   • either by retrying with a different profile dir or by exposing a “reset”/“restart” tool that the agent can call.
4. Consider a health‑check endpoint in the MCPs so the agent can detect “zombie” browsers and trigger a restart without relying on pkill.

Right now, from inside Codex CLI, I can see and diagnose the problem, but I have no programmatic way to fix it; all higher‑level UX
tooling depending on MCP browsers is effectively unavailable.

Happy to provide more logs (full pm2 / process listings, tool call traces) if that hel

What steps can reproduce the bug?

Uploaded thread: 019a7f71-6e9b-7d13-a4e9-41befc64c9b6

What is the expected behavior?

No response

Additional information

No response

[etraut-openai]

This bug is quite stale at this point, and it hasn't received any upvotes for a couple of months.

Are users still seeing this problem with the latest version of Codex?

[ArtAndrew]

Hi, the problem is still here. I worked with Claude code & codex everyday.

Cc - no problems
Codex doesn’t work

[joevtap]

What worked for me: #5166 (comment)