[macOS][Codex Desktop] file:// tabs are renderable and annotatable, but Browser Use blocks read-only inspection

Summary

Codex Desktop applies contradictory access policies to the same user-opened file:// tab:

the in-app Browser opens and renders the local HTML;
browser.user.openTabs() lists the tab with its exact file:// URL;
Comment with Codex exports the selected text, DOM selector, node position, and a rendered marker screenshot from that page;
Browser Use then rejects read-only DOM inspection, screenshots, reload, and evaluation with a URL-policy error.

This is not a missing file or failed initial navigation. The page is already open, visible, annotatable, and discoverable when Browser Use reports that it cannot visit it.

#24847 reports the underlying file:// policy rejection on Windows and includes a macOS confirmation. This issue adds a current macOS reproduction and isolates the sharper contract failure between opening, annotation, acquisition, and read-only Browser Use inspection.

Private diagnostic correlation

Feedback ID: 019fbfef-fc24-7bb3-a813-fc96a70f1794

The in-app feedback report includes the current Codex session logs plus all browser tabs and browser logs.

Environment

Codex Desktop / ChatGPT.app: 26.727.51351 (build 6119)
Browser plugin: 26.727.51351
codex-cli: 0.146.0-alpha.9.2
macOS 27.0 beta, build 26A5388g, arm64
Platform output: Darwin 27.0.0 arm64 arm
Browser backend: Codex in-app Browser (iab)
Browser configuration: full_cdp_access_enabled=true
Reproduced previously with codex-cli 0.144.2 and again with 0.146.0-alpha.9.2

Reproduction

Open a local HTML artifact in the Codex in-app Browser with a file:// URL. The page renders normally.
Call browser.user.openTabs(). The returned tab contains the exact local file:// URL.
Use Comment with Codex on an element in that page. Codex receives the page URL, DOM selector, node position, selected text, and a rendered marker screenshot.
Ask Browser Use to inspect that already-open tab.

Acquisition followed by domSnapshot() and screenshot() is rejected with:

Browser use cannot visit the requested page because its URL is blocked by the Browser use URL policy.

Explicitly select the in-app Browser and retry acquisition followed by reload() and read-only evaluation. The same policy rejection occurs.

The failure is reproducible with a normal local artifact; it does not depend on malformed HTML or a missing file.

Actual behavior

The Desktop UI and annotation path can render and transfer structured evidence from a user-opened file:// page, while Browser Use cannot inspect that same page. The error says Browser Use cannot visit a page that is already open and visible, obscuring the operation that was actually denied.

Expected behavior

A file:// tab explicitly opened by the user in the in-app Browser and shared through Comment with Codex should support read-only Browser Use inspection, including DOM snapshots and screenshots.

Opening, annotation, tab acquisition, and Browser Use should share one coherent access decision for the same page.

Likely policy seam

This section is an inference from the currently bundled browser client, not a claim that each internal command completed independently:

browser selection routes file: URLs to the in-app Browser;
the command URL predicate accepts about:blank, http:, and https:, but not file:;
browser_user_claim_tab is in the no-check command set;
subsequent current-tab reads are URL-policy checked.

That makes the likely failing operation the first DOM/read/reload command after acquisition, rather than tab discovery. The combined acquisition-plus-read calls in the session logs are the observed evidence.

No matching implementation symbol or error literal is present in the public openai/codex repository, so this policy appears to live in the bundled Desktop/Browser layer rather than the public app-server Browser Use configuration surface.

Impact

This blocks agent visual QA of local HTML artifacts inside Codex Desktop. It also drives misleading recovery attempts because the product reports a visit failure even though the page has already been opened and partially exposed to Codex through annotations.

Serving every static artifact through localhost changes the workflow and does not repair the contradictory authorization contract for a user-opened local tab.

Acceptance criteria

One of these product contracts should be made coherent:

Preferred: allow DOM snapshots, screenshots, and other read-only inspection for user-opened file:// tabs whose files are inside approved workspace or artifact roots.
Alternatively, provide a first-class local-artifact origin shared by opening, annotation, and Browser Use.
If file:// inspection is intentionally prohibited, align the UI and annotation affordances with that restriction and report the exact blocked operation. Do not say that Browser Use cannot visit an already-open page.

Whichever contract is chosen, add a regression covering this sequence:

open local artifact -> list tab -> annotate element -> acquire tab -> inspect DOM -> capture screenshot.

Feedback correlation update

Feedback ID 019fbfef-fc24-7bb3-a813-fc96a70f1794 now also contains the exact cross-report audit of Codex passivity, unnecessary permission-seeking, and model-dependent tool failures discussed after this reproduction.

That audit found at least 11 directly relevant public issues. The important technical conclusion is not simply that Sol is cautious. Several different failure boundaries currently collapse into the same user-visible behavior: Codex refuses to act, claims that a tool is unavailable, or asks the user to authorize something already authorized.

Boundaries isolated in this incident

This task produced three separable failures:

Model/instruction-handling failure: the user explicitly asked Codex to use Chrome. That request already authorized launching Chrome for the task. Codex instead converted a disconnected provider into another permission/setup question and incorrectly suggested that the extension might need installation.
Provider lifecycle state: Chrome and the extension were installed correctly. The Chrome provider was absent only while Chrome was not running; launching Chrome registered the provider without any installation or configuration change.
Product policy failure: after the Chrome provider became available, the independent hard file:// URL-policy denial remained. The same denial also affected the in-app Browser despite the page being rendered, discoverable, and annotatable there.

The current product and model behavior do not reliably distinguish these states. A user therefore receives variations of “tool unavailable,” “permission required,” or “cannot visit” for failures owned by different layers.

Related controlled evidence

Browser and Chrome plugins unavailable with gpt-5.6-sol but work with gpt-5.6-terra #33592: Browser and Chrome are unavailable with Sol but work with Terra on the same installation; the issue contains independent macOS and Windows confirmations.
gpt-5.6-sol drops Codex Desktop thread-management tools that are available on gpt-5.6-terra in the same task #33637: same-task A/B/A registry evidence shows Terra -> tools present, Sol -> tools absent, Terra -> tools present with no permission, working-directory, or task change.
GPT-5.6-Sol skips ClickUp Get task and can fabricate an answer while Terra/Luna invoke it #33646: across 12 fresh Sol tasks, Sol skipped an explicitly requested ClickUp read call or claimed it was unavailable, while Terra and Luna invoked it. The report was later closed after the routing recovered.
Codex 5.6 GitHub connector regression: fails to use valid branch-write access that works under 5.5 #36042: the 5.6 path claimed it could not update a GitHub PR branch; 5.5 used the same connector and permissions successfully.
Codex asks for permission despite full access and approval prompts disabled #29235: Codex asks permission despite Full Access and disabled approval prompts; it currently has 13 thumbs-up reactions and several detected related reports.
Terra and luna stop their turn without doing anything #34033: Terra and Luna can also terminate turns without executing, so premature passivity is not Sol-only.

These reports support two distinct defect classes:

tool-surface construction/routing: the selected model genuinely receives a different callable registry;
tool-selection and authorization reasoning: the tool is callable, but the model declines to use it, invents a permission gate, or ends the turn without acting.

Diagnostic and regression requirements

Feedback bundles and per-turn telemetry should make the boundary mechanically identifiable. For each affected turn, record:

selected model and routing path;
hash or inventory of the model-visible tool registry;
plugin/provider discovery result;
whether a provider is installed, connected, or merely not running;
active approval policy and permission profile;
the exact component that denied an operation: model decision, tool registry, provider connection, approval layer, or URL policy;
the first denied command after tab acquisition, rather than only the final generalized error.

User-facing errors should also use distinct states instead of collapsing them:

tool_not_exposed_for_model
provider_not_connected
confirmation_required
operation_denied_by_url_policy

A regression matrix should run the same authorized tool task across Sol, Terra, Luna, and the current previous-generation control model while holding the task, permissions, plugin installation, and provider state constant. At minimum, cover Browser/Chrome, Codex thread tools, one connector read, and one connector write.

For the specific issue reported here, the acceptance test remains:

open local artifact -> list tab -> annotate element -> acquire tab -> inspect DOM -> capture screenshot

The broader model/tool regression should not obscure that deterministic file:// policy defect, but it explains why recovery in the originating task became needlessly permission-gated and misleading.

Additional macOS reproduction: 26.901.51231 (build 8109)

This is another reproduction of the user-opened local HTML / Browser Use policy mismatch, observed on 2026-09-08. The user also reports similar failures in other projects.

Environment verified for this reproduction

Installed desktop bundle: ChatGPT.app, running a Codex desktop task.
App version: 26.901.51231; build: 8109, read from the installed app's Info.plist (not copied from another report or the About dialog).
OS: macOS 26.5.2; Darwin 25.5.0 arm64.
Browser backend: the built-in browser (iab).
Tool interface: mcp__cua_repl.js using the documented cua APIs.
The account tool reports planType: prolite; the human-readable subscription label in the UI was not independently verified.

What was directly observed

A local HTML report exists inside the current project's writable workspace. Reading and editing that file through filesystem tools works.
The user opens the report in the built-in browser.
Browser discovery succeeds. cua.listTabs() for the discovered in-app browser returns the existing tab, its document title, and its file:// URL.
Calling cua.getTab() with the exact returned tab and browser IDs is rejected:

Blocked browser navigation by Browser Use URL policy: file:///<private-path-redacted>

The documented getTab() wrapper also returns initial page state. This reproduction therefore establishes failure of that combined operation; it does not isolate handle acquisition from the automatic initial-state read.

Earlier in the same task, opening another local HTML report directly through cua.createBrowserTab() also returned:

Browser Use rejected this action due to browser security policy.
Reason: The browser URL policy blocks this action.

No independent DOM snapshot or browser screenshot succeeded after the rejection. Filesystem checks, direct SVG rendering, and DOM-library tests were possible, but they do not verify the actual browser layout or native browser interactions.

Cross-project scope and limitations

User-reported: similar browser-access failures also occur in other projects.
Directly verified here: the sequence above in this project, including successful tab discovery followed by the URL-policy denial.
The other projects' exact errors and settings have not been compared independently.
A separate minimal HTML reproduction has not been tested.
The current website-approval and full-CDP settings were not independently inspected in this reproduction. The settings described in Browser Use blocks a local file URL despite “Always allow” approval settings #42679 are not being presented as verified settings for this machine.
The private document, filenames, absolute paths, account data, and financial contents are intentionally omitted. No feedback ID from someone else's report is being reused.

Impact and requested clarification

This interrupts visual development of local HTML artifacts: the file can be edited, and the user-opened tab can be discovered, but the agent cannot inspect the rendered result. The cross-project reports suggest that investigation should not assume one malformed document, although they do not establish a common root cause.

Could a maintainer clarify:

Is read-only Browser Use inspection of user-opened file:// pages intentionally unsupported?
If access is supported for approved workspace/artifact files, which supported setting or recovery procedure enables it?
If this is a bug, can the regression cover user opens local HTML -> list existing tab -> acquire/read initial state -> inspect DOM/screenshot?
Can the denial identify the rejected operation and policy layer, rather than describing every failure as navigation to a page that is already open?

The official browser documentation describes manual preview of file-backed pages. Clarifying the distinction between that workflow and agent inspection would help avoid repeated, ineffective permission changes.

Related reports: #24847 and #42679.

Additional macOS observation on desktop 26.901.51231 (build 8109), bundled CLI 0.153.4, recorded September 8, 2026.

Opening an existing, user-authorized local HTML report through the documented Browser Use file URL path returned a Browser Use URL policy refusal. The local file is readable through filesystem tools. The existing browser configuration had full_cdp_access_enabled=true; this did not make file URL navigation permissible. No private path is included, and this report does not claim a new reproduction at a substituted example path.

Separately, a temporary report-only HTTP server could be read, screenshotted and navigated through the supported in-app browser. That demonstrates a working HTTP reading path, not successful file URL inspection or a resolution of this issue. The temporary server and browser tab were closed afterwards.

Could maintainers provide the supported contract for read-only inspection of user-authorized local HTML, including its rendered screenshot and relative attachment navigation? If file URL inspection is intentionally unavailable, please distinguish the exact denied operation and expose a first-party artifact preview capability with an explicit proof boundary. For our acceptance, an HTTP conversion or queued open request cannot be labeled as a native/file URL validation.

General host-app Computer Use remains separately prohibited by documented safety guidance; a request for a bounded Markdown artifact-preview API is being discussed in #23452. No private document, financial content, local path, account detail, configuration, full conversation or logs are attached. We did not bypass the URL policy or use an alternate browser surface to inspect the denied URL.

Additional verified macOS reproduction on September 9, 2026, with desktop app 26.901.51231 (build 8109) and the bundled CUA interface.

The user opens a local HTML artifact in the built-in browser and can send element annotations with screenshots. cua.getState() discovers the existing tab. Selecting that exact tab with the documented cua.getTab(tabId, { browser: browserId }) returns:

Blocked browser navigation by Browser Use URL policy: file:///<private-path-redacted>

getTab() includes an initial state read; this observation does not independently isolate acquisition from that read. No DOM inspection, screenshot, reload or UI interaction succeeded after the rejection. This was reproduced on the actual existing artifact; the redacted path above is not a separately tested example.

The user reports that permissions are enabled. This report does not claim an independent audit of every setting. Earlier successful project QA used a separately launched browser, so it does not establish a regression of the same CUA path or identify a first-bad version.

There is a documentation/behavior inconsistency worth clarifying: the April 23 changelog explicitly describes Codex operating file-backed pages in the built-in browser for UI interaction and visual verification. The current Browser documentation also documents file-backed page preview and annotations.

Could the Browser/Desktop team confirm the intended support contract and provide a supported fix or release reference for the exact sequence user opens local artifact -> lists tab -> annotates -> CUA selects/reads tab -> inspects rendered page? If agent access to file-backed pages is intentionally unsupported, please reconcile the public capability description and expose an explicit supported artifact-inspection path.

This blocks visual acceptance of generated HTML. A successful tool connection or a passing code test is not rendered-page verification. No URL conversion, alternate browser, policy modification or workaround was used in this reproduction.

Only installation version, redacted error, reproduction steps and public documentation links are included. No project names, local paths, source code, media, account details, conversation transcript, private logs or bundled application code are attached.

Additional macOS confirmation on September 11, 2026, using the bundled cua_repl interface and the Codex in-app browser.

Current installation: desktop app 26.908.31457, build 8690.

The agent attempted cua.createBrowserTab('iab', fileUrl, {visible: true}) for a real local HTML document. It was rejected with:

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 response also explicitly prohibited achieving the same outcome through workarounds or alternate browser surfaces. A later user-requested retry through the original interface produced the same rejection. No rendered inspection succeeded.

We initially suspected the latest update, but checked the earlier session before concluding that:

On September 10, the same thread already received the same rejection twice when creating a file:// tab for another local HTML document, and once when selecting its existing tab with cua.getTab(...).
A read-only inspection of the September 10 Time Machine snapshot identified the previous app as 26.903.61454, build 8378. Both that app and the current app contain the same URL-scheme predicate accepting about:blank, HTTP and HTTPS, and the same denial classification. The old app was not launched or restored over the current installation.

This is evidence that the symptom predates the September 11 update on this machine, not evidence identifying the first affected release. Successful native app inspection and static HTML checks must not be confused with successful Browser Use inspection.

The denial wording also creates a recovery dead end. The user explicitly requested that the agent start a local server and test the HTML through localhost. The agent refused because the preceding file-URL rejection prohibited achieving the same outcome through alternative routes. This blocked the requested localhost workflow before any server was started or localhost browser request was attempted. The user also proposed Playwright, which the agent likewise declined under that prohibition. The observed failure is therefore a policy-message-driven refusal to execute the requested recovery, rather than a localhost connection failure or a rejection returned by Playwright. From the user's perspective, both alternative workflows were unavailable despite explicit authorization for a legitimate local HTML check.

Could maintainers clarify the intended support contract for local HTML and explicitly distinguish an unsupported URL scheme from a denied resource? In particular, please clarify whether the normal local development-server workflow is a supported recovery from a file:// scheme rejection, and make that distinction actionable in the tool response.

Only version numbers, redacted reproduction details and observations are included here. No private paths, HTML contents, screenshots, session logs or bundled source code are attached.

Navigation Menu

Repository navigation

[macOS][Codex Desktop] file:// tabs are renderable and annotatable, but Browser Use blocks read-only inspection #36552

Summary

Private diagnostic correlation

Environment

Reproduction

Actual behavior

Expected behavior

Likely policy seam

Impact

Acceptance criteria

Feedback correlation update

Boundaries isolated in this incident

Related controlled evidence

Diagnostic and regression requirements

Additional macOS reproduction: 26.901.51231 (build 8109)

Environment verified for this reproduction

What was directly observed

Cross-project scope and limitations

Impact and requested clarification

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[macOS][Codex Desktop] file:// tabs are renderable and annotatable, but Browser Use blocks read-only inspection #36552

Description

Summary

Private diagnostic correlation

Environment

Reproduction

Actual behavior

Expected behavior

Likely policy seam

Impact

Acceptance criteria

Activity

Allmight97 commented on Aug 2, 2026

Feedback correlation update

Boundaries isolated in this incident

Related controlled evidence

Diagnostic and regression requirements

samulee003 commented on Sep 8, 2026

Additional macOS reproduction: 26.901.51231 (build 8109)

Environment verified for this reproduction

What was directly observed

Cross-project scope and limitations

Impact and requested clarification

luftcc commented on Sep 8, 2026

dengxianghua888-ops commented on Sep 9, 2026

ThisMakesSenseToMe commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions