[Windows][Browser] Trusted RPC service fails in D: workspace but succeeds in C: workspace

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

• #39136

Powered by Codex Action

Additional reproduction on Windows x64 (2026-08-19):

• Codex desktop package: 26.814.5167.0
• Bundled Browser/Chrome plugin: 26.814.41407
• Workspace is on drive D:
• Edge browser control worked earlier the same day, then began failing consistently without any target-site interaction.
• The failure occurs before tab discovery, so it is independent of the website or authentication state.
• Full Codex/Edge restarts, permission re-approval, and removing/re-adding the browser extension/plugin did not recover it.
• Chrome control now fails at the same bootstrap stage as Edge.

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

The referenced bundled service file exists and is readable. The generated configuration also names the Browser service path, but the active browser-control runtime still rejects it before connecting to Edge or Chrome.

No page contents, credentials, cookies, or remote commands were accessed during these tests.

Resolution report — workaround confirmed, closing as duplicate

I have completed a controlled investigation of this issue. The browser workflow is operational again in a qualified configuration. This is a workaround confirmation, not evidence that the underlying regression in the normal permission profile has been fixed.

Problem

Codex Desktop browser control failed on Windows during initialization, before browser discovery, tab selection, or access to any target website. The bundled browser service was rejected at the trusted RPC / trusted-worker boundary even though the referenced service existed and the expected trusted configuration was present.

This mattered operationally because the affected workflow requires frequent, reproducible navigation and file exports; manual intervention is not a sufficiently reliable substitute at scale.

The additional x64 reproduction from @SenhuWong confirms that this is not limited to one processor architecture and that it occurs before any website or authentication state becomes relevant.

Recovery paths considered but not adopted

• Downgrading Codex Desktop: rejected as a durable solution because automatic updates could immediately reintroduce version drift. Permanently suppressing updates would also create maintenance, security, support, and reproducibility risks.
• Changing between ARM64 and x64 packages: not pursued because the installed package ultimately worked and changing architecture would add another uncontrolled variable without addressing the demonstrated permission boundary.
• Repairing/reinstalling the app or repeatedly rebuilding the plugin cache: not used as the solution because the available evidence did not indicate missing or corrupted bundled files.
• Reinstalling Edge, Chrome, or their extensions: not retained because multiple browser surfaces failed at the same pre-browser bootstrap stage.
• Moving the workspace between drives: tested rather than assumed. Equivalent fresh-task matrices on two local drives passed with identical fixtures once the working permission profile was used. The drive letter was therefore not the root cause.
• Manual trusted-path configuration edits: rejected because application-managed configuration was regenerated and such edits would not be stable or supportable.

Working solution

The decisive workaround was:

1. enable Full Access before starting the run;
2. start a fresh task after Full Access is active;
3. use the Codex In-App Browser for the qualified workflow;
4. verify task/environment binding before navigation;
5. close controlled tabs after every cycle;
6. rerun a short browser smoke test after Codex, plugin, or major Windows updates.

The qualification was coordinated with GPT-5.6 Sol, reasoning effort High, in Full Access with network enabled. No external browser fallback was used in the final qualification.

Validation and duration

The workaround was validated through fresh tasks on two local drives, repeated navigation and page-state checks, 63 successful browser cycles across the documented matrices, restart checks, repeated hash-matched downloads, a representative large CSV download repeated three times, and four negative controls. A narrowly scoped technical TradingView chart-data export canary also passed. No strategy evaluation, optimization, broker action, alert, webhook, paper trade, live trade, or source-code modification was performed.

The auditable investigation lasted approximately 30 hours elapsed across two calendar days from the first recorded connection test to the final verified technical export. This was elapsed time, not continuous hands-on time.

Conclusion

The evidence supports a regression at the sandbox/trusted-worker permission boundary rather than a target-site problem, external-browser installation problem, or general drive-letter problem. The workflow is resolved for me under Full Access + fresh task + Codex In-App Browser, but the normal sandboxed/workspace profile may still be affected.

Thank you to everyone who contributed reproductions, diagnostics, and recovery ideas here and in #39136. Special thanks to @Ali-Karaki for the concrete observation that switching to Full Access and starting a fresh task restores browser control; that was the decisive recovery path. Thanks also to @SenhuWong for the independent x64 reproduction linked above.

I am closing this report as a duplicate of #39136 while preserving this comment as confirmation of the tested workaround and its limits.