[Windows][26.903.61454] In-app PDF viewer blocked by Browser Use URL policy, leaving blank pages

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

• Installed application version: 26.903.61454, read from the installed owl-app.ini.
• Windows Store/MSIX package: OpenAI.Codex 26.903.8094.0, read with Get-AppxPackage.
• Runtime: Owl.
• These values were read from the installation, not the About dialog.

What subscription do you have?

Not included in this report.

What platform is your computer?

Windows 11, version 10.0.26200, x64.

What issue are you seeing?

The built-in browser displays a blank dark-gray area instead of its PDF reader. This reproduces with a public HTTPS PDF during Browser Use, so the reproduction does not require private files, authentication, or a local file: URL.

Public reproduction URL:
https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf

The PDF request succeeds with HTTP 200 and MIME type application/pdf. The reader's stylesheet also loads, but the built-in PDF reader document is blocked:

The main frame remains the public PDF URL; its child frame remains about:blank. No PDF toolbar, page counter, or document content appears.

Client logs at 2026-09-09T11:32:11.994Z and again after reload at 2026-09-09T11:32:59.096Z explicitly identify the rejected reader document:

warning [browser-sidebar-manager] blocked browser-use navigation
errorMessage="Blocked browser navigation by Browser Use URL policy: chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai/index.html"

What steps can reproduce the bug?

1. In the Windows desktop app, use the built-in browser through Browser Use.
2. Open the public W3C PDF above. The observed test used:

   const tab = await cua.createBrowserTab(
     "iab",
     "https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf",
     { visible: false }
   );
   await tab.getScreenshot();
   

3. The screenshot is a solid dark-gray content area; the accessibility tree contains the PDF web area and an about:blank child.
4. Reload the tab. The same blank rendering and URL-policy log recur.
5. Network diagnostics show the PDF itself succeeds while the built-in reader's index.html is blocked.

The original user-visible symptom also affects a local PDF opened manually in the browser. The same local file displays correctly through the separate artifact/file-preview surface. That comparison establishes that the file is usable, but artifact preview is not a fix for the requested browser workflow. The directly instrumented reproduction above is the public HTTPS PDF during agent control.

What is the expected behavior?

The built-in browser should display its trusted PDF reader and allow normal reading/navigation when the PDF itself is successfully loaded. If PDF browsing is unsupported, the app should show an actionable explanation instead of a blank area.

Additional information

Suspected regression window, not a confirmed introducing commit:

• The user reports PDF browsing worked yesterday or before today's update.
• Windows AppX deployment events record 26.901.6511.0 → 26.903.8094.0, completed at 2026-09-09T03:22:23Z.
• The first recorded launch of the new package is 2026-09-09T03:28:14.885Z.
• Retained client logs from August 26 onward contain earlier PDF dom-ready events, but these do not prove successful rendering. The specific reader-document denial was first captured during this September 9 reproduction.
• No downgrade, older-build reproduction, or source-history bisect was performed. Please confirm the introducing app/runtime change rather than treating this update correlation as proof.

Read-only inspection of the installed client suggests the active Browser Use navigation check admits HTTP(S) and permitted blank pages but does not exempt the built-in PDF reader's chrome-extension: subframe. This is consistent with the runtime denial above; no policy or application files were changed.

Potentially related: #43831 concerns selecting blob: PDF tabs in external Chrome, and #42302 concerns queued right-panel actions across PDF/PNG/HTTPS. This report instead has a completed PDF fetch followed by a specifically logged denial of the built-in reader document in the in-app browser.

Please route this to the desktop Browser Use/PDF integration team and identify a supported fix that preserves the intended navigation protections.

Only a public test PDF and minimal redacted diagnostic facts are included. No private PDF, user path, credentials, account details, full logs, or conversation transcript are attached.

Start with the Browser Use navigation check exercised by cua.createBrowserTab and reproduce the public W3C PDF URL while reviewing the blocked chrome-extension reader navigation. Trace how the URL policy handles the PDF subframe; done means the trusted reader renders or an actionable unsupported-PDF message appears without weakening intended navigation protections.