›_ Codex Issues
Codex Issues / #26470

Codex Browser/Chrome plugins installed, but no browser backend registers; `agent.browsers.list()` stays empty

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

What version of the Codex App are you using (From “About Codex” dialog)?

26.602.30954

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Title: Codex Browser/Chrome plugins installed, but no browser backend registers; agent.browsers.list() stays empty

Product: Codex desktop app
Severity: High
User impact: Blocks browser-assisted workflows and burns paid tokens during repeated recovery attempts
Token spend: [Could not load usage settings. (gpt-5.4 xhigh, approx. 41 minutes)]

Environment:

  • macOS
  • Codex Browser plugin installed
  • Codex Chrome plugin/extension installed and enabled
  • Local networking enabled
  • Browser pane opened to a real URL
  • Browser bundle version: 26.602.30954
  • Chrome bundle version: 26.602.30954

Summary:
The Codex Browser and Chrome integrations appeared installed correctly, but no browser backend ever registered with the runtime. Repeated retries, reinstalls, Chrome relaunches, Codex relaunches, and opening the Browser pane to a real URL did not change the result. agent.browsers.list() always returned []. The local app itself was healthy and could be verified through a Playwright fallback, so the failure appears to be inside Codex/plugin registration rather than the user app.

Steps to reproduce:

  1. Install/reinstall the Codex Browser plugin.
  2. Install/enable the Codex Chrome extension/plugin.
  3. Restart Codex.
  4. Restart Chrome.
  5. Open the Codex Browser pane to a real URL such as http://127.0.0.1:5173.
  6. Run browser setup and list available browsers.
  7. Observe that no backend is registered.

Expected result:

  • The in-app browser should register and be discoverable.
  • agent.browsers.list() should return at least one backend.
  • agent.browsers.get("iab") and/or agent.browsers.get("extension") should succeed when the corresponding surface is active.

Actual result:

  • agent.browsers.list() returned [] consistently.
  • agent.browsers.get("iab") failed with Browser is not available: iab.
  • agent.browsers.get("extension") failed with Browser is not available: extension.
  • Significant paid usage was consumed before a non-Codex fallback was used.

Diagnostics that passed:

  • Chrome was running.
  • Chrome extension was installed and enabled in the selected Default profile.
  • Native host manifest existed and matched the expected extension origin.
  • Browser pane was opened to a real URL and left open.
  • Local app itself was healthy:
  • control-plane web responded on http://127.0.0.1:5173
  • control-plane API responded on http://127.0.0.1:3001
  • Playwright fallback successfully opened the app and verified Job Studio UI behavior

Notable evidence:

  • Browser runtime bundle:

/Users/timfarmer/.codex/plugins/cache/openai-bundled/browser/26.602.30954/scripts/browser-client.mjs

  • Chrome runtime bundle:

/Users/timfarmer/.codex/plugins/cache/openai-bundled/chrome/26.602.30954/scripts/browser-client.mjs

  • Both runtimes reported zero backends.

Impact:

  • Browser-dependent Codex workflows are blocked even when installation checks pass.
  • Recovery guidance can lead to repeated reinstall/restart loops with no progress.
  • Users can burn substantial tokens before discovering they need an external fallback.

Suggested investigation:

  • Why plugin install state can be healthy while backend registration remains empty
  • Whether Browser pane creation is failing to advertise session metadata
  • Whether Codex is filtering out valid backends by session/build unexpectedly
  • Whether the app should fail fast with a clear registration error instead of repeatedly returning an empty backend list

What steps can reproduce the bug?

Steps to reproduce:

  1. Install/reinstall the Codex Browser plugin.
  2. Install/enable the Codex Chrome extension/plugin.
  3. Restart Codex.
  4. Restart Chrome.
  5. Open the Codex Browser pane to a real URL such as http://127.0.0.1:5173.
  6. Run browser setup and list available browsers.
  7. Observe that no backend is registered.

What is the expected behavior?

Expected result:

  • The in-app browser should register and be discoverable.
  • agent.browsers.list() should return at least one backend.
  • agent.browsers.get("iab") and/or agent.browsers.get("extension") should succeed when the corresponding surface is active.

Additional information

I hope this helps.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

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

  • #25353
  • #25811
  • #25247
  • #26364

Powered by Codex Action

angelrancelantigravity · 1 month ago

This appears related to the failure mode I just documented in #25827: extension and native host checks can pass while the current Codex Desktop node_repl/browser backend registration remains stale or closed.

Key additional observation: a fresh worker/subagent with a new node_repl process could sometimes recover agent.browsers.get("extension"), while the original coordinator session kept returning Transport closed. That points away from Chrome installation/profile state and toward session-local MCP/browser backend registration.

Consolidated details and suggested diagnostics are here: https://github.com/openai/codex/issues/25827#issuecomment-4843304928

timotheecour · 1 month ago

Fresh-session reproduction on macOS after Chrome/plugin reinstall, with newer bundled plugin versions.

Date: 2026-07-04 UTC
Codex Browser plugin bundle: openai-bundled/browser/26.623.101652
Codex Chrome plugin bundle: openai-bundled/chrome/26.623.101652
Environment: Codex desktop/app session on macOS; Chrome previously showed connected in Codex UI, and the prior session had verified Chrome extension/native-host state as healthy after reinstall.

What I ran in a brand-new Codex session:

var browserRoot = `${nodeRepl.homeDir}/.codex/plugins/cache/openai-bundled/browser/26.623.101652`;
var chromeRoot = `${nodeRepl.homeDir}/.codex/plugins/cache/openai-bundled/chrome/26.623.101652`;

var chromeClient = await import(`${chromeRoot}/scripts/browser-client.mjs`);
await chromeClient.setupBrowserRuntime({ globals: globalThis });
await agent.browsers.list();
await agent.browsers.get("extension");

var browserClient = await import(`${browserRoot}/scripts/browser-client.mjs`);
await browserClient.setupBrowserRuntime({ globals: globalThis });
await agent.browsers.list();
await agent.browsers.get("iab");

Observed output:

{
  "chromeList": []
}
extension: Error: Browser is not available: extension

{
  "iabList": []
}
iab: Error: Browser is not available: iab

Per the bundled troubleshooting docs, I then waited 2 seconds and retried the lightweight connector list call:

{
  "retryList": []
}

Result: the fresh session still had no registered browser backends. Both agent.browsers.get("extension") and agent.browsers.get("iab") failed, so I could not use Chrome to open a localhost admin page or capture a screenshot through the Codex connector.

This seems to rule out only stale resumed-thread state. The connector client modules are present and importable, but backend registration remains empty in a new session despite the desktop UI previously reporting Chrome as connected.

tacticalu · 1 month ago

macOS, fresh repro 2026-07-05. Same failure class as this thread: extension installed/enabled, native host manifest valid, Chrome and the native-messaging helper process both confirmed healthy — but the official browser client still returns agent.browsers.list() = []. New detail: the rejection surfaces as nativePipe failing with reason missing-code-signing-identity. Confirmed this isn't a Chrome/extension-side problem — a temporary direct-socket client (bypassing the official nativePipe path entirely) connected fine and listed 114 real tabs from the live Chrome profile. So the block is specifically in Codex's own trust/authorization check on the native pipe, not in Chrome, the extension, or the native host. This bug's been open across 10+ duplicate reports since at least June 4 with no maintainer response — flagging with fresh data in case that helps triage.