›_ Codex Issues
Codex Issues / #27962

Chrome plugin installed but Chrome backend is not exposed; only In-app Browser appears

Open 💬 5 comments Opened Jun 12, 2026 by EyJustMix
💡 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)?

Codex Desktop 26.609.3341.0 Plugin/cache version observed: 26.609.30741

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 Locale: pt-BR

What issue are you seeing?

The Chrome plugin and Codex Chrome Extension appear installed/enabled, and extension-host.exe is running, but Codex Desktop never exposes the Chrome backend to threads.

In a Codex thread, agent.browsers.list() only returns:

  • Codex In-app Browser (type: iab)

Both of these fail:

  • agent.browsers.get("extension") => Browser is not available: extension
  • agent.browsers.get("chrome") => Browser is not available: chrome

The Chrome extension UI shows Connected, and the Codex Desktop plugin page also shows the Chrome plugin installed/enabled. However, Codex cannot access or claim current Chrome tabs.

What steps can reproduce the bug?

  1. Install/enable the Chrome plugin in Codex Desktop.
  2. Install/enable the Codex Chrome Extension in Chrome.
  3. Restart both Chrome and Codex Desktop.
  4. Open a Chrome tab.
  5. In Codex, ask it to access the current Chrome tab.
  6. Observe that Chrome is not available as a browser backend.

I also tried:

  • reinstalling the Chrome extension
  • uninstalling/reinstalling the Codex Chrome plugin
  • clearing a corrupted plugin cache manually
  • restarting Chrome and Codex Desktop multiple times
  • opening Chrome via scripts/open-chrome-window.js
  • running Chrome and Codex as administrator
  • creating a new thread
  • setting Chrome as default browser

The result is always the same: only the in-app browser backend appears.

What is the expected behavior?

Codex Desktop should expose the Chrome plugin backend so that agent.browsers.list() includes a Chrome/extension backend, and agent.browsers.get("extension") or the documented Chrome backend should allow Codex to list/claim open Chrome tabs.

Additional information

Chrome extension version: 1.1.5
Chrome profile: Default
Chrome plugin/cache version: 26.609.30741

extension-host.exe is running from:
C:\Users\******\.codex\plugins\cache\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

The native host manifest exists:
C:\Users\******\AppData\Local\OpenAI\extension\com.openai.codexextension.json

Direct registry check confirms:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension
(default value points to the manifest above)

Potential related issue:
scripts/check-native-host-manifest.js appears to falsely report the registry key as missing on pt-BR Windows, because it expects the default registry value name "(Default)", while reg query /ve outputs "(padrão)" on this system.

Even after the native-host file updated to a current PID and extension-host.exe was running, Codex still only exposed the iab backend.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #27866
  • #27865

Powered by Codex Action

rajnpatel · 2 months ago

I’m seeing the same failure class on Windows Store Codex, with a slightly newer build and matching local evidence.

Environment / observed state:

  • Codex Desktop package: OpenAI.Codex_26.616.6631.0_x64__2p2nqsd0c76g0
  • Browser-use metadata in config: BROWSER_USE_CODEX_APP_VERSION = "26.616.51431"
  • Installed Chrome extension: hehggadaopoacecdllhhajmbjkdcmajg, version 1.1.5_0
  • Chrome profile: Default
  • Extension is installed/enabled in Chrome profile preferences, has nativeMessaging, and its service worker has started.
  • Native messaging registry exists at:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

  • Native host manifest exists and points to:

...\openai-bundled\chrome\latest\extension-host\windows\x64\extension-host.exe

  • extension-host.exe processes are running.
  • Codex config has:

[plugins."chrome@openai-bundled"] enabled = true
and BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab".

Actual behavior:

  • Codex Plugins UI search for Chrome shows No plugins or skills found.
  • agent.browsers.get("chrome") returns:

Browser is not available: chrome

  • Chrome is not exposed as a usable backend, so Codex cannot list or claim current Chrome tabs.
  • Computer Use can detect/launch Chrome, but when trying to operate Chrome it stops with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

Additional local clue:

  • codex plugin marketplace list does not show openai-bundled, even though config.toml contains stale-looking openai-bundled marketplace/plugin entries.
  • Attempting to add the local bundled marketplace path through codex plugin marketplace add fails because the folder does not contain a supported marketplace manifest.
  • The local Browser plugin cache present is 26.616.41845, while current browser-use metadata says 26.616.51431.

This looks like the Chrome extension/native host can be installed and running, but the Codex Desktop runtime still does not publish/register the Chrome backend into the agent session.

DokPlay · 1 month ago

Adding a related Windows data point. My symptom is not exactly “only IAB appears”, but it looks connected to the same Chrome integration / native-host / backend wiring area.

Environment:

  • Codex app / plugin build: 26.623.70822
  • Computer Use plugin: openai-bundled/computer-use/26.623.70822
  • Chrome plugin: openai-bundled/chrome/26.623.70822
  • Codex Chrome Extension: 1.1.5
  • Chrome profile: Default
  • Chrome version: 149.0.7827.201
  • OS: Windows 11 Pro 10.0.26200 x64

Local Chrome setup checks look valid:

  • Codex Chrome extension is installed and enabled
  • Native messaging host registry entry exists:

HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

  • com.openai.codexextension.json exists
  • extension-host.exe exists
  • allowed origin is:

chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

  • no Chrome enterprise policy / native messaging blocklist was found in HKCU or HKLM

Important detail: Computer Use is not generally broken in my case. It can list apps/windows, and the same kind of workflow works in another browser, for example Sun Browser.

The failure is specific to Google Chrome.

Computer Use detects Chrome and the active Chrome window correctly, but when targeting Chrome it stops at get_window_state() with:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

So even when the extension/native-host setup appears valid, Chrome can still be unusable from Codex/Computer Use on Windows. This may be a related failure mode where the Chrome backend/native-host wiring is present, but the Chrome window cannot be reliably mapped to the current tab URL.

EyJustMix · 28 days ago

Working well now on the current version

Codex desktop windows 10: 26.721.81911.
plugin chrome: 1.2.27236.6274

zemeng5208 · 13 days ago

I maintain WinBridge Recovery, an independent Windows Codex Desktop local-state recovery tool: https://github.com/zemeng5208/winbridge-recovery

This is a useful failure signature because several layers look healthy at once — the extension says Connected, extension-host.exe is running, the manifest/registry exist — but the thread only advertises the iab backend. WinBridge treats that as a consistency problem to diagnose, not as “the extension is installed so everything is fine.”

It checks the active CODEX_HOME, official AppX plugin source, generated bundled marketplace, concrete Chrome plugin version/latest, native-host manifest + registry/v2 records, and cua_node/node_repl paths together. That can catch stale or split local state left by updates/reinstalls. It also avoids relying on localized reg.exe output such as (Default) vs (padrão) as the sole health signal.

If all of those local layers validate and a fresh thread still exposes only iab, WinBridge will not try to manufacture a privileged browser backend; that remaining state is more consistent with Desktop session/backend injection and needs an upstream fix.

If someone here tests WinBridge on this exact “host running + Connected + only iab exposed” case, please leave the outcome at https://github.com/zemeng5208/winbridge-recovery/issues/4. ✅ / 🟡 / ❌ are all valuable, including no-change results.