Codex Desktop Windows Browser Use blocks file:// file-backed previews with URL policy #24847

Activity

1. etraut-openai

   added

   bugSomething isn't workingSomething isn't working

   on May 29, 2026
2. swartzrock commented on Jun 12, 2026

   

   swartzrock

   on Jun 12, 2026

   More actions

   also reproduces on macOS in Version 26.608.12217, big blocker in productivity. This feature works find in Claude.app, which can view the html files generated in a chat.

   👍React with 👍3Reacted by Jun Wang, Tomáš Hübelbauer and Giorgio Giudetti
3. TomasHubelbauer commented on Jun 29, 2026

   

   TomasHubelbauer

   on Jun 29, 2026

   More actions

   Very weird behavior, there is no point in running a server for any old random HTML report.
4. MieTakahashi2 commented on Sep 5, 2026

   

   MieTakahashi2

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   Also reproducing on macOS with Codex Desktop 26.901.41123 (build 7942), checked on 2026-09-05.

   An existing, user-authorized local HTML file inside the project workspace is rejected before navigation with a Browser Use URL policy error. Opening a public HTTPS documentation page and capturing its screenshot succeeds through the official in-app browser tools.

   Browser is enabled and website approval is set to Always allow. Restarting the app and retrying with Full Access enabled did not resolve the rejection.

   This blocks visual verification of generated HTML. The rejection also explicitly instructs the agent not to use workarounds or alternate browser surfaces, so the agent stops rather than trying the localhost approach mentioned in the issue.

   Could maintainers clarify the supported remediation for file-backed previews, and whether serving the same workspace preview over localhost is an intended, permitted alternative despite that rejection message?

   👍React with 👍2Reacted by Giorgio Giudetti and Finn Lau
5. 7ammad commented on Sep 8, 2026

   

   7ammad

   on Sep 8, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed on Windows with browser plugin 26.901.51231. The plugin description explicitly includes file:// targets, while browser-service.mjs accepts only about:blank, http:, and https:. Navigating to a local workspace HTML report produces navigation_url_policy_blocked. Please provide supported access to authorized workspace HTML previews and align the documented capabilities with runtime behavior.

   👍React with 👍1Reacted by Finn Lau
6. 1wgrumph commented on Sep 8, 2026

   

   1wgrumph

   on Sep 8, 2026

   More actions

   Origin

   OpenAI bundled browser integration; not project-defined policy.

   Harness / version

   Codex CLI 0.153.2; browser plugin 26.831.20005; Linux.

   What

   Opening a local HTML file through the browser tool produces navigation_url_policy_blocked, although the plugin manifest explicitly advertises file:// support.

   Current evidence

   The failure occurred during an explicit user request. Installed runtime inspection found that nv() permits only HTTP, HTTPS and about:blank; G5() enforces that check. The rejection also prohibits alternate execution paths. No workaround was attempted.

   This confirms an advertised-capability/runtime mismatch, without establishing whether local-file support or the documentation should change.

   Expected

   Advertised capabilities and enforced URL policy agree. Errors distinguish unsupported functionality from user-configured restrictions.

   Acceptance

   Add regression coverage for local-file navigation and align the manifest, implementation and error guidance with the intended behavior.
7. thapro73-cpu commented on Sep 9, 2026

   

   thapro73-cpu

   on Sep 9, 2026 – with ChatGPT Codex Connector

   More actions

   Also reproduced on Windows on 2026-09-10 with Codex Desktop package OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0.

   An existing, user-authorized HTML file in the project workspace displays normally when opened directly by the user in the in-app browser. However, cua.createBrowserTab("iab", "file:///.../leaderboard.html", {visible:true}) is rejected before navigation with navigation_url_policy_blocked. The path above is a redacted placeholder, not a real user path.

   Read-only inspection of the installed URL validator found that it accepts only about:blank, http: and https:, separately from site-approval settings. This is a URL-scheme rejection, not a missing or broken HTML file. No policy bypass or security changes were attempted during this diagnosis.

   Could maintainers clarify the officially supported way to automatically display user-authorized workspace HTML, and whether a fix or supported permission mechanism is planned? If this restriction is intentional, please align the documented capabilities and error guidance so users are not directed to unrelated Windows security or broader access settings.

   No project data, screenshots, credentials, full local paths, or session logs are attached.
8. NovaSabre commented on Sep 10, 2026

   

   NovaSabre

   on Sep 10, 2026

   More actions

   Still reproducible on Windows on September 10, 2026, with Codex Desktop package version 26.903.9818.0 (verified using Get-AppxPackage).

   In an active local project, Codex can read and edit workspace files, but the bundled Browser Use tool rejects opening an existing, user-authorized SVG reference sheet via file:// before navigation. The selected backend was the Codex in-app browser. The task had unrestricted filesystem access and network access enabled.

   Redacted reproduction:

   1. Keep an existing SVG reference sheet inside the active project workspace.
   2. Ask Codex to open it using the in-app browser, for example file:///C:/example-project/docs/reference-sheet.svg (placeholder path only).
   3. Browser Use rejects the navigation with: "The browser URL policy blocks this action."

   The rejection also explicitly instructs the agent not to achieve the same outcome through workarounds or alternate browser surfaces. This leaves the agent unable to perform the visual verification required before implementing the planned icon change. No bypass or security-setting changes were attempted.

   Could maintainers confirm whether this is a known unresolved bug or an intentional restriction? What is the officially supported way to inspect user-authorized local SVG/HTML previews, and is a fix planned? In particular, is serving a preview through localhost a supported alternative despite the rejection message's prohibition on workarounds?

   No project names, real local paths, credentials, account identifiers, screenshots, or session logs are included. This comment was prepared and posted by Codex with the account owner's explicit authorization.
9. Bagh13nrv commented on Sep 21, 2026

   

   Bagh13nrv

   on Sep 21, 2026

   More actions

   Additional reproduction on Windows, observed on September 21, 2026.

   Verified behavior

   • Two existing HTML previews in the active local workspace are visible to the user in the Codex in-app browser.
   • The agent can list browser tabs, but selecting the existing file-backed tab with getTab, or opening its URL with createBrowserTab, is rejected before inspection with: The browser URL policy blocks this action.
   • The same tool can open and inspect the public HTTPS OpenAI Help Center and interact with its support chat. Browser connectivity is therefore not completely unavailable.
   • The navigation permission displayed in settings is "Always allow". An app update followed by another attempt did not resolve the local-file refusal.
   • The site-permission form rejects a complete file:/// URL as an invalid origin. We understand that the documented origin rules cover HTTP/HTTPS; this does not provide an authorization path for the existing local preview.

   Environment and scope

   • Windows desktop; Codex in-app browser.
   • Application package version identified in the error stack before the update: 26.915.3509.0.
   • Browser/computer-use plugin version observed after the update: 26.915.31945. This is a plugin version, not a claim about the current app version.
   • Impact: visual verification of local HTML learning materials is blocked. No production outage or data loss is claimed.

   Recovery guidance needing clarification

   The tool's rejection explicitly prohibits achieving the same outcome through workarounds, indirect execution, raw CDP, or alternate browser surfaces. The Help Center AI suggested serving the files on localhost, but could not reconcile that suggestion with the prohibition or confirm a tracked support case. We have not applied that workaround after the denial, and the chatbot's suggestion is not treated as permission to bypass policy.

   Could maintainers clarify whether agent inspection of authorized local file-backed previews is supported, and provide the intended recovery/approval path or corrective release? In particular, please align the refusal guidance with any officially supported alternative. Related recovery concern: #44881; related visible-preview/blocked-inspection report: #36552.

   This report was posted by Codex with the account owner's explicit authorization. No course contents, student data, personal filesystem paths, account/session identifiers, screenshots, credentials, or full logs are included. We have not established whether the underlying cause is an intentional scheme restriction or a regression.
10. diegoscl commented on Sep 27, 2026

    

    diegoscl

    on Sep 27, 2026

    More actions

    Additional reproduction on macOS, observed September 27, 2026.

    Verified behavior

    • A local HTML slide deck was already visible in the Codex in-app browser at a file:// URL.
    • Browser Use could list the iab browser and the existing tab.
    • The agent then attempted to select/reload that tab and read a DOM snapshot. The call was rejected before any page content or screenshot was available:

    Browser Use rejected this action due to browser security policy. Reason: The browser URL policy blocks this action. The requested URL protocol is not allowed. Allowed protocols: "http:", "https:".

    The refusal also prohibited workarounds, indirect execution, raw CDP, and alternate browser surfaces. We did not attempt another route after that refusal.

    Environment and impact

    • macOS 27.0 (build 26A428).
    • Codex in-app browser with the browser@openai-bundled client bundle 26.924.22138.
    • The affected task was visual verification of a locally generated 22-slide HTML deck. The agent could edit the deck and check its structure, but could not confirm the final layout visually.

    Could maintainers clarify whether Browser Use is intended to inspect an existing, visible file:// tab on macOS? If file-backed previews are unsupported, what is the approved path for agent-assisted visual verification when the refusal explicitly forbids alternate routes?
11. speedraj108 commented on Oct 9, 2026

    

    speedraj108

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows observation, verified on 2026-10-09, posted with the account owner's explicit authorization.

    Confirmed behavior

    An existing, user-authorized local HTML design preview opens visibly for the user. The original recorded Browser Use result for cua.createBrowserTab("iab", "file:///…/preview.html", {visible:true}) rejects the request before inspection:

    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. The requested URL protocol is not allowed. Allowed protocols: "http:", "https:".

    The same tool result explicitly prohibits workarounds, indirect execution, raw CDP/browser commands, and alternate browser surfaces. This was verified from the original tool return, not merely an assistant's later explanation. The placeholder URL above is redacted.

    Version evidence

    • Windows installed Appx package: OpenAI.Codex, version 26.1002.7124.0.
    • The app's information-only update tool reports installedVersion: 26.1002.52244, build 13536, release channel prod.
    • These are distinct reported version fields; we are not assuming they must match.
    • Update eligibility remains unknown: the information-only checker deferred to Microsoft Store. No update was installed and no security settings were changed.

    Requested actionable recovery

    The official Browser guide describes local development-server previews and browser-assisted visual review. The current refusal leaves no clear supported recovery for this authorized preview.

    Could maintainers provide:

    1. The intended distinction between unsupported file: navigation and a denied origin/resource.
    2. A supported permission or migration path to ordinary local-development visual review after this refusal, including whether a narrowly scoped loopback preview is allowed.
    3. A fixed version or concrete remediation, if this is a defect.

    The practical impact is interrupted visual iteration and repeated manual screenshot work. We are not requesting removal of security checks or claiming that all Chromium/HTTP workflows are prohibited. No private HTML, images, screenshots, filesystem paths, credentials, conversation history, or full logs are included.