Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path
Resolved 💬 82 comments Opened Aug 18, 2026 by Double-hhd Closed Aug 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
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_
82 Comments
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:
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.
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
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.
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).
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?
Feedback ID - 01a0139f-3bae-7732-95da-99c84f988703
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.
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.
@zemeng5208 Thanks for the suggestion. I downloaded and tried WinBridge Recovery, but the repair could not be completed successfully. The original error still persists, and the Browser/Chrome plugins remain unusable. This may indicate that the issue is upstream rather than recoverable local cache or trust-state drift.
Codex Chrome/browser bridge fails with trusted RPC and native-host errors
This appears to be the same issue.
Environment
26.814.41407Profile 3hehggadaopoacecdllhhajmbjkdcmajg1.2.27259.19709_0Problem
The Codex in-app browser can open and display web pages, and Chrome synchronization/chats appear normally. However, Codex cannot initialize the Chrome browser-control session, so it cannot list or interact with my existing Chrome tabs.
When Codex tries to initialize the Chrome bridge, it fails immediately with:
Diagnostics
The Chrome extension is installed and enabled:
However, the native-host diagnostic reports:
The native-host manifest file exists at:
The manifest contains the expected extension origins and native host:
But the corresponding Windows registry registration is missing.
Troubleshooting already attempted
The issue is therefore not caused by the Chrome extension being disabled or absent. Reinstalling the extension alone does not restore the missing native-host registration.
Expected behavior
Codex should initialize the browser-control bridge successfully and allow me to list and interact with tabs in my existing Chrome profile.
Actual behavior
The browser UI may work, but the Chrome automation bridge fails before a controllable browser session is created. As a result, Codex cannot see or report my open Chrome tabs.
Impact
I cannot use my existing Chrome profile, signed-in sessions, open tabs, or Chrome extensions through Codex. The built-in browser works only as a separate browser and cannot access my existing Chrome tabs.
Confirming the same issue on Windows x64.
This regression blocks browser automation required for my daily work.
Independent macOS reproduction with an additional root-cause signal.
Environment
26.814.414070.148.0-alpha.1526.814.41407Both Browser and Chrome fail before browser discovery with the same error:
Chrome, the ChatGPT extension, and the native-host manifest all pass their bundled diagnostics. No page, tab, cookie, or other browser data is reached.
Parent/worker environment difference
The parent
node_replprocess receives the expected non-secret configuration:However, after it spawns
trusted-worker.js, inspecting only those same variables shows that the worker'sNODE_REPL_TRUSTED_CODE_PATHShas been replaced with the task-scoped read-only.env/.env.localpaths plus the bundledcua_node/lib/node_modulespath.$HOME/.codexis absent, whileNODE_REPL_TRUSTED_SERVICES.browserstill points into$HOME/.codex/plugins/cache/....The active filesystem profile has
:root = writewith exact read-only.envand.env.localexceptions. This suggests the 0.148 trusted-worker construction derives trusted code roots from read-only filesystem entries and drops the writable$HOME/.codexroot. Desktop still registers its official Browser service from that dropped user-cache root, so validation must fail before browser discovery.Controlled validation
As a bounded local test, I added only this stable Browser cache root as a read-only filesystem entry:
A clean isolated
node_replsetup using that read-only root changed the result from the trusted-path error tosetup-ok. The Browser and Chrome copies ofbrowser-service.mjsare byte-identical. This was a diagnostic workaround, not a recommendation to weaken or manually bypass the trust check.This machine previously completed Chrome control successfully with the bundled 0.147 runtime, so the behavior is a regression.
A durable upstream fix could place the official service under an app-owned read-only root, or atomically register its exact installed root as read-only/trusted when the bundled plugin is installed. An integration test using a
:root = writeprofile with narrow read-only exceptions should reproduce this failure.Confirming the same issue on Windows x64.
Environment:
26.814.414071.2.27259.19709Exact error:
Reinstalling/re-enabling the extension and restarting Codex, the browser, and Windows did not resolve it. The error occurs before the browser-control session is created, while ordinary pages and the local web application at
http://127.0.0.1:8000/remain accessible.Subject: Codex Desktop on Windows fails to initialize Browser/Chrome control before backend selection with a trusted RPC error
On Windows Codex Desktop, the official Browser/Chrome integration fails before any Chrome profile, extension backend, or tab is selected. The error is:
Steps to reproduce:
browser-clientis initializing, before browser backends are enumerated.Expected result: Browser/Chrome backends can be enumerated and an existing Chrome tab can be selected.
Actual result: Initialization stops before backend enumeration.
Observed environment:
OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g026.814.41407Checks already completed:
browser-service.mjsexists and is readable; it is not a reparse point and has no alternate data stream beyond the default data stream.NativeMessagingHosts\\com.openai.codexextensionregistry registration is absent. The bundled Windows installer code explicitly creates that exact HKCU key.I found a public user report with the same error in
openai/codex #39136:https://github.com/openai/codex/issues/39136
Could you confirm whether this is a known issue involving trusted-code-path registration, path normalization, or runtime-context injection, and provide a safe official recovery procedure?
Thanks, but that doesn't solve my problem. The following are identical:
The following are not confirmed:
Important difference: In the screenshot, the browser session fails already during initialization. In our case, initialization, Edge detection, and window activation worked; the failure occurred only during the URL security check.
Conclusion: strong indication of a known bug in the same Codex version, but no definitive confirmation of the cause for our case yet. Furthermore, this report points to a path on C:—therefore, it does not confirm that D: is necessarily the trigger.
The switch from C: to D: is currently the most likely trigger. The internal cause—Trusted RPC, path validation, or a downstream URL security check—has not yet been conclusively confirmed.
Пидорасы.
Confirming this issue. Please enable app rollbacks. This has hampered all work for me.
А кто возместит потери? Я платил за использование, а не за ожидание устранения неисправностей. Альтман, ты на счётчике.
go bottom left in codex/chatgpt -> settings -> general -> permissions -> full access enabled
@nicholasinapexschulz-png Thanks for the suggestion. After enabling Full Access under Settings → General → Permissions, the browser works normally. I appreciate the workaround, but I still hope the official team can fix the underlying issue, since requiring Full Access is not consistent with normal day-to-day usage.
already enabled.
Trusted RPC dependency must resolve within a configured trusted code path: …/browser-service.mjs
The in-app Browser is still inaccessible in this Codex build. Public web search remains available. Chrome is also inaccessible.
Didn't help. Same reaction as in the previous comment. But didn't test the Chrome plugin, only in-app browser.
Additional reproduction and isolation details
I can reproduce this consistently on Windows after reinstalling both the ChatGPT Chrome extension and the Codex Chrome plugin, restarting Chrome and Codex multiple times, and testing in new Codex tasks.
Environment
10.0.26200)26.814.5167.026.814.41407Observed behavior
A normal Codex task fails before creating a Chrome browser session with:
Same issue! any solution or something that i can do to get the browser working again?
We encountered the same issue on Windows with the following setup:
26.814.5167.026.814.414071.2.27259.19709The error was:
A temporary workaround worked for us:
After doing this, the browser bridge initialized successfully, the extension session connected, and Codex could read the open browser tabs. The
Trusted RPC dependencyerror no longer appeared in our local test.This looks like a useful temporary workaround, not a confirmed fix. Full Access grants broader permissions, so it should be used with appropriate caution until the trusted-code-path/browser plugin issue is fixed upstream.
Reproduced on Windows with Codex MSIX 26.814.5167.0 and browser plugin 26.814.41407. Restarting Codex and reinstalling the Chrome extension do not help; both in-app Browser and Chrome fail before backend selection.
Additional diagnostics: package/source/cache copies of
browser-client.mjsandbrowser-service.mjsare byte-identical and Authenticode-valid.NODE_REPL_TRUSTED_SERVICESpoints to the existing service, andNODE_REPL_TRUSTED_CODE_PATHScontains the.codexroot. The bundled Node runtime resolves the service beneath that root, yet the trusted worker still rejects it.A narrow local test duplicating the same trusted path into
shell_environment_policy.setwas automatically removed on restart and did not change the failure. Also suspicious: configured browser-client allowlist SHA-256 starts with8e172ec9…, while the signed shippedbrowser-client.mjshashes to3B9D8DCC….This points to a trust-metadata/environment-forwarding regression in this packaged build rather than a missing/corrupt file or Chrome-extension problem.
Confirming the same issue on macOS with a controlled before-and-after permissions test. Switching the task to Full Access immediately restored Chrome control.
Environment
25A354), arm6426.814.41407(build6720)26.814.4140726.814.41407151.0.7922.1381.2.27259.19709_0Profile 1Failure under default permissions
With the task running under the default sandbox:
Chrome initialization failed before browser discovery or access to any tab:
I verified that:
browser-service.mjsexisted at the rejected path.The screenshot below shows the user-facing failure under the default permissions profile:
<img width="887" height="341" alt="Chrome control failing under the default permissions profile" src="https://github.com/user-attachments/assets/bfd8c574-cd18-45de-aeb0-cd4b3ab094d4" />
Successful test under Full Access
I then switched the same task to Full Access:
Without changing the desktop app, plugin versions, Chrome profile, or extension installation, the Chrome integration initialized successfully.
Codex was then able to:
The screenshot below shows the successful read-only test after enabling Full Access:
<img width="851" height="501" alt="Chrome control succeeding after enabling Full Access" src="https://github.com/user-attachments/assets/38dbd6fd-cbab-4654-9eb4-29f3486946d0" />
Conclusion
This confirms that the issue also affects macOS and strongly suggests a regression in sandbox/trusted-service path handling or trusted configuration propagation.
The Chrome extension and native-host connection are functional. Full Access is a temporary workaround, but it is not an acceptable permanent requirement because it removes the normal filesystem and network sandbox boundaries.
Expected behavior: Browser and Chrome control should initialize successfully under the default
workspace-writepermissions profile.Confirming another independent reproduction of this issue.
Both the in-app Browser and Chrome control paths fail before browser discovery with the same trusted RPC path error reported above.
The following troubleshooting did not resolve it:
The error remains unchanged after reinstalling the Chrome plugin. This indicates that the failure occurs during bundled trusted-path initialization, before the Chrome extension or tab connection is reached.
Confirming an independent reproduction on Windows x64 from a
D:workspace.Environment:
OpenAI.Codex_26.814.5167.0_x64browser@openai-bundled 26.814.41407chrome@openai-bundled 26.814.41407Exact failure, before browser discovery or tab access:
Recovery attempted without success:
%USERPROFILE%/.codex/plugins/cache/openai-bundledand reopened Codex so the bundled cache was rebuilt.The rebuilt cache contains the expected service file, but trusted-path validation still rejects it. No browser session is created and no webpage is accessed. This supports the existing reports that the failure is in Desktop trusted-runtime registration/propagation rather than browser authentication or the Chrome extension handshake.
I have the same issue with both the internal browser and the Chrome extension on Windows ARM64.
Same issue on windows stable version 26.814.41407
Confirming an exact independent reproduction of this issue.
Feedback ID:
Environment:
10.0.26200.9168OpenAI.Codex 26.814.5167.0browser@openai-bundled 26.814.41407chrome@openai-bundled 26.814.41407151.0.7922.1381.2.27259.19709Profile 1Both
@Browserand@Chromefail before browser discovery or tab enumeration with the same error:The Chrome extension is installed and enabled, its side panel opens normally, and the Native Messaging Host registry entry, manifest, and host executable are present.
Troubleshooting already completed without resolving the issue:
The uploaded diagnostic logs are associated with the Feedback ID above.
I can reproduce this consistently on Windows as well.
Environment:
OpenAI.Codex_26.814.5167.0_x6426.814.41407The in-app browser can open and render pages, but Browser automation (both built in & chrome) initialization fails with the same error:
Confirming the same regression on Windows x64.
OpenAI Feedback ID:
01a01508-09d6-7551-b14e-cd8ebe79b530
I can independently reproduce the same failure on Windows.
Additional environment detail:
26.814.5167.026.814.41407Exact error:
Additional diagnostics:
the network connection.
projectless Codex chat, before Browser attaches to any tab.
already open; failure occurs before any form field can be accessed.
effective
NODE_REPL_TRUSTED_CODE_PATHScontains only the bundled CUA Noderuntime
node_modulesdirectory. The bundled Browser pluginscriptsdirectory is absent.
.codexroot.A temporary experiment with the exact Browser
scriptspath was filteredbefore helper startup as well. The experiment was fully reverted.
This appears to be a desktop security-wrapper or packaging/version mismatch:
the OpenAI-bundled Browser service is rejected before browser selection or page
interaction.
Expected behavior: the bundled Browser service should be included in the
trusted paths passed to its helper so Browser can attach to the in-app tab.
No credentials, cookies, authenticated URLs, page contents, or customer data
are included here. No website write occurred during diagnosis.
Confirming an independent reproduction on Windows x64 with the same stable version pairing.
Environment
OpenAI.Codex 26.814.5167.0browser@openai-bundled 26.814.41407chrome@openai-bundled 26.814.414071.2.27259.19709_0Observed behavior
The in-app browser UI opens and renders
https://example.com/, but both explicit browser-control routes abort before discovery or tab access:Both return:
Connector checks
The Chrome connector installation itself appears intact:
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.jsonexists.HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextensionexists and points to that manifest.Recovery attempts — no change
This blocks routine web-app QA and forces fallback to less efficient screen-level Computer Use. No trusted-path bypass or security-setting reduction was attempted.
Problem confirmed in Version 26.814.41407 - Released Aug 17, 2026.
Switched session to full access as a temporary workaround but inapproriate.
<img width="231" height="67" alt="Image" src="https://github.com/user-attachments/assets/cb3a3161-ff58-4189-9abe-3c4f161681c7" />
Please provide a way to roll back the update ! Entire day washed out, really can;'t afford this.
Confirming an independent reproduction on Windows 10.
26.814.5167.026.814.41407Both
@Browserand@Chromefail before browser discovery or the Chrome handshake with the same trusted-RPC error referencing the bundledbrowser-service.mjs.The Chrome extension is installed and enabled, its side panel loads, and the Native Messaging Host registration is present. Fully restarting Codex and Chrome and reinstalling the Chrome plugin/extension did not resolve the failure. Screen-level Computer Use still works, but direct Chrome/Browser control remains unavailable.
This blocks routine WordPress administration and frontend QA that depends on direct signed-in Chrome control. No local trust or security settings were weakened during diagnosis.
I rolled back to 26.810.7004.0 and can continue working. It works.
Same on 26.814.5167.0
If I may ask: How did you roll back the update? I don't see an option to do that.
I can independently reproduce the same failure on Windows.
Environment:
26.814.5167.026.814.41407Exact error:
The failure persists after restarting the Browser helpers, restarting the desktop application, reinstalling Codex, and verifying the network connection.
It also reproduces in a newly created projectless chat before Browser attaches to any tab. The same behavior occurs with a blank GitHub issue form open after authentication; the failure happens before any form field can be accessed.
Read-only diagnostics show that the Browser helper's effective
NODE_REPL_TRUSTED_CODE_PATHScontains only the bundled CUA Node runtimenode_modulesdirectory. The bundled Browser pluginscriptsdirectory is absent.The local Codex configuration already contains the broader
.codexroot. A temporary experiment with the exact Browserscriptspath was filtered before helper startup and was fully reverted.This appears to be a desktop security-wrapper or packaging/version mismatch. The bundled Browser service is rejected before browser selection or page interaction.
Expected behavior: the Browser plugin
scriptsdirectory should be included in the trusted paths passed to the helper so the Browser service can initialize and attach to the in-app tab.No credentials, cookies, authenticated URLs, page contents, or customer data were included. No website write occurred during diagnosis.
I can confirm this on Windows 25H2 (build 26200.9168) with Browser plugin / Codex app version 26.814.41407.
The in-app browser panel opens and renders pages correctly, and the browser URL is visible to the agent, but control fails during
setupBrowserRuntime()beforeagent.browsers.get("iab")is reached.Exact error:
I reproduced it after resetting the browser-control JavaScript kernel and starting again from a clean session. The bundled
browser-client.mjsandbrowser-service.mjsfiles are present in that directory.Is there a supported interim mitigation for Windows users, or is this fixed by an upcoming app/plugin release? I’d prefer not to switch the whole task to Full access just to restore in-app browser control.
Confirming another independent reproduction on Windows x64. This was working before the current desktop update and now blocks authenticated browser workflows.
Environment
OpenAI.Codex 26.814.5167.00.148.0-alpha.15browser@openai-bundled 26.814.41407C:(the project path contains Cyrillic characters)Failure
The in-app browser itself opens and can render an already signed-in web application, but Browser control fails before DOM/tab access with:
The error is identical in a fresh runtime after a full application restart.
Checks completed
browser-service.mjsexists and is not a symlink/reparse point.%USERPROFILE%\.codexinNODE_REPL_TRUSTED_CODE_PATHS.NODE_REPL_TRUSTED_SERVICESpoints to the exact installedbrowser-service.mjs.codex doctorreports the installation consistent, config loaded, authentication/network checks OK, and no newer runtime version available.Impact
This prevents Codex from operating authenticated web interfaces and interrupted a production workflow that needed to create and send several reviewed email drafts. The failure occurs before any website interaction, so it is not site-specific.
Could the maintainers confirm whether this is a packaging/trust-metadata regression in
26.814.5167.0, and whether there is a supported interim workaround or a fixed build planned?same on 26.814.41407
Workaround confirmed on Windows x64
I managed to get the in-app Browser working again by downgrading the desktop app.
Broken version:
26.814.5167.0Working version:
26.810.7004.0I did not reinstall the app through the Microsoft Store. I downloaded the official Store-signed x64 MSIX directly from OpenAI’s CDN and installed it manually:
https://learn.chatgpt.com/docs/enterprise/windows-deployment
Steps:
26.814.5167.0to26.810.7004.0.26.814Browser components.The Browser is now working normally. I successfully tested it by opening Google and other external websites.
The app is already offering the newer version for download, but I am not going to update it for now. I will keep using
26.810.7004.0, the version included in the downloaded MSIX package, until this regression is confirmed as fixed.Important: at the time of writing, the URL above downloads
26.810.7004.0. It is a stable OpenAI download URL and is not permanently pinned to that specific version, so it may serve a newer build in the future.This is only a workaround, not a permanent fix.
Additional workspace-context A/B result
I observed a useful control case on the same Windows installation:
http://127.0.0.1:3000/en, and could read the page title/DOM and capture the rendered viewport.The target URL and installed Browser bundle were unchanged. Codex did not start the development server, install dependencies, or modify any project files during either test.
In this reproduction, Browser availability therefore appears to depend on the conversation's project/workspace context: a new projectless conversation can use Browser, while a new project-folder conversation cannot. This may help isolate the trusted-path configuration or propagation difference between those task types.
亲测有用！！！强烈推荐
Adding another independent Windows reproduction from a trusted project on the primary
C:drive.Environment:
26.814.5167.026.814.4140726.814.41407C:(so this reproduction is not limited to alternate-drive workspaces)Observed behavior:
This corroborates the current app/plugin version pairing and shows the same failure from a primary-drive workspace.
Adding a related Linux reproduction, although the failure mode differs from the Windows trusted-path error reported here.
Environment
26.814.41957chrome@openai-bundled 26.814.419571.2.27259.19709151.0.7922.13722Observed behavior
Tasks started from the Chrome extension can read the current page through
getTabContext, but receive no interactive controls (no click, DOM inspection, screenshot, navigation, or clipboard operations). They then report that the “Codex Chrome native host is out of date.”However, a Codex desktop task can connect to the same running Chrome instance through browser-client, enumerate and claim tabs, inspect the DOM, and click controls successfully. I verified this on the same Mage.Space tab by opening the newest generation, clicking Copy Prompt, and closing the detail panel.
The native-messaging manifest points to an existing executable host; it is executable, matches the app-bundled copy by hash, and the extension/host protocol versions agree. Multiple browser manifests found locally were identical registrations rather than stale competing installations.
This therefore appears to be asymmetric session capability provisioning/routing for Chrome-extension-started tasks, plus a misleading generic “native host is out of date” message—not a missing or genuinely outdated native host. Restarting Chrome did not change it.
This may be related to the broader browser regression here, but it is not the exact Windows trusted-RPC failure because desktop-initiated Chrome control remains fully functional.
worked! thank you
Independent Windows reproduction — Browser/Chrome regression also breaks scheduled analytics workflows
Confirming an independent reproduction after the current Codex Desktop update.
Environment
2620026.814.5167.026.814.41407Both the built-in Browser and external Chrome control are affected.
The page itself can open and render, but Codex fails before browser discovery / tab enumeration with:
Trusted RPC dependency must resolve within a configured trusted code pathfor the bundled
browser-service.mjs.Restarting Codex, switching Codex/ChatGPT modes, and targeted trust-state/hash checks did not resolve the failure. No page data was collected and no website state was changed during these attempts.
Workflow impact
One additional point that may be useful for assessing severity: this regression affects more than interactive browser control.
I use Browser / Computer Use as a read-only acquisition layer for authenticated web applications where public web search, direct HTTP access, or APIs are insufficient.
Several workflows depend on it to:
When Browser control fails globally after an update, these acquisition workflows stop simultaneously. This also creates gaps in historical time-series data that may not be reconstructable later.
Temporary fallback layers are public Web access, APIs where available, external scraping tools, and manual data transfer, but none fully replaces authenticated Browser / Computer Use.
Workaround status
I have seen reports in this issue that switching a task to Full Access restores Browser/Chrome control for some users. Other users report that the same Trusted RPC error remains even with Full Access enabled.
Because Full Access broadens the normal sandbox permissions, I would treat it as a temporary diagnostic/community workaround, not a normal permanent solution.
I have not seen a confirmed upstream fix yet.
Expected behavior: the official Browser and Chrome integrations should initialize under the normal task permission profile and allow read-only access to authorized pages without requiring Full Access.
Happy to provide additional sanitized diagnostics if maintainers need a specific trace or configuration comparison.
I can reproduce this issue on Windows with Codex App
26.814.41407, and I was able to narrow the failure down further.The problem does not appear to be in Chrome, the extension,
config.toml, or Windows path parsing.The trusted root is configured correctly and reaches
node_repl.execorrectly, but it is removed whennode_repl.exeprepares the environment for the trusted sandbox/worker.Environment seen by
node_repl.exe:Environment seen by the child sandbox launcher and final trusted Node worker:
So this trusted root is removed before the trusted worker is spawned:
The process chain is:
The last confirmed correct point is the environment of
node_repl.exe.The first confirmed incorrect point is the environment of
codex.exe sandbox.The installed
node_repl.execontains references to:There are also debug references around:
This strongly suggests that the environment is being filtered or rebuilt inside the native trusted-process supervisor.
trusted-worker.jsitself appears to behave correctly. It reads the already incomplete environment value:The rejected file is:
The resulting error is:
When
%USERPROFILE%\.codexis included in the trusted roots, the same path-validation algorithm accepts this file successfully.I also confirmed that:
26.814.41407);browser-service.mjsis byte-identical to the copy shipped in the currently installed package;config.tomlis read correctly;NODE_REPL_TRUSTED_CODE_PATHSis initially formed correctly;;path separation works correctly;node.exe;trusted-worker.jsis not dropping%USERPROFILE%\.codex— it never receives it;So the most likely failure boundary is:
At that boundary,
NODE_REPL_TRUSTED_CODE_PATHSis effectively reduced from:to:
This causes the browser service under:
to fail the trusted-path check even though it was included in the original trusted roots.
I did not modify the binaries, configuration, trusted paths, registry, Chrome extension, or browser state while diagnosing this.
Strongly confirming and supporting @rafapapa’s workaround: https://github.com/openai/codex/issues/39136#issuecomment-5331274519
If you are affected, download and save the official x64 installer right now, before the rolling download is replaced with a newer build:
https://learn.chatgpt.com/docs/enterprise/windows-deployment
The working downgrade is
26.810.7004.0; the regression is present in26.814.5167.0with the26.814.41407Browser/Chrome components. After downgrading, clear these cached plugin folders so Codex does not keep loading the broken components:Then restart on the downgraded build. Once it is working, do not close Codex unnecessarily and do not accept the offered update until OpenAI confirms that this regression is fixed. The deployment URL is rolling and is not permanently pinned to
26.810.7004.0, so preserving the installer now is important.This workaround has multiple successful confirmations in this thread.
EDIT: Sorry, I somehow didn't see the workaround of @rafapapa, but maybe the powershell commands in my comment will make it a bit easier for some.
Workaround: downgrade the Windows app
This is only a temporary workaround and certainly not the best or a sustainable solution, but others may want to try it.
I downgraded the Windows app from
26.814.41407to26.810.7004.0using OpenAI’s official Store-signed MSIX:Verify the installed version:
This successfully installed
OpenAI.Codex 26.810.7004.0on my system. Automatic app/Store updates may need to be disabled temporarily; otherwise Windows could immediately reinstall the latest version.Again, this does not fix the underlying trusted-path problem and older versions may contain unresolved security issues. It is only intended as a troubleshooting workaround until an official fix is available.
Confirming that the downgrade workaround also worked on another affected Windows x64 installation, with one additional observation about trust metadata regeneration.
Before
26.814.5167.026.814.41407Trusted RPC dependency must resolve within a configured trusted code pathfor%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-service.mjsProcedure
26.810.7004.0.%USERPROFILE%\.codex\plugins\cache\openai-bundled\.Result
26.810.52044.NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256Sas:8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701https://example.com/(Example Domain).This independently supports the diagnosis that the
26.814.5167.0update left the Browser plugin and trusted-RPC configuration inconsistent. Downgrading and resetting the plugin caches restored a coherent Browser/trust configuration automatically.Independent Windows reproduction confirming a complete browser-control regression after the 26.814.41407 rollout.
Environment
Observed
Trusted RPC dependency must resolve within a configured trusted code path: .../browser/26.814.41407/scripts/browser-service.mjsLocal forensic finding
8E172EC9F458F2E636FC69A1B8C68C217F6BB8D10C41F70A05A0878B738637013B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87Impact
All Browser/Chrome automation paths are unavailable in existing signed-in sessions, while read-only tab context and unrelated Windows Computer Use remain functional. This is a full regression from the previous bundled client version.
No credentials, cookies, browser contents, or private paths are included.
Confirmed working workaround on Windows.
The previously suggested downgrade method using:
https://persistent.oaistatic.com/codex-app-prod/ChatGPT-x64.msixno longer works for downgrading, because that URL currently returns the latest package (
26.814.5167.0), not26.810.7004.0.I was able to successfully restore the built-in Browser by downloading the version-pinned package instead:
I verified the MSIX manifest before installing and confirmed:
Then downgraded with:
Verified:
Result:
Before starting the app again, I also removed the cached bundled Browser/Chrome plugins:
After rebooting Windows and starting Codex again, the built-in Browser automation works normally. I tested actual browser control (opening Yandex and entering text), not just page rendering.
For reference, before the downgrade I was on
26.814.5167.0and Browser control was still broken.So the important difference from the earlier workaround is using the version-specific
/releases/26.810.7004.0/URL, because the non-versioned MSIX URL now serves the newer affected build.Root cause: browser plugin trust failure — supervisor rebuilds
NODE_REPL_TRUSTED_CODE_PATHSfrom module dirs only, droppingCODEX_HOMEConfirming this issue on the same build (adding one more affected user), and posting a root-cause trace in case it saves triage time. I found the mechanism and confirmed it experimentally — including a workaround that fixes it locally.
Environment
| | |
|---|---|
| Codex Desktop |
26.814.5167.0(MSIX) || codex-cli |
0.148.0-alpha.15|| browser / chrome plugin |
26.814.41407|| Node runtime |
cua_nodebuild2fb562745e6d66f0, nodev24.19.0|| OS | Windows 11 Enterprise
10.0.26200x64 |First: the
SHA256Shash mismatch in this thread is a red herringSeveral comments here point at
NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S = 8e172ec9…not matching the installedbrowser-client.mjs(3b9d8dcc…). I see that mismatch too, but it is not what produces this error:registerHooks({resolve})hook intrusted-worker.jsthat does pure path-containment checking. No hash is computed or compared anywhere on that path.node_repl.execontains noNODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256Sstring at all, and in the generated config that variable sits under[shell_environment_policy.set]— which governs shell-command environments, not thenode_replMCP server env. It never reaches the runtime.So the stale hash is real but inert. Chasing it will not fix this. Also relevant: #39160 (fails in a
D:workspace, succeeds inC:) is consistent with path-containment logic, not integrity checking —path.relativeacross drives returns an absolute path, which fails the same test.Root cause
The Electron shell and the Rust
node_replsupervisor use two different trust models, and the supervisor silently discards the shell's.1. The shell grants trust via
CODEX_HOMEGenerator in
app.asar(deobfuscated, names mine):This is self-consistent: the service lives under
CODEX_HOME, andCODEX_HOMEis placed inNODE_REPL_TRUSTED_CODE_PATHS. Written toconfig.toml, it looks correct:2. The supervisor overwrites that variable
node_repl.exedoes not pass its ownNODE_REPL_TRUSTED_CODE_PATHSto the trusted worker. It regenerates it fromNODE_REPL_NODE_MODULE_DIRSalone.Read directly from process memory (PEB) of a live trusted worker:
The child's value is exactly
canonicalize(NODE_REPL_NODE_MODULE_DIRS)— note the\\?\prefix, absent from the shell-written value.CODEX_HOMEis dropped.This also explains @HopeCollector's observation that the
NODE_REPL_TRUSTED_*values appear unavailable from the failing session: they are not missing from the environment, they are replaced by the supervisor with a narrower derived set before the worker starts.Supporting detail:
node_repl.execontains a contiguous string listNODE_REPL_TRUSTED_SERVICES/NODE_REPL_NODE_MODULE_DIRS/NODE_REPL_TRUSTED_CODE_PATHS/NODE_OPTIONS/NODE_PATH/LD_PRELOAD/LD_LIBRARY_PATH/DYLD_INSERT_LIBRARIES/BROWSER_USE_SECURITY_MODE, adjacent to trusted-process management strings — consistent with these being supervisor-controlled rather than inherited. (Interpretation; the process-memory observation above is the direct evidence.)3. The worker rejects the import
trusted-worker.js:resolveTrustedService()short-circuits for absolute paths, sobrowseris imported by absolute plugin-cache URL — which is outside the only surviving root.The
skyservice does not break, because it is declared as a bare specifier and resolves through the module dirs. That contrast is the clearest statement of the bug: one trust model per service, in the same config block.Confirmation
Adding the plugin's
scriptsdirectory toNODE_REPL_NODE_MODULE_DIRS— the variable the supervisor does honor — fixes it immediately:Chrome control then initializes and enumerates tabs normally, in both a fresh Desktop task and
codex exec. Reverting the line reproduces the failure.Editing
NODE_REPL_TRUSTED_CODE_PATHSinstead has no effect whatsoever, since the supervisor discards it — worth noting, as that is the variable the error message points you toward.Additional finding: the workaround is erased automatically
[mcp_servers.node_repl]inconfig.tomlis a generated block. A marketplace refresh regenerates it and reverts any edit. Observed:Anyone applying a config workaround should expect it to disappear without warning, which likely makes this look intermittent in user reports.
Suggested fixes
NODE_REPL_TRUSTED_CODE_PATHS(or union it with the derived module dirs), rather than discarding it; orscriptsdirectory inNODE_REPL_NODE_MODULE_DIRS; orbrowseras a bare specifier the wayskyalready is.A startup assertion that every path in
NODE_REPL_TRUSTED_SERVICESresolves inside the derived roots would turn this into an actionable error instead of a generic trust failure at import time.Same issue, with additional diagnostic detail:
NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\Ramon\.codex;C:\Users\Ramon\AppData\Local\OpenAI\Codex\runtimes\cua_node\2fb562745e6d66f0\bin\node_modules'
C:\Users\Ramon\.codex\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-service.mjs
This rules out local corruption. The validator appears to reject a path that is already listed as trusted — possibly a URI-format (file:///C:/...) vs. Windows-path-format (C:\...) mismatch in the prefix comparison used by the trusted-code-path check.
Browser control is a huge problem. No replys from Devs? We need help ASAP
Same issue on Windows11,
Additional reproducible case and managed-vs-standalone boundary evidence:
01a012c3-b60d-79b2-9acf-76baea06fb7aMicrosoft Windows NT 10.0.26220.026.814.5167.026.814.41407v24.19.0The managed Browser startup fails before returning an
iabbinding with:Additional boundary checks:
.codexdirectory.realpathSync.native()pluspath.relative()containment locally shows the service is beneath that trusted root.setupBrowserRuntime()successfully (isError=false, 415 ms).This supports the existing analysis that the failure is at the managed node_repl/trusted-worker environment propagation boundary, rather than a missing file or ordinary filesystem containment failure. The non-ASCII profile path may be relevant, but this case does not prove it is required.
No session transcript, full config, credentials, local username, or project data are included.
I can reproduce the same issue on Windows.
Codex Desktop version: 26.814.5167.0
Browser/Chrome plugin version: 26.814.41407
The built-in Browser and the Chrome extension control path both fail with the
same trusted RPC dependency error pointing to browser-service.mjs.
Reinstalling the plugin, regenerating the plugin/runtime cache, restarting
Windows, and testing with both a fresh and restored config.toml did not resolve it.
Additional Windows reproduction — app package 26.814.5167.0 / browser plugin 26.814.41407
I can reproduce the same failure on Windows.
Environment
26.814.5167.026.814.41407Observed behavior
Both the in-app Browser and Chrome initialization fail before tab discovery with:
The same failure occurs after retrying.
I changed the Codex UI permission setting to Full access, but the already-open task continued to receive:
This suggests that changing permissions may not update an existing task/session. I have not yet confirmed whether a completely new task after restarting Codex receives Full access and avoids the trust-path error.
Additional Chrome diagnostics
The Chrome and Edge extensions are both detected as installed and enabled. The native-host manifest exists, but the diagnostic reports that this registry entry is missing:
That registry issue may be separate from the in-app Browser trust-path failure, because the in-app Browser fails before any external-browser extension connection is selected.
No browser cookies, profile data, or private task contents were inspected.
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.
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.
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.
I have the same problem. When will it be fixed?
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.
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-9d4ba88e7d49Adding 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.
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.
Update: Installing the latest version worked for me.
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
@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.@hattimon Thanks man. I can confirm the latest update fixed it for me.
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).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.