[macOS] Chrome/Browser plugin fails with `browser-client is not trusted` despite extension and native host checks passing
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:
- Prompt:
@Chrome file my expenses for me - Follow the Chrome skill bootstrap using the bundled Chrome plugin
scripts/browser-client.mjsabsolute path. - Attempt to set up the browser runtime and get the
extensionbrowser backend. - 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: selectedDefaultprofile 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, andcorrect: 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.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗