›_ Codex Issues
Codex Issues / #13138

Bug: browser MCP transports drop on macOS and require app restart (Chrome DevTools + Playwright)

Open 💬 7 comments Opened Feb 28, 2026 by swordfish444
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

Desktop app current as of February 28, 2026.

What subscription do you have?

Plus Team

Which model were you using?

gpt-5.3-codex

What platform is your computer?

macOS

What issue are you seeing?

This is a reliability bug (not a feature request): browser MCPs can fail mid-session with transport errors and become unusable until Codex is restarted.

Observed failures include transport-level errors such as:

  • Transport send error
  • Broken pipe (os error 32)
  • Transport closed

Affected MCP servers:

  • chrome-devtools
  • playwright

What steps can reproduce the bug?

  1. Start a Codex session with browser MCPs enabled.
  2. Run a browser MCP call (e.g., mcp__chrome-devtools__new_page or mcp__playwright__browser_tabs).
  3. During or between turns, the MCP child process/transport drops.
  4. Next browser MCP call fails with transport errors and browser MCP becomes unreliable for the session.

What is the expected behavior?

Codex should automatically recover from browser MCP transport drops and continue serving MCP tool calls in the same session, without requiring a full Codex app restart.

Additional information

A fix and E2E validation were prepared in closed PR #13100:

That PR includes:

  • transport-recovery matching for Transport send/receive error, Broken pipe, and Transport closed
  • unit coverage for matcher behavior
  • end-to-end macOS validation for both chrome-devtools and playwright showing recovery in-session after forced transport/process termination

This issue is being opened per maintainer request to track the bug through Issues.

Duplicate triage (reviewed)

Reviewed potential duplicates surfaced by automation:

  • #11489 (MCP client does not auto-reconnect after disconnect): related / likely umbrella, but broader and framed as generic MCP reconnect behavior across transports.
  • #12869 (CLI degrades after stale streamable-http MCP session): related but distinct. That issue is CLI + streamable HTTP stale-session (401 Unauthorized: Session not found). This issue is desktop app browser MCP transport/process drop behavior (Transport closed, Broken pipe) requiring app restart.

Keeping this issue open for desktop-app/browser-MCP tracking. The underlying recovery change may improve multiple related issues, including #11489 and #12869, but the reproduction and user impact here are app-specific and should remain explicit.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #11489
  • #12869

Powered by Codex Action

swordfish444 contributor · 4 months ago

Scope clarification for reviewers:

  • #13138 (this issue): desktop app + browser MCP transport/process drop recovery (Chrome DevTools + Playwright), with restart-required user impact.
  • #11489: broader umbrella for MCP auto-reconnect across transports; likely related and potentially improved by the same recovery approach.
  • #12869: separate failure mode (CLI + streamable-http stale session / 401 Session not found), not the same repro as this app/browser transport-drop bug.

Recommendation: keep #13138 open for app-specific tracking. If a reconnect fix lands from #13100 (or equivalent), then reassess whether #11489 and/or #12869 are fully resolved and close each independently based on validation.

swordfish444 contributor · 4 months ago

Quick follow-up: this is still actively impacting desktop app browser MCP reliability on macOS (chrome-devtools + playwright). Could a maintainer please triage and route this to the desktop-app owner? Happy to provide additional logs or rerun validation if helpful.

DragonnZhang · 3 months ago

Same issue.

ChrisJohnNewton · 3 months ago

Same issue. Playwright MCP + Codex do not perform well together due to this issue.

vucinatim · 3 months ago

I hit the same problem today on macOS, and I was able to narrow it down a bit further.

What I confirmed locally:

  • The original Chrome MCP config was using a fixed --userDataDir for both project browser entries.
  • That caused profile contention / sticky browser state. I saw prior log entries like:
  • The browser is already running for /Users/timvucina/.codex/.tmp/chrome-yugiai. Use --isolated to run multiple browser instances.
  • I then changed both Chrome MCP entries in Codex config to use --isolated instead of fixed --userDataDir.
  • After restarting Codex, the MCP server logs showed that the config fix did take effect:
  • isolated_present: true
  • user_data_dir_present: false

So the shared-profile problem is fixed in my setup.

However, the remaining transport bug still reproduces in the desktop app:

  • chrome-devtools-yugiai/list_pages immediately fails with:
  • Transport closed
  • right after restart, there are no surviving chrome-devtools-mcp processes
  • the MCP log shows the server starts successfully and then exits with:
  • Parent death detected (stdin end). Sending shutdown event...

That strongly suggests there are two separate layers here:

  1. local browser-profile contention (--userDataDir / non-isolated launches)
  2. Codex desktop MCP transport/session lifecycle dropping the child stdio connection even after the Chrome config is corrected

In other words: fixing the Chrome MCP launch config to --isolated removed one failure mode, but the desktop app still has a transport-lifecycle bug that makes the browser MCP unusable in-session.

Current working config:

[mcp_servers.chrome-devtools-yugiai]
command = "npx"
args = [
  "chrome-devtools-mcp@latest",
  "--isolated",
  "--logFile", "/Users/timvucina/.codex/.tmp/chrome-yugiai.log"
]

Observed log sequence after restart:

  • Starting Chrome DevTools MCP Server v0.21.0
  • Chrome DevTools MCP Server connected
  • isolated_present: true
  • later: Parent death detected (stdin end). Sending shutdown event...

Impact:

  • even after correcting the unsafe shared-profile setup, the browser MCP still dies before normal tool calls like list_pages can be used reliably
  • this blocks browser validation workflows in the desktop app

This feels like good additional evidence that the issue is not just stale Chrome state; the app-side MCP transport/session handling is still failing after restart.

Thinkscape · 3 months ago

Completely breaks BrowserMCP on codex desktop, but works fine in codex cli...