›_ Codex Issues
Codex Issues / #40123

Codex Desktop Browser Use blocks an explicitly allowed website

Open 💬 2 comments Opened Aug 22, 2026 by HelioCentrik

Environment

  • Windows
  • Codex Desktop 0.149.0-alpha.4.1
  • In-app Browser / Browser Use
  • Website: https://1f3d9.com
  • Reproduced August 22, 2026

Summary

Codex Desktop Browser Use is blocking navigation to an explicitly allowed public website with:

net::ERR_BLOCKED_BY_CLIENT

The hostname is explicitly allowed under Settings → Browser.

This appears to be a recent regression. Browser Use successfully accessed this same website after August 13, 2026 using the same general Firefly/AI City workflow. The failure began only recently.

Reproduction

The failure occurs in two independent contexts:

  1. A background scheduled task.
  2. A brand-new ordinary user-created project task.

The ordinary task had:

thread_source=user

so the problem does not appear limited to scheduled/background execution or an approval_policy=never environment.

In both cases, Browser Use attempts to navigate to:

https://1f3d9.com

and receives:

net::ERR_BLOCKED_BY_CLIENT

Important isolation

The failure occurs during in-app Browser navigation, before the destination website or its MCP server is contacted.

The website itself remains publicly reachable outside this Browser Use path.

The project also has an MCP integration associated with this service, but the observed failure happens before MCP authentication or communication is attempted. This therefore does not appear to originate from the remote MCP server or its authentication mechanism.

Expected behavior

A public website explicitly configured as allowed under Settings → Browser should be navigable by Browser Use.

If another security or policy layer overrides the user-visible allowlist, the product should surface that policy and explain why navigation was denied.

Actual behavior

Browser Use rejects the navigation with:

net::ERR_BLOCKED_BY_CLIENT

despite the hostname being explicitly allowed.

Recreating the task as an ordinary user-created task does not change the result.

Regression signal

Browser Use successfully accessed this same website and workflow on August 21, 2026.

The failure was first observed and reproduced on August 22, 2026, after a Codex Desktop alpha/beta update on August 21. The currently affected environment is running 0.149.0-alpha.4.1.

This suggests a possible regression introduced by that update or an associated bundled Browser/security-policy change, rather than a longstanding incompatibility with the site.

Requested investigation

Please investigate why Browser Use now returns ERR_BLOCKED_BY_CLIENT for a hostname explicitly allowed under Settings → Browser, despite the same website and workflow working successfully the previous day.

In particular, please check whether the August 21 Codex Desktop alpha/beta update or an associated Browser/security-policy component introduced this regression.

If another policy intentionally overrides the user-visible allowlist, please expose the effective policy or blocking reason in the UI.

View original on GitHub ↗

2 Comments

HelioCentrik · 5 days ago

Additional isolation evidence from August 22, 2026:

Ordinary ChatGPT web retrieval can reach the public https://1f3d9.com origin and read its current front door, while Codex Desktop Browser Use on the same user setup still returns:

net::ERR_BLOCKED_BY_CLIENT

This further isolates the failure to the Codex Browser Use path rather than the hostname or upstream service itself.

Two recent open issues may be related:

  • #38369 — Windows Browser Use blocks public JSON/CSV/plain-text resources with ERR_BLOCKED_BY_CLIENT, including independent public APIs that work in normal browsers.
  • #37885 — a hostname shown as allowed in Settings → Browser remains blocked because the effective Browser Use permission state appears out of sync with the visible saved permission.

Neither is an exact duplicate of this report, but both describe recent Windows Browser/security-policy regressions consistent with the current failure mode.

HelioCentrik · 3 days ago

Additional corroborating evidence as of August 24, 2026:

The 1f3d9.com failure remains reproducible after the affected environment moved onto the newer 26.818.61809 Browser / Computer Use component generation.

Issue #40354 is especially relevant because it independently demonstrates a closely related current behavior: a legitimate site can be configured as Always allow, yet Browser Use is still rejected by a separate site-safety policy before DOM access, with no user permission prompt or Auto-review attempted. Computer Use rejects the same URL as well.

That does not prove that the net::ERR_BLOCKED_BY_CLIENT seen here is produced by the exact same backend policy/checker, so I would not treat #40354 as a confirmed duplicate or root-cause identification. It does, however, provide strong corroborating evidence that the user-visible Browser allowlist is not necessarily the final effective authorization layer.

Separately, #40411 reports a different Windows Browser/Computer Use regression immediately after its bundled components updated from 26.818.41509 to 26.818.61809. Its failure mode is initialization/trusted-path related rather than site-specific, so it is not a duplicate either, but it is useful regression context for the same current Browser/Computer Use component generation.

Taken together with #38369 and #37885, the evidence continues to point more strongly toward the Codex Browser/security-policy path than toward the destination site, MCP integration, authentication, or task configuration.

If the block here is coming from a separate site-status/safety policy, surfacing the effective policy decision in the UI would make this class of failure substantially easier to diagnose.