Repository navigation
[Windows] Browser plugin fails with "browser-client is not trusted" despite advertised chrome and iab backends #21781
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.2212.0
What subscription do you have?
Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Codex Desktop Browser / browser-use plugin fails with:
privileged native pipe bridge is not available; browser-client is not trusted
This happens even though the Node REPL request metadata advertises both chrome and iab as available browser backends.
The issue appears to be with the Browser plugin runtime or Node REPL trusted native pipe injection, not with the local web app being tested. Direct Playwright automation against the same localhost URL works.
Diagnostics observed from Node REPL:
{
"hasNativePipe": false,
"requestMeta": {
"x-codex-browser-use-available-backends": [
"chrome",
"iab"
]
}
}
Additional observations:
x-codex-browser-use-available-backends includes chrome and iab
import.meta.__codexNativePipe is not available
\\.\pipe\codex-browser-use-* pipes exist
~/.codex/config.toml has the Browser plugin enabled
The local app is reachable over HTTP
Direct Playwright Chromium automation against the same URL succeeds
### What steps can reproduce the bug?
Uploaded thread: daff1fa5-966b-436a-8791-682411321073
*To Codex dev teams, reference this id. You have my submitted logs.
Start Codex Desktop on Windows.
Use the bundled Browser plugin:
browser-use@openai-bundled
observed path: ~/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/
In the Node REPL, run:
const { setupAtlasRuntime } = await import(
"file:///C:/Users/ms-ef/.codex/plugins/cache/openai-bundled/browser-use/0.1.0-alpha2/scripts/browser-client.mjs"
);
await setupAtlasRuntime({ globals: globalThis });
const browser = await agent.browsers.get("chrome");
Repeat with iab:
const browser = await agent.browsers.get("iab");
Both fail with the same trust/native pipe error.
### What is the expected behavior?
What is the expected behavior?
If chrome or iab is advertised as an available backend, Browser plugin setup should succeed:
await setupAtlasRuntime({ globals: globalThis });
const browser = await agent.browsers.get("chrome");
// or
const browser = await agent.browsers.get("iab");
After setup, browser navigation, DOM snapshots, screenshots, clicks, and reloads should work.
### Additional information
Workaround: direct Playwright execution works against the same target.
npx -y playwright install chromium
npx -y playwright screenshot --browser chromium "http://127.0.0.1:59832/?sample=web-edited-sales&v=type-old-new-layout" tmp/page.png
A temporary Node runner with the playwright package also works for multi-step UI checks.
Suspected cause: the browser backends are detected, but the current Node REPL runtime is not receiving the trusted native pipe bridge. This looks like a Codex Desktop / Browser plugin runtime initialization issue, or a failure to inject import.meta.__codexNativePipe into the Node REPL environment.
Reacted by Greg Peden, Mickitty0511, Ivan Wang and Michael Broner
Activity
github-actions commentedon May 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rodrigoantonioli commentedon May 12, 2026
Additional data point from Windows:
Importing
browser-client.mjsfrom 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: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.
ceoaliongroo commentedon May 18, 2026
I’m seeing the same issue on Windows with the Codex Desktop Chrome plugin.
Error:
Local diagnostics:
Commands/checks used from the bundled Chrome plugin all pass:
Tried recovery steps:
Expected:
Actual:
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.
Denzarva commentedon May 20, 2026
I can reproduce the same trusted bridge failure on a newer Codex Windows build.
Environment:
OpenAI.Codex_26.513.4821.0codex-cli 0.132.0Profile 3Connected1.1.4_0Failure:
Both Browser/IAB and Chrome extension direct bridge fail before any page interaction with:
What I tested:
%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\0.1.0-alpha2\scripts\browser-client.mjs%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome\0.1.7\scripts\browser-client.mjs%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\browser\scripts\browser-client.mjs%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\plugins\chrome\scripts\browser-client.mjsThe cache and bundled marketplace
browser-client.mjsfiles currently have the same SHA256 hash on this machine.Both bundled marketplace clients export
setupBrowserRuntime. In the active JS turn, request metadata contains:x-codex-browser-use-available-backendscontains:x-codex-turn-metadatais present and includes keys such as:But the JS runtime still has:
Latest Desktop logs show:
Latest logs do not show:
Fresh local Codex Desktop thread tests:
@Browser open https://example.com and read the page titlereproduced the trusted native-pipe failure, then only succeeded through the Playwright MCP fallback.@Chrome list my open tabsdid 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.
AmoebaChaos commentedon May 21, 2026
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.
Stef9332 commentedon May 22, 2026
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:
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 aChromebackend withtype: "extension", and navigation tohttps://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:
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.
dingjianhui123-create commentedon May 31, 2026
Additional Windows recovery datapoint from another affected machine. This is not an official fix, but it may help narrow down the failure mode.
Environment:
26.527.3686.0codex-cli 0.135.0-alpha.1browser,chrome, andcomputer-useplugins at26.527.31326Symptoms observed:
browser-client is not trustedprivileged native pipe bridge is not availablecodex plugin list --marketplace openai-bundledcould show plugins as enabled, while runtime bootstrap still failednot installedbecause local plugin cache directories/manifests were missingWhat recovered this machine:
browser,chrome, andcomputer-useplugin cache directories/manifests from the bundled marketplace source. Avoided overwriting already-loaded native files while Codex was running.node_replMCP server: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.SKY_CUA_NATIVE_PIPE_DIRECTORYto the current live pipeconfig.tomlVerification after repair:
config.tomlparsed successfullycodex mcp get node_replshowed the expected env entriescodex plugin list --marketplace openai-bundledshowed Browser, Chrome, and Computer Use asinstalled, enabledagent.browsers.list()sky.list_apps()andsky.list_windows()My interpretation:
config.tomlrepair scripts.Sanitized write-up of the local repair is here:
https://gist.github.com/dingjianhui123-create/9c3c2b83c2a45c2ef32f9991e712edba
zejiangPG commentedon Jul 14, 2026
Windows Codex Desktop datapoint, likely related but with an earlier bootstrap failure:
26.707.71524codex-cli --version:0.27.0browser-client.mjsfrom the Node REPL fails before backend discovery with:The plugin begins by assigning a
processShimtoglobalThis.processandglobalThis.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 trustederror because it fails immediately at theprocessshim initialization. No browser account, cookies, or site-specific data are involved.zemeng5208 commentedon Aug 14, 2026
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 trustedwhile 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_replruntime, 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 trustedfailure, please report the outcome even if it works. I created a short feedback thread specifically for real field results: zemeng5208/winbridge-recovery#4 — ✅ worked / 🟡 partial / ❌ no change are all useful.ErdoesiT commentedon Aug 18, 2026
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:
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.
shiina-kaze commentedon Aug 18, 2026
Additional Windows reproduction on a newer Codex build.
Environment:
26.814.5167.026.814.414071.2.27259.19709Regression timeline:
Current bootstrap error:
The Chrome skill imports:
Verified healthy:
Recovery attempts that did not fix it:
After regeneration, the failure remains specifically at the trusted RPC service dependency check for
browser-service.mjs.This appears to be a
26.814regression in cross-plugin trusted-service resolution: the Chrome client starts from thechromeplugin root but its registered RPC service resolves from thebrowserplugin root and is rejected before any Chrome connection attempt.adamczhang commentedon Aug 18, 2026
Current-build datapoint that appears to be the newer manifestation of this shared IAB/Chrome trust-runtime problem:
26.814.5167.026.814.41407C:iabandchromeinitialization fail before backend/tab discoveryCurrent error:
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.Rayi0406TW commentedon Aug 19, 2026
Additional Windows data point from Codex App
26.814.5167.0/ CLI0.148.0-alpha.15on Windows 11 Pro10.0.26200x64 (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:
This occurs before browser discovery or access to any tab/site.
codex plugin list --jsonreportsbrowser@openai-bundled26.814.41407asinstalled=trueandenabled=true. The trust evidence is deterministic: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.mjspath 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 doctorpasses install, config, auth, MCP, sandbox, update, network, WebSocket, endpoint reachability, and state database checks. Its only failure isTERM=dumbin 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.
takatori67 commentedon Aug 19, 2026
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:
OpenAI.Codex_26.814.5167.0_x6426.814.4140710.0.26200.9168 x64Reproduction:
Diagnostics:
browser-client.mjsandbrowser-service.mjsSHA-256 hashes exactly match the copies bundled in the installed app, so this is not cache corruption.~/.codex/config.tomlcontains:.../scriptsdirectory, but not to the parentC:/Users/<user>/.codexdirectory used as the configured trusted code root.realpathSync.native()on each configured trusted root and drops roots that cannot be resolved. The Browser service file itself resolves, but the.codexroot is absent fromtrustedCodeRoots, soisTrustedCodePath()rejects the service.skytrusted service loads in the same Node REPL, which narrows the failure to the Browser path rooted under.codex..codex/.tmp/bundled-marketplaces/..., and reinstall/cache checks do not resolve it..codexroot at startup..codex/config.tomloverride 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 pluginscriptsdirectory), or ensure the configured.codexroot is resolvable inside that sandbox. Trusting the exact service directory would also be narrower than trusting all ofCODEX_HOME.No sandbox disablement was used.
Yurii0123 commentedon Aug 19, 2026
Additional reproducible Windows data point with a newer build.
Environment:
Current error:
Checks:
codex doctor --summary: 17 ok, 0 failbrowser-client.mjsandbrowser-service.mjsboth existpath.relative(trustedRoot, serviceFile)returnsbrowser-service.mjs, so the path check would pass if the configured root reached the runtime.Key diagnostic:
codex mcp get node_repllistsNODE_REPL_TRUSTED_CODE_PATHS,NODE_REPL_TRUSTED_SERVICES,NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S,BROWSER_USE_AVAILABLE_BACKENDS, andBROWSER_USE_CODEX_APP_VERSIONas configured.nodeRepl.envcontains none of those values.node_repl.exeprocess 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.
hangwihui742-sys commentedon Oct 1, 2026
Additional Windows reproduction, October 1, 2026.
I am seeing the same failure in Codex Desktop built-in Browser:
privileged native pipe bridge is not available; browser-client is not trusted
Environment:
Behavior:
Policy checks:
Sandbox check:
sandbox = "unelevated"
Current reproduction session / feedback ID:
01a0f6f2-8039-7160-b7a4-ceeb8c0ab077
The actual failing JSONL event is an McpToolCall from node_repl / js invoking the bundled browser-client.mjs, with:
and the exact error:
privileged native pipe bridge is not available; browser-client is not trusted
The failure occurs before the requested page can be opened or read.
mickitty0511 commentedon Oct 9, 2026
Windows Computer Use initialization findings
I finally recovered a Windows Computer Use and browser initialization failure through configuration changes alone.
These findings may help investigate environment-variable inheritance.
And I'm afraid to say the error message posted in my first issue comment disappeared without knowing. New error messages arose instead.
Problem
My environment produced these new errors:
The second error occurred when a generated trusted worker parsed
NODE_REPL_TRUSTED_SERVICESas JSON.The verification environment was Windows build
10.0.26200.0, Codex Desktop26.1002.52244, and bundled CLI0.162.0-alpha.2.Codex ran directly on Windows with
workspace-writeand the Windowselevatedsandbox.Possible cause
My existing
shell_environment_policyusedinherit = "core"and a restrictiveinclude_onlylist.The allowlist omitted app runtime variables including
NODE_REPL_NODE_MODULE_DIRS,NODE_REPL_TRUSTED_SERVICES,NODE_REPL_TRUSTED_CODE_PATHS,NODE_REPL_JS_BANNER, andNODE_REPL_TRUSTED_RPC_ENABLED.Initialization succeeded after I adjusted inheritance, making custom environment filters a useful diagnostic target.
I have not isolated the contribution of each variable.
I referred to the official advanced configuration documentation for environment inheritance and filtering.
Basic setup and recovery
The basic setup is Codex Desktop with its bundled Computer Use/browser capabilities enabled and the normal access permissions required for the requested operations.
The desktop must be unlocked for native app operations.
I followed the official Computer Use guide.
No project code changes, runtime patches, or manually installed alternative helpers were needed.
This procedure recovered my environment:
shell_environment_policy.inheritto"all".include_onlyentries and appended the 23 variables below.NODE_REPL_NODE_PATHwas already included.Secret-related exclusions and sandbox settings were preserved.
This is a verified working configuration, not a proven minimum allowlist.
You don't have to set sandbox to unelevated! This is important for the security reasons and what I really wanted.
Verification
After recovery, the built-in browser opened
example.comand read its contents.Edge opened OpenAI Help Center and successfully switched it to Japanese.
Native Windows app checks covered screenshots, clicking, typing, and keyboard input.
Relationship to this issue and investigation request
I have not reproduced and resolved the error in the October 1 comment under the same conditions:
These results therefore do not establish that this issue is resolved.
Could maintainers check whether user environment filters also affect app-managed workers and whether required initialization variables are missing?
Documenting those variables and reporting missing variable names during initialization would make configuration-dependent failures easier to diagnose.
carabinshely commentedon Oct 13, 2026
Additional observation on Windows, October 12, 2026; environment package read back October 13 as
OpenAI.Codex 26.1007.2314.0, OS reported by .NET10.0.26300.0.The available bundled skill was
browser-use/0.1.0-alpha2. Its documented setup throughmcp__node_repl__js:failed during setup, before a usable browser inventory or a selected backend:
Separated attempts over several hours produced the same result while read-only OS process checks confirmed Chrome and Edge running. Ordinary shell operations and isolated installed Edge/Playwright runtime checks worked; those checks do not establish authenticated existing-tab access.
Important scope limits: the supplied skill describes the in-app-browser backend. Earlier attempts to use this setup as a recovery route for an existing Chrome extension tab were an agent routing mistake; we do not claim this runtime is a documented route to Edge. However, the observed setup itself fails before backend selection. We did not inspect private native pipes or establish whether trust metadata was injected. No trust allowlist, native-host registration, browser security or account setting was changed.
The separately exposed
cua_replentry point later failed withfailed to write kernel assets ... (os error 3), reported in #41359. The two signatures are not claimed to share a root cause.Expected: the advertised documented runtime should initialize or report a supported, actionable explanation of the missing trust/bridge component. No private page contents, credentials, raw logs, local usernames or task IDs are included.
Hirachy commentedon Oct 21, 2026
Additional Windows in-app Browser reproduction after an app update and normal restart. The supported Browser setup still fails before any tab/page is returned. This report requests a supported recovery procedure; the root cause is not confirmed. No trust bypass or broader permissions were applied.
Codex 内置 Browser 连接故障报告
日期：2026-10-21（Asia/Shanghai）
更新前状态：
版本 26.1013.40934，build 20770，prod。
官方更新检查返回 restart_required。
更新后状态：
用户已正常更新并重启。
官方更新检查返回：
installedVersion: 26.1016.51333
installedBuildVersion: 21161
installedReleaseChannel: prod
status: up_to_date
问题：
正常使用内置 Browser 官方技能初始化时，仍返回：
privileged native pipe bridge is not available; browser-client is not trusted
本轮复现：
结果：上述错误，未返回任何标签或页面。
结果：同样错误，未返回任何标签或页面。
预期：
内置 Browser 能返回当前标签并读取普通页面。
影响：
无法操作内置 Browser；真实网页认证流程未开始。
没有账号、店铺、短信或API请求成功的证据。
已保持的边界：
没有更改信任配置、插件文件、权限或浏览数据。
没有开启CDP、切换浏览器、安装第三方组件、反复重启或强杀进程。
没有在该错误后绕过信任检查。
请求：
请排查当前 Windows 桌面版本中内置 Browser 官方组件的信任/原生连接状态，
提供受支持的恢复步骤。更新已生效，但不能确定该错误的根因。
本报告不包含账号、手机号、URL查询参数、Cookie、密钥、令牌、私有配置或会话全文。
本次仅提交这份脱敏技术报告，未附聊天会话或原始日志。
0xdevalias commentedon Oct 26, 2026
Your October 21 Windows report on 26.1016.51333 still describes failure during trusted bootstrap, before browser control. Our macOS CLI/SDK 0.163.0 investigation verifies a different trusted-RPC path and separates missing transport from a missing public
nodeRepl.nativePipeproperty. detailed investigation supplies diagnostic context; it does not establish a Windows fix.Related investigations and reports
Grouped by diagnostic boundary; these links do not imply a shared root cause or that every report is fixed.
browser-client is not trusteddespite extension and native host checks passing #27186