Skip to content

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

Open
Open
Codex Browser/Chrome plugins installed, but no browser backend registers; agent.browsers.list() stays empty#26470
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skills

Description

@noirtim
noirtim
opened on Jun 4, 2026

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.

Activity

  1. noirtim
    added
    appIssues related to the Codex desktop app
    on Jun 4, 2026
  2. github-actions
    added
    bugSomething isn't working
    browser
    skillsIssues related to skills
    on Jun 4, 2026

  3. github-actions commented on Jun 4, 2026

    @github-actions
    github-actionsBot
    on Jun 4, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. angelrancelantigravity commented on Jun 30, 2026

    @angelrancelantigravity
    angelrancelantigravity
    on Jun 30, 2026

    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: #25827 (comment)

  5. timotheecour commented on Jul 4, 2026

    @timotheecour
    timotheecour
    on Jul 4, 2026

    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.

  6. tacticalu commented on Jul 5, 2026

    @tacticalu
    tacticalu
    on Jul 5, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingskillsIssues related to skills

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions