Browser plugin bootstrap fails in Codex App: browser-client is not trusted

[workpodsjun]

Summary

Browser plugin / in-app browser automation fails during bootstrap in the Codex desktop app.

Environment

• Codex App version: 26.527.31326
• Thread id: 019e7814-b976-73a0-aaa2-36cc02b620be
• This thread is being used from the Codex desktop app, not only from CLI/cmux.

Error

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

Minimal checks

• The in-app browser itself is visible in the Codex App UI.
• Browser skill bootstrap uses an absolute path import for browser-client.mjs.
• No localhost navigation, URL transition, tab creation, or real UI inspection was attempted.
• nodeRepl exists.
• nodeRepl.nativePipe is false / missing.
• requestMeta keys are only progressToken, threadId, and x-codex-turn-metadata.
• Browser backend metadata is not visible in request metadata.
• Computer Use has worked separately in a Codex App session with list_apps.

Current diagnosis

The trusted native bridge / browser backend metadata for the Browser plugin appears not to be injected into this thread's Node REPL runtime, even though the thread is being used from the Codex desktop app and the in-app browser is visible.

[github-actions]

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

• Chrome plugin fails after reinstall: browser-client is not trusted / native pipe bridge unavailable #23884
• codex chrome can't be used in windows edition #24845
• Chrome plugin disappeared from Codex App marketplace after update; cached browser-client is not trusted #23831

Powered by Codex Action

[workpodsjun]

Additional recovery attempt:

• Ran codex plugin remove browser@openai-bundled.
• Ran codex plugin add browser@openai-bundled.
• Confirmed browser@openai-bundled is installed and enabled again.
• In the existing Codex App thread, nodeRepl.nativePipe is still false / missing.
• Request metadata still only has progressToken, threadId, and x-codex-turn-metadata.
• Browser bootstrap still fails with:

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

• Also tried js_reset before running bootstrap again. Same result.

Current interpretation: plugin reinstall succeeds, but the existing thread's Node REPL runtime still does not receive the Browser plugin trusted native bridge / backend metadata.

[workpodsjun]

Follow-up after reviewing the duplicate candidates suggested by the bot.

I checked the suggested issues:

• Chrome plugin fails after reinstall: browser-client is not trusted / native pipe bridge unavailable #23884: same browser-client is not trusted / native pipe bridge unavailable error, but reported on Windows / Chrome plugin.
• codex chrome can't be used in windows edition #24845: same class of browser-client/native-pipe issue, also Windows-focused.
• Chrome plugin disappeared from Codex App marketplace after update; cached browser-client is not trusted #23831: closest recovery pattern. It describes a plugin marketplace/cache/trusted-path mismatch after update, and a recovery path of fully closing Chrome and Codex, starting Codex first, waiting for bundled plugin refresh, then reopening Chrome if external Chrome control is needed.

What is similar:

• The visible error is the same:

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

• Local plugin files and browser-client cache can exist while the active runtime still does not receive a trusted browser-client/native-pipe path.
• A thread/runtime/tool-injection mismatch remains a plausible root cause.

What is different in this report:

• This is macOS, not Windows.
• The primary failing surface is the Browser plugin / in-app browser automation (iab), not only the external Chrome plugin.
• Chrome extension and native messaging host checks pass.
• Browser/Chrome browser-client.mjs hashes match the trusted hash configured locally.
• Loading from both the cache path and bundled marketplace path still fails.
• A Browser plugin remove/add reinstall completed successfully, but the existing thread still had no nodeRepl.nativePipe.
• A fresh Codex App thread with @Browser also failed at bootstrap before any tab creation, URL navigation, localhost access, or UI inspection.

Current narrowed failure point:

• nodeRepl.nativePipe is missing.
• browser-related env keys are not visible in the Node REPL runtime.
• request metadata does not include browser backend metadata.
• Therefore the Browser plugin trusted native bridge/backend metadata does not appear to be injected into the active Codex App thread runtime.

So this may be related to the duplicate candidates, especially #23831, but I do not think it is an exact duplicate unless the same fix is expected to cover macOS Browser plugin / in-app browser automation as well.

[dingjianhui123-create]

Additional Windows recovery datapoint from another affected machine. This is not an official fix, but it may help narrow down the failure mode.

Environment:

• Windows x64
• Codex App 26.527.3686.0
• codex-cli 0.135.0-alpha.1
• bundled browser, chrome, and computer-use plugins at 26.527.31326

Symptoms observed:

• browser-client is not trusted
• privileged native pipe bridge is not available
• Computer Use also failed with native pipe unavailable/path unavailable errors
• codex plugin list --marketplace openai-bundled could show plugins as enabled, while runtime bootstrap still failed
• after a restart, Browser/Chrome regressed to not installed because local plugin cache directories/manifests were missing

What recovered this machine:

1. Closed Codex/Chrome where possible before cache repair, because live Node/Codex/plugin smoke-test processes can lock native files under the plugin cache.
2. Restored missing browser, chrome, and computer-use plugin cache directories/manifests from the bundled marketplace source. Avoided overwriting already-loaded native files while Codex was running.
3. Ensured these plugin blocks existed and stayed enabled:

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

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

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

4. Added runtime env values to the local node_repl MCP server:

[mcp_servers.node_repl.env]
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = "<sha256 values for the installed bundled browser/chrome/computer-use client scripts>"
SKY_CUA_NATIVE_PIPE_DIRECTORY = "\\\\.\\pipe\\codex-computer-use-<current-session-id>"

The important part was not hard-coding someone else's values. The SHA-256 list was computed from the installed plugin client files on that machine, and the Computer Use pipe was discovered from the current live \\.\pipe\codex-computer-use-* pipe.

5. Because the Computer Use pipe changes after Codex restarts, I added a local Windows scheduled-task watchdog that runs once per minute and only writes when needed. It:

• restores missing bundled plugin cache/manifests if absent
• recomputes trusted client SHA-256 values from installed plugin files
• refreshes SKY_CUA_NATIVE_PIPE_DIRECTORY to the current live pipe
• keeps the three bundled plugins enabled
• creates a timestamped backup before changing config.toml
• uses a mutex to avoid concurrent writes

Verification after repair:

• config.toml parsed successfully
• codex mcp get node_repl showed the expected env entries
• codex plugin list --marketplace openai-bundled showed Browser, Chrome, and Computer Use as installed, enabled
• Browser smoke test succeeded with both Chrome and Codex In-app Browser listed
• Chrome smoke test succeeded when using the dynamic browser id returned by agent.browsers.list()
• Computer Use smoke test succeeded with sky.list_apps() and sky.list_windows()

My interpretation:

• For a simple marketplace/cache mismatch, the "fully close Chrome and Codex, start Codex first, wait for plugin refresh, then reopen Chrome" recovery is safer and should be tried first.
• In this case that was not enough, because plugin cache/manifests, trusted client hashes, and a session-specific Computer Use pipe all had to be kept in sync.
• The ideal official fix would make this unnecessary by ensuring bundled plugin cache regeneration, trusted browser-client injection, and native-pipe discovery are handled atomically by Codex Desktop instead of relying on user-maintained config.toml repair scripts.

Sanitized write-up of the local repair is here:

https://gist.github.com/dingjianhui123-create/9c3c2b83c2a45c2ef32f9991e712edba

[benjo456]

Same here