Affected browser targets: Chrome, Microsoft Edge, external browser extension, and automatic browser selection
Date observed: 2026-08-18
Summary
The Browser plugin cannot initialize because a shared RPC dependency is rejected by the trusted-code-path validation. The failure occurs before a browser can be selected or controlled, so switching from Chrome to Edge or another external browser does not help.
Exact error
Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/Administrator/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
Steps to reproduce
Start the Codex desktop app on Windows.
Enable/install the bundled Browser plugin and a browser integration.
Ask Codex to open a URL or connect specifically to Chrome, Edge, or an external browser extension.
Browser runtime initialization fails before browser discovery.
Expected behavior
The bundled browser-client.mjs should be able to load its bundled browser-service.mjs dependency from the same signed/trusted Browser plugin package, after which Codex should discover and control the selected browser.
Actual behavior
The shared browser-service.mjs dependency is rejected as being outside the configured trusted code path. The same error occurs for automatic selection, Chrome, Edge, and an external browser extension.
Troubleshooting already attempted
Restarted Codex.
Reinstalled the browser integration.
Tried Chrome, Microsoft Edge, and an external browser extension.
Reset the browser-control runtime between attempts.
Verified that the failure occurs before browser selection or authentication.
Impact
All browser automation is blocked, including creating and publishing a LinkedIn article. This is not an authentication failure on the target website.
Request
Please verify the trusted RPC path configuration and packaging relationship between the bundled Browser client and browser-service.mjs on Windows. It appears that a bundled dependency is not included in the runtime’s trusted path allowlist, or the desktop app and bundled plugin manifests are out of sync.
I can provide additional logs or version information if needed.
I’m seeing the same issue on Windows and can independently reproduce it.
My environment:
Codex desktop package: 26.814.5167.0
Browser plugin/runtime: 26.814.41407
Windows
Exact error:
Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users/gmorelli/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
A few additional observations from my logs:
The built-in browser backend starts successfully.
The native pipe is created successfully.
browser-service.mjs and browser-client.mjs both exist at the expected paths.
The Chrome native messaging manifest exists.
The Chrome NativeMessagingHosts registry key exists.
extension-host.exe is running.
I do not see MODULE_NOT_FOUND, EACCES, EPERM, or missing-file errors.
The failure occurs during trusted-RPC dependency validation after the browser backend has started.
I have also already tried a full Windows app reset, and the issue persists.
This affects both the built-in Browser and Chrome control for me, so it does not appear to be limited to the Chrome extension/native-host setup.
Happy to provide the relevant log lines or additional diagnostics if useful.
It affects all browser integrations using the shared browser service: the in-app browser, Chrome, and Edge. The failure occurs during initialization, before browser discovery or backend selection.
Trusted RPC dependency must resolve within a configured trusted code path: file:///C:/Users//.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
The referenced file physically exists below the configured trusted root C:\Users.codex. There are no symlinks, junctions, or reparse points in the path, and the file permissions are valid.
I have already tried:
Windows Repair
complete uninstall and reinstall
regenerating the entire cua_node runtime
regenerating the browser plugin cache
verifying Node.js and npm
checking both browser JavaScript bundles with node --check
The regenerated runtime and browser-plugin files were byte-for-byte identical, and the error remained.
This appears to be a Windows path-canonicalization or trusted-root containment regression, or a version mismatch between the desktop app, cua_node runtime, and bundled browser service. It does not appear to be caused by a browser extension, missing dependencies, permissions, or a corrupted cache.
I can independently reproduce the same issue on Windows. The exact Trusted RPC error occurs before browser discovery for the built-in Browser, Chrome, and Edge. I have already restarted the PC, reinstalled ChatGPT, removed ChatGPT Classic, repaired and reset the Windows app, and recreated the browser plugin cache. The issue persists.
Codex version: 26.814.5167.0
Operating system: Windows
Affected feature: Computer Use / Chrome browser control
Error:
Trusted RPC dependency must resolve within a configured trusted code path:
file:///C:/Users/balazs/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs
The Codex application and Chrome Computer Use connection have both been removed and reinstalled, but the error persists. Browser control fails before any Chrome tab can be accessed.
You are welcome to discuss Codex issues here. However, the official place to report and track them is the OpenAI Codex GitHub issue tracker.
I asked ChatGPT to look for the closest related issue, and it identified:
The issue was opened about a day ago. The workaround suggested in the community replies is to downgrade to an earlier version.
Affected users report that downgrading the Windows desktop app from 26.814.5167.0 to 26.810.7004.0, then clearing the cached Browser and Chrome plugin folders, restores browser control:
The OP has since closed the issue. I wish it had been left open, as there does not appear to be an official fix yet.
If that issue matches your problem, consider adding a reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.
If it does not describe the same problem, search the existing Codex issues for a closer match. If you cannot find one, open a new issue and include as much relevant detail as possible.
Conclusion: This is more likely a browser-bridge regression introduced by a Codex update, rather than an issue with your Chrome configuration or corrupted local data. My confidence in this assessment is about 85%.
More precisely, it is likely a compatibility issue introduced by the update that only affects certain Windows environments. At this point, there is not enough evidence to conclude that all users are affected.
The supporting evidence is:
Chrome, the extension, and Native Messaging registration are all working normally.
The error occurs during Codex’s trusted-path validation stage, before Chrome tab discovery even begins.
The file triggering the error is indeed located inside a configured trusted directory. Running the same validation algorithm with Codex’s bundled Node runtime also returns trusted: true.
The trusted-service configuration related to the failure was automatically generated by the newer Codex version, rather than being leftover configuration created manually. The older configuration backup did not contain this additional mechanism.
Restarting, reinstalling the Browser extension, and using Windows “Repair” on Codex did not change the error at all.
The official public documentation currently does not list this specific error as a known issue, so we cannot conclude that it affects every user.
So the final assessment is:
The root cause is most likely a runtime defect in the newer Codex browser-control module. Your local environment may be a trigger condition, but it does not appear to be the source of corruption.
At this point, I would not recommend continuing to wipe .codex, delete Chrome profiles, or reinstall Chrome. The expected benefit is very low, and those actions could unnecessarily disrupt other local data.
The more reasonable approach is to keep the current environment unchanged and wait for a Codex update. Even if the issue only affects a subset of Windows users, it would still require a fix at the Codex runtime level.
I found two possible causes of browser-control failures in the Codex Windows desktop app.
Version regression
ChatGPT-x64-26.810.7004.0 works correctly on my system. After upgrading to a newer release, Codex browser navigation/control stopped working.
Imported project/thread permissions
Importing or attaching projects and conversations from another or older Codex installation may preserve incompatible NTFS ACL entries. The problem disappeared after I repaired the imported folder’s NTFS permissions before importing it again.
Environment:
Windows
Last known working version: ChatGPT-x64-26.810.7004.0
Affected feature: Codex in-app browser / browser control
Suggested investigation:
Compare browser sandbox behavior between 26.810.7004.0 and later builds.
Validate and normalize NTFS permissions when importing or attaching an existing project.
Detect inherited or stale security identities and show a clear repair message instead of silently blocking browser access.
Security note:
I temporarily used broader permissions while diagnosing the problem, but granting “Everyone” access or disabling sandbox isolation should not be the recommended permanent workaround. The application should repair the folder using the minimum permissions required for the current user and Codex sandbox.
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.