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

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?

Install/enable the Chrome plugin in Codex Desktop.
Install/enable the Codex Chrome Extension in Chrome.
Restart both Chrome and Codex Desktop.
Open a Chrome tab.
In Codex, ask it to access the current Chrome tab.
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.

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

Windows Chrome plugin: native host launches but extension backend is not registered #27866
Windows Store Codex: Chrome backend not registered and Computer Use native pipe missing #27865

Powered by Codex Action

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.

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.

Working well now on the current version

Codex desktop windows 10: 26.721.81911.
plugin chrome: 1.2.27236.6274

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 zemeng5208/winbridge-recovery#4. ✅ / 🟡 / ❌ are all valuable, including no-change results.

This is related to my macOS report in #29389, but not an exact platform duplicate. The macOS reproduction shows the same product-level invariant: Chrome, the extension, and native-host checks can look healthy while the Codex session exposes no usable Chrome backend.

The cross-platform requirement is to expose separate health states for Chrome, extension, native host, and session/backend registration, with a reason for each unavailable backend and a recoverable state after transient disconnects. Please keep the Windows-specific registration/packaging diagnosis separate from the macOS backend/session diagnosis while tracking this shared observability and recovery gap.

Codex-Browser-Backend-Evidence.zip

Cross-reference / independent confirmation — reproduced on a second Windows machine.
Related open reports: #24838, #37307, #49247, #48146, #21781

New finding that narrows this down: it is not the Chrome/native-messaging transport and it is
not browser-specific. On this machine the extension backend pipes were alive and answered
getInfo correctly for both Chrome and Edge at the very moment agent.browsers.list() still
returned only mcpapps. A synthetic mock backend on a clean \\.\pipe\codex-browser-use-* name
reproduces it too. Evidence bundle attached as Codex-Browser-Backend-Evidence.zip.

[Bug] Chrome extension browser backend is discovered but never registered — `agent.browsers.list()` only ever returns `mcpapps`

Summary

On Windows, a healthy ChatGPT/Codex Chrome extension backend (served by
extension-host.exe over \\.\pipe\codex-browser-use\<uuid>) is discovered and
answers getInfo correctly, but the browser runtime never registers it.
agent.browsers.list() returns only the desktop-provided mcpapps backend, and
agent.browsers.get("chrome" | "extension" | "iab") always fails with
Browser is not available: <id>.

Reproducible with a synthetic mock backend as well, so the defect is in the
runtime's backend registration, not in Chrome, the extension, native messaging,
or the chrome-native-hosts-v2.json discovery files.

Environment

OS: Windows 10 x64 10.0.19045 (zh-CN, Asia/Shanghai)
Codex Desktop: 26.1007.2314.0 (latest; only version installed)
bundled runtime: 0.162.0-alpha.17.2
bundled plugin bundle: 26.1007.21434 (chrome plugin, latest junction OK)
Chrome extension: 1.26.901.11451, enabled, profile Default
CODEX_HOME relocated via junction: C:\Users\admin\.codex -> E:\AI-Data\CodexHome

Steps to reproduce

// node_repl via the Browser/Chrome plugin
const { setupBrowserRuntime } = await import(
  "<CODEX_HOME>/plugins/cache/openai-bundled/chrome/latest/scripts/browser-client.mjs");
const agent = await setupBrowserRuntime();
await agent.browsers.list();
// => [{ id: "1", name: "Codex MCP Apps", type: "mcpapps", metadata:{ codexSessionId: ... } }]
await agent.browsers.get("chrome");
// => Error: Browser is not available: chrome

Transport-side checks all pass:
installed-browsers.js --json, chrome-is-running.js --browser chrome --json,
check-extension-installed.js --browser chrome --json,
check-native-host-manifest.js --json (see attached JSON).

Evidence

Chrome launches the native host 1 s after startup
(cmd.exe /d /s /c "...\extension-host.exe" chrome-extension://hehgg.../ --parent-window=0 < \\.\pipe\chrome.nativeMessaging.in.<h> > \\.\pipe\chrome.nativeMessaging.out.<h>),
and extension-host.exe listens on \\.\pipe\codex-browser-use\<uuid>
(verified with GetNamedPipeServerProcessId).
The runtime enumerates that pipe as a candidate — fs.readdirSync("\\\\.\\pipe\\") +
path.resolve("\\\\.\\pipe\\", name) + startsWith("\\\\.\\pipe\\codex-browser-use")
returns it, and the runtime really does connect to it (verified with a
transparent relay; the request below was captured on the wire).
Request the runtime sends (raw frame, 4-byte LE length prefix + JSON):

{"jsonrpc":"2.0","method":"getInfo","params":{"session_id":"<session>","turn_id":"<turn>","session_context":"live"},"id":1}

Reply the extension backend sends (raw frame, verbatim, captured on the wire):

{"id":1,"jsonrpc":"2.0","result":{"agentRequestHeaderEnabled":false,"browserTabMentions":{"buildChannel":"prod","generation":"<uuid>","protocolVersion":1},"capabilities":{"browser":[{"description":"Controls an explicit browser viewport override ...","id":"viewport"}],"tab":[{"description":"List assets already observed ...","id":"pageAssets"}]},"family":"chrome","metadata":{"extensionId":"hehggadaopoacecdllhhajmbjkdcmajg","extensionInstanceId":"982991cc-b5a1-4d57-8795-516477f6a7df"},"name":"Chrome","type":"extension","version":"1.26.901.11451"}}

Direct probe at the same moment (plain Node client, no relay): connect to the pipe,
write frame (3), read → frame (4) in under 100 ms. So the backend is alive and correct.
Controlled A/B experiment (fresh JS kernel, one process):

$te() in browser-service.mjs increments a module-level counter Nte for every
backend it successfully creates, so the id of the mcpapps entry reveals how many
backends were created during a refresh.
```
mcpapps ids: X=2  Y=3  Z=4
baseline delta (no mock)        = 1
delta with 1 mock present       = 1     <-- not 2
mock received getInfo requests  = 1     <-- request reached the mock
```
The mock is a faithful byte-copy of reply (4) served on a clean pipe name
(\\.\pipe\codex-browser-use-abtest). It receives the request and replies, but the
runtime creates no browser for that pipe. Therefore the response is never
delivered to / processed by the JS transport, and the per-pipe result is
{ failure: "backend-info-request/<msg>" }.

Conclusion: for every candidate pipe that is not served by ChatGPT.exe, the
getInfo handshake never completes, so kF() keeps only the desktop's
mcpapps backend and the Chrome/Edge extension backends are always dropped.

Things that do NOT cause it (all verified)

native-messaging manifest + HKCU\Software\Google\Chrome\NativeMessagingHosts + allowed_origins
Chrome extension install/enable state, profile, Chrome process
extension-host.exe process, its pipe, its getInfo reply
both chrome-native-hosts-v2.json files (schemaVersion 2, valid, paths exist)
plugin latest junction and every path in the v2 entries (all Test-Path = True)
BROWSER_USE_AVAILABLE_BACKENDS allowlist: Rn("extension") === "chrome" and
VC() accepts chrome, iab, cdp, mcpapps (probed through trusted RPC), so
the allowlist cannot be the filter
Lte() session filter: extension backends default to discoveryScope: "global"
and are therefore never dropped by it
desktop app version (already on the latest build), start order of Chrome vs Codex
the two runtime builds differ, but their embedded native-pipe host code
(privileged-node-repl.js) is byte-identical, so the local build skew is not proven causal

Diagnostics visibility request

The per-pipe failure reason (failures: [...] in kF()) is only reported through
the Statsig event browser_use_backend_discovery_failed (Zte() -> Qm()); nothing
is written to any local log. Searching local logs for
browser_use_backend_discovery_failed therefore finds nothing, which makes this
class of failure very hard to diagnose on user machines. Please emit the same
diagnostic to a local log (or expose it through a command such as
runtime_config / a browser_diagnostics command).

Also observed on this machine (possibly unrelated, reported for completeness)

Desktop bundled-plugin reconcile fails on every startup/focus:
bundled_plugins_marketplace_add_failed errorMessage="marketplace openai-bundled is reserved and cannot be added from this source"
followed by bundled_plugins_reconcile_failed.
bundled_plugin_chrome_extension_sync_decision never appears in any historical log,
i.e. the Chrome-extension install-state sync path never runs.
On 2026-10-09 08:03Z and 2026-10-10 07:51Z the desktop uninstalled
chrome@openai-bundled / browser@openai-bundled with
reason=not_in_bundled_marketplace_plugin_names and issued
chrome_native_host_manifest_remove_requested
(the last successful backend=chrome PiP record is 2026-10-10 06:41:49Z).
Leaked per-session pipes are never reclaimed: 5 \\.\pipe\codex-browser-use-<uuid>
instances from dead sessions stay open for the lifetime of ChatGPT.exe.
codex doctor --summary on this machine reports
[XX] sandbox elevated Windows sandbox provisioning recorded a structured failure.

Attachments

evidence/extension-endpoint-getInfo-trace.txt (raw frames + direct probe)
evidence/ab-experiment-id-delta.txt (A/B experiment)
evidence/pipe-ownership.txt (pipe -> server process map)
evidence/check-*.json (4 plugin diagnostics)
evidence/chrome-native-hosts-v2.*.json, evidence/com.openai.codexextension.json
evidence/config.toml.snapshot, evidence/codex-doctor.txt

Attachments: the full evidence bundle is provided as Codex-Browser-Backend-Evidence.zip (uploaded to this issue manually; GitHub CLI cannot upload binary attachments).

The newer diagnostics are useful because they further separate local Chrome/native-host health from Codex-side bundled-plugin/session registration. If Desktop can remove or fail to reconcile chrome@openai-bundled while local transport still looks healthy, the product needs explicit backend-registration/reconcile diagnostics and a recovery path rather than sending users back through reinstall loops.

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

[Bug] Chrome extension browser backend is discovered but never registered — `agent.browsers.list()` only ever returns `mcpapps`

Summary

Environment

Steps to reproduce

Evidence

Things that do NOT cause it (all verified)

Diagnostics visibility request

Also observed on this machine (possibly unrelated, reported for completeness)

Attachments

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Jun 12, 2026

rajnpatel commented on Jun 23, 2026

DokPlay commented on Jul 1, 2026

EyJustMix commented on Jul 30, 2026

zemeng5208 commented on Aug 14, 2026

barcuchj commented on Sep 3, 2026

bernard9708c commented on Oct 11, 2026

[Bug] Chrome extension browser backend is discovered but never registered — agent.browsers.list() only ever returns mcpapps

Summary

Environment

Steps to reproduce

Evidence

Things that do NOT cause it (all verified)

Diagnostics visibility request

Also observed on this machine (possibly unrelated, reported for completeness)

Attachments

barcuchj commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug] Chrome extension browser backend is discovered but never registered — `agent.browsers.list()` only ever returns `mcpapps`