›_ Codex Issues
Codex Issues / #15365

macOS desktop Browser MCP consistently returns `Transport closed` while Codex CLI succeeds on the same machine

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

Summary

On macOS, Codex desktop's built-in Browser MCP consistently fails with a Transport closed error on brand new threads.

On the same machine, Codex CLI succeeds against the same Browser MCP setup.

Environment

  • Date observed: 2026-03-21
  • OS: macOS 15.7.2 (24G322)
  • Codex CLI: 0.115.0
  • Browser MCP runtime: 0.1.3
  • Browser: Google Chrome + Browser MCP extension connected

Reproduction

  1. Open Codex desktop on macOS.
  2. Open a brand new thread.
  3. Use the built-in Browser MCP tool only.
  4. Call browser_snapshot.

Actual

The desktop thread fails immediately with:

tool call error: tool call failed for `browsermcp/browser_snapshot`

Caused by:
    Transport closed

Expected
Desktop Browser MCP should either return a snapshot or a meaningful extension-connection error, and it should behave consistently with Codex CLI on the same machine.

What I verified locally
The Browser MCP wrapper/runtime is healthy.
The Browser MCP extension is connected in Chrome.
The local wrapper now launches Browser MCP 0.1.3.
resources/list and resources/templates/list both succeed locally.
browser_snapshot succeeds from Codex CLI on the same machine.
Wrapper stderr is clean; I no longer see the earlier RangeError: Maximum call stack size exceeded from Browser MCP 0.1.2.
CLI workaround that succeeds
cd /tmp
codex exec --json --skip-git-repo-check 'Use the browser MCP tools only. Call browser_snapshot. If a tool call fails, report the exact error and stop.'
Notes
This looks more like a Codex desktop MCP transport/lifecycle problem than a Browser MCP install problem, because:

the same Browser MCP config works from CLI
a fresh desktop thread still fails
the local Browser MCP runtime is responsive and not crashing
Then click Create. After submitting, report the final GitHub issue URL only.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 5 months ago

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

  • #13138

Powered by Codex Action

nos1609 · 1 month ago

Additional data point, in a different environment and MCP implementation:

  • On Linux, the named Playwright MCP tool in a fresh desktop thread fails with Transport closed before it opens a blank tab.
  • A one-shot local stdio client using the equivalent Playwright MCP setup can open the MCP tabs successfully.
  • The divergence happens before target navigation or authentication, so this looks consistent with a desktop MCP transport/lifecycle boundary rather than a target-application or browser-runtime failure.

I am intentionally omitting host, configuration, target, and runtime-artifact details.

DhruvJ19 · 16 days ago

Maintainer data point from macOS Codex Desktop 26.803.61601 on 2026-08-11: the in-app Browser can remain visibly open while the Browser bridge returns zero user tabs and the desktop log records repeated owner-discovery timeouts followed by No ChatGPT browser route is available across unrelated local conversations. After disabling the Obsidian/Seekstone MCP for future initialization and observing no new ENFILE event, the route defect persisted. In the same bounded window, the independent Computer Use fallback to an already-open Comet browser returned Transport closed at the control-bridge layer. Full restarts/reconnects only recover temporarily. Please cross-link this with the route/renderer lifecycle reports (#35083/#35372) and advise whether there is an engineering owner, incident reference, supported in-session rebind, or fixed desktop build.

DhruvJ19 · 16 days ago

Post-restart update (2026-08-11 HKT):

I fully restarted the macOS desktop app. The explicit in-app Browser client initialized, but user.openTabs() still returned an empty list while the visible Codex UI reported one Help Center tab open. The fresh desktop log then recorded owner-discovery timeouts across multiple active conversations, followed by repeated No ChatGPT browser route is available errors for the current Browser session.

As a control, the already-open Comet app was queried through the Computer Use bridge immediately afterward and returned a live window, URL, accessibility tree, and screenshot successfully. This is therefore not a general macOS accessibility failure or a Comet failure. The user has also reproduced the issue with Surfshark disabled, so it is not Surfshark-only.

The Obsidian/Seekstone MCP is disabled again; no CDP, VPN, cookie, credential, or browser-state changes were made. Please route this to the macOS desktop in-app Browser owner/engineering and provide either the owning incident, a supported rebind procedure, or a fixed desktop build. The issue remains reproducible after a full restart.

DhruvJ19 · 16 days ago

New materially separated result from the Codex macOS desktop investigation on 2026-08-11: I gracefully terminated only the verified orphaned codex_chronicle PID 59900, which had been alive for about 1 day 9 hours from an older Sparkle-cached ChatGPT.app bundle and held codex_chronicle.lock. The current PID 51807 then acquired the lock; the log showed Chronicle starting display streams and writing chronicle-started.pid. A single immediate read-only bundled in-app Browser check still returned user.openTabs() = [] while the visible UI retained the Help Center tab, followed by No ChatGPT browser route is available for the affected Browser session at about 21:42 HKT. This isolates two layers: the stale Chronicle process was a real local contention amplifier and is now cleared; the Browser session route-owner/registry defect persists independently after restart, MCP disabled, Surfshark disabled, and lock recovery. Comet remains a separate fallback. Please route this to the owning desktop Browser/Computer Use team and provide a supported rebind, owner/incident reference, and fixed build.

DhruvJ19 · 16 days ago

Clean reproduction after shared-task containment (2026-08-11 HKT):

  • Paused the other active Browser/Computer Use task chats for a bounded quiet window.
  • Confirmed the Obsidian/Seekstone MCP remained disabled.
  • Made exactly one fresh read-only bundled in-app Browser call to list open tabs.
  • The Browser tool itself failed before returning state with Transport closed.

No navigation, tab claim, click, cookie, credential, CDP, VPN, or browser-state operation occurred. This reproduces the failure with cross-chat contention removed. Combined with the visible-tab/openTabs()=[] and No ChatGPT browser route is available evidence, the remaining defect is the desktop Browser/Computer Use transport/session lifecycle, not a target site, account, or single MCP configuration. Please route this to the owning engineer and provide a supported rebind, incident/owner reference, or fixed build.