[Windows] Browser plugin fails with "browser-client is not trusted" despite advertised chrome and iab backends

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

• #21670
• #20248
• #21698
• #21765

Powered by Codex Action

Additional data point from Windows:

Importing browser-client.mjs from the plugin cache path produced:

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

But importing it from the bundled marketplace source path worked:

C:\Users\rodri\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjs

After that, agent.browsers.list() returned both:

• Chrome, type extension
• Codex In-app Browser, type iab

The Chrome extension backend then successfully opened https://example.com/ and read the title "Example Domain".

So at least in this case, the trust error was path-sensitive: cache path failed, bundled marketplace path succeeded.

I’m seeing the same issue on Windows with the Codex Desktop Chrome plugin.

Error:

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

Local diagnostics:

OS: Windows
Chrome: running
Codex Chrome Extension: installed and enabled
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Detected Chrome profile: Profile 13
Native host manifest: exists and is correct
Registry native host path: matches manifest path
allowedOrigins includes: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/
Node REPL request metadata advertises browser backends: ["chrome", "iab"]

Commands/checks used from the bundled Chrome plugin all pass:

scripts/chrome-is-running.js --json
scripts/check-extension-installed.js --json
scripts/check-native-host-manifest.js --json

Tried recovery steps:

- Restarted Chrome
- Reinstalled the Codex Chrome extension
- Restarted Codex
- Opened a fresh Chrome window using the detected profile
- Reset the Node REPL kernel and retried setupAtlasRuntime
- Tried both bundled chrome and browser-use browser-client paths

Expected:

const { setupAtlasRuntime } = await import("file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/0.1.7/scripts/browser-client.mjs");
await setupAtlasRuntime({ globals: globalThis });
globalThis.browser = await agent.browsers.get("extension");
await browser.user.openTabs();

Actual:

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

This looks like the Desktop runtime is not injecting/exposing the trusted native pipe bridge to the Node REPL despite the Chrome extension and native host installation checks passing.

I can reproduce the same trusted bridge failure on a newer Codex Windows build.

Environment:

• Codex Windows package: OpenAI.Codex_26.513.4821.0
• codex-cli 0.132.0
• Windows, x64
• Chrome extension installed/enabled in Profile 3
• Chrome extension popup shows Connected
• Chrome extension version: 1.1.4_0
• Native host manifest and registry checks pass:
• manifest exists
• host name matches
• expected extension origin is present
• registry path matches manifest path

Failure:

Both Browser/IAB and Chrome extension direct bridge fail before any page interaction with:

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

What I tested:

• Browser/IAB via cache path:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\0.1.0-alpha2\scripts\browser-client.mjs

• Chrome via cache path:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7\scripts\browser-client.mjs

• Browser/IAB via bundled marketplace path:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\browser\scripts\browser-client.mjs

• Chrome via bundled marketplace path:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjs

The cache and bundled marketplace browser-client.mjs files currently have the same SHA256 hash on this machine.

Both bundled marketplace clients export setupBrowserRuntime. In the active JS turn, request metadata contains:

threadId
x-codex-browser-use-available-backends
x-codex-turn-metadata

x-codex-browser-use-available-backends contains:

["chrome", "iab"]

x-codex-turn-metadata is present and includes keys such as:

session_id
thread_id
turn_id
model
reasoning_effort
sandbox
turn_started_at_unix_ms

But the JS runtime still has:

globalThis.__codexNativePipe === undefined

Latest Desktop logs show:

browser_use_availability_resolved available=true
browser-use native pipe listening

Latest logs do not show:

bundled_executable_relocation_failed
Windows Computer Use helper paths are unavailable
expected active turn id

Fresh local Codex Desktop thread tests:

• @Browser open https://example.com and read the page title reproduced the trusted native-pipe failure, then only succeeded through the Playwright MCP fallback.
• @Chrome list my open tabs did not expose the real Chrome-backed tab API and only saw an isolated Playwright tab (about:blank), not the user's real Chrome profile tabs.

The user also retried the Browser/Chrome plugin repair/re-add flow and restarted Codex, but the direct bridge still did not recover.

Workaround:

Playwright MCP still works for browser automation. The failure appears specific to Codex Desktop trusted native-pipe / browser-client trust injection for the direct Browser/Chrome bridge.

I am seeing the same issue on Windows Codex App.

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

In my environment, Chrome is running, the Codex Chrome Extension is installed and enabled, and the native host manifest appears to be correct, but Codex still cannot control Chrome/Gmail through the Chrome plugin.

This blocks browser automation for Gmail. I would appreciate a fix or an official workaround.

Adding a related Windows datapoint that may help narrow this down.

On Codex Desktop for Windows, I can reproduce a browser/native-pipe failure mode that changes depending on the filesystem sandbox setting.

Observed behavior:

• With sandboxing enabled, Chrome/browser automation fails from the browser client path with:

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

• After disabling the sandbox and restarting Codex Desktop, the Chrome extension backend becomes visible and usable through the bundled browser client. agent.browsers.list() shows a Chrome backend with type: "extension", and navigation to https://x.com/ works in the logged-in Chrome profile.

• Re-enabling sandboxing causes the Chrome/browser path to fail again with the trusted native pipe / browser-client error.

This makes the issue look less like a Chrome extension install problem and more like the Windows sandbox is blocking or preventing the trusted native pipe bridge / browser-client trust path from being injected or accessed correctly.

Environment details:

• Platform: Windows
• Codex Desktop Windows app
• Chrome extension backend present and working when sandbox is off
• Failure mode appears before page-specific navigation, during browser client / backend setup

I do not have a minimal code fix, but the sandbox on/off comparison seems like a useful signal: the same Chrome profile and extension setup works when the sandbox is disabled, and fails when sandboxing is enabled.

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

1. 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.

1. 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

Windows Codex Desktop datapoint, likely related but with an earlier bootstrap failure:

• Bundled Browser plugin version: 26.707.71524
• codex-cli --version: 0.27.0
• An in-app browser tab is present and can be navigated manually.
• Importing the bundled browser-client.mjs from the Node REPL fails before backend discovery with:

Cannot redefine property: process

The plugin begins by assigning a processShim to globalThis.process and globalThis.global.process. In this Desktop Node REPL environment, that assignment is rejected. As a result, setupBrowserRuntime() never completes and neither IAB nor Chrome control can be attempted.

Tried: fully exiting Codex, rebooting Windows, reopening the in-app browser, and retrying. The error is unchanged.

This appears related to the trusted browser/native-pipe runtime injection issues in this thread, but differs from the later browser-client is not trusted error because it fails immediately at the process shim initialization. No browser account, cookies, or site-specific data are involved.