CLI cannot acquire Chrome extension backend while Codex app UI works

[khudt01]

Summary

The Codex app UI can use the Codex Chrome Extension successfully on this machine, but the terminal-based Codex CLI cannot acquire the Chrome extension browser backend in the same environment.

This does not look like a Chrome profile, extension installation, or native host manifest problem. The extension works from the Codex app UI, while the CLI Node runtime appears to lack the privileged/native browser runtime bridge metadata needed to discover the extension backend.

Expected behavior

When chrome@openai-bundled is installed/enabled and the Codex Chrome Extension/native host checks are healthy, terminal Codex CLI sessions should either:

• expose the Chrome extension backend to the Node/browser runtime, or
• clearly document/report that Chrome extension browser control is app-only and unavailable from terminal CLI sessions.

Actual behavior

In the terminal Codex CLI session:

const { setupBrowserRuntime } = await import('/Users/hunyongkim/.codex/.tmp/bundled-marketplaces/openai-bundled/plugins/chrome/scripts/browser-client.mjs');
await setupBrowserRuntime({ globals: globalThis });
const cliChromeBrowser = await agent.browsers.get('extension');

fails with:

Browser is not available: extension

The same Chrome extension setup works from the Codex app UI for reading web content.

Environment

• Platform: macOS
• Chrome: 149.0.7827.53
• Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Codex Chrome Extension version: 1.1.5_0
• Terminal codex --version: codex-cli 0.137.0
• Codex app bundled CLI: /Applications/Codex.app/Contents/Resources/codex --version -> codex-cli 0.137.0-alpha.4
• Active terminal thread id: 019e9e6a-e81e-7442-bac0-d3bc42cc1b45

Local diagnostics

Plugin state

Marketplace `openai-bundled`
/Users/hunyongkim/.codex/.tmp/bundled-marketplaces/openai-bundled/.agents/plugins/marketplace.json

browser@openai-bundled       installed, enabled  26.602.40724
chrome@openai-bundled        installed, enabled  26.602.40724
computer-use@openai-bundled  not installed

CLI Node runtime metadata

In the terminal Codex CLI session:

{
  "requestMetaKeys": [
    "progressToken",
    "threadId",
    "x-codex-turn-metadata"
  ],
  "hasNativePipe": false,
  "turnMetadata": {
    "model": "gpt-5.5",
    "reasoning_effort": "high",
    "sandbox": "none",
    "session_id": "019e9e6a-e81e-7442-bac0-d3bc42cc1b45",
    "thread_id": "019e9e6a-e81e-7442-bac0-d3bc42cc1b45",
    "thread_source": "user"
  }
}

This seems to be the key difference from the app UI path: the CLI runtime does not appear to have a native pipe / browser backend metadata injected.

Chrome running check

Google Chrome running: yes

Extension check

{
  "extensionId": "hehggadaopoacecdllhhajmbjkdcmajg",
  "userDataDirectory": "/Users/hunyongkim/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
    }
  ],
  "exitCode": 0
}

Native host manifest check

{
  "manifestPath": "/Users/hunyongkim/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
}

Why this looks different from an install/profile issue

• The Codex app UI can access Chrome/web content successfully on the same machine.
• The terminal CLI sees chrome@openai-bundled as installed and enabled.
• The selected Chrome profile has the extension installed and enabled.
• The native host manifest is present and correct.
• The terminal CLI Node runtime reports hasNativePipe: false, and agent.browsers.get("extension") fails immediately with Browser is not available: extension.

Related issues

This looks related to the same Chrome extension/backend discovery class as:

• Codex Desktop Chrome plugin connection times out despite extension and native host checks passing #21851
• Chrome plugin hangs during backend setup despite extension and native host running #21879
• Windows: Chrome extension installed and native host registered, but extension backend is unavailable #24838
• Browser plugin bootstrap fails in Codex App: browser-client is not trusted #25247
• Codex Desktop plugins disappear after restart; Chrome native host manifest is not created and computer-use MCP is not attached #25809

The additional narrowing here is that the Codex app UI path works, while the terminal CLI path fails on the same machine without changing Chrome/extension settings.

[github-actions]

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

• Browser skill is mounted in CLI TUI even when no in-app browser backend is available #25647
• Codex Browser/Chrome plugins installed, but no browser backend registers; agent.browsers.list() stays empty #26470
• Chrome plugin backend unavailable despite extension showing Connected #25811
• macOS 26.601: Chrome plugin cannot bootstrap because node_repl/js is not exposed despite extension-host and node_repl processes running #26364

Powered by Codex Action

[if6was9]

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.

[token42-buildbot]

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.

[yesyesyes001]

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

[jbaehova]

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.

[riwagne]

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:

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.

[mileslow]

Please fix this this its so annoying!!!

[jonasreinsch]

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.

[obviousbread]

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.

[jnardiello]

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.