Chrome plugin works in UI, but Codex browser bridge reports Browser is not available: chrome. #37307

Activity

1. sandeepbangera

   added

   bugSomething isn't workingSomething isn't working

   on Aug 6, 2026
2. ryo88c commented on Aug 12, 2026

   

   ryo88c

   on Aug 12, 2026

   More actions

   I can reproduce this issue on a newer Codex desktop/plugin build.

   Environment:

   • macOS
   • Codex desktop / Chrome plugin: 26.803.61601
   • Google Chrome: 151.0.7922.110
   • ChatGPT Chrome extension: 1.2.27236.6274
   • Chrome profile: Profile 3, not the Default profile

   The bundled diagnostics report:

   • Profile 3 is selected
   • The extension is installed and enabled in Profile 3
   • The Native Messaging Host manifest exists and is valid
   • The expected extension origin is configured correctly

   However, the browser runtime still returns:

   Browser is not available: chrome

   I also tried:

   • disabling and re-enabling the extension
   • removing and reinstalling the extension
   • restarting Chrome
   • updating the Codex desktop app
   • bringing the Profile 3 Chrome window to the foreground

   The problem remains reproducible.

   Because the extension is installed in a non-default Chrome profile, this may also be related to #31540.
3. cypres0099 commented on Aug 14, 2026

   

   cypres0099

   on Aug 14, 2026

   More actions

   Assistant-submitted follow-up at the GitHub account owner's explicit request.\n\nI reproduced this on macOS with a useful recovery boundary that points to stale browser-runtime state rather than a Chrome profile or installation problem.\n\nEnvironment observed during failure:\n- Bundled Chrome plugin loaded by the existing task: 26.803.61601\n- Google Chrome: 151.0.7922.138\n- ChatGPT Chrome extension in the selected profile: 1.2.27259.19709\n- Chrome was running\n- The extension was installed and enabled\n- The native-host manifest existed, matched the expected host name and origins, and the packaged diagnostic reported it correct\n\nRuntime result in the existing Codex task:\n- agent.browsers.get("chrome") returned: Browser is not available: chrome\n- Waiting and retrying did not help\n- Opening a fresh Chrome window in the selected profile did not help\n- Reinstalling the Chrome extension and Codex Chrome plugin did not make that already-running task recover\n\nThe significant recovery boundary:\n1. The original task had already initialized and retained the browser runtime from plugin bundle 26.803.61601.\n2. After the reinstall/update, a fresh Codex task initialized the browser runtime from plugin bundle 26.810.41047.\n3. The fresh runtime immediately returned a live Chrome extension browser instance.\n4. It successfully listed open Chrome tabs, claimed an existing authenticated tab, read its DOM, and navigated within the site.\n\nCurrent post-recovery cache state:\n- chrome/latest resolves to chrome/26.810.41047\n- The native-host manifest target exists and resolves through that alias\n\nThis suggests a lifecycle/invalidation failure: an existing task can retain a stale in-memory browser client or backend registration after the plugin/extension changes. Reinstalling the files is insufficient because the persistent task runtime continues reusing its already-initialized agent/browser state. A fresh task/runtime loads the new bundle and recovers.\n\nExpected behavior:\n- On plugin version change, extension reconnection, or a Browser is not available result after otherwise healthy diagnostics, Codex should invalidate and rebuild the browser runtime automatically.\n- The retry path should not keep reusing an in-memory client loaded from an older plugin bundle.\n- Diagnostics should expose the loaded browser-client version and the currently installed plugin version so version skew is visible.\n- Users should not need to reinstall components or create a fresh task to clear stale browser registration.\n\nNo browsing history, authenticated page content, account identifiers, or private logs are included in this report.
4. scott-cmd11 commented on Aug 20, 2026

   

   scott-cmd11

   on Aug 20, 2026

   More actions

   For anyone hitting Browser is not available: chrome while the extension is installed/enabled and all four bundled diagnostic scripts exit 0 — a diagnostic checklist from a machine where this recurred repeatedly:

   1. Check the latest symlink actually resolves. The manifest host path goes through ~/.codex/plugins/cache/openai-bundled/chrome/latest/.... Run:

      ls -la ~/.codex/plugins/cache/openai-bundled/chrome/
      readlink ~/.codex/plugins/cache/openai-bundled/chrome/latest

      If latest points at a deleted version (or is missing), that's the bug — see macOS: same-version Chrome plugin cache reconciliation deletes chrome/latest while the plugin remains current #37059. Repair:

      cd ~/.codex/plugins/cache/openai-bundled/chrome
      ln -sfn "$PWD/$(ls | grep -E '^[0-9]' | sort -V | tail -1)" latest

      then fully quit and relaunch both the ChatGPT app and Chrome (the app caches the failed plugin init from its own startup and does not retry until relaunched).

   2. The bundled checks have a blind spot: check-native-host-manifest.js validates JSON fields but never verifies the manifest's path exists/is executable, so it exits 0 while every host spawn fails with ENOENT.

   3. If the path is fine but the bridge is dead: check for a stale resident host. If pgrep -f "ChatGPT for Chrome" shows a process spawned before the last extension update or system wake, kill it — Chrome's extension immediately reconnects and spawns a fresh host; no app restart needed.

   4. If only ONE Codex thread reports the browser missing while a fresh codex exec session lists tabs fine: that thread's browser binding is stale (host replacement rotates runtime session ids). Reset the session's JS runtime / re-run browser setup, or start a new thread.

   5. Check disk space on the volume hosting ~/.codex. ENOSPC in the thread-store (No space left on device (os error 28) in logs) produces confusing secondary failures including browser errors.

   All five were needed on the same machine across two weeks; #1 recurred on every plugin update until a local watchdog was added.
5. FelixMiske commented on Aug 24, 2026

   

   FelixMiske

   on Aug 24, 2026

   More actions

   Assistant-submitted current-version reproduction at the GitHub account owner's explicit request.

   I reproduced this again on a newer Codex desktop/plugin build, with a narrower lifecycle boundary: browser selection can initially succeed and return documentation, but the returned browser ID is already unavailable on the first lightweight call. Opening a fresh Chrome window causes a new browser ID to register and immediately restores control.

   Environment:

   • macOS 26.5.2 (25F84), arm64
   • Codex desktop / bundled Chrome plugin: 26.818.41705 (app build 6971)
   • Bundled Codex CLI: 0.149.0-alpha.4.1
   • Google Chrome: 151.0.7922.170
   • ChatGPT Chrome extension: 1.2.27268.51612_0
   • Selected profile: Default

   Exact result:

   1. Chrome was already running.
   2. The packaged browser runtime initialized from the current 26.818.41705 plugin.
   3. agent.browsers.get("chrome") returned a Chrome extension browser and chrome.documentation() completed, yielding browser ID -760e-4154-8ba3-af110d721b1c.
   4. The next supported lightweight call (chrome.nameSession(...) / chrome.user.openTabs()) failed with Browser is not available: -760e-4154-8ba3-af110d721b1c.
   5. Waiting two seconds and retrying chrome.user.openTabs() once failed with the same error.
   6. All installation/transport checks passed:
      • Chrome running: yes
      • supported Chrome installation found
      • extension installed and enabled in Default
      • native-host manifest exists, host name/origins match, and reports correct
   7. Running the packaged recovery command open-chrome-window.js --browser chrome opened a new Default-profile about:blank window.
   8. After two seconds, agent.browsers.get("chrome") returned a new browser ID, -7efa-4dd1-9ba4-1361d6ceb437.
   9. nameSession(...) and user.openTabs() then succeeded immediately.

   Expected behavior:

   • A browser returned by get("chrome") should remain usable for the first call.
   • If the extension/native-host session rotated or the returned browser ID was stale, the runtime should invalidate and reacquire it automatically.
   • A user should not need to open an extra Chrome window to force backend registration when Chrome, the extension, and native host all pass diagnostics.

   This looks like a stale or prematurely invalidated extension-browser registration rather than a damaged install. Reinstalling was intentionally skipped because the official fresh-window recovery succeeded and every local diagnostic passed.

   No browsing history, authenticated page content, account identifiers, credentials, or raw logs are included.
6. quentez commented on Sep 2, 2026

   

   quentez

   on Sep 2, 2026

   More actions

   Assistant-submitted current-version reproduction at the GitHub account owner explicit request.

   Reproduced on 2026-09-02 with a new symptom: every browser-selection attempt visibly reloads the ChatGPT Chrome extension, but the runtime never receives a Chrome registration.

   Environment:

   • macOS 27.0 (26A5416b), arm64
   • Bundled Chrome plugin: 26.818.32112
   • Google Chrome: 152.0.7977.76
   • Chrome profile launched: Default

   Observed behavior:

   1. Chrome was initially not running.
   2. The packaged launcher started a new Default-profile Chrome window.
   3. agent.browsers.get("chrome") returned Browser is not available: chrome.
   4. The user could see the extension reload when each connection attempt ran.
   5. Waiting two seconds and retrying still returned Browser is not available: chrome.
   6. Waiting another eight seconds and calling agent.browsers.list() returned [].
   7. Chrome remained running throughout.

   Transport checks:

   • Native-host manifest reports correct host name and allowed origins.
   • The manifest host path exists and is executable.
   • chrome/latest resolves to the installed 26.818.32112 plugin bundle.
   • A ChatGPT for Chrome native-host process is running for the expected extension origin.
   • The volume has 32 GiB available, so this is not an ENOSPC failure.
   • The extension-install diagnostic itself cannot inspect Chrome state because macOS returns EPERM while reading Chrome Local State; the extension is visibly present and reloading in Chrome.

   Expected behavior:

   • A connection attempt should not leave the extension in a reload loop or unloaded registration state.
   • After an extension/native-host reload, the browser runtime should reacquire the Chrome backend automatically.
   • If registration fails, diagnostics should expose the failure instead of returning only Browser is not available: chrome and an empty browser list.

   No browsing history, tab contents, account identifiers, credentials, or private logs are included.