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

[loritextile-coder]

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.

[github-actions]

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

• [Windows 26.818] Built-in Browser fails trusted RPC dependency validation #40405
• [Windows 26.814] Browser and Chrome control stopped after morning component update #39305
• Windows regression that completely disables both the built-in Browser and Chrome control. #39414
• Windows: shared Browser runtime rejects bundled browser-service during trusted RPC validation #39407
• [Windows] Browser/Chrome plugin fails trusted RPC dependency path validation #39399

Powered by Codex Action

[loritextile-coder]

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:

• Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 was closed as completed on August 23.
• [Windows 26.814] Browser and Chrome control stopped after morning component update #39305 covers the older 26.814 plugin rollout and was closed as a duplicate.
• [Windows 26.818] Built-in Browser fails trusted RPC dependency validation #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]

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.

[alfatrademarks-creator]

Additional longitudinal reproduction: Trusted RPC failure continues across later Windows Browser component generations

Adding a longer-term Windows data point to this issue.

I previously reported the same Trusted RPC failure family in #39136:

• initial independent reproduction: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment)
• follow-up after the next Desktop/Browser update: Codex built-in browser plugin initialization fails: Trusted RPC dependency is not within a trusted code path #39136 (comment)

That earlier issue was later closed as completed. Since then, I have continued tracking Browser Use across multiple newer bundled component generations, and the failure has either persisted or reappeared after automatic updates.

Earlier controlled reproductions

August 18

Environment:

• Windows 11
• Codex Desktop 26.814.5167.0
• Browser 26.814.41407

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

Trusted RPC dependency must resolve within a configured trusted code path

for the bundled browser-service.mjs.

No website content or authentication state was reached before the failure.

August 19

After updating to:

• Codex Desktop 26.814.5517.0
• Browser 26.814.41957

the same Trusted RPC failure was reproduced under the normal permission profile, again before browser discovery.

I also ran a controlled permission A/B test on that environment:

Normal workspace permissions
→ Browser runtime initialization failed with the Trusted RPC error.

Full Access
→ the Browser runtime initialized successfully;
→ the built-in Browser opened example.com;
→ URL, page title, and H1 (Example Domain) were read programmatically;
→ the test tab was then closed.

This confirmed Full Access as a workaround in that specific environment, but not as an acceptable steady-state solution.

Browser access should not require disabling the normal sandbox boundary merely to initialize an official bundled service.

Later Browser component checkpoints

Since the original 26.814.41407 reproduction, the Browser component has moved through at least these observed package/build checkpoints:

• 26.814.41957
• 26.818.21641
• 26.818.31338
• 26.818.61809
• 26.820.60940
• 26.820.71523
• 26.825.32147
• 26.825.41651

I am listing these as observed component generations, not as eight separate Desktop installations or eight identical controlled A/B tests.

There was also a temporary interval after an intermediate update in which normal-permission Browser Use appeared to work in other tasks. I do not have a controlled build-specific A/B for that observation, so I am not treating it as proof of a particular fixed version.

That pattern is independently consistent with this issue's stronger version-to-version reproduction: 26.818.41509 worked earlier in the day, then the automatic update to 26.818.61809 caused Trusted RPC initialization to fail again.

August 28 controlled reproduction

Environment:

• Codex Desktop 26.825.4187.0
• Browser 26.825.32147

Under the normal permission profile:

1. browser-client.mjs imported successfully.
2. setupBrowserRuntime() then failed before a browser or tab could be obtained.
3. The failure was again the Trusted RPC rejection of the bundled browser-service.mjs.
4. No page data was read.

This is important because the client module itself could load; the failure remained at trusted service initialization.

Current August 29 environment

Current installed versions:

• Codex Desktop 26.825.5331.0
• Browser / Chrome / Computer Use 26.825.41651
• bundled CLI 0.151.0-alpha.7.1

The current owner-side observation is that normal-permission Browser Use is still not operational and Full Access remains the practical workaround.

I have not captured a fresh complete Trusted RPC trace from 26.825.41651 in this reporting session yet, so I am deliberately not claiming an exact error string for that build until another clean trace is recorded.

What has been established in earlier controlled tests

Across the earlier reproductions:

• the bundled browser-service.mjs existed and was readable;
• its service path was physically inside the configured trusted root;
• the trusted runtime still rejected the service as outside the trusted code path;
• browser initialization failed before site access, authentication, CDP, or tab inspection;
• restart and manual trust/hash/path configuration experiments did not provide a durable normal-permission fix;
• Full Access changed the outcome in a controlled A/B test.

These observations make a target website or Chrome authentication state an unlikely immediate cause of this failure.

Root-cause boundary

Community investigations have proposed several related mechanisms, including:

• trusted roots not being propagated correctly to a child trusted-service process;
• Windows path normalization / sandbox identity handling;
• trusted runtime environment reconstruction during plugin initialization.

I am not presenting any of these as an official OpenAI root cause.

Operational impact

For my workflow, Browser Use is not primarily a UI-clicking convenience. It is a read-only acquisition layer for authorized web interfaces where public Web access or APIs are insufficient.

Scheduled workflows use it to:

1. access an already-authorized page;
2. collect a point-in-time analytical snapshot;
3. retain successive observations;
4. pass the accumulated history into later analysis.

When Browser Use stops after an automatic component update, the result is not just an interrupted interactive task. It can create gaps in historical time-series data that cannot necessarily be reconstructed later.

Public Web access, APIs, external scraping tools, and manual transfer are useful partial fallbacks, but they do not replace access to an existing signed-in UI session.

Expected behavior

The official bundled Browser service should initialize under the normal permission profile.

Website permissions should control which sites the agent may access. A user should not need to enable Full Access — which broadens filesystem and other sandbox permissions far beyond the browser task — simply for the official bundled Browser runtime to trust its own service.

Request to maintainers

Could you please confirm:

1. which current Windows Desktop / Browser component combination is expected to contain the normal-permission fix for this Trusted RPC failure family;
2. whether the recurrence across later automatic component updates is a known regression;
3. what additional safe, read-only, sanitized diagnostics would be most useful from an affected 26.825.5331.0 / 26.825.41651 installation.

I can provide another fresh trace from the current build if maintainers specify the preferred diagnostic boundary. No credentials, cookies, authenticated page contents, private paths, project identifiers, or conversation/thread IDs need to be included.