Windows / Chrome Browser Use: URL policy blocks user-opened blob PDF tabs, preventing authorized professional document workflows

What version of the Codex App are you using?

Installed application version: 26.901.51231, read from the installed owl-app.ini.
Windows package: OpenAI.Codex 26.901.6511.0, read with Get-AppxPackage.
These are installation values, not an About-dialog observation.

What platform is your computer?

• Microsoft Windows 11 Home, version 10.0.26200, 64-bit.
• Installed Google Chrome: 152.0.7977.76.
• Codex Browser Use connected to ordinary Chrome through the extension backend.
• Observed again on September 8, 2026 (America/Buenos_Aires, UTC-03:00).

What issue are you seeing?

Codex can discover an already-open PDF tab from an authenticated professional website, but selecting that tab through Browser Use is rejected by URL policy before the agent can inspect the PDF or reach its download controls.

The affected workflow is viewing PDF docket entries in the SED judicial portal of Salta, Argentina. Public site origin: https://plataforma.justiciasalta.gov.ar. The tab URL has this redacted form:

blob:https://plataforma.justiciasalta.gov.ar/<redacted-object-id>

The user reports that the PDF displays correctly in Chrome. The directly observed agent failure is the URL-policy rejection; no PDF corruption, generation failure, or rendering defect has been established.

This is a website-provided PDF in Chrome, not a ChatGPT-generated attachment or a sandbox: download link.

Observed reproduction

1. The user has already opened a PDF docket entry in their ordinary Chrome session.
2. In Codex, call cua.getState(). Chrome is available with backend type extension, and the open blob: PDF tab is listed.
3. Select the exact tab ID and browser ID returned by that discovery:
   await cua.getTab("<observed-tab-id>", { browser: "<observed-browser-id>" });
4. The tool rejects the operation:

Browser Use rejected this action due to browser security policy. Reason: The browser URL policy blocks this action. Browser use cannot visit the requested page because its URL is blocked by the Browser use URL policy. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

No subsequent download-button click was attempted in this reproduction because selecting the tab was already blocked. Thus the evidence demonstrates an upstream access block that prevents continuing to read/download; it does not establish a separate download subsystem defect.

This is an observed reproduction in the affected workflow, not a claim that all blob PDFs or all websites fail. No synthetic public reproduction has yet been tested.

Professional impact

I use Codex in daily professional work involving judicial documents. Being able to view a document myself while Codex cannot access the same authorized document interrupts document review and analysis. Having to manually download and attach individual documents shifts repetitive work back to me and substantially reduces the usefulness of the browser integration for this workflow.

This is a recurring practical limitation for my work, not merely a cosmetic error message.

Expected behavior / request

Please triage this with the Codex Desktop Browser Use / Chrome integration team:

1. Clarify whether access to already-open blob: PDF tabs is intentionally unsupported or affected by a defect, and identify the relevant restriction.
2. Provide a supported, appropriately scoped way for the user to authorize read-only access or transfer the selected PDF to Codex while preserving website/session boundaries.
3. If direct access is intentionally unavailable, expose a clear supported user handoff or document-import action instead of leaving the workflow at a generic denial.
4. Track the compatibility request and communicate any documented resolution or planned support.

I am requesting a supported product capability, not instructions to disable or bypass protections.

Related reports and privacy

#42699 concerns blob iframes after navigation in the macOS in-app browser; #24847 concerns file URLs on Windows. They may help routing, but neither establishes the same failure or root cause.

No judicial documents, docket numbers, party names, account details, credentials, cookies, session identifiers, full browser inventory, or private logs are included. Only the public portal origin, redacted URL shape, installation versions, and tool error are reported.

Start by tracing the Browser Use URL-policy check reached by cua.getTab after cua.getState lists an extension-backed blob PDF tab. Determine whether user-opened blob URLs are intentionally rejected and identify the supported authorization or handoff path. Done means the behavior and supported workflow are defined and verified with an appropriate regression test.