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

I maintain WinBridge Recovery, an independent Windows Codex Desktop local-state diagnostic/recovery tool: https://github.com/zemeng5208/winbridge-recovery

This thread is relevant because the failure is path-sensitive: the same browser client can fail from the managed plugin cache with browser-client is not trusted while succeeding from the bundled marketplace source. That is exactly the kind of split state WinBridge checks before attempting any repair — Store AppX bundled source, managed bundled marketplace, versioned plugin cache/latest, node_repl runtime, and Chrome Native Host state are validated together instead of assuming the cache copy is authoritative.

For cases where the official bundled source is present and valid but the user-owned cache/runtime pointers have drifted, WinBridge can back up the current state, stage a verified replacement from the installed official package, hash-check it, and switch the local state with rollback data. It does not patch WindowsApps or bypass the trusted native-pipe model; if all local layers validate and a fresh task still lacks the privileged bridge, that remaining failure should be treated as upstream Desktop provisioning.

If anyone here tries it on this exact browser-client is not trusted failure, please report the outcome even if it works. I created a short feedback thread specifically for real field results: https://github.com/zemeng5208/winbridge-recovery/issues/4 — ✅ worked / 🟡 partial / ❌ no change are all useful.

Reproduced on Windows with Codex/Browser plugin build 26.814.41407.

The in-app browser opens the target page normally, but agent control fails before browser discovery with:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/<redacted>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The service file exists and the trusted paths are present in the generated configuration, but the live runtime receives an empty environment, so the trusted roots are unavailable to the service loader. Reinstalling the Browser plugin and fully restarting the desktop application and worker processes did not resolve it.

This appears consistent with the missing runtime environment reported in #28752, now reproducing in the current Windows desktop build through the trusted RPC dependency check.

Additional Windows reproduction on a newer Codex build.

Environment:

• Codex Windows app package: 26.814.5167.0
• Codex runtime / bundled Browser, Chrome, and Computer Use plugins: 26.814.41407
• Chrome extension: 1.2.27259.19709
• Google Chrome stable on Windows x64

Regression timeline:

• Chrome control worked earlier the same day.
• It stopped working immediately after updating Codex to the versions above.

Current bootstrap error:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The Chrome skill imports:

C:/Users/<user>/.codex/plugins/cache/openai-bundled/chrome/26.814.41407/scripts/browser-client.mjs

Verified healthy:

• Chrome is running.
• ChatGPT Chrome extension is installed, registered, and enabled.
• Native messaging host manifest exists and is correct.
• HKCU native messaging registry entry matches the manifest.
• Expected extension origins are present.
• Computer Use works and can read Windows application state.
• Browser and Chrome plugin bundle versions match.

Recovery attempts that did not fix it:

• Reinstalled Browser/Chrome plugins.
• Restarted Codex and Chrome.
• Rebuilt bundled marketplace/plugin caches.
• Removed stale generated Node REPL/trusted-browser hash configuration and allowed Codex to regenerate its runtime configuration.

After regeneration, the failure remains specifically at the trusted RPC service dependency check for browser-service.mjs.

This appears to be a 26.814 regression in cross-plugin trusted-service resolution: the Chrome client starts from the chrome plugin root but its registered RPC service resolves from the browser plugin root and is rejected before any Chrome connection attempt.

Current-build datapoint that appears to be the newer manifestation of this shared IAB/Chrome trust-runtime problem:

• Codex Windows package path version: 26.814.5167.0
• Browser and Chrome plugins: 26.814.41407
• Trusted project workspace on C:
• In-app browser UI is open and renders a Yahoo page normally
• Both explicit iab and chrome initialization fail before backend/tab discovery

Current error:

Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

The referenced service file exists. Chrome and IAB both resolve through the same rejected Browser service, so this is upstream of the Chrome extension handshake and independent of the loaded website. This supports the thread's broader diagnosis of a shared trusted-runtime/native-bridge provisioning failure, now expressed as a trusted RPC dependency rejection in build 26.814.

Additional Windows data point from Codex App 26.814.5167.0 / CLI 0.148.0-alpha.15 on Windows 11 Pro 10.0.26200 x64 (zh-TW). The in-app Browser worked before the 2026-08-18 app update and has failed consistently since the update.

The current exact bootstrap error is:

Trusted RPC dependency must resolve within a configured trusted code path: file:///%USERPROFILE%/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

This occurs before browser discovery or access to any tab/site.

codex plugin list --json reports browser@openai-bundled 26.814.41407 as installed=true and enabled=true. The trust evidence is deterministic:

configured NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S
8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701

cached browser-client.mjs SHA-256
3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87

bundled-marketplace browser-client.mjs SHA-256
3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87

cached browser-service.mjs SHA-256
B6FD7F485FDF59CC4A25445479545B24972F6226C79C72AB7BD985D86F069615

The two shipped client files match each other, but neither matches the configured trust value. The trusted-services mapping points to the same cached browser-service.mjs path that the runtime rejects. This looks like stale or mixed trust metadata after update, although I cannot determine the internal root cause from the public runtime surface.

Already attempted without success:

• Codex restart.
• Windows App Repair and restart.
• Official Browser plugin remove/reinstall and restart.
• Verified uninstall removed the cache and reinstall recreated it.
• Tested both cached and bundled-marketplace plugin sources.
• Controlled trust regeneration: backed up config, removed only the client trust hash, reinstalled Browser, restarted. The app did not regenerate a trust value, so the test was stopped and the original config value was restored exactly.

codex doctor passes install, config, auth, MCP, sandbox, update, network, WebSocket, endpoint reachability, and state database checks. Its only failure is TERM=dumb in the non-interactive diagnostic shell, which is unrelated to Browser bootstrap.

Full CDP remains disabled. No credentials, browser data, ChatGPT Project data, repository files, or other plugins were modified.

This is fully reproducible on the current installation. A sanitized diagnostic JSON is available if maintainers want it.

Additional data point from the current Windows desktop build. This appears to be the same class of sandbox/trust-path issue, now failing in the newer trusted RPC service loader.

Environment:

• ChatGPT/Codex desktop package: OpenAI.Codex_26.814.5167.0_x64
• Browser plugin: 26.814.41407
• Windows: 10.0.26200.9168 x64
• The Browser plugin and in-app browser are enabled; Microsoft Store shows the installed app as current.

Reproduction:

1. Open a Codex desktop task on Windows with the bundled Browser plugin enabled.
2. Import the bundled client:

``js
const { setupBrowserRuntime } = await import(
"C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-client.mjs"
);
await setupBrowserRuntime();
``

1. Setup fails before browser discovery or page interaction with:

``text
Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
``

Diagnostics:

• The cached browser-client.mjs and browser-service.mjs SHA-256 hashes exactly match the copies bundled in the installed app, so this is not cache corruption.
• Generated ~/.codex/config.toml contains:

``toml
NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\<user>\.codex;...\cua_node\...\bin\node_modules'
NODE_REPL_TRUSTED_SERVICES = '{"browser":"C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs","sky":"@oai/sky/service"}'
``

• The trusted worker sandbox command grants read access to the exact Browser .../scripts directory, but not to the parent C:/Users/<user>/.codex directory used as the configured trusted code root.
• The trusted service host calls realpathSync.native() on each configured trusted root and drops roots that cannot be resolved. The Browser service file itself resolves, but the .codex root is absent from trustedCodeRoots, so isTrustedCodePath() rejects the service.
• The sky trusted service loads in the same Node REPL, which narrows the failure to the Browser path rooted under .codex.
• Restarting the desktop app and JS kernel, importing the client from .codex/.tmp/bundled-marketplaces/..., and reinstall/cache checks do not resolve it.
• Manually editing the generated global config is not persistent; the desktop app regenerates the broad .codex root at startup.
• A workspace-local .codex/config.toml override was also not applied by this desktop path.

Likely fix:
Align the trusted root with the directory already granted to the trusted worker sandbox (for example, dirname(browser-service.mjs) / the plugin scripts directory), or ensure the configured .codex root is resolvable inside that sandbox. Trusting the exact service directory would also be narrower than trusting all of CODEX_HOME.

No sandbox disablement was used.

Additional reproducible Windows data point with a newer build.

Environment:

• Windows 11 Pro x64, build 26200
• VS Code extension / Browser plugin: 26.814.41407
• codex-cli: 0.148.0-alpha.15
• cua_node runtime: 0.0.8/20260814183844-5f25dc4fe44e
• Browser plugin was removed/re-added and VS Code was fully restarted

Current error:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/<user>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

Checks:

• codex doctor --summary: 17 ok, 0 fail
• browser-client.mjs and browser-service.mjs both exist
• The configured trusted root and service path resolve to canonical Windows paths. Using the bundled Node runtime, path.relative(trustedRoot, serviceFile) returns browser-service.mjs, so the path check would pass if the configured root reached the runtime.
• Plugin reinstall and a fresh app process do not change the error.

Key diagnostic:

• codex mcp get node_repl lists NODE_REPL_TRUSTED_CODE_PATHS, NODE_REPL_TRUSTED_SERVICES, NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S, BROWSER_USE_AVAILABLE_BACKENDS, and BROWSER_USE_CODEX_APP_VERSION as configured.
• In a fresh live runtime, nodeRepl.env contains none of those values.
• A read-only inspection of the fresh node_repl.exe process environment also confirms that all six values are absent before the worker starts.

This points to the configured MCP environment being dropped between the VS Code/Codex host and node_repl.exe, rather than an ACL, missing-file, SHA calculation, or canonical-path problem. Adding an exact trusted path and current client SHA to config had no effect and was reverted because it only widened the trust boundary without reaching the process.

No private logs, pipe identifiers, or project data are included.