›_ Codex Issues
Codex Issues / #40411

Windows desktop auto-update breaks Chrome and Computer Use with Trusted RPC path errors

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

Summary

After the Codex Windows desktop app automatically updated its bundled Chrome, Browser, and Computer Use components, both Chrome control and Computer Use began failing during initialization with Trusted RPC path/module validation errors.

The same machine, Chrome profile, signed-in page, Codex thread, and workflow worked earlier that day. No Chrome, extension, or Codex settings were changed by the user.

Environment

  • Windows Codex Desktop package: 26.818.8289.0
  • Current bundled Chrome / Browser / Computer Use plugin version: 26.818.61809
  • Previously working Chrome plugin version: 26.818.41509

Timeline

  1. Around 11:50 local time, Chrome control worked successfully with plugin version 26.818.41509. It enumerated multiple Chrome extension instances, skipped an empty instance, and claimed the instance containing the signed-in target tab.
  2. Around 22:10, the bundled Chrome, Browser, and Computer Use plugin directories were automatically replaced with version 26.818.61809.
  3. Around 22:11, the bundled control runtime also switched to a new build.
  4. Immediately afterward, Chrome control failed before browser-instance or tab discovery.
  5. Codex was fully exited and restarted after the update. New Codex processes were confirmed, but a fresh initialization attempt produced the same error.
  6. The in-app feedback upload was retried multiple times and also failed, although the app retained a local feedback ID.

Chrome error

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

Computer Use error

Trusted RPC package must resolve within a configured trusted module directory:
@oai/sky/service

Expected behavior

After an automatic bundled-plugin update and app restart, Chrome and Computer Use service dependencies should be registered as trusted. Chrome control should enumerate connected extension instances and allow the existing signed-in tab to be claimed.

Actual behavior

Both browser control and Computer Use fail during initialization, before any browser instance, tab, webpage, or authentication state is inspected.

Additional observations

  • The Chrome tab remained open and signed in throughout.
  • The error occurs before extension-instance enumeration, so it is not caused by selecting an empty Chrome profile or by page login state.
  • The previously working plugin version 26.818.41509 was removed by the automatic update, so a safe local rollback was not available.
  • Restarting Codex after the update did not repair the trusted-path registration.
  • This blocks scheduled workflows that require confirmation from an existing signed-in Chrome tab and cannot safely substitute cached data or another browser.

Please check whether the trusted RPC dependency/module registration in Windows Desktop 26.818.8289.0 is compatible with bundled plugin version 26.818.61809.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 days ago

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

  • #40405
  • #39305
  • #39414
  • #39407
  • #39399

Powered by Codex Action

loritextile-coder · 3 days ago

I reviewed the suggested duplicates.

This is the same trusted-RPC failure family, but I am keeping this issue open because it is a fresh reproduction after the earlier reports were closed as completed:

  • #39136 was closed as completed on August 23.
  • #39305 covers the older 26.814 plugin rollout and was closed as a duplicate.
  • #40405 reproduces the browser error on plugin 26.818.41509 and is already closed as completed.
  • This report reproduces the failure on the newer Windows Desktop package 26.818.8289.0 with bundled plugin 26.818.61809, after a confirmed full app restart.
  • In addition to Browser/Chrome, Computer Use now fails during initialization with Trusted RPC package must resolve within a configured trusted module directory: @oai/sky/service.

The newer plugin/runtime version and the simultaneous Computer Use failure suggest a regression or incomplete trusted-module registration after the newer automatic update.

zemeng5208 · 3 days ago

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

This looks close enough to WinBridge’s current Windows local-repair scope to be worth checking, specifically the layer between the newly staged bundled plugin set and the user-side trusted runtime state after the automatic update.

For this report, the useful local checks are:

  • whether ~/.codex/plugins/cache/openai-bundled/{browser,chrome,computer-use} contains one complete immutable version matching the new 26.818.61809 bundle rather than a partially materialized mix;
  • whether each plugin’s latest link/junction resolves to that complete version;
  • whether the bundled marketplace/staging metadata and the active plugin cache agree on the same version;
  • whether the user-side cua_node / node_repl runtime/helper paths used by the new bundle still resolve to the currently installed files rather than an older relocated runtime;
  • for Chrome specifically, whether the Native Host manifest, HKCU registration, schema-v1 host config, and chrome-native-hosts-v2.json entries all point to current existing binaries/resources and current browser-client trust data.

WinBridge can diagnose and, where the inconsistency is in those user-writable local layers, rebuild/reconcile that state without modifying the signed WindowsApps package.

Important limitation: the errors in this issue may also be an upstream regression in how Desktop 26.818.8289.0 launches trusted RPC services or constructs the trusted module/code-path environment for plugin 26.818.61809. If the bundled cache, latest, relocation targets, and Chrome native-host/v2 state are already internally consistent and match the installed package, then this is outside what WinBridge can reliably repair and needs an upstream fix. I would not treat a successful local-state repair as guaranteed for this report.