›_ Codex Issues
Codex Issues / #36552

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

Open 💬 1 comment Opened Aug 2, 2026 by Allmight97

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

  1. Open a local HTML artifact in the Codex in-app Browser with a file:// URL. The page renders normally.
  2. Call browser.user.openTabs(). The returned tab contains the exact local file:// URL.
  3. 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.
  4. Ask Browser Use to inspect that already-open tab.
  5. Acquisition followed by domSnapshot() and screenshot() is rejected with:

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

  1. 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:

  1. Preferred: allow DOM snapshots, screenshots, and other read-only inspection for user-opened file:// tabs whose files are inside approved workspace or artifact roots.
  2. Alternatively, provide a first-class local-artifact origin shared by opening, annotation, and Browser Use.
  3. 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.

View original on GitHub ↗

1 Comment

Allmight97 · 26 days ago

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:

  1. 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.
  2. 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.
  3. 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

  • #33592: Browser and Chrome are unavailable with Sol but work with Terra on the same installation; the issue contains independent macOS and Windows confirmations.
  • #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.
  • #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.
  • #36042: the 5.6 path claimed it could not update a GitHub PR branch; 5.5 used the same connector and permissions successfully.
  • #29235: Codex asks permission despite Full Access and disabled approval prompts; it currently has 13 thumbs-up reactions and several detected related reports.
  • #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.