›_ Codex Issues
Codex Issues / #39236

[Windows 26.814] Browser/Chrome repair flow does not rebuild trusted RPC configuration

Open 💬 5 comments Opened Aug 18, 2026 by dgwyer
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On native Windows Codex Desktop, the documented Chrome repair flow does not recover Browser/Chrome control.

The Chrome plugin uninstall action reports Failed to uninstall plugin. After closing Chrome and Codex completely, removing/re-adding the Chrome plugin and extension, restarting the desktop app after reinstall, and testing from fresh tasks, both the built-in Browser and Chrome still fail before browser discovery with:

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

This report is separate from #39173. That issue records the browser-control symptom. This issue focuses on the plugin uninstall/reinstall and trust-configuration lifecycle: the supported repair flow does not restore a trusted Browser RPC service.

Environment

  • Windows x64
  • Codex desktop package: OpenAI.Codex_26.814.5167.0_x64
  • Browser plugin: 26.814.41407
  • Chrome plugin: 26.814.41407
  • Chrome extension/native host: installed; side panel loads

Reproduction

  1. Install/enable the bundled Browser and Chrome plugins.
  2. Install the ChatGPT Chrome extension.
  3. Ask a fresh Codex task to access Chrome or the built-in browser.
  4. Observe the trusted RPC dependency error above.
  5. Attempt to remove the Chrome plugin in Codex.
  6. Observe Failed to uninstall plugin.
  7. Close the Chrome side panel and all Chrome processes.
  8. Fully terminate Codex and its browser extension host.
  9. Reopen Codex, remove/re-add the Chrome plugin, and reinstall the Chrome extension.
  10. Fully terminate Codex again after reinstall.
  11. Reopen Codex and test from a brand-new task.
  12. The same trusted-path failure occurs immediately.

The error also reproduces after starting a fresh browser runtime session.

Diagnostics

  • The Chrome native-messaging registration and manifest are present and valid.
  • The native host executable exists and starts.
  • Browser and Chrome plugin files exist and are version-matched.
  • The Browser and Chrome copies of browser-client.mjs and browser-service.mjs are byte-identical.
  • Failure occurs before tab discovery, so it is not caused by the Chrome profile, website permissions, authentication state, blocklist, or target page.
  • The same shared browser-service.mjs rejection affects Chrome and the built-in browser.

Actual behavior

The supported uninstall/reinstall workflow either fails to uninstall or reinstalls without rebuilding a trust configuration that accepts the bundled Browser service. Fresh tasks and fresh runtime sessions continue rejecting Codex's own version-matched Browser service.

Expected behavior

  • Removing the Chrome plugin should succeed when its active host is stopped, or explain which state prevents removal.
  • Re-adding the Browser/Chrome plugins and restarting Codex should regenerate a valid trusted RPC service configuration.
  • The version-matched bundled browser-service.mjs should resolve within an allowed trusted code path.
  • Fresh tasks should connect to the built-in browser and Chrome without manual cache or registry modification.

Related issues

  • #39173 — same browser-control symptom; this report does not add a comment there.
  • #39212 — same desktop/plugin version and trusted RPC error for the built-in Browser.
  • #39136 — broader trusted RPC browser initialization failure.

No plugin cache, registry, security settings, or filesystem permissions were manually modified.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 9 days ago

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

  • #39173
  • #39212
  • #39136
  • #39160

Powered by Codex Action

adamczhang · 9 days ago

Confirmed community downgrade workaround

Cross-referencing the original workaround from #39136:

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.

troymoody · 9 days ago

Additional Windows reproduction with the same regression, plus missing Chrome native-messaging host registration.

Environment:

  • Codex Desktop: 26.814.5167.0
  • Bundled Browser/Chrome plugin: 26.814.41407
  • Windows
  • Chrome installed and running

Primary failure:

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

Background Chrome-tab control worked correctly for weeks, including the previous day. Codex could claim authenticated Chrome tabs and interact with

talhaaltaf24 · 9 days ago

01a019b0-7728-7681-a9e7-4c4711537d50

Codex Desktop: 26.814.5167.0
Browser plugin: 26.814.41407
Chrome plugin: 26.814.41407
Windows x64

pcormack-sudo · 8 days ago

Same here — adding detailed diagnostics from a day of deep debugging on this machine. May help narrow it down.

Environment

  • Codex desktop (Appx OpenAI.Codex): 26.814.5517.0, runtime/CLI 26.814.41957
  • Chrome plugin: 26.814.41957 · ChatGPT Chrome extension: 1.2.27259.19709
  • Windows 11 Home 10.0.26200 x64, system locale es-ES
  • Chrome 151.0.7922.170

Symptom — started immediately after the 26.814 auto-update on Aug 18 ~21:21 local: the Codex side panel in Chrome can read tabs (getTabContext works) but all interactive control is unavailable. Session system prompts contain: "…unavailable because the Codex Chrome native host did not provide a browser-client path… explain that the native host is out of date". Reinstalling the app, the extension, the plugin (and even Windows) does not help — matching this issue's title: the repair flow does not rebuild the needed state.

Key finding — the native messaging chain is actually healthy. I interposed a tee wrapper on the native host and captured the wire traffic: codexRuntime/hello and codexRuntime/ensure both succeed, and the ensure result contains the full runtimeConfig including browserClientPath and a valid localAppServerUrl with token. Yet new side-panel sessions still compose the degraded "no browser-client path" instructions. So on this build the failure appears to be between the (successful) ensure result and the side panel's session composition, not in the host itself.

Two additional bugs found while debugging that break every recovery path:

  1. chrome-native-hosts-v2.json entries are never refreshed. The app writes its runtime entry (paths + presence.pid) once per app version and never updates presence on later startups. After an auto-update restarts the app, presence.pid points at a dead process forever. App updates also delete the previous runtimes\cua_node\<hash> directory, leaving older registry entries with a nonexistent nodePath that still match host lookups. Manually setting entries: [] in both copies (%LOCALAPPDATA%\OpenAI\Codex\ and ~/.codex/) and restarting the app forces a healthy re-registration (fresh live pid) — reinstalls never do this.
  1. Registry parsing is broken on non-English Windows. scripts/check-native-host-manifest.js, scripts/installed-browsers.js and scripts/open-chrome-window.js (chrome plugin) parse reg query <key> /ve output looking for the literal value name (Default). Spanish Windows prints (Predeterminado) (German: (Standard), French: (par défaut), etc.), so readWindowsRegistryValue returns null and the checks report "Windows native host registry key does not exist" for a key that exists. Every native-host/browser detection based on these scripts fails on any localized Windows.

Even after fixing both locally (verified: the plugin's own check-native-host-manifest.js --json returns "correct": true, and ensure returns a complete runtimeConfig on the wire), side-panel sessions on 26.814.41957 still receive the degraded prompt. No "Trusted RPC" errors appear in local logs_2.sqlite, so this may be an additional regression alongside the trusted-code-path one tracked here.

Happy to provide the full wire captures or logs if useful.