Repository navigation
Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.814.41407
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Summary
The Codex in-app browser UI can open and render web pages successfully (for example, https://example.com/). However, the Browser plugin cannot initialize an automation/control session.
Steps to reproduce
- Open Codex.
- Invoke the Browser plugin to control the in-app browser.
- Initialize the browser runtime and attempt to obtain the default browser connection.
- Initialization fails immediately before a controllable browser session is created.
Actual result
The following error is returned consistently, including after retrying in the same session:
Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/47820/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
### What steps can reproduce the bug?
Feedback ID: no-active-thread-01a01314-4c4a-79c1-b74f-e80ee32a0b33
### What is the expected behavior?
_No response_
### Additional information
_No response_
Activity
[-]Codex 内置浏览器插件初始化失败：Trusted RPC dependency 不在受信任代码路径[/-][+]Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path[/+]github-actions commentedon Aug 18, 2026
English translation:
What version of the Codex App are you using (From “About Codex” dialog)?
26.814.41407
What subscription do you have?
ChatGPT Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Summary
The Codex in-app browser UI can open and render web pages successfully (for example,
https://example.com/). However, the Browser plugin cannot initialize an automation/control session.Steps to reproduce
Actual result
The following error is returned consistently, including after retrying in the same session:
n0va39 commentedon Aug 18, 2026
Confirming an independent reproduction on the current stable Windows app.
OpenAI.Codex 26.814.5167.0(x64)10.0.26200.0browser@openai-bundled 26.814.4140701a0130a-c8bc-7902-b470-86f07bdef385The failure occurs before browser discovery/selection:
Troubleshooting already completed without resolving it:
Expected: the Browser plugin initializes and proceeds to browser discovery.
Actual: trusted RPC path validation aborts initialization.
twilight-sparkle-crazy-fan commentedon Aug 18, 2026
Adding an independent reproduction, matching n0va39's environment — plus a few diagnostics that may help.
Environment
OpenAI.Codex 26.814.5167.0(x64, Microsoft Store)10.0.26200.9168browser@openai-bundled 26.814.41407chrome@openai-bundled 26.814.41407Symptom
Browser control worked before updating to
26.814.5167.0. After the update, both@Browserand@Chromefail during initialization — before browser discovery or tab selection — with:Reproduction
@Browser(or@Chrome) to open or inspect a page.Troubleshooting attempted — none resolved it
chrome/extension-host/Codexprocesses; started Codex first, waited for plugin refresh, then reopened Chrome.WindowsApps— not local file corruption.Diagnostics that look relevant
~/.codex/config.tomlcontainsNODE_REPL_TRUSTED_CODE_PATHS(including the.codexdirectory of the rejected file) andNODE_REPL_TRUSTED_SERVICESpointing at the exact installedbrowser-service.mjs— yet during the failing init, the Node REPL environment does not appear to receive theseNODE_REPL_TRUSTED_*values.This looks like the update left stale trust metadata (the hash whitelist) instead of regenerating it for the new plugin files.
Question for maintainers
The desktop package reports
26.814.5167.0while both browser plugins report26.814.41407. Is this version pairing expected, and are the trust-path / client-hash metadata supposed to be updated atomically with the plugin files during upgrade?Expected vs actual
HopeCollector commentedon Aug 18, 2026
Confirming the same failure on another Windows machine with the same stable version combination.
Environment
26.814.5167.026.814.414071.2.27259.19709_010.0.26200Both the Browser and Chrome routes fail before browser discovery or the Chrome handshake with:
Restarting Codex and Chrome, reinstalling the Browser/Chrome plugins and Chrome extension, and retrying from a fresh task did not resolve it.
Additional diagnostics
The Chrome Native Messaging registration is present on this machine:
The manifest also exists and points to the bundled
extension-host.exe. Therefore, this reproduction does not appear to be caused by a missing Chrome native-host registration.The local Codex configuration contains:
NODE_REPL_TRUSTED_CODE_PATHScovering the.codexdirectoryNODE_REPL_TRUSTED_SERVICESpointing to the exactbrowser-service.mjspath aboveNODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256SHowever, from the live Node REPL session producing the error, all three corresponding
NODE_REPL_TRUSTED_*environment values are unavailable (null).There is also a hash mismatch:
This suggests that the trusted-RPC metadata or environment propagation may be out of sync with the installed
26.814.41407plugin bundle. That is only an inference, but it would explain why reinstalling the Chrome extension does not help: the failure occurs at the trusted-RPC gate before any browser backend is contacted.Please let me know if any additional diagnostics would be useful.
hattimon commentedon Aug 18, 2026
I can reproduce a closely matching Windows regression after the latest Codex Desktop update on Aug 18, 2026.
Observed behavior
8e172...while the installed/cached Browser module hash began with3b9d8....Recovery attempts that did NOT fix it
%USERPROFILE%\.codex.The Browser integrity mismatch persisted after the full app reinstall, which strongly suggests stale/incompatible trusted Browser state under
%USERPROFILE%\.codexsurvives the package reinstall and is not reconciled with the newly installed bundled Browser module.Codex briefly proposed changing the trusted hash in
%USERPROFILE%\.codex\config.tomlto trust the currently cached module. I tested that only briefly; it did not solve Chrome control, and the original integrity configuration was restored from backup. The security check is not currently weakened.Expected behavior
After a Codex Desktop update/reinstall, the trusted Browser module metadata and bundled/cached Browser module should be atomically reconciled so their hashes match. Users should never need to manually edit the integrity hash.
If the cached module is stale, Codex should invalidate/redownload it automatically rather than leaving an unrecoverable mismatch that survives reinstall.
Impact
Browser and Chrome automation are completely unavailable. A large part of the weekly Codex usage allowance was consumed while troubleshooting this update regression, without productive project work. The usage issue has been separately escalated to OpenAI Support.
Potentially related: #23831, #29673, and #39146 (same-day Windows update regression family).
zemeng5208 commentedon Aug 18, 2026
I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery
This report looks like a plausible match for one of the local Windows state layers WinBridge is intended to diagnose: bundled plugin cache/version drift after an app update, especially when the installed app package, cached
browser@openai-bundled/chrome@openai-bundledversions, and generated trust metadata are no longer in sync.The strongest local-state signal here is the reported mismatch between the configured
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256Svalue and the SHA-256 of the actually installedbrowser-client.mjs, together with the26.814.5167.0package vs26.814.41407plugin pairing. WinBridge can help inspect/recover the local bundled marketplace/cache/version/lateststate and related staged plugin files, so it may be useful for determining whether this machine is carrying stale metadata from a partial/previous plugin staging cycle rather than a clean current state.A limitation is important here: if the cached plugin files are already byte-identical to the current WindowsApps bundle and Codex still fails because the app-server / Node REPL does not propagate the expected
NODE_REPL_TRUSTED_*environment or regenerates the wrong trust hash on every clean install, that is an upstream trusted-runtime/update-assembly bug, not something WinBridge can reliably fix locally. Likewise, WinBridge does not modify WindowsApps package contents or guarantee that an incompatible package/plugin version pairing can be made functional.So I would use it here mainly to answer one question cleanly: is there recoverable local cache/version/trust-state drift, or is the local state already healthy and the failure reproducibly comes from the current upstream build?
nathanbentley commentedon Aug 18, 2026
Feedback ID - 01a0139f-3bae-7732-95da-99c84f988703
BarryRodick commentedon Aug 18, 2026
Confirming an independent reproduction from a projectless Codex task on Windows x64.
Unlike #39160, this workspace is on
C:, so the failure is not limited to cross-drive/D:workspaces.Environment
10.0.26200.0, x64browser@openai-bundled 26.814.41407chrome@openai-bundled 26.814.41407%USERPROFILE%\Documents\Codex\...onC:Actual result
Both the Browser runtime and the Chrome/Edge bridge abort before browser discovery or tab access:
Importing the refreshed
chrome/latest/scripts/browser-client.mjsstill resolves the service dependency to the siblingbrowser/26.814.41407/scripts/browser-service.mjs, which is rejected by the trusted-RPC gate. No webpage is opened.Recovery attempted
The same error persists after reinstall and restart.
Expected result
The bundled browser service is accepted as trusted, then Edge discovery and a read-only open-tab check proceed.
Diviniteck commentedon Aug 18, 2026
Confirming an independent reproduction on another Windows x64 machine.
Environment:
10.0.26200.9168, x64OpenAI.Codex_26.814.5167.0browser@openai-bundled 26.814.41407M:)The in-app browser opens and renders pages normally, but every attempt to initialize Browser control fails before tab discovery with:
Troubleshooting completed without resolving the issue:
Additional diagnostics:
NODE_REPL_TRUSTED_CODE_PATHSalready contains%USERPROFILE%\.codexbrowser-service.mjsis located below that trusted directory8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701browser-client.mjsSHA-256:3b9d8dcc6dc968887e8a969c63dae6380e3c1c59ff5c474eb32df08c353dad87The configured allowlisted hash therefore does not match the browser-client file installed by the current package. The failure persists after a clean reinstall.
59 remaining items
whisper-house commentedon Aug 19, 2026
Confirming the same issue on Windows with Codex Desktop MSIX 26.814.5167.0 and Browser plugin 26.814.41407. The in-app browser UI opens and renders pages, but agent control fails with the identical Trusted RPC dependency / browser-service.mjs error. In this reproduction CODEX_HOME is on a non-default local drive. The issue persists after a full restart, Browser plugin reinstall, and cache refresh. We verified that browser-client.mjs and browser-service.mjs hashes match the files bundled with the installed app, so this does not appear to be plugin corruption or a stale-version mismatch. NODE_REPL_TRUSTED_CODE_PATHS is present under mcp_servers.node_repl.env, but the live trusted worker does not receive the required path. Adding the same value under shell_environment_policy.set allows a fresh diagnostic worker to select and control the IAB, but the Codex startup/plugin refresh rewrites config.toml and removes that line, so the failure returns after restart. An older working configuration from before the current update included the trusted code path in the shell policy. This points to a regression in trusted environment propagation or configuration persistence in the current Windows build. Sanitized logs can be provided if useful.
Ali-Karaki commentedon Aug 19, 2026
Same issue on Windows with
browser@openai-bundled 26.814.41407andcodex-cli 0.148.0-alpha.15:node_replis enabled and works correctly outside the Desktop browser flow. Runningcodex execand invokingnode_repl/jssuccessfully printsNODE_REPL_OK.codex-browser-use-*andcodex-computer-use-*named pipes are present.NODE_REPL_TRUSTED_CODE_PATHSincludes%USERPROFILE%\.codex, andNODE_REPL_TRUSTED_SERVICESpoints to the installedbrowser-service.mjs.This seems to further support the theory that the failure is specifically at the sandbox/trusted-worker boundary rather than the Browser plugin, Node REPL runtime, or native bridge itself.
yuyoungdock-blip commentedon Aug 19, 2026
Independent Windows reproduction with update-timing and clean-cache evidence (2026-08-19 KST).
Environment
OpenAI.Codex_26.814.5167.0_x6426.814.414070.148.0-alpha.15Timeline
browser-service.mjsandbrowser-client.mjshave a bundled last-write time of 2026-08-19 05:17:24 KST.Exact failure
The failure occurs before browser discovery/connection.
Verification and recovery already completed
browser-service.mjsexists and is readable.%USERPROFILE%\.codex, and the rejected service is a descendant of that root.browser-client.mjsSHA-256 is3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87, matching the active trusted-client configuration.This rules out a missing or corrupted cached Browser bundle and strongly suggests a Windows desktop regression in trusted RPC service path or environment propagation introduced during the update window. Reinstalling or regenerating the same bundle is unlikely to address it.
Please investigate the trusted-service subprocess launch and provide a corrected Windows build. No credentials, browser contents, cookies, private paths, or private logs are included in this report.
samson-xu commentedon Aug 19, 2026
I have the same problem. When will it be fixed?
alfatrademarks-creator commentedon Aug 19, 2026
Update: still reproducible on Desktop 26.814.5517.0 / Browser 26.814.41957
Retested after Codex Desktop updated from
26.814.5167.0to26.814.5517.0.The bundled Browser/Chrome component also updated from
26.814.41407to26.814.41957.Under the normal permission profile, with Full Access not enabled, a fresh Browser Use bootstrap is still blocked before browser discovery / tab enumeration with the same error class:
Trusted RPC dependency must resolve within a configured trusted code pathThe rejected service is the newly installed
browser-service.mjsfrom Browser component26.814.41957.No settings were changed for this retest. No browser tab was obtained, no page data was read, and no website state was modified.
Result: the
26.814.5517.0+26.814.41957combination still reproduces this Windows failure.If
26.814.41957was intended to address #39136, this retest indicates the issue is still present in this environment.I have not separately retested Computer Use or the Excel bridge after this update, so I am not making any claim about their current status.
mustafaerciyas-pixel commentedon Aug 19, 2026
Confirming the same issue on Windows.
The ChatGPT Chrome extension is installed and enabled, site access is set to All sites, and the Chrome side panel loads normally. In ChatGPT/Codex, the bundled Chrome plugin is enabled and Settings → Computer use → Google Chrome is also enabled. I also tried the Windows app repair flow and re-tested, but the failure persists.
Codex still cannot inspect/control the open Chrome tab and reports a trusted component/code-path validation failure consistent with this issue.
Feedback ID:
01a016df-09d5-7ed1-9120-9d4ba88e7d49gmorelli300-coder commentedon Aug 19, 2026
Adding an Enterprise reproduction from Sonoma County, California.
Environment:
Codex Windows app: 26.814.5167.0
Browser runtime/plugin: 26.814.41407
ChatGPT Enterprise workspace
Windows
The built-in Browser and Chrome control both fail before browser discovery with:
Trusted RPC dependency must resolve within a configured trusted code path: ...browser-service.mjs
This same machine was previously running Codex 26.810.7004.0, where Browser control worked normally. Windows AppX deployment history confirms the machine was upgraded from 26.810.7004.0 to 26.814.5167.0 on August 18, after which the failure appeared.
County IT also assisted with troubleshooting. We confirmed:
fresh projectless Codex tasks fail the same way;
Full Access was already enabled;
the Browser service file exists;
reinstall/restart steps do not resolve it;
the previous signed package has already been removed from the machine, so there is no clean local rollback option.
I have now submitted the affected Codex session directly through the in-app Bug feedback flow with current session logs and browser logs attached.
Feedback ID: 01a01aa4-adec-7062-af10-ee26bc710d17
Please correlate that feedback submission with this issue if possible.
I am intentionally not using unofficial third-party rollback packages because this is an enterprise-managed government computer.
This appears to be the same regression reported here and across the growing related issue cluster.
nazedaque commentedon Aug 19, 2026
Update: working locally again after downgrade/cache regeneration
Following up on my previous workaround report: the same machine has since auto-updated to:
26.814.5517.026.814.41957Browser control now works on this installation under the normal
workspace-writepermission profile, without Full Access. I verified that the in-app Browser initializes successfully, navigates tohttps://example.com/, and reads the page content.I did not perform another manual cache reset or configuration change after the earlier downgrade to
26.810.7004.0, which had regenerated the Browser plugin and trust configuration. The working state therefore survived the subsequent automatic update to26.814.5517.0.This suggests that the downgrade plus clean cache/trust regeneration repaired my local environment and that the later update preserved that coherent state. It does not establish that the regression is fixed globally, since other users still report the same failure on the current version combination.
dgwyer commentedon Aug 19, 2026
Update: Installing the latest version worked for me.
adamczhang commentedon Aug 20, 2026
no one assigned yet? Is this really not going to get any love? browser control is incredibly important to fix. this is breaking shit guys
hattimon commentedon Aug 20, 2026
@adamczhang I managed to get Browser control working again today on Windows after installing the latest app update.
What fixed it for me:
OpenAI.Codex 26.814.5517.0.26.814.41957(browser@openai-bundledandchrome@openai-bundled).@Browserto openhttps://example.comand read the page title. After the update this returnedExample Domainfor me, so the previous Trusted RPC error was gone.For
@Chrome, there was one extra issue in my case: the ChatGPT Chrome extension was installed in other Chrome profiles, but not in the profile I was actually using. Checkchrome://version->Profile Path, then make sure the ChatGPT extension is installed/enabled in that exact profile. After installing it in the active profile and restarting Chrome + Codex,@Chromealso worked and could read the current tab title.Separate note for anyone who also gets login error
failed to start login server ... os error 10013: Codex login uses localhost ports1455and fallback1457. On my machine Windows had both inside an excluded range because the TCP dynamic port range had been changed to start at1024. I restored the normal dynamic range to49152-65535, shut down WSL, rebooted, and both ports became bindable again. This fixed login, not the Browser Trusted RPC bug itself.Commands I used for that port case (only if
netsh int ipv4 show dynamicport tcpshows an abnormal range starting at 1024):After reboot I verified
1455and1457could bind successfully.So in short: the new
26.814.5517.0Windows package fixed the Browser regression for me; Chrome additionally required the extension to be present in the active Chrome profile.rajakhoury commentedon Aug 20, 2026
@hattimon Thanks man. I can confirm the latest update fixed it for me.
HopeCollector commentedon Aug 20, 2026
The latest update resolved this issue for us as well. Both the built-in Browser and Chrome control are working again.
Environment:
26.814.5517.0(x64)26.814.4195726.814.4195725H2, x64, build10.0.26200.9168Verification:
https://example.com/, and reads the page title (Example Domain).danila18-hub commentedon Aug 20, 2026
Update: the issue is resolved for us after installing the latest update.
26.818.21641The Browser runtime now initializes successfully, and the previous
Trusted RPC dependency must resolve within a configured trusted code patherror no longer appears.