In-app Browser plugin works but tool discovery routes agents to standalone browser MCP sessions

[schickling-assistant]

What version of the Codex App are you using?

Codex Desktop for macOS 26.623.141536

What platform is your computer?

macOS arm64

What issue are you seeing?

When the user asks Codex to use the visible/current in-app browser session, the actual in-app Browser backend is available and works, but the model-facing/tool-discovery surface strongly suggests the wrong browser tools.

The Codex Browser plugin is enabled:

[plugins."browser@openai-bundled"]
enabled = true

The current configuration also has standalone browser MCP servers enabled:

[mcp_servers.playwright]
command = "playwright-mcp"

[mcp_servers.chrome-devtools]
command = "chrome-devtools-mcp"

Observed behavior:

• The in-app browser is visibly open and has a current tab.
• mcp__playwright.browser_tabs sees only its own separate Playwright browser, e.g. about:blank.
• mcp__chrome_devtools targets a separate managed Chrome profile.
• Tool discovery for browser/in-app-browser terms exposes the Node bridge and standalone MCP browser tools, but does not clearly surface the bundled Browser plugin skill as the preferred route for the current in-app browser.
• If the agent follows the exposed mcp__playwright or mcp__chrome_devtools tools, it controls the wrong browser session.

However, manually bootstrapping the bundled Browser plugin proves that the in-app Browser backend is healthy:

if (globalThis.agent?.browsers == null) {
  const { setupBrowserRuntime } = await import("<browser-plugin-root>/scripts/browser-client.mjs");
  await setupBrowserRuntime({ globals: globalThis });
}

const iab = await agent.browsers.get("iab");
await iab.tabs.list();
await iab.tabs.selected();

That returns the actual visible in-app browser tab and allows working APIs such as:

• tab.url()
• tab.title()
• tab.playwright.evaluate(...)
• tab.dom_cua.get_visible_dom()
• tab.screenshot(...)

So the failure is not IAB backend discovery or permissions. It is a routing/surfacing problem: the correct Browser plugin path is hidden behind manual browser-client.mjs bootstrap, while unrelated standalone browser MCP tools are exposed prominently.

What steps can reproduce the bug?

1. Enable the bundled Browser plugin:

   [plugins."browser@openai-bundled"]
   enabled = true

2. Also configure standalone browser MCP servers:

   [mcp_servers.playwright]
   command = "playwright-mcp"
   
   [mcp_servers.chrome-devtools]
   command = "chrome-devtools-mcp"

3. Open Codex Desktop's in-app browser to any webpage.

4. Ask Codex to use the built-in/current in-app browser session.

5. Observe that the model-visible tools include standalone mcp__playwright / mcp__chrome_devtools browser tools. Those control separate browser sessions, not the visible in-app browser.

6. Manually bootstrap the bundled Browser plugin with setupBrowserRuntime(...) and agent.browsers.get("iab"). It successfully sees the visible in-app browser tab.

What is the expected behavior?

When browser@openai-bundled is enabled and the user/app context refers to the current in-app browser tab, Codex should surface and route to the Browser plugin path first.

At minimum, the model should be guided away from standalone MCP browser tools when the user explicitly asks for the built-in/current in-app browser.

Ideally, Codex would expose first-class app/browser tools for the current in-app browser, or make the Browser plugin skill directly visible and preferred in tool discovery.

Additional information

There is a separate domSnapshot() compatibility issue covered by #30968. This report is about Browser plugin routing/surfacing. In this reproduction, the in-app Browser backend itself is available and usable once selected through the correct Browser plugin runtime.