Deep Research / Codex Browser / 15 July 2026

Can A User Permit Agent-Controlled file:// Pages?

Official documentation, current installed behavior, GitHub issue reports, web-platform guidance, and community discussion converge on one low-tech answer.

Direct answer: not currently. Adam can manually click and view a file:// page, but there is no supported user permission that allows Codex Browser automation to navigate to that scheme when the URL policy blocks it. The lowest-tech reliable solution is one reusable loopback static server, not one server per artifact.

Recommended Operating Rule

Manual View Only

Keep using clickable local file links. The official Browser documentation explicitly describes opening a file-backed page by clicking a URL or navigating manually.

Codex Must Verify

Use /start path/to/page.html. ForgeApps routes every repository HTML file through the single shared origin http://127.0.0.1:4231/ and reuses the server.

Permission To Grant

If prompted, allow 127.0.0.1:4231 in Settings > Browser. This is a normal website-origin permission. It does not grant file:// access.

Do Not Escalate

Administrator mode, workspace trust, full CDP access, alternate browser control, and disabled browser security are not supported ways to bypass the file-scheme policy.

External Results

SourceDateEvidenceConfidence
OpenAI Browser documentationCurrentWebsite access can be allowed in Settings > Browser; file-backed pages are described as user-clicked or manually navigated previews. Full CDP is a separate developer-mode control.High
openai/codex #2484728 May 2026Exact Windows reproduction: agent navigation to file:// is rejected before navigation, including in a trusted workspace and elevated sandbox. The issue remained open during this research.High for observed bug
Running Codex safely at OpenAI8 May 2026OpenAI documents localhost as an explicit bounded capability through allow_local_binding, supporting loopback as the intended low-risk local-web boundary.High
MDN: CORS request not HTTP30 Nov 2025Modern browsers often treat local files as opaque origins. MDN recommends a local server for testing so assets share one HTTP origin.High
MDN: Secure contexts30 Nov 2025http://127.0.0.1 and http://localhost are potentially trustworthy because they are delivered on the same device.High
openai/codex #2301416 May 2026Shows that Browser maintains allowed and denied website origins separately and that Windows builds have had bugs even when localhost was explicitly allowed.Medium
r/codex: Inbuilt browser is fantastic2026Community users report using the in-app browser as an end-to-end local web-app test harness; the useful pattern is web origins and user flows, not direct filesystem automation.Low / community
X topic: Codex browser improvements13 May 2026X discussion focuses on responsive testing, screenshots, annotations, and frontend test-harness improvements. No direct X post documenting a supported file:// permission or successful permission workaround was found.Low / social summary

Internal Results

Local EvidenceFindingConfidence
Installed Browser plugin 26.707.72221The plugin metadata claims local file:// targets are in scope, but the runtime URL policy rejected the navigation. This confirms a product inconsistency rather than a missing ForgeApps file.Internal-high
C:\Users\AdamK\.codex\browser\config.tomlApproval modes are already never_ask and full_cdp_access_enabled = true. No file-scheme permission exists in the installed configuration.Internal-high
ForgeApps start workflowThe repository already owns a shared local-html route on port 4231, resolves repository-relative HTML paths, and returns an encoded 127.0.0.1 URL.Internal-high
Focused verificationThe updated start guidance, Windows launch fix, and regression checks pass all 29 focused tests.Internal-high

Synthesis And Caveats