Repository navigation
Codex Desktop Browser Use blocks an explicitly allowed website #40123
Description
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:
- A background scheduled task.
- 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.
Activity
HelioCentrik commentedon Aug 22, 2026
Additional isolation evidence from August 22, 2026:
Ordinary ChatGPT web retrieval can reach the public
https://1f3d9.comorigin and read its current front door, while Codex Desktop Browser Use on the same user setup still returns: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:
ERR_BLOCKED_BY_CLIENT, including independent public APIs that work in normal browsers.Neither is an exact duplicate of this report, but both describe recent Windows Browser/security-policy regressions consistent with the current failure mode.
HelioCentrik commentedon Aug 24, 2026
Additional corroborating evidence as of August 24, 2026:
The
1f3d9.comfailure remains reproducible after the affected environment moved onto the newer26.818.61809Browser / 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_CLIENTseen 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.41509to26.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.
leixyou commentedon Sep 20, 2026
This matches the cloud
site_status/ site-safety check (allowlisting the origin in Settings does not override it). Browser Use callshttps://chatgpt.com/backend-api/aura/site_statusand fails closed with “not permitted” on hosts like an explicitly allowlisted origin.The bundled plugin already has a local-testing flag that skips that check:
BROWSER_USE_SECURITY_MODE=disabled-for-local-testing. I wrapped that into a small third-party helper (macOS): wrapnode_repl, optional origin allowlists, re-apply after ChatGPT updates.Repo: https://github.com/leixyou/bypass-codex-site-safety
Not affiliated with OpenAI. Does not MITM chatgpt.com or patch
browser-service.mjs. After install, start a new Codex thread. Computer Use has a separate “current Chrome URL is not allowed” kill switch this does not cover.