Chrome plugin, browser and computer use refuse to interact with certain sites.
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.616.51431
What subscription do you have?
pro €225/month
What platform is your computer?
_No response_
What issue are you seeing?
Codex silently refuses to load certain sites using the Chrome plugin.
there seems to be a server-side blacklist of sites that Codex refuses to load. When you try and access one of these sites, the browser plugin throws an error:
Browser Use rejected this action due to browser security policy.
Reason: Browser Use is not permitted on https://detail.1688.com.these sites aren't malicious or don't seem to be against TOS or anything: normal e-commerce sites such as Taobao or 1688.com.
futhermore, this isn't documented anywhere either.
Philosophically, having a web browser that decides - server side - which websites it can and can't load, without any transparency on this, it's not great. I could (grudgingly) understand if the sites are malicious/pornographic/illegal/etc, but these are genuine huge e-commerce sites - the Western equivalent of blocking Amazon or Walmart. More broadly, silently blocking sites in a non-transparent/undocumented way doesn't feel right either.
It seems like you ALSO can't even use Computer Use on Chrome if a tab is open from one of the "non-permitted" websites:
mcp__computer_use.get_app_state({
"app": "Google Chrome"
})
// returns:
[{"type":"text","text":"This session has been stopped because Computer Use is not allowed on the current browser URL. Stop your work and send a final message noting why the session has been ended. Note that Computer Use is not allowed on this URL even if the user navigates to it themselves."}]Obviously I could monkey-patch around this by modifying the javascript plugin or computer use.... but that's not an okay workaround either. Computer use, Chrome, and the Browser plugin should just work on all (legal) sites.
What steps can reproduce the bug?
Feedback ID: 019ee97a-589a-7670-9b4c-a7eadac555ba
What is the expected behavior?
The built in plugins do not run a server-side check to see if users are permitted to look at a certain site or not.
Additional information
Codex investigated the issue further, a brief summary (before we get the clanker to attach a big slop comment of everything it found):
- On every request, the Chrome plugin will make a request to
https://chatgpt.com/backend-api/aura/site_status, if this endpoint returns something, the request will be blocked - chrome plugin code:
/Users/<me>/.codex/plugins/cache/openai-bundled/chrome/26.616.51431/scripts/browser-client.mjs:3234
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
here's a bunch of slop from the clanker explaining the issue in more detail, included a list of blocked and not blocked sites. (i told it to check a bunch of chinese and western e-commerce sites, and a bunch of semi-dodgy sites to see what it found. you get the idea).
<details>
<summary>Additional Browser Use site-policy matrix from local Chrome-plugin testing</summary>
</details>
<details>
<summary>AI-generated note on the bot-linked potential duplicates (#28764, #28478)</summary>
AI-generated.
GitHub's duplicate bot linked #28764 and #28478. I checked both. They are adjacent Browser Use security-policy reports, but they do not look like clean duplicates of this issue.
https://calendar.google.com, despite visible Codex allow settings andAlways allowbrowsing approval.That is a local allow-state / explicit-deny mismatch for a specific Google Calendar origin. This issue is different: the Chrome/Browser runtime works across many sites, but selected public destinations are denied by the Browser Use policy layer. The behavior looks like server-side destination classification, not a stale local user-deny setting for one allowed origin.
my.feishu.cnand says it is blocked by a higher-level enterprise/network policy even whenhttps://*is allowed.That may be in the same general policy area, but it is not the same report. It is a single enterprise SaaS/workspace domain with enterprise/network-policy wording and little reproduction detail. This issue maps a broader selective blocklist/allowlist pattern across public ecommerce, sourcing, China web, file-storage, payment, and sensitive comparator sites.
Why this issue is distinct:
So #28764 and #28478 are useful related examples of Browser Use policy friction, but they should not close this issue as duplicates unless the intended maintainer conclusion is that all of these symptoms share one underlying undocumented policy classifier. If so, this issue still adds the blocked/unblocked comparator matrix needed to debug that classifier.
</details>
I checked the robots.txt files for a bunch of the blocked examples you posted + there is def a pretty clear pattern here
1688.com disallows generic crawlers from /offer/, /product/, /seller/, /member/, /catalog/ and a bunch of detail/query paths
item.taobao.com allows Googlebot and Googlebot-Image but has User-agent: * Disallow: /
login.taobao.com is also User-agent: * Disallow: /
AliExpress disallows generic crawlers from /items/, /search/, /productdetail/, /product/, /shopcart/, /wishlist/, /api/* + related AJAX/detail/store surfaces
Pinduoduo is just straight Disallow: /
Mega has User-agent: * Disallow: / with a specific allowlist only for public/static/help/marketing pages
Baidu Pan disallows share-link/share-home/list paths like /share/link/, /share/home/, /s/1*, /share/list
WeChat Pay disallows most /index.php/ paths except a small public/docs/static allowlist
So this does not look random to me, server side site status check Codex calls before browser interaction seems to be flagging sites/surfaces where the site itself is publishing restrictive crawler/automation rules especially product detail, search, login, cart/payment, file share + API surfaces
The main thing I still agree with in this issue is the opacity. Browser Use is not permitted on <url> makes it look arbitrary. Even a extremely rough reason category like “site automation policy” / “scraping sensitive surface” / “marketplace/product detail surface” would make this much easier to understand
This also breaks appshots, btw. If you try and take an appshot on a Chrome window with a URL that's also blocked, you get an "unable to take appshot" message. Move the same Chrome window to a tab with a different non-blocked URL open, and appshots work just fine. This silent blocking really is not great UX :(
Feedback ID: no-active-thread-019ef9fa-4ca5-7ed2-a621-b50d2b6519ce
Adding one concrete use case from #30167 before closing it as a duplicate of this broader issue.
In my case, the blocked Taobao surfaces were encountered during an anti-cheat / abuse-reporting workflow, not normal shopping automation:
https://s.taobao.com/searchandhttps://item.taobao.com/item.htm.This seems useful as a safety-governance edge case for the same site-policy issue: the current block prevents defensive reporting work, even when the requested agent behavior is limited to read-only review and user-confirmed report drafting.
Adding another data point from Windows Codex Desktop.
Environment:
26.623.13972.026.623.1016521.1.5149.0.7827.201Observed blocked origins:
Both fail with the same class of error:
Control sites that worked in the same session/profile:
https://www.google.com/- claim/read/evaluate/screenshot/search interaction workedhttps://www.facebook.com/- navigation/read/evaluate/screenshot workedhttp://e1.ru/->https://www.e1.ru/- navigation/read/evaluate/screenshot workedhttps://www.gismeteo.ru/- navigation/read/evaluate/screenshot worked; clicking an internalНовостиlink also workedAlso checked that this is not a blanket
.rublock:e1.ruandgismeteo.ruworked normally. Addinghttps://dzen.ruto local Browser Use origin allowlists did not change the rejection.This looks like a domain/category-level Browser Use policy decision rather than a broken Chrome extension or general network/browser failure. The main user-facing issue is that the rejection does not expose whether the block is intentional policy, a remote site-status result, or a local config/state problem, so users can spend time trying to repair Chrome/config when there may be nothing local to fix.
Adding a current macOS data point for WeChat public pages.
Environment:
Blocked:
Allowed controls in the same Browser session:
Troubleshooting already completed:
mp.weixin.qq.comis present in~/.codex/browser/config.tomlunder allowed origins; denied origins are empty.approval_modefromnever_asktoask, reset the Browser runtime, and retested: no change.Exact error:
Browser use is not permitted for this request. See the Browser Use policy documentation.This confirms the issue is still reproducible in build 26.707.72221 and appears specific to the WeChat domain policy classification rather than local origin permissions, plugin installation, Browser session state, or general network access.