Limited-time offerPro & Max plans — 20% offSave 20% on monthly and yearly billing.
Save 20% on monthly and yearly billing.
Troubleshooting · Updated September 30, 2026
Codex generated the HTML, but Browser Use cannot open the local file? Use localhost for local debugging, or turn the file into an HTTPS preview URL when you need a shareable, agent-accessible page. HTMLShare is that external preview link. It is not a fix for the Codex file:// policy.
The reports quote this refusal when Browser Use is asked to open a local HTML prototype:
Browser Use rejected this action due to browser security policy. Reason: The browser URL policy blocks this action.
The public pattern is specific. Codex writes index.html or another local artifact, the user asks Browser Use to open it, the file:// URL is rejected, and the next search is the error text. The current browser docs still tell you to open a local route, a file-backed page, or a public page, and their Computer Use example uses http://localhost. That gap is why the error is confusing. It is not a claim that every Codex version on every platform blocks file://.
Issue #46729 reports Codex Desktop 26.901.6511.0 on Windows. Browser Use rejected a local HTML prototype in the in-app browser. Changing Settings > Browser did not allow the file URL. A September 30 comment on the same issue describes an unsupported-protocol rejection that names HTTP and HTTPS as the allowed schemes.
Issue #47280, opened September 22, says agent interaction had succeeded through a loopback HTTP URL. After the prototype moved into the project directory, the entry became file:// and Browser Use rejected it. A September 30 follow-up on desktop 26.924.22138 still reports navigation_url_policy_blocked for a local HTML report.
Issue #42679, opened September 4 on macOS, reports the same error with built-in browser control enabled, website approval set to Always allow, and full CDP access enabled. The user could open the HTML report manually. Later comments add Windows and Linux observations of the same split.
Issue #48009, opened September 25, says Browser Use rejected a Codex-generated local PNG file:// URL on macOS. That is an image artifact, not an HTML page. It shows the same policy language, and HTMLShare does not preview that PNG.
The reported policy accepts web URLs and rejects the file scheme. Pick the web URL that matches the job.
Keep the HTML on your machine, start the dev server, and open the loopback URL. Issue #47280 records earlier successful agent interaction on a loopback HTTP address. The current browser docs also tell you to start the development server before opening a local page.
local HTML → localhost dev server → http://localhost:…
Publish the static snapshot when the next step is a link someone else can open, including a phone, a teammate, or an agent that should not depend on your dev server. HTMLShare returns an HTTPS preview URL. It does not patch Codex.
local HTML → HTMLShare → https://…
If you already have the static page and only need a browser URL, skip the dev server:
index.html → publish with HTMLShare → preview URL → open in the browser
For a multi-file prototype, publish the static folder, not a loose HTML file that points at assets left on disk:
site/ ├── index.html ├── styles.css ├── script.js └── assets/
Use the index.html, report, dashboard, or static UI Codex already wrote. You do not need a hosting pipeline to get a review URL.
A single self-contained HTML file can upload directly. A page that references styles.css, script.js, or an assets folder should be published as that folder, with paths still relative.
Upload in the browser, or ask Codex to publish with HTMLShare after the Skill is installed. Guest limits are 1 MB HTML and 3 MB ZIP. Signed-in projects allow 5 MB for one HTML file and 20 MB overall.
Copy the preview URL and open it in a normal browser or ask Browser Use to open that HTTPS URL. Do not point the agent back at the rejected file:// address.
file://
Manual local viewing when that view is supported
Browser Use reports reject this scheme before navigation. A path on your disk is not a link someone else can open.
localhost
Active local development
Works on that computer while the server is running. A remote agent, phone, or teammate cannot use your loopback address.
HTTPS preview URL
Agent review, teammates, mobile, and client sharing
Serves the static snapshot you uploaded. It is not a Codex bug fix and it does not run your app server.
The rejection is a policy result. Publishing elsewhere does not disable it, and the issue threads say the refusal text also tells the agent not to work around it with another browser surface, raw CDP, or an indirect fetch of the same file.
It addresses a file on the computer that opened it. It is not an HTTP origin, and it does not travel to another device.
The reported refusal happens before page interaction. Comments inspecting specific desktop bundles describe a protocol allowlist, with file rejected as an unsupported protocol.
You can render the file in the in-app browser and still have Browser Use refuse to inspect that same URL. The docs describe opening a file-backed page yourself as one preview step.
The browser settings page describes Always allow as website access without an extra review step. The issue comments say origin consent is not consulted once the protocol check has already failed.
If the HTMLShare Skill is installed, ask Codex to publish the static project and then open the HTTPS URL. That is a new web address, not a second attempt at the blocked file.
Publish this static HTML project with HTMLShare and return the preview URL. Then open the HTTPS preview in the browser and verify the layout.
Install the Skill for Codex, Claude, and Cursor with npx @htmlshare/cli install --agent all, then use /htmlshare in the session. The normal publish flow is documented on Codex HTML preview.
The sharpest new reports are Windows Codex Desktop: the in-app browser, Browser Use, a local HTML prototype, and a file:// rejection. Use the same two URLs there as anywhere else.
Stay on localhost. If the only goal is local development and the loopback URL loads, you do not need HTMLShare for this error.
A phone check is a common reason to leave localhost. The agent mobile preview guide covers opening the same static HTML on a device that cannot see your loopback server.
This is the refusal sentence in the September reports. Read the reason line. For these previews it says the browser URL policy blocks the action.
For a file:// HTML URL, switch the target to an HTTP or HTTPS address. Retrying the same file URL does not change the scheme.
Treat it as a scheme restriction reported in current desktop builds. It is not evidence that the HTML file itself is invalid.
Manual rendering and agent navigation are separate. Ask the agent to open the localhost or HTTPS URL instead of the file tab.
Open the preview URL and check the browser console. A blank shell often means the entry file is not index.html, or the upload was a source folder rather than the page the browser should render.
If the HTML points at ./styles.css or ./assets/logo.png, those files have to be in the upload with the same relative paths. A lone HTML file cannot see the rest of your disk.
HTMLShare serves static files. It does not run a bundler, install packages, or start a framework server. Publish the built static output when the project needs a build.
http://localhost and http://127.0.0.1 refer to the machine running the server. Another device, a teammate, or a remote browser cannot open that address. Use an HTTPS preview for that handoff.
FAQ
Public Codex Desktop reports from September 2026 say Browser Use rejects a file:// URL for a local HTML prototype, report, or dashboard, even when the same file opens by hand. The reported error is a browser URL policy block. Those reports cover Windows, macOS, and Linux desktop sessions. They do not prove that every Codex version or surface behaves this way.
The cited GitHub issues were still open on September 30, 2026. Comments on those issues describe a shipped check that accepts http, https, and exactly about:blank, then rejects file before navigation. That is reporter evidence about specific desktop builds, not an OpenAI statement that every install blocks file:// forever. Codex CLI and the Codex IDE extension are documented as not including this browser at all.
That sentence is the error text in the local-preview reports: “Browser Use rejected this action due to browser security policy. Reason: The browser URL policy blocks this action.” For these HTML cases, the refusal is tied to the file:// URL, not to a missing index.html.
Use a URL whose scheme the browser policy accepts. For work on the same machine, start a local development server and open the http://localhost or http://127.0.0.1 address. When you need a link without that server, publish the static HTML or ZIP and open the HTTPS preview URL. You can also open a file-backed page yourself in the desktop browser; that manual view is separate from an agent Browser Use action.
Yes, when the output is static HTML, CSS, and JavaScript. Publish the file or the static folder, then open the HTTPS preview. That path does not start a dev server, and it does not change Codex. If the page needs a running app server, API, or build step, localhost is still the local debugging path.
Upload the HTML file, or zip index.html with its relative CSS, JavaScript, images, and fonts, then publish it on HTMLShare. The result is a browser URL. Guest uploads are 1 MB HTML and 3 MB ZIP. Signed-in projects accept one HTML file up to 5 MB and a project up to 20 MB.
The local-file reports describe a scheme check, not a block on every website. http and https are the schemes those comments say are accepted, and an HTMLShare preview is an HTTPS URL. Codex can still ask before it uses a new site. HTMLShare does not override Codex policy and cannot promise that a given desktop build will open the link.
Opening a tab yourself and letting Browser Use navigate are different actions. Issue reports say the in-app browser can show the file after a manual open, while the agent action is rejected. “Always allow” in Settings > Browser is a website permission. Comments on the macOS, Windows, and Linux reports say the protocol check runs before saved site consent, so that setting does not approve file://.
Use localhost when you are actively developing on that computer and the loopback URL already loads. Use an HTTPS preview when you do not want to run a server, or when a phone, teammate, client, or remote agent needs a stable link. A working localhost session is not a reason to publish.
A file:// path and a localhost URL stay on your machine. An HTTPS preview can be opened in a normal browser by someone who does not have Codex, your repo, or your dev server. Send that link for review. Keep production hosting for the version you intend to operate long term.
Publish the static HTML or ZIP, stay inside the 5 MB file and 20 MB project limits, and open the preview URL. Sign in first if the file is larger than the 1 MB guest HTML cap. Leave localhost in place when that server already answers the question.