[macOS] Chrome/Browser plugin fails with `browser-client is not trusted` despite extension and native host checks passing

Resolved 💬 2 comments Opened Jun 9, 2026 by HoboCY Closed Jul 17, 2026

Summary

The Codex Desktop Chrome plugin cannot connect to Chrome from a Codex App thread on macOS. Both the Chrome-backed @Chrome flow and the in-app Browser bootstrap fail with:

privileged native pipe bridge is not available; browser-client is not trusted

This appears related to the same native-pipe / browser-client trust class as existing issues, but this report is a macOS repro where the Chrome extension and native host checks both pass.

Related issues found before filing:

  • #25247
  • #23884
  • #21781

Environment

  • Platform: macOS 26.5.1, build 25F80
  • Codex App bundled CLI: codex-cli 0.137.0-alpha.4
  • PATH codex --version: codex-cli 0.118.0
  • Google Chrome: 149.0.7827.103
  • OpenAI bundled Chrome plugin path/version: openai-bundled/chrome/26.602.71036
  • OpenAI bundled Browser plugin path/version: openai-bundled/browser/26.602.71036
  • Chrome profile checked: Default
  • Codex Chrome Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
  • Codex Chrome Extension version: 1.1.5_0

Reproduction

From a Codex Desktop App thread:

  1. Prompt: @Chrome file my expenses for me
  2. Follow the Chrome skill bootstrap using the bundled Chrome plugin scripts/browser-client.mjs absolute path.
  3. Attempt to set up the browser runtime and get the extension browser backend.
  4. Attempt a lightweight read-only operation such as browser.user.openTabs().

The same error also occurred earlier with @Browser / in-app browser bootstrap using the bundled Browser plugin client.

Actual behavior

Bootstrap fails immediately with:

privileged native pipe bridge is not available; browser-client is not trusted

After retrying, the error remains unchanged. Codex cannot list tabs or claim a Chrome tab.

Expected behavior

Codex should trust the bundled browser-client path for the active plugin runtime and expose the Chrome extension backend so browser.user.openTabs() can work, or provide a clear recovery action when the trust bridge is unavailable.

Checks already performed

Chrome and plugin health checks were performed using the bundled Chrome plugin troubleshooting scripts:

  • scripts/chrome-is-running.js --check: Chrome is running.
  • scripts/installed-browsers.js --check: Google Chrome is installed at /Applications/Google Chrome.app.
  • scripts/check-extension-installed.js --json: selected Default profile has the Codex Chrome Extension installed and enabled.
  • scripts/check-native-host-manifest.js --json: native host manifest exists, host name matches, expected origin is allowed, and correct: true.

The Codex-provided scripts/open-chrome-window.js was run after user approval to open Chrome with the selected Default profile. After waiting and retrying the browser-client bootstrap, the same trust error still occurred.

The user also confirmed that the Chrome extension is already installed.

Impact

This blocks Chrome-backed workflows that require the user's signed-in Chrome session. In this case it prevented an expense filing workflow from even reaching read-only tab discovery. The agent correctly stopped before using any workaround or side channel because the official Chrome plugin path was unavailable and the workflow involves sensitive financial data.

Notes

A public search found existing reports with the same error string, but most visible reports appear Windows-focused or Browser-plugin focused. This issue adds a macOS data point where extension installation/enabled state and native-host manifest validation both pass, but Codex Desktop still reports the browser-client as untrusted.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗