Browser control fails: trusted RPC dependency outside configured trusted code path

I'm at a work stoppage and can not continue working until bug is fixed.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #39305
• #39302
• #39252
• #39212
• #39236

Powered by Codex Action

I can reproduce this exact defect on Windows.

Codex desktop: 26.814.5167.0
Bundled browser plugin: 26.814.41407
Platform: Microsoft Windows NT 10.0.22631.0 x64
OpenAI Support case: 13410185

The failure affects both in-app browser and Chrome control and reproduces in brand-new tasks:

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

This currently blocks browser-only OAuth/Clerk verification work.

I can reproduce this exact issue on Windows as well.

Environment:

• ChatGPT/Codex desktop package: OpenAI.Codex 26.814.5167.0 x64
• ChatGPT Plus
• Windows x64
• Built-in Browser present
• Computer Use installed and enabled
• Chrome integration also installed

Exact error:

Trusted RPC dependency must resolve within a configured trusted code path:
.../browser-service.mjs

Behavior:

• Built-in Codex Browser opens normally, but Codex cannot inspect or control it.
• Chrome control fails with the same trusted RPC/browser-service.mjs error before Chrome tab selection.
• The failure occurs before any website is accessed.
• It affects multiple Codex projects, including existing projects that were working earlier.

Troubleshooting already performed:

• Completely quit and restarted ChatGPT/Codex.
• Started fresh Codex chats.
• Windows Settings → Apps → ChatGPT → Reset.
• Confirmed Computer Use is enabled.
• Confirmed the built-in Browser pane exists and opens normally.
• Tested both built-in Browser and Chrome control.
• Checked installed Windows packages. Only OpenAI.Codex was found.
• Microsoft Store/winget reports the current package is already installed and that no newer version is available.

Important additional observation:
Browser control was working earlier on this same machine and then stopped working. The visible browser itself still functions; only the Codex control/runtime attachment fails.

This currently blocks browser-dependent production work for me in both HighLevel and Replit.

Happy to provide additional diagnostics or logs if useful.

yes, I’m experiencing the same issue as well. It seems like it might have been caused by the latest version? My case 01a01784-61ce-78c2-abfa-094223224177

Another affected Windows user can reproduce this consistently with the same version combination:

• ChatGPT/Codex desktop app: 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Platform: Windows x64
• Exact failure: Trusted RPC dependency must resolve within a configured trusted code path for the bundled browser-service.mjs
• Affects both the in-app Browser and browser control through the Edge/Chromium extension

Additional troubleshooting performed:

1. Fully restarted the desktop app and reproduced in a same-directory fork/new task.
2. Used Windows App Repair, then restarted; no change.
3. Moved the entire bundled Browser cache directory to a timestamped backup while the app was closed.
4. Confirmed the app recreated a fresh Browser cache directory on the next launch.
5. Retested browser runtime initialization; the same trusted-path error still occurs before any page interaction.

This rules out a stale per-thread runtime and a corrupted local Browser plugin cache for this installation. No browser profile, credentials, or page data were involved.

Restart-persistent workaround and root-cause evidence (Windows, Codex Desktop 26.814.5167.0)

I reproduced the failure across multiple app restarts and found a narrower cause:

• Adding NODE_REPL_TRUSTED_CODE_PATHS to the user-level ~/.codex/config.toml under [shell_environment_policy.set] fixes Browser/Chrome immediately after a node_repl reset.
• However, Codex Desktop regenerates the user-level config during app startup and drops that setting. The hash allowlist remains, but the trusted-code-path entry disappears.
• A repair process that successfully rewrote and strict-validated the user config after the previous Codex process exited still lost the line about 11 seconds later when the desktop app started. This rules out a shutdown-write race; the overwrite happens in the startup config serializer/generator.

A restart-persistent workaround is to put the setting in the trusted project's own .codex/config.toml, which is a separate config layer and is not rewritten by the desktop global-config generator:

#:schema https://developers.openai.com/codex/config-schema.json

[shell_environment_policy.set]
NODE_REPL_TRUSTED_CODE_PATHS = 'C:\Users\<USER>\.codex\plugins\cache\openai-bundled\browser;C:\Users\<USER>\.codex\plugins\cache\openai-bundled\chrome;C:\Users\<USER>\AppData\Local\OpenAI\Codex\runtimes\cua_node'

Using the parent plugin/runtime directories avoids pinning the workaround to a particular plugin/runtime version.

Verification:

• strict config load: PASS
• fresh task in the repaired project after desktop restart: in-app Browser bootstrap PASS
• https://example.com/: URL/title/h1/body readback PASS
• temporary tab explicitly closed; remaining test tabs: 0
• another repaired project: in-app Browser PASS; Chrome binding and documentation bootstrap PASS without trusted-path rejection
• full Chrome page test had previously passed with the same trusted-path value; on the latest run, new-tab creation separately reported Grouping is not supported by tabs in this window, so I am not counting that run as a page-level Chrome PASS
• the same validated project config was then deployed to seven existing saved local projects; all seven files had the same SHA-256 on readback

This is a workaround, not a product fix. The remaining product issue appears to be that the Desktop startup writer does not preserve user-supplied shell_environment_policy.set.NODE_REPL_TRUSTED_CODE_PATHS values.

Additional confirmed reproduction on Windows with the same builds and error.

Environment:

• Codex Desktop package: OpenAI.Codex_26.814.5167.0_x64
• Codex command runner: 0.148.0-alpha.15
• Bundled browser component: 26.814.41407
• Browser: Microsoft Edge

Exact primary error:

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

Regression observation: browser automation worked with bundled browser component 26.810.52044 on the preceding day, then failed after 26.814.41407 appeared locally. The error occurs before tab discovery or page interaction.

Troubleshooting completed without improvement:

• Fully restarted Codex Desktop multiple times
• Restarted Microsoft Edge multiple times
• Reconnected browser control/extension multiple times
• Reduced Edge to one tab
• Confirmed the correct signed-in Edge window was visible

Computer Use fallback also fails after detecting the Edge window:

Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.

This leaves both browser-control paths unavailable. No plugin files, trust configuration, browser profile, or security settings were manually modified.

Additional reproduction from #39400 with a physical non-system CODEX_HOME:

• Codex Desktop: 26.814.5167.0
• Browser bundle: 26.814.41407
• Windows 11 x64 (10.0.26200.0)
• CODEX_HOME=D:\CodexHome, a physical ASCII-only directory on D: (not a junction or symlink)
• User-level and process-level CODEX_HOME both resolve to that directory
• Generated NODE_REPL_TRUSTED_CODE_PATHS includes D:\CodexHome
• Generated NODE_REPL_TRUSTED_SERVICES maps browser to the bundled browser-service.mjs beneath that root
• After minimum diagnostic read/traverse permissions were temporarily applied, Node REPL lstat() and realpath() succeeded for the trusted root, Browser client, and Browser service
• Relevant Browser files/directories were restored to desktop-user ownership
• Node REPL was reset, Codex was fully restarted, and the same failure reproduced in a brand-new task

The runtime still rejected the service with:

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

This additionally rules out a Unicode profile path, junction canonicalization, simple file readability, and ownership as sufficient explanations. Temporary diagnostic sandbox ACL rules were rolled back afterward.

Closing #39400 as a duplicate so investigation can continue here.

Follow-up: the issue also reproduces with the in-app browser after the user successfully signed in and opened https://creator.xiaohongshu.com/new/home. The in-app browser UI had one active tab and rendered the signed-in page, but browser-control initialization still failed immediately with the same trusted RPC dependency error before the tab could be inspected. This confirms that a visible/authenticated in-app session does not bypass the runtime failure.

GitHub issue #39318 comment

Additional reproduction evidence for the same Windows Browser runtime defect:

• In-app feedback session ID: 019f6962-8ca0-78a2-ba07-ce5e6c6601ad
• Failing attempt timestamp: 2026-08-19T04:36:44.075000Z UTC / 2026-08-19T13:36:44.075000+09:00 Asia/Seoul (UTC+09:00)
• Codex Windows AppX: 26.814.5167.0
• Bundled Browser/Chrome plugin generation: 26.814.41407
• Result: the in-app Browser page surface can open and render, but the control runtime fails before Browser binding. The explicit Chrome route fails at the same trusted RPC validation layer before Chrome/Extension binding.
• No enabled Microsoft Defender state was returned; Windows Security Center reports 0 registered AV product(s).
• Endpoint security disable test: NOT PERFORMED. No AV or endpoint-security protection was disabled.

The user-accessible $CODEX_HOME/sessions / $CODEX_HOME/archived_sessions evidence was searched and minimally redacted. The session record retained the fail-closed outcome marker; the nested raw RPC line was not duplicated in the session transcript. The attached excerpt therefore includes that session outcome marker plus the exact redacted key error from the separately verified local diagnostic. Raw session files were not copied or modified.

Key error:

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

I initially opened #39407 before GitHub surfaced the duplicate candidates. I am closing #39407 as a duplicate of this issue and consolidating the additional evidence here.

OPENAI_CODEX_ISSUE_39318_REDACTED_SESSION_EVIDENCE_20260819.zip

I can reproduce the same failure on Windows in a local Codex task.

Error:

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

Impact: this prevents browser automation needed to update an authenticated web application (PROJECT DESK). The failure occurs before any website access or authentication interaction.

Troubleshooting completed:

• Windows Apps > Codex > Repair
• Codex desktop uninstall and reinstall
• Retried in a fresh Codex task
• Tried both the normal browser path and Chrome-specific path

Result: the same trusted-path error persists after every step. No browser profile, credentials, project data, or plugin files were manually modified.

Additional independent reproduction on Windows (2026-08-19).

Environment:

• Codex Desktop package: OpenAI.Codex_26.814.5167.0_x64
• Browser plugin: 26.814.41407
• Windows 10 Pro 25H2, build 26200.9168, x64
• Bundled CUA Node runtime: 24.19.0
• In-app Browser/Computer Use surface is present, but the browser-control bridge cannot initialize

Safe test performed:

1. Attempted the documented Browser runtime bootstrap in a fresh current Codex task.
2. Intended next steps were to open a neutral page and read its title.
3. Bootstrap failed before browser selection, tab discovery, navigation, or any page interaction.

Exact error (user path redacted):

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

Sanitized stack:

Error: Trusted RPC dependency must resolve within a configured trusted code path: .../browser-service.mjs
    at <node_repl-temp>\\kernel.js:1458:16
    at <node_repl-temp>\\worker-runtime.js:379:5
    at <node_repl-temp>\\kernel.js:1688:11

Observed impact:

• In-app Browser control is unavailable.
• No neutral URL could be opened by automation because initialization fails first.
• No cookies, browser profiles, credentials, page contents, or repository data were accessed or included.
• External Chrome/Edge page-level version could not be queried because the control bridge failed before browser handshake.

The visible Browser UI may still render pages manually; the failure is specifically the Codex-to-browser control runtime.

Additional independent reproduction of the same Windows Browser runtime failure:

• ChatGPT/Codex desktop app: 26.814.5167.0
• Bundled Browser/Chrome component: 26.814.41407
• Platform: Windows x64
• Chrome extension: installed and enabled
• Native-host manifest and HKCU registration: verified correct
• Chrome: running
• Affected paths: explicit in-app Browser (iab), automatic/default browser selection, and Chrome control
• Full application quit/reopen, including background processes: no change

Exact error (user path redacted):

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

Additional diagnostic detail: the generated NODE_REPL_TRUSTED_CODE_PATHS includes C:\Users\<REDACTED>\.codex, and NODE_REPL_TRUSTED_SERVICES points to the exact browser-service.mjs beneath that root, yet initialization still rejects it.

The failure occurs before browser selection, tab discovery, navigation, page access, or authentication. It is therefore not website-specific. It currently blocks an authorized authenticated-account maintenance workflow, and switching from Chrome to the built-in Browser does not bypass it.

No cookies, browser profile data, credentials, page contents, or session logs are included in this report. Please prioritize a corrected Windows build or bundled runtime fix.

Additional root-cause evidence from another affected Windows installation:

• Codex Desktop: 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Both in-app Browser and Chrome fail before browser discovery with the same browser-service.mjs trusted-path rejection.
• No newer Microsoft Store update is currently offered.

I inspected the actual environment of the spawned trusted worker process (user path redacted). It receives:

NODE_REPL_TRUSTED_CODE_PATHS=\\?\C:\Users\<REDACTED>\AppData\Local\OpenAI\Codex\runtimes\cua_node\2fb562745e6d66f0\bin\node_modules
NODE_REPL_TRUSTED_SERVICES={"browser":"C:/Users/<REDACTED>/.codex/plugins/cache/openai-bundled/browser/26.814.41407/scripts/browser-service.mjs"}

The important mismatch is that NODE_REPL_TRUSTED_SERVICES points to the Browser service under .codex\plugins, while the worker's effective NODE_REPL_TRUSTED_CODE_PATHS contains only the bundled runtime's node_modules. The .codex/Browser plugin root has already been removed before the trusted worker starts.

Additional checks:

• The service file and every parent directory exist and are readable.
• realpathSync.native() resolves the plugin root, scripts directory, and service file successfully in a comparable Codex sandbox.
• Recreating the global config.toml from scratch does not change the failure.
• Adding the exact Browser scripts directory to the global trusted-path value does not survive/effectively reach the trusted worker.
• A separately configured diagnostic server with an explicit trusted-path environment shows the same filtering behavior.
• The diagnostic configuration was reverted; no unsupported workaround or modified plugin file remains.

This narrows the defect to trusted-root filtering/propagation between Desktop configuration/server launch and the trusted worker process, rather than filesystem ACLs, Chrome extension setup, browser discovery, or page access.

Please inspect the Windows trusted-worker launch path that canonicalizes/filters NODE_REPL_TRUSTED_CODE_PATHS, and why the Browser service remains registered after its containing trusted root is discarded.

Independent reproduction on Windows ARM64 with additional package/hash evidence.

Environment:

• Microsoft Store package: OpenAI.Codex_26.814.5167.0_arm64__2p2nqsd0c76g0
• Codex desktop: 26.814.5167.0
• Codex CLI: 0.148.0-alpha.15
• Browser plugin: 26.814.41407
• Runtime ID: 54e694a67f9eb156

Exact failure, before browser discovery or any site-specific navigation:

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

Observed hashes:

• Active Browser client SHA256: 3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87
• Browser service SHA256: B6FD7F485FDF59CC4A25445479545B24972F6226C79C72AB7BD985D86F069615
• Last observed enforced Browser-client allowlist SHA256: 8E172EC9F458F2E636FC69A1B8C68C217F6BB8D10C41F70A05A0878B73863701

The active Browser client hash therefore does not match the last observed allowlisted client hash.

Additional isolation/troubleshooting completed:

• Full Codex restart: no change.
• Full Windows restart: no change.
• Windows App Repair: no change.
• Machine-scope NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S: NOT SET.
• User-scope NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S: NOT SET.
• Independent evaluation of the installed trusted-path algorithm accepts the Browser service path beneath %USERPROFILE%/.codex.
• Relevant .codex and Browser plugin directories are not reparse points.
• Bundled marketplace and materialized Browser cache compared 475/475 files with zero mismatches.
• Packaged and active Node runtime hashes match.
• Clean uninstall/reinstall from the official Microsoft Store completed successfully; app version, Browser plugin version, runtime ID, Browser client hash, Browser service hash, and exact trusted-RPC failure all remained unchanged.
• No manual config.toml, trust/hash, plugin-cache, runtime, credential, repository, or browser-profile edits were made.

After the clean Store reinstall, the supported runtime environment did not independently re-expose the allowlist value, but the identical package/plugin/runtime hashes and identical trusted-RPC failure remain.

This appears to be a packaged/runtime trust-configuration or allowlist-alignment regression rather than ordinary local corruption or a site/session issue.

Requested investigation:

1. Please confirm whether desktop 26.814.5167.0 is expected to ship/use Browser plugin 26.814.41407 with client SHA256 3B9D8D…DAD87.
2. Please verify the trusted Browser-client allowlist injected into the Windows trusted worker/runtime for this package.
3. If the released package/plugin pair is mismatched, please provide a corrected build/plugin rollout or an officially supported signed rollback/repair path.

No browser discovery was reached, so no website, authentication session, or page data is involved in the reproduction.

Independent x64 reproduction with the Chrome extension and Native Messaging layer verified healthy:

Environment

• Microsoft Store package: OpenAI.Codex 26.814.5167.0 (x64)
• Codex CLI: 0.146.0
• Bundled Browser/Chrome plugin: 26.814.41407
• Google Chrome: 151.0.7922.140
• Browser client SHA-256: 3B9D8DCC6DC968887E8A969C63DAE6380E3C1C59FF5C474EB32DF08C353DAD87
• Browser service SHA-256: B6FD7F485FDF59CC4A25445479545B24972F6226C79C72AB7BD985D86F069615

Verified healthy before retry

• Google Chrome was running.
• The ChatGPT Chrome extension was installed and enabled in the selected regular Chrome profile.
• check-native-host-manifest.js --browser chrome --json returned correct: true.
• The HKCU NativeMessagingHosts registration matched the manifest path.
• The manifest contained both expected extension origins.
• check-extension-installed.js --browser chrome --json returned installed: true and enabled: true.

Following the bundled Chrome troubleshooting procedure, I used open-chrome-window.js --browser chrome to wake the selected regular Chrome profile and retried browser-client initialization. It still failed before browser discovery or tab listing with:

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

Additional isolation

• The same error affects explicit in-app Browser, Chrome, and Edge selection.
• A full Codex desktop restart did not help.
• Temporarily narrowing NODE_REPL_TRUSTED_CODE_PATHS to the .codex root allowed the same browser runtime to initialize in a standalone diagnostic process, but the desktop app regenerated its configuration on startup and the trusted service launched by Codex continued to reject the path.
• No browser profile, extension files, bundled plugin files, cookies, credentials, page contents, or repository data were modified or included.

This reproduction has a fully healthy Chrome Native Messaging layer, so the failure is isolated to the Codex-launched trusted RPC worker/path propagation boundary. It blocks browser automation that depends on an already-authenticated regular Chrome session.

Please provide a corrected Windows package/runtime or a supported repair/rollback path. Reinstalling the Chrome extension is not a meaningful recovery step when both extension and native-host checks already pass.

I am experiencing the same issue.

Environment:

• Codex Desktop: 26.814.5167.0
• Browser plugin: 26.814.41407
• Windows: Microsoft Windows NT 10.0.26200.0 x64
• Related feedback ID: 01a00a49-e9c4-7390-9b89-447d2979d0e9

I confirmed that NODE_REPL_TRUSTED_CODE_PATHS contains the bundled Browser scripts directory and that the corrected configuration survives a complete Codex restart.

However, inspecting nodeRepl.env in the active runtime shows that no NODE_REPL_* environment variables were passed to the bundled node_repl process.

The plugin therefore continues to fail with:

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

This reproduces across multiple Codex tasks after a full system-tray exit and restart.

Independent reproduction on Windows with the same failure.

Environment:

• Codex/ChatGPT desktop package: 26.814.5167.0
• Bundled Codex CLI: 0.148.0-alpha.15
• Browser plugin: 26.814.41407
• Chrome plugin: 26.814.41407

Additional observations:

• The built-in Browser UI opens normally and supports manual navigation and sign-in.
• Agent control through @Browser fails during runtime initialization, before tab discovery, with:

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

• Reinstalling the Chrome plugin/extension does not help.
• Explicit @Chrome control produces the identical trusted-path error before extension communication.
• The same browser workflow succeeded with plugin build 26.810.52044, then began failing when the task loaded 26.814.41407.
• The referenced client and service files exist. The generated configuration points to the current service file and includes the parent .codex directory among trusted code paths.
• A complete desktop-app restart and fresh browser-control attempts did not resolve it.
• No plugin-cache or configuration files were modified.

This further isolates the defect to trusted-service/runtime initialization rather than browser UI availability, website authentication, tab state, or the Chrome extension handshake.

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report is a plausible match for one specific local failure layer that WinBridge can diagnose: desktop/plugin version drift between the installed Codex build and the cached openai-bundled Browser/Chrome plugin tree, including cache/version/latest state and partial bundled-marketplace staging.

In this case, the notable signal is the desktop build 26.814.5167.0 loading Browser/Chrome 26.814.41407. WinBridge can help verify whether that mismatch is just the normal packaged layout or whether the local plugin cache/latest pointers and bundled marketplace state are stale or partially staged, then rebuild those local pointers/copies from the installed official package when appropriate.

Important limitation: if the Browser/Chrome files are already byte-correct and version-consistent with the official package, and Codex is still rejecting browser-service.mjs because the trusted-code-path configuration generated by the current app build does not include that official runtime path, that is an upstream trust-registration/runtime bug. WinBridge cannot fix that product logic and I would not expect a local cache repair to be durable in that case.

So the useful diagnostic split is: first verify/cache-repair the local bundled plugin layer; if that layer is healthy and the trusted-path rejection remains, this should stay with upstream Codex.

Please escalate this as a Codex Windows desktop browser-control bug.

Environment

• Codex desktop: 26.814.5167.0
• Browser/Chrome plugin: 26.814.41407
• Windows x64
• Affected: built-in Browser, Chrome, and Microsoft Edge

Error

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

Browser control fails before tab discovery or page interaction. Edge’s official ChatGPT extension is installed, enabled, and authenticated, and its side panel works, but the Codex desktop-control handshake still produces the same error.

Restarting/reinstalling the desktop app, rebuilding the plugin cache, restoring configuration, and testing new tasks did not resolve it.

This matches issue #39318.

Please provide a corrected signed update or an officially supported rollback procedure.