[Windows] Browser/Chrome plugin fails trusted RPC dependency path validation

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

• #39387
• #39318
• #39302
• #39253
• #39252

Powered by Codex Action

Independent reproduction on Windows with the same versions and failure:

• Codex desktop app: 26.814.5167.0
• Bundled Browser/Chrome plugins: 26.814.41407
• The in-app Browser, Chrome, and Edge control paths all fail before page interaction with the same trusted RPC dependency error for the bundled browser-service.mjs.
• Windows Repair for the Codex app completed successfully, followed by full Codex and PC restarts; the failure persisted.
• The Browser and Chrome copies of browser-service.mjs are byte-identical (SHA-256: B6FD7F485FDF59CC4A25445479545B24972F6226C79C72AB7BD985D86F069615).
• Generated configuration already includes %USERPROFILE%\.codex in NODE_REPL_TRUSTED_CODE_PATHS, and NODE_REPL_TRUSTED_SERVICES points to the service file beneath that directory, but validation still rejects it.
• Adding an exact path manually to the user configuration was not a durable workaround: the desktop app regenerated config.toml on the next startup and overwrote the change.

No browser page interaction or external write occurred because initialization failed first. This seems consistent with a Windows trusted-path canonicalization/config propagation issue rather than an extension login or site-session problem.

lso reproduced when explicitly selecting Microsoft Edge; failure occurs before browser discovery.

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

There are two separate layers in this report, and only one of them is clearly in WinBridge's current local-repair scope.

The local Windows layer is the Chrome Native Messaging registration state: the manifest exists at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json, but HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension is missing and the bundled checker reports correct: false. WinBridge can help diagnose/recover that local manifest/registry/chrome-native-hosts-v2.json state and verify that the registered host points at the expected bundled extension-host.exe. It can also check whether the Browser/Chrome bundled cache version and latest pointer are internally consistent after repair/reinstall.

The Trusted RPC dependency must resolve within a configured trusted code path failure is a different boundary. In this issue, the versioned Browser service exists, is readable, the configured trusted root contains %USERPROFILE%\.codex, and the same node_repl.exe can initialize the Browser runtime outside the Codex-launched trusted-service environment. If those facts remain true after the local cache/native-host state is repaired, that points to an upstream trusted-service environment/path-propagation problem rather than a damaged local plugin cache. WinBridge cannot guarantee a fix for that upstream runtime behavior.

So I would treat WinBridge here as a way to restore/verify the Native Host + bundled-cache layer and then re-test. If the trusted-RPC rejection persists with those local layers healthy, this issue still needs an OpenAI-side fix.

macOS here. I think my case may be closer to #39387 than this issue, but I'm commenting here as well because I believe these may be manifestations of the same underlying problem.

Independent reproduction with additional process-level evidence on Windows 10:

Environment

• Windows 10 Pro 22H2, build 19045.6466, x64
• Codex desktop package: 26.814.5167.0
• Codex CLI: 0.148.0-alpha.15
• Browser/Chrome bundled plugins: 26.814.41407
• Google Chrome: 151.0.7922.138

Failure

Chrome runtime initialization fails before browser discovery with:

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

The versioned service file exists. The bundled Browser client SHA-256 is:

3b9d8dcc6dc968887e8a969c63dae6380e3c1c59ff5c474eb32df08c353dad87

New diagnostic boundary

The generated config.toml contains NODE_REPL_TRUSTED_CODE_PATHS, NODE_REPL_TRUSTED_SERVICES, module paths, browser backends, and the Codex home under [mcp_servers.node_repl.env]. However, reading only those keys from the actual failing JavaScript process returned:

{
  "NODE_REPL_TRUSTED_CODE_PATHS": null,
  "NODE_REPL_TRUSTED_SERVICES": null,
  "NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S": null,
  "NODE_REPL_NODE_MODULE_DIRS": null,
  "BROWSER_USE_AVAILABLE_BACKENDS": null,
  "BROWSER_USE_CODEX_APP_VERSION": null,
  "CODEX_HOME": null
}

This was reproduced after fully restarting the desktop app, not just after resetting the JavaScript kernel.

Controlled configuration experiment

1. Backed up config.toml and verified the backup SHA-256 matched the source.
2. Added the verified Browser client hash under [mcp_servers.node_repl.env].
3. Removed a stale copy of that override from [shell_environment_policy.set].
4. Parsed the resulting TOML and verified an exact two-change diff.
5. Kept the existing versioned NODE_REPL_TRUSTED_SERVICES path unchanged; did not create a browser/latest junction.
6. Restarted Codex and retried.

On restart, Codex regenerated config.toml and removed the manually added Browser-client hash while preserving the versioned NODE_REPL_TRUSTED_SERVICES entry. Initialization still failed, and the actual process environment above was still entirely absent.

No registry changes, launcher installation, service deletion, or trust-bypass attempt was made.

This strongly suggests the desktop-launched Node runtime is not receiving its generated MCP environment, rather than the bundled service path merely failing lexical containment.

Additional reproducible case after the latest Windows desktop update:

• Codex App: 26.818.2872.0
• Bundled Browser plugin: 26.818.22352
• Windows Home edition
• C:\Users\<redacted>\.codex is an NTFS directory junction targeting D:\CodexData\.codex because the system drive has insufficient free space.

The in-app Browser runtime fails before browser discovery with:

EPERM: operation not permitted, lstat 'C:\Users\<redacted>\.codex'

Diagnostics:

• The signed-in user owns the junction and has Full Control.
• PowerShell can read the junction and target normally.
• The Browser runtime alone fails while resolving the configured Codex home path.
• Fully restarting Codex does not resolve it.
• The same failure reproduced with Browser plugin 26.814.41957 and remains after updating to 26.818.22352.
• Other Codex filesystem and terminal functions continue to work; in-app Browser control cannot initialize.

Moving the Codex data back to the system drive is not a viable workaround because of system-drive capacity constraints. Please support a non-system-drive CODEX_HOME/junction configuration in the trusted Browser runtime, or provide an officially supported low-disk migration/relocation method.

Independent Windows reproduction of the native-host installation gap described in this issue.

Environment

• Windows x64
• Bundled Chrome plugin: 26.814.41957
• Google Chrome is installed in the standard Program Files location
• mcp__node_repl__js is exposed and the bundled browser-client.mjs imports successfully

Observed failure

The browser runtime initializes, but acquiring Chrome fails twice with:

Browser is not available: chrome

The bundled diagnostics then report:

check-extension-installed.js --browser chrome --json
Browser user data directory does not exist: %LOCALAPPDATA%\Google\Chrome\User Data

and:

check-native-host-manifest.js --browser chrome --json
exists: false
correct: false
Windows native host registry key does not exist:
HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension

Native host manifest does not exist:
%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

The user is signed into the intended Chrome profile, but Codex cannot obtain the Chrome backend. The Chrome-running diagnostic was inconclusive because tasklist was denied in the sandbox; no conclusion is drawn from that check.

This is not the missing-JS-tool case from #30026. The generic runtime error resembles #37307, while the concrete missing manifest/registry state matches the Windows installation/repair gap requested here.

Request

Please make Settings → Computer use install/repair both the native-host manifest and its HKCU registration atomically, and surface this specific missing-host state instead of only Browser is not available: chrome. A supported re-registration/repair action would unblock users without requiring manual registry edits.

No account data, tokens, private URLs, or workspace paths are included.

Independent reproduction on a newer Windows build, also supporting the physical non-system-drive case described in #39400.

Environment

• Codex desktop app: 26.818.5229.0
• Bundled Browser plugin: 26.818.41509
• Windows x64
• CODEX_HOME: physical directory on a fixed non-system drive, represented below as X:\Codex\home (not a junction or symlink)

Failure

The packaged browser-client.mjs imports successfully, but setupBrowserRuntime() fails before browser discovery or any tab/page interaction:

Trusted RPC dependency must resolve within a configured trusted code path:
file:///X:/Codex/home/plugins/cache/openai-bundled/browser/26.818.41509/scripts/browser-service.mjs

This affects the common Browser runtime before it can select either the in-app Browser or an extension-backed browser.

Checks and control result

• The rejected browser-service.mjs exists and is readable.
• The CODEX_HOME directory, plugin cache, version directory, and service file are physical filesystem objects with no reparse target.
• The bundled Node runtime's realpath, realpath.native, and path.resolve results all identify the expected X:\Codex\home\...\browser-service.mjs; pathToFileURL produces the same URL shown in the failure.
• Generated configuration includes X:\Codex\home in NODE_REPL_TRUSTED_CODE_PATHS and maps the Browser trusted service to that exact versioned service file.
• Ordinary JavaScript execution in the same runtime works.
• As a control, nodeRepl.rpc("sky", {type: "setup"}) succeeds in the same live runtime (target: windows, 13 methods). This indicates that the core Node runtime and trusted-RPC channel are alive; rejection is specific to resolving/launching the local Browser service dependency.
• The failure reproduces with fresh node_repl processes after a full Codex app restart.

Local task history contains successful Browser control before CODEX_HOME was relocated off the system drive, followed by this exact failure after relocation. That is correlation rather than proof, but it closely matches #39400's non-system-drive boundary.

Secondary configuration observation

After the app/plugin/home migration, [shell_environment_policy.set].NODE_REPL_TRUSTED_BROWSER_CLIENT_SHA256S still contains the SHA-256 of the former Browser 26.814 client (3b9d8dcc6dc968887e8a969c63dae6380e3c1c59ff5c474eb32df08c353dad87), while the active 26.818.41509 client hashes to 53484b46fedd277e436a0c3f38820eca8aab4e32c01bb44e1b5766eb369b5e6. The active client nevertheless imports successfully and the reported rejection names browser-service.mjs, so I am not asserting that this stale hash is the sole cause. It does show that Browser trust metadata was only partially refreshed during regeneration.

No browser profiles, tokens, private URLs, user names, repository contents, registry entries, ACLs, or plugin files were modified during this diagnosis.