Windows: shared Browser runtime rejects bundled browser-service during trusted RPC validation

Resolved 💬 2 comments Opened Aug 19, 2026 by DukeChoi Closed Aug 19, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Windows AppX 26.814.5167.0 Bundled Browser/Chrome plugin generation 26.814.41407

What subscription do you have?

Pro

What platform is your computer?

windows 11 pro, version 25H2, OS build 26200.9168

What issue are you seeing?

The Codex Windows app can open and display an in-app Browser page, but Codex cannot bind to the Browser for inspection or interaction.

The bundled Browser runtime fails before browser binding with:

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

The explicit in-app Browser and Chrome control routes both fail at the same trusted RPC dependency validation layer. Neither route reaches tab discovery, Chrome Extension discovery, CDP, screenshot capture, coordinate interaction, semantic DOM inspection, or accessibility inspection.

The Browser and Chrome plugin copies of browser-client.mjs are byte-identical by SHA-256, so the evidence points to a shared bundled Browser runtime/trust validation defect rather than a website-specific or Chrome Extension-specific failure.

What steps can reproduce the bug?

Feedback ID: 019f6962-8ca0-78a2-ba07-ce5e6c6601ad

  1. Start Codex Windows AppX 26.814.5167.0.
  2. Open or display any page in the in-app Browser.
  3. Ask Codex to inspect or interact with the page.
  4. Codex loads bundled browser-client.mjs from Browser plugin generation 26.814.41407.
  5. Browser-client attempts to initialize the bundled browser-service.mjs.
  6. Trusted RPC dependency validation rejects browser-service.mjs before Browser binding.
  7. Repeat using the explicit Chrome control route.
  8. The same failure occurs before Chrome binding or Extension discovery.

This reproduces on every attempt.

What is the expected behavior?

Codex should trust and initialize its own bundled browser-service.mjs, bind to the selected in-app Browser or supported Chrome session, and allow screenshot, coordinate, semantic DOM, accessibility, and page interaction APIs to operate.

Opening and displaying an in-app Browser page should be followed by a successful controllable Browser binding.

Additional information

Previously working baseline:
The same semantic, non-coordinate in-app Browser workflow worked on 2026-08-07 with Browser plugin generation 26.803.41515.

Recovery attempts already completed:

  • Codex restart
  • Full Windows reboot
  • Plugin cache re-materialization
  • Windows App Repair
  • AppX re-registration
  • Controlled trust-path/configuration experiments followed by rollback
  • Official-default-only configuration experiment
  • Official Microsoft Store clean reinstall

The defect still reproduces with AppX 26.814.5167.0 and plugin generation 26.814.41407.

The diagnostic bundle contains no credentials, tokens, cookies, raw configuration, patient data, or private application data.

OPENAI_CODEX_BROWSER_TRUST_DEFECT_BUNDLE_V2_20260819.zip

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 9 days ago

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

  • #39399
  • #39387
  • #39318
  • #39252
  • #39136

Powered by Codex Action

DukeChoi · 9 days ago

GitHub issue #39407 close comment

Closing this as a duplicate of #39318.

The AppX version, bundled Browser plugin generation, exact trusted RPC error, and failure before in-app Browser/Chrome binding are the same. Additional feedback-session and redacted evidence will be added to #39318 so the reports remain consolidated.