CLI cannot acquire Chrome extension backend while Codex app UI works

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

• #25647
• #26470
• #25811
• #26364

Powered by Codex Action

I can reproduce this from another terminal Codex CLI session on macOS.

Environment

• Platform: macOS / Darwin 25.2.0 / arm64
• codex --version: codex-cli 0.137.0
• Chrome plugin cache path/version in this session: chrome/26.527.60818
• Chrome: 149.0.7827.54 at /Applications/Google Chrome.app
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version: 1.1.5_0
• Selected Chrome profile: Default

Reproduction

In the CLI session, using the bundled Chrome plugin browser client:

const { setupBrowserRuntime } = await import("/Users/rob/.codex/plugins/cache/openai-bundled/chrome/26.527.60818/scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
const available = await agent.browsers.list();
globalThis.browser = await agent.browsers.get("extension");

Result:

{
  "ok": false,
  "available": [],
  "error": "Browser is not available: extension"
}

The clean retry also logged native pipe discovery failures:

IAB_DISCOVERY no session-owned iab browser ...
failures: [
  "pipe-connect/Error: failed to connect native pipe: Connection refused (os error 61)",
  "backend-info-request/native pipe closed before response",
  "pipe-connect/Error: failed to connect native pipe: Connection refused (os error 61)",
  "pipe-connect/Error: failed to connect native pipe: Connection refused (os error 61)"
]
reason: "no-iab-backends"

Local diagnostics

Chrome running check:

{
  "platform": "darwin",
  "running": true,
  "processes": [
    {
      "pid": 1591,
      "process_name": "Google Chrome",
      "command": "Google Chrome"
    }
  ]
}

Extension check:

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "userDataDirectory": "/Users/rob/Library/Application Support/Google/Chrome",
  "selectedProfileDirectory": "Default",
  "installed": true,
  "enabled": true,
  "profiles": [
    {
      "profileDirectory": "Default",
      "installed": true,
      "registered": true,
      "enabled": true,
      "disabled": false,
      "versions": ["1.1.5_0"],
      "selected": true
    },
    {
      "profileDirectory": "Profile 2",
      "installed": true,
      "registered": true,
      "enabled": true,
      "disabled": false,
      "versions": ["1.1.5_0"],
      "selected": false
    }
  ],
  "exitCode": 0
}

Native host manifest check:

{
  "manifestPath": "/Users/rob/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json",
  "expectedHostName": "com.openai.codexextension",
  "actualHostName": "com.openai.codexextension",
  "expectedExtensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
  "allowedOrigins": ["chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/"],
  "exists": true,
  "nameMatches": true,
  "hasExpectedOrigin": true,
  "registryMatchesManifestPath": true,
  "correct": true,
  "problem": null
}

The documented recovery step also failed from the CLI session:

node scripts/open-chrome-window.js
Command failed: open -n -a /Applications/Google Chrome.app --args --profile-directory=Default --new-window about:blank
The application /Applications/Google Chrome.app cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10827 "kLSNoExecutableErr: The executable is missing"

This matches the report: the selected Chrome profile, extension install/enabled state, and native host manifest all look healthy, but the CLI cannot discover/acquire the extension browser backend.

I spent a fair amount of time trying to figure this one out, but all I learned was that the Codex app is able to control Chrome just fine. It is only the CLI that breaks. I tried both the hombrew-installed CLI and the app-bundled CLI and both failed.

same failue here.

codex-cli: 0.140.0
Codex app bundled CLI: 0.140.0-alpha.19
Chrome: 149.0.7827.114
Codex Chrome Extension: 1.1.5_0
agent.browsers.list(): []
hasNativePipe: false
extension installed/enabled: true
native host manifest correct: true

I have the same issue on my Mac

Environment:

• macOS
• Terminal Codex CLI: codex-cli 0.142.0
• Codex app / bundled plugin version: 26.616.71553
• Chrome: 149.0.7827.156
• Codex Chrome extension version: 1.1.5_0

Behavior:

• Chrome control works from the Codex app.
• The same Chrome profile/extension does not work from terminal Codex CLI.
• agent.browsers.list() returns [].
• agent.browsers.get("extension") fails with:

Browser is not available: extension

Local checks:

• Chrome is running.
• The Codex Chrome extension is installed and enabled in the selected Chrome profile.
• The native messaging manifest exists and points to the expected extension host.
• The extension host process is running.
• A direct framed JSON-RPC probe to the extension-host socket succeeds and returns getInfo with:

{
  "name": "Chrome",
  "type": "extension",
  "version": "1.1.5",
  "metadata": {
    "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg"
  }
}

The key CLI-side difference appears to be that the Node runtime does not expose the privileged native pipe bridge:

globalThis.nodeRepl?.nativePipe
// undefined

So this does not look like a Chrome profile, extension installation, or native host manifest issue. The Chrome extension backend is alive, but terminal Codex CLI cannot acquire it because the trusted/native pipe bridge is missing in the CLI runtime.

Could you confirm whether Chrome extension control is expected to work from terminal CLI sessions? If it is app-only, the CLI should probably report that explicitly. If it is supported, this looks like a CLI/runtime bridge regression.

Same issue here:
Here’s a concise issue writeup you can paste into GitHub.

## Summary

@Chrome works from the Codex Mac desktop app, but fails from Codex CLI with:

```text
Browser is not available: extension

This happens even though Chrome is running, the Codex Chrome Extension is installed/enabled, the native host manifest is valid, and the native host process is running.

## Environment

• macOS: 26.5.1 arm64
• Codex Desktop / bundled Chrome plugin: 26.616.71553
• Codex CLI: 0.142.0
• Chrome: 148.0.7778.179
• Chrome plugin path: ~/.codex/plugins/cache/openai-bundled/chrome/26.616.71553
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

## Reproduction

From Codex CLI:

use @Chrome to browse www.oracle.com

The Chrome skill loads, then this call fails:

const { setupBrowserRuntime } = await import("/Users/riwagne/.codex/plugins/cache/openai-bundled/chrome/26.616.71553/scripts/browser-client.mjs");
await setupBrowserRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");
nodeRepl.write(await browser.documentation());

Result:

Browser is not available: extension

## Expected Behavior

Codex CLI should connect to the same Codex Chrome Extension / native host path that works from the Codex Mac desktop app, then open or control a Chrome tab.

## Actual Behavior

Codex CLI cannot discover or connect to the Chrome extension backend:

Browser is not available: extension

## Diagnostics Already Checked

Chrome is running:

Google Chrome running: yes
process: Google Chrome

Codex Chrome Extension is installed and enabled in the selected profile:

{
"extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
"selectedProfileDirectory": "Default",
"installed": true,
"enabled": true,
"exitCode": 0
}

Native host manifest is valid:

{
"manifestPath": "/Users/riwagne/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.openai.codexextension.json",
"expectedHostName": "com.openai.codexextension",
"actualHostName": "com.openai.codexextension",
"expectedOrigin": "chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/",
"hasExpectedOrigin": true,
"correct": true,
"problem": null
}

Native host process is running:

/Users/riwagne/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

Opening Chrome through the plugin helper succeeds:

node scripts/open-chrome-window.js
Google Chrome window open request
status: opened
profile: Default
command: open -n -a "/Applications/Google Chrome.app" --args --profile-directory=Default --new-window about:blank

But retrying agent.browsers.get("extension") still fails with:

Browser is not available: extension

## Sandbox Observation

The CLI launches node_repl through a sandbox with network disabled, even when the main Codex config has network enabled:

/Applications/Codex.app/Contents/Resources/codex sandbox ... default_permissions="node_repl" ... permissions.node_repl={..., network = {enabled = false}} ...

I also tried launching Codex CLI with:

codex -C /Users/riwagne/.codex/plugins/cache --dangerously-bypass-approvals-and-sandbox

The Chrome connection still failed with the same error. A later ps still showed node_repl sandbox processes with network = {enabled = false}.

## Additional Notes

Two bundled helper scripts in the Chrome plugin cache are not executable on disk:

-rw-r--r-- scripts/installed-browsers.js
-rw-r--r-- scripts/check-native-host-manifest.js

Running them through node works:

node scripts/installed-browsers.js --check
node scripts/check-native-host-manifest.js --json

So this may be unrelated, but it made the documented troubleshooting commands fail unless invoked through node.

## Impact

The same Chrome plugin works in Codex Mac desktop, but not in Codex CLI. This blocks using @Chrome from CLI sessions for sites that require the user’s existing Chrome profile/session.

Please fix this this its so annoying!!!

I can reproduce this on the current macOS/CLI/plugin versions. The Codex/ChatGPT app can use Chrome, but a fresh terminal Codex CLI session cannot discover the same Chrome extension backend.

Environment

• macOS 26.4 (25E246), arm64
• Terminal Codex CLI: codex-cli 0.144.0
• App-bundled CLI: codex-cli 0.144.0-alpha.4
• ChatGPT app / bundled Chrome plugin: 26.707.31123
• Chrome: 150.0.7871.115
• Selected Chrome profile: Default
• Installed extension versions: 1.1.5_0, 1.2.27203.26575_0

CLI result

After loading the bundled browser-client.mjs and running setupBrowserRuntime({ globals: globalThis }):

agent.browsers.list() -> []
agent.browsers.get("extension") -> Browser is not available: extension

The required delayed retry returns the same result.

Verified healthy

• Chrome is installed and running.
• The ChatGPT Chrome Extension is installed, registered, and enabled in the selected Default profile.
• The native messaging manifest exists, has the expected host/origin, and passes the bundled validation script.
• The native extension-host process is running.
• Chrome control works from the app on the same machine.

Recovery attempts completed

1. Restarted/resumed Codex CLI to ensure it loaded the current plugin rather than a stale pre-update bundle.
2. Reinstalled the Chrome plugin from the ChatGPT app Plugins UI.
3. Confirmed the native-host manifest and plugin cache were rewritten before starting a new CLI process.
4. Started a fresh CLI session after reinstall.
5. Opened the documented about:blank window in Default using scripts/open-chrome-window.js.
6. Waited and retried browser discovery.

The fresh post-reinstall CLI still returns an empty browser list and Browser is not available: extension, while the app continues to work. This rules out a stale CLI process and makes the CLI-to-extension runtime registration/routing path the likely failure point.

Same here. MacOS Sequoia 15.6. Codex CLI (codex-cli 0.144.0) just won't connect to Chrome while the Codex Desktop app does it fine. Tried both npm and brew installs, no result. I wish there was an option to spin out a Chrome session from the CLI without needing to run the desktop app. Bumping this in hopes they'll fix it soon.

Same failure on codex-cli 0.144.0 and 0.144.1 (macOS arm64, Chrome 150.0.7871.115, extension 1.2.27203.26575, ChatGPT/Codex app 26.707.31428). I spent a day root-causing it and can add some evidence beyond the (excellent) diagnostics already in this thread — in particular @jbaehova's finding that nodeRepl.nativePipe is undefined in CLI sessions while the extension-host socket itself answers getInfo correctly. I can confirm that and extend it:

1. The pipe-granting side is not present in the standalone CLI binary

Strings analysis of the CLI binaries (both 0.144.0 and 0.144.1, standalone installer):

• present: x-codex-turn-metadata (the CLI is the MCP client that spawns node_repl and passes turn metadata — that part works);
• zero occurrences of codex-browser-use (the socket rendezvous dir), native_pipe, NODE_REPL_TRUSTED, browser-client.mjs, or chrome-native-hosts.

So the privileged native-pipe bridge that browser-client.mjs needs (discovery = readdir /tmp/codex-browser-use + dial each socket through nodeRepl.nativePipe) has no granting side in the standalone CLI. This is not a per-machine misconfiguration — it isn't shipped.

I also reproduced the exact CLI behavior with a minimal MCP harness spawning node_repl with the same env the CLI uses from config.toml (including NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S matching the installed browser-client.mjs sha256, and _meta["x-codex-turn-metadata"] set): setupBrowserRuntime() succeeds, nodeRepl.nativePipe stays null, every per-pipe dial fails internally, and agent.browsers.list() returns [] with no surfaced error. NODE_REPL_TRUST_ALL_CODE=1 doesn't change it, and with RUST_LOG=trace no bridge handshake is even attempted.

2. The granting side lives in the desktop app process, gated on peer code signing

The desktop app's logs (~/Library/Logs/com.openai.codex/...) show the counterpart component, browser-use-native-pipe-server, which verifies the connecting peer's code signature:

warning [browser-use-native-pipe-server] browser-use native pipe rejected socket peer reason=missing-code-signing-identity

So the capability appears to be deliberately confined to node_repl instances the app itself spawns. That would be a reasonable security posture — if it were surfaced. Which leads to the actual bug as experienced from the CLI:

3. Every agent-visible signal claims browser use works in the CLI

• codex features list on the standalone CLI reports browser_use stable true (also browser_use_external, in_app_browser);
• the control-chrome skill is installed and instructs the model through the full bootstrap + troubleshooting flow;
• the app writes BROWSER_USE_AVAILABLE_BACKENDS="chrome,iab" into the CLI's config.toml node_repl env;
• all four diagnostic scripts from the plugin docs pass (Chrome running, extension installed+enabled in the selected profile, native host manifest valid);
• the terminal failure mode is a silent [] / Browser is not available: extension.

The combination is effectively undiagnosable from inside a session: the model re-runs the documented troubleshooting for hours, asks the user to update Chrome / reinstall components that are already healthy, and can never conclude anything. Echoing the question upthread: please confirm whether Chrome extension control is intended to work from terminal CLI sessions. If it is app-only, the minimal fix would be any of: an explicit error from browsers.list()/get("extension") ("browser use requires the Codex/ChatGPT desktop app runtime"), not reporting browser_use = true where it cannot work, or not installing the control-chrome skill + browser env into standalone CLI configs.

4. Related but distinct: the bundled plugin auto-updater can break the app path too

While investigating, the chrome@openai-bundled plugin auto-updated 3 times in ~24h (26.707.30751 → .31123 → .31428). The update replaces the cache dir but does not re-run installManifest.install(): the native-messaging manifest mtime never changed across updates, chrome/latest/ was transiently deleted while both the manifest and chrome-native-hosts-v2.json still pointed at it, extension-host-config.json was missing next to the extension-host binary, and the running extension host kept executing from a deleted binary — after which the app's pipe server rejected it (missing-code-signing-identity) and the app itself logged "No ChatGPT browser route is available for browser session …". Browser use was broken in the desktop app as well until a manual Settings → Computer use → Google Chrome → Reinstall extension plus a Chrome restart. Happy to file that separately with full logs if useful.

I can reproduce this on the current macOS/CLI/plugin versions. This report adds repeated reinstall evidence and an uninstall-state/UI problem that keeps sending users through the same ineffective recovery loop.

Environment

• macOS 26.5.1 (25F80), arm64
• Standalone terminal CLI: codex-cli 0.144.1
• Bundled Chrome plugin/native host: 26.707.51957
• Google Chrome: 150.0.7871.115
• ChatGPT Chrome Extension: 1.2.27203.26575_0
• Selected Chrome profile: Default

Actual behavior

From a terminal Codex CLI session, after loading the plugin-provided browser-client.mjs and initializing the browser runtime:

agent.browsers.list() -> []
(wait 2 seconds and retry)
agent.browsers.list() -> []
agent.browsers.get("extension") -> Browser is not available: extension

The ChatGPT Chrome sidepanel works in the same Chrome profile and can see/control the active signed-in tab. The failure is isolated to terminal CLI backend discovery.

All local checks pass

• Chrome is installed and running.
• The ChatGPT Chrome Extension is installed, registered, and enabled in Default.
• The native messaging host manifest exists and validates successfully:
• host name: com.openai.codexextension
• expected extension origin present
• correct: true
• problem: null
• The native-host registry entry is present in ~/.codex/chrome-native-hosts-v2.json.
• The manifest points to the current chrome/latest extension host.
• scripts/open-chrome-window.js successfully opens a new about:blank window in Default.
• Waiting two seconds and retrying discovery after opening that window still returns [].

Recovery attempts

The Chrome plugin was uninstalled/reinstalled from the ChatGPT/Codex plugin UI and Codex was restarted five times. Chrome and Codex were also restarted, and the documented selected-profile window reconnect was attempted. None of these changed the CLI result.

Additional uninstall/reinstall UX problem

After clicking uninstall and restarting Codex, the plugin appears again. Local state explains the visible behavior:

[plugins."chrome@openai-bundled"]
enabled = true

The bundled marketplace is registered from the local openai-bundled snapshot, so startup rehydrates the plugin while the config still says enabled. This makes an uninstall appear to have succeeded temporarily, then reverses it on restart. More importantly, reinstalling does not repair the missing CLI backend.

Please ensure plugin removal updates the durable enabled state, and stop recommending reinstall when extension/native-host checks already pass but the terminal runtime exposes no browser backend.

Possible version/bridge clue

The current native-host registration points to the separate plugin app-server executable:

~/.codex/plugins/.plugin-appserver/codex

Local logs show the working Chrome sidepanel connecting as codex-chrome-extension-sidepanel, while the standalone terminal CLI session still receives no browser backend. This supports the existing hypothesis that the terminal runtime is missing the privileged/native bridge rather than having a broken Chrome install.

Expected behavior

Either:

1. terminal Codex CLI sessions should acquire the connected Chrome extension backend, or
2. the CLI/plugin must explicitly state that this surface is unsupported and must not expose a troubleshooting flow that repeatedly asks users to reinstall healthy components.

No credentials, cookies, or private browser/session contents are included in this report.