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

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.

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.

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:

``bash
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 #37059. Repair:
`bash
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).

1. 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.

1. 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.

1. 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.

1. 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.

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

1. Running the packaged recovery command open-chrome-window.js --browser chrome opened a new Default-profile about:blank window.
2. After two seconds, agent.browsers.get("chrome") returned a new browser ID, -7efa-4dd1-9ba4-1361d6ceb437.
3. 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.