Fails to control browser [ in app or Chrome ]

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

• #39136
• #39160

Powered by Codex Action

I can reproduce this issue on Windows with:

• ChatGPT/Codex desktop package: OpenAI.Codex_26.814.5167.0_x64
• Bundled Browser plugin: 26.814.41407
• Bundled Chrome plugin: 26.814.41407
• Workspace located on the D: drive

Both the in-app browser and Chrome fail before browser 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

Additional diagnostics:

• Chrome and Edge are installed.
• The official ChatGPT Chrome extension is installed and enabled.
• The extension has access to all sites and file URLs.
• The desktop Computer Use settings show Chrome as installed and enabled.
• check-native-host-manifest.js --json reports that both of these are missing:
• %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Troubleshooting already attempted:

• Restarted ChatGPT/Codex and Windows.
• Rebuilt the bundled plugin cache.
• Reinstalled the desktop application.
• Disabled and re-enabled the Chrome integration.
• Removed and reinstalled the official Chrome extension.

The trusted-path error remains, and the desktop app does not recreate the missing native-host manifest or registry entry.

Additional reproduction on Windows x64:

• Running Codex Desktop package: OpenAI.Codex 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Bundled Chrome plugin: 26.814.41407
• Workspace and plugin cache are on drive D:
• Both the in-app browser and Chrome fail during runtime initialization with the same trusted-path error, before any tab or account data can be read.
• Exact rejected service path class: D:\...\.codex\plugins\cache\openai-bundled\browser\26.814.41407\scripts\browser-service.mjs
• Browser control worked before the desktop app update earlier the same day.
• The failure began immediately after updating the desktop app.
• Fully quitting/reopening Codex and rebooting Windows did not resolve it.
• The service file exists, and the Browser/Chrome cache directories were freshly created after the update.

This looks like a regression in the desktop app/browser plugin trusted-code-path registration rather than a browser sign-in or extension problem.

I can reproduce the same trusted-path error on Windows with Codex Desktop 26.814.41407, but I observed an additional runtime-lifecycle detail that may help narrow down the cause.

The Chrome integration worked correctly during its first initialization. Codex successfully:

• Connected to Chrome through the Chrome integration.
• Opened https://example.com/.
• Read the page title, URL, and DOM.
• Clicked the “Learn more” link.
• Navigated back to the test page.
• Preserved the test tab.

After the browser-control session was interrupted and the previous runtime binding was lost, Codex could no longer reinitialize the Chrome integration in the same desktop app process.

The lost binding was first reported as:

chrome is not defined

Every subsequent attempt to initialize the Chrome browser runtime failed before any tab discovery or interaction 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

The Chrome client was loaded from:

.../openai-bundled/chrome/26.814.41407/scripts/browser-client.mjs

but initialization resolved the RPC service from:

.../openai-bundled/browser/26.814.41407/scripts/browser-service.mjs

Resetting the browser-control JavaScript runtime did not recover it. Explicitly invoking the Chrome plugin again with @Chrome also produced the same trusted-path error before any tab could be accessed.

This suggests that, at least in this reproduction, the extension and initial Chrome connection are functional. The failure may specifically affect browser runtime recovery or reinitialization after the original binding/session is interrupted, possibly when resolving a trusted dependency across the bundled Chrome and Browser plugin packages.

Additional Windows x64 reproduction on C: with the native host intact

I can reproduce the same failure with the following environment:

• Codex Desktop package: OpenAI.Codex 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Bundled Chrome plugin: 26.814.41407
• Chrome: 151.0.7922.138
• Windows x64
• Workspace: local C: drive

Both browser-control initialization paths fail before tab discovery with:

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

Unlike a reproduction where the native host was missing, the native host is intact here:

• HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension exists.
• %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json exists and parses successfully.
• The registered extension-host.exe exists.
• The current native-host runtime entry was refreshed by the installed desktop version.

Path-resolution evidence:

• The registered browserServicePath uses ...\chrome\latest\scripts\browser-service.mjs.
• latest is a Windows junction targeting ...\chrome\26.814.41407.
• The service exists through both paths, and both paths produce the same SHA-256 hash.
• Initialization reports the resolved versioned path as untrusted.
• Loading the browser client through either the latest path or the versioned path produces the same trusted-path error.

This reproduction shows that the issue is not limited to a D: workspace and does not require a missing native-host registration. It may be a Windows junction/realpath normalization problem in trusted RPC dependency validation: the trusted configuration records the latest path, while validation rejects the equivalent resolved versioned path.

Expected behavior: the package-managed Browser service should remain trusted after resolving the latest junction to its current version directory.

No trusted-path bypass, browser-profile inspection, or security-setting change was attempted.

Additional reproducible evidence from a second Windows installation:

• Codex Desktop package: OpenAI.Codex 26.814.5167.0
• Codex CLI/runtime: 0.147.0
• Browser plugin: 26.814.41407
• Chrome plugin: 26.814.41407
• Windows x64; both Chrome control and the in-app browser fail with the same trusted-path error.

Windows AppX deployment logs show an automatic update on 2026-08-18 at 12:28 local time:

OpenAI.Codex_26.810.7004.0_x64 -> OpenAI.Codex_26.814.5167.0_x64

Browser control was working before this update (confirmed in normal use two days earlier); the failure appeared after the update. This is temporal correlation, not definitive causation.

Diagnostics already completed:

• Reinstalled both bundled Browser and Chrome plugins.
• Reinstalled/enabled the ChatGPT Chrome extension.
• Restarted Chrome, Codex, and Windows.
• Verified the native messaging manifest, registry entry, and host executable exist.
• Verified browser-service.mjs exists at the rejected path.
• Tested from two different workspaces, including outside the application project; Desktop still fails.
• Important positive control: an isolated codex exec --ephemeral --sandbox read-only run initializes the Browser plugin successfully and returns browser discovery []. The same bundled service is rejected only by the current Codex Desktop task/runtime.

Exact Desktop 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

This points toward a regression or trust-path configuration mismatch in the Windows Desktop host rather than Chrome, the extension, or the workspace.

Yes is broken after last update today. Having the same problem.

Same here 🫠

Additional Windows x64 reproduction with a space in %USERPROFILE% and update/config evidence:

• Previous Codex Desktop package: OpenAI.Codex 26.810.7004.0
• Current package: OpenAI.Codex 26.814.5167.0
• AppX deployment log records the update on 2026-08-18 at 16:17 local time.
• Bundled Browser and Chrome plugins: 26.814.41407
• The new cua_node runtime and Browser plugin cache were created immediately after the update.
• Browser control worked under the previous app version the prior day.
• Both the in-app Browser and Chrome now fail before browser/tab discovery.

The Windows profile directory contains a space. The rejected service URL includes the corresponding percent-encoded segment:

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

There was also a generated trust-hash mismatch after the update:

• Generated NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S: 8e172ec9f458f2e636fc69a1b8c68c217f6bb8d10c41f70a05a0878b73863701
• Actual installed browser-client.mjs SHA-256: 3b9d8dcc6dc968887e8a969c63dae6380e3c1c59ff5c474eb32df08c353dad87

Updating only the hash did not resolve the RPC service-path failure.

Additional diagnostics attempted:

• Verified browser-service.mjs exists at the rejected path.
• Restarted Codex and retried both browser surfaces.
• Copied the verified Browser runtime to a no-space path and tested a Windows 8.3 short-path representation.
• The app regenerated the Node/browser security configuration on restart and restored the original versioned service path, so neither path representation became a durable workaround.
• No website navigation or browser-profile data access occurs before the failure.

This adds evidence that the regression may involve both generated trust metadata and Windows path canonicalization/URL decoding, particularly when %USERPROFILE% contains a space. Expected behavior is for the package-managed service to remain trusted after canonicalization and for the generated client hash to match the installed bundle.

Confirmed on Windows Codex Desktop with bundled Browser and Chrome plugins 26.814.41407.

@Chrome control fails during bootstrap before any tab can be discovered, 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

Chrome can be installed/enabled and appear connected, but the task still cannot initialize browser control. Retrying the connection and resetting the browser runtime did not recover it. This matches a desktop trusted-path/runtime regression rather than a website or account issue.

Independent confirmation on Windows x64:

• Codex Desktop package: OpenAI.Codex 26.814.5167.0
• Bundled Browser plugin: 26.814.41407
• Bundled Chrome plugin: 26.814.41407
• Workspace: local C: drive
• Windows profile path contains no spaces

Both explicit initialization paths fail before browser selection or tab discovery:

1. Reset the browser-control JavaScript session.
2. Load the documented Browser client from the bundled Browser plugin and initialize the runtime.
3. Repeat from a fresh session using the documented Chrome client.

Both attempts reject the same bundled service:

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

The failure persists after fully restarting Codex and after a full Windows reboot. The service file exists at the rejected path. No browser tab, cookie, profile, or webpage data is reached, and Codex itself does not crash.

This confirms the regression affects both in-app Browser and Chrome control and is not limited to a workspace on another drive or a Windows profile containing spaces.

same isshue here - I have even reinstalled and deleted all .codex and.agents file - issue remain

Additional confirmation from a Windows x64 project-folder task on the local C: drive:

• The built-in Browser was asked to open an already-running local page at http://127.0.0.1:3000/en.
• Browser initialization failed before navigation, so page rendering could not be verified.
• A subsequent explicit Chrome-control initialization in the same task failed with the same trusted RPC error.
• Bundled Browser/Chrome client version: 26.814.41407.
• Loading through either documented Browser or Chrome client path still resolved the RPC service under the bundled Browser package and rejected it with:

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

No development server was started by Codex, no dependencies were installed, and no project files were modified. This reproduces inside a project-folder task and occurs before any website-specific interaction.

Additional reproduction on Windows with the same Browser/Chrome plugin version.

Versions

• Windows AppX package: 26.814.5167.0
• System / primary dependencies: 26.813.12317
• Browser plugin: 26.814.41407
• Chrome plugin: 26.814.41407
• Windows 11 24H2, build 26100.9168
• Chrome 151.0.7922.138 (64-bit)

Error progression

Initially, browser initialization failed with:

Trusted RPC dependency must resolve within a configured trusted code path

After moving CODEX_HOME to an ASCII-only path (C:\CodexHome), the trusted-path error disappeared, but browser initialization still fails with:

windows sandbox failed: orchestrator_helper_incomplete: setup helper exited successfully before setup completed

The Node/browser runtime exits before either the in-app browser or Chrome tabs can be accessed.

The sandbox log also contains:

runner exit write failed: The pipe is being closed. (os error 232)

The app’s “Reinstall Codex dependencies” action also fails with “Unable to reinstall Codex dependencies.”

Already tried

• Reinstalled and re-enabled the Browser and Chrome plugins
• Reinstalled the Chrome native messaging host
• Restarted Chrome, Codex, and Windows
• Tested both elevated and unelevated Windows sandbox modes
• Fully rebuilt the Codex sandbox state and sandbox users
• Confirmed that the sandbox setup helper reports successful completion
• Confirmed that the Codex AppX package status is Ok

The failure occurs before Chrome extension communication or tab discovery, so it appears to be in the Windows sandbox/orchestrator startup path rather than the Chrome extension itself.

Please let me know if a sanitized sandbox log or additional diagnostics would be useful.

I can corroborate this on Windows with the same failure in both browser surfaces.

Observed evidence:

• Installed Codex package path: C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0\\...
• Cached Browser plugin: 26.814.41407
• Cached Chrome plugin: 26.814.41407
• In-app Browser initialization fails before tab discovery.
• Chrome initialization fails before tab discovery.
• Both return the identical error:

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

The referenced browser-service.mjs exists. The app/cache version mismatch may be relevant: the installed app package is 26.814.5167.0, while both cached browser integrations remain at 26.814.41407. This is an inference, but it is consistent with a stale trusted-path allowlist or bundled-plugin cache mismatch. Reconnecting Chrome does not help because the failure occurs in the shared browser service before either surface can enumerate tabs.

I am experiencing the same issue on Windows 11.

Environment:

• Codex Desktop app: 26.814.5167.0
• Browser runtime: 26.814.41407
• Last known working browser integration: chrome/26.810.52044
• Last known working time: approximately 2026-08-17 07:40 CEST

Both @Browser and @Chrome fail before browser tab discovery with:

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

The Chrome extension and Native Host diagnostics are normal, and the same PC and Chrome configuration worked before the update.

Feedback thread ID:
01a0163b-7b72-7a92-97f4-885a1cac13ff

I’m experiencing the same issue.

Environment

• Windows 11 Enterprise 23H2, build 22631.7517
• About ChatGPT/Codex version: 26.814.41407 — use this as the app version.
• Windows package identity: 26.814.5167.0 — this came from the installed MSIX package path.
• Browser/Chrome plugin bundle: 26.814.41407

Additional finding: Edge is also affected

The same trusted-path failure affects all three browser-control surfaces:

• Built-in @Browser
• Google Chrome, shown as Connected under Settings → Computer Use
• Microsoft Edge, shown as Connected under Settings → Computer Use

All three fail before tab discovery with:

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

I removed and reinstalled the browser integrations/extensions, fully restarted the browsers and Codex, and retested. The issue remains 100% reproducible.

Feedback ID: 01a0164d-01d9-7782-8755-0f5664c5e17e

Confirmed community downgrade workaround

Cross-referencing the original workaround from #39136:

• Reference post: https://github.com/openai/codex/issues/39136#issuecomment-5331274519
• Independent confirmations: https://github.com/openai/codex/issues/39136#issuecomment-5331825624 and https://github.com/openai/codex/issues/39136#issuecomment-5332888685

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:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\browser
%USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome

The official Store-signed x64 installer is available through OpenAI’s Windows deployment page:

https://learn.chatgpt.com/docs/enterprise/windows-deployment

Because that download URL is rolling and is not permanently pinned to 26.810.7004.0, affected users may want to download and preserve the currently working installer immediately. After recovery, decline the offered update until OpenAI confirms the 26.814 Browser/Chrome trusted-RPC regression is fixed.

This is a community workaround, not an official fix. Back up relevant local state before deleting plugin caches.

### Confirmed community downgrade workaround Cross-referencing the original workaround from #39136: Reference post: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment) Independent confirmations: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment) and Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment) 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: `` %USERPROFILE%\.codex\plugins\cache\openai-bundled\browser %USERPROFILE%\.codex\plugins\cache\openai-bundled\chrome ` The official Store-signed x64 installer is available through OpenAI’s Windows deployment page: https://learn.chatgpt.com/docs/enterprise/windows-deployment Because that download URL is rolling and is not permanently pinned to 26.810.7004.0, affected users may want to download and preserve the currently working installer immediately. After recovery, decline the offered update until OpenAI confirms the 26.814` Browser/Chrome trusted-RPC regression is fixed. This is a community workaround, not an official fix. Back up relevant local state before deleting plugin caches.

Please clarify how do I downgrade the link you shared again installs the 41407 version.
Version 26.814.41407
Released 18 Aug 2026
--- and the in app browser does not work ---
open google.com in the inapp browser
Worked for 11s
The in-app browser is still unavailable—the same internal security-check error occurred, so I couldn’t open Google. The ChatGPT desktop app needs to be updated or reinstalled before browser control will work.

Independent reproduction on Windows.

Environment:

• Codex desktop: 26.814.5167.0
• Browser plugin: 26.814.41407
• Chrome plugin: 26.814.41407

Both the built-in Browser and Chrome control fail before browser/tab discovery with:

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

Troubleshooting completed:

• Reinstalled the Chrome extension.
• Reinstalled the Chrome plugin from Codex.
• Fully terminated all ChatGPT/Codex processes.
• Restarted Codex and Chrome.
• Retested both Chrome and the built-in Browser; both still fail with the same trusted-path error.

In-app feedback/session ID: 01a0170e-a332-7c12-a1f0-d2d3f019bc8b

No browser cookies, credentials, local storage, or other sensitive browser data were inspected or included.

I downgraded : https://codex-190977.en.uptodown.com/windows/download/1201884335

Independent reproduction: initial Chrome control works, reinitialization fails after the browser binding is lost

I can reproduce this on Windows with the bundled Browser/Chrome plugin build 26.814.41407.

What worked initially

• I loaded .../openai-bundled/chrome/26.814.41407/scripts/browser-client.mjs and initialized the Chrome browser binding.
• chrome.user.openTabs() returned my already-open Google Flights and Skyscanner tabs.
• I claimed both tabs and successfully used DOM snapshots and navigation to read the signed-in Skyscanner Price Alerts page and Google Flights tracked-prices page.

Failure

After the browser-control binding was lost between user turns, reinitializing the same Chrome integration failed before tab discovery 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

I then:

• reset the browser-control JavaScript runtime;
• waited and retried initialization;
• re-imported the Chrome browser client;
• added the plugin node_modules directory to the runtime;
• opened a fresh Chrome window using the same Default profile and retried.

Every attempt failed with the same trusted-path error before any tab could be read.

Diagnostics

• Chrome is running and installed.
• The Codex Chrome extension is installed, enabled, and registered in the Default profile.
• The native-host manifest exists, matches the registry entry, and contains the expected Chrome extension origins.
• This reproduction therefore does not depend on a missing browser, a disabled extension, a missing native host, or an authentication problem.

No cookies, credentials, local storage, or browser history were inspected, and no account actions were performed after the bridge failure.

Suspected scope

This looks like a browser-runtime lifecycle or trusted-RPC dependency-resolution bug after the original browser binding is lost. The first initialization and tab operations work; later reinitialization fails before tab discovery, even though the Chrome extension and native host remain healthy.

An update was available today on Microsoft Store AUG 19, 2026 - it corrected the issue