Browser URL denial prohibits recovery via previously authorized methods, without scoped approval or escalation

Summary

A Browser Use URL denial can turn a rejected access method into an apparent prohibition on completing otherwise authorized local-preview work through a previously successful method. Please provide a narrowly scoped denial and an explicit supported recovery/approval path.

This is a report about denial semantics and agent recovery behavior, related to #24847 but distinct from requesting file:// support itself.

Environment

• ChatGPT desktop / Codex on macOS 26.6.2, Apple Silicon.
• Installed app version 26.903.71938, build 8576, read from the application Info.plist.
• Subscription: not included.
• Observed September 11, 2026.
• Browser Use via the in-app browser.

Observed sequence

1. In the same conversation, the agent successfully opened and inspected two generated HTML previews through local HTTP servers (127.0.0.1). Actual browser accessibility output confirmed success.
2. For another generated visualization, the agent later attempted a direct file:///…/preview.html URL.
3. That request returned the denial below.
4. The user explicitly authorized completing the verification and asked to reuse the previously successful local HTTP approach.
5. The agent refused on the basis of the denial's prohibition on alternate routes to the same outcome, repeatedly reporting that approval could not resolve it.
6. The agent produced a static PDF substitute, which did not establish the original HTML's rendering or interaction behavior. The original verification remains unfinished.

Important limit: the rejected visualization was not subsequently tested through localhost. This report does not claim that an HTTP request was technically blocked or that every earlier preview used the identical artifact. The demonstrated failure is the tool wording and resulting agent behavior, not proven retroactive revocation of a network permission.

Exact denial

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.

Expected behavior / requested change

Distinguish a prohibited destination or action from a rejected URL scheme or access method.

A method-specific denial should not automatically prohibit reusing a previously established, authorized method for the same family of work. If the destination or underlying action is prohibited across methods, state that scope, the relevant reason, and whether it can be resolved by the user or an administrator.

Provide an actionable recovery path where policy permits: for example, a scoped user approval or re-evaluation of the established method. Asking for input is misleading when even explicit approval has no effect and the agent has no escalation mechanism.

The user's preference is that previously established methods remain usable unless there is a specific reason to revoke them. Requiring approval before seeking genuinely new methods would be a more understandable boundary than treating every alternative as circumvention. This is product-design feedback, not a request to disable genuine destination/action restrictions.

Impact and diagnostics

A routine local visualization check became repeated refusal, explanation and user intervention. No reason was given establishing that the generated file itself was unsafe.

No explicit browser_use restriction was present in the inspected user configuration; the checked local requirements files were absent. This does not exclude app-held or remotely managed policy.

Official guidance documents local preview workflows and site permission controls: https://learn.chatgpt.com/docs/browser

Please clarify whether the denial is intended to block all methods of accessing the artifact, whether the agent overinterpreted its scope, and how an already-authorized workflow is supposed to recover.

No private files, absolute user paths, session transcripts, account identifiers, credentials, or screenshots are attached.

Start by reviewing the Browser Use URL policy and the documented local preview workflows linked in the issue. Clarify whether the denial applies to a destination, an action, or only a URL scheme, then define a supported scoped approval or escalation path; done means the policy wording and recovery behavior no longer imply that every alternate method is circumvention.