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
17 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.
Adding a current Windows reproduction and a legitimate read-only procurement workflow.
Environment:
26.721.4979.026.721.410591.2.27221.15725_0Blocked in a fresh Browser runtime:
https://www.1688.com/https://work.1688.com/home/buyer.htm?.../buyListhttps://air.1688.com/app/ctf-page/trade-order-list/buyer-order-list.htmlhttps://air.1688.com/app/ctf-page/trade-order-detail/index.html?...The public 1688 home page and authenticated buyer pages all return:
Controls and troubleshooting:
https://1688.com,https://work.1688.com, andhttps://air.1688.com; denied list is empty.sandbox: none; this is notnetworkAccess: false.Business use case:
This confirms that the issue persists in the newer
26.721build and is not resolved by the documented local site controls. Please reclassify 1688 for user-authorized read-only workflows, or provide an official appeal/override path for personal accounts.Additional reproducible evidence from 2026-07-27:
https://aop.alibaba.com/.https://open.1688.com/console.This is significant because
open.1688.com/consoleis the official developer/OAuth management surface, not the buyer marketplace order page. The current domain classification blocks the safest supported alternative for legitimate 1688 buyer-order integration (creating an app and authorizing read-only order APIs), even while the public AOP homepage remains accessible.Please include
open.1688.com/ the developer console in the classification review, or provide a documented enterprise/admin override for user-authorized business domains. Current Codex app version is26.721.4979.0; Chrome plugin26.721.41059; extension1.2.27221.15725_0.Adding a local Windows reproduction for Taobao in the built-in in-app Browser (not the Chrome extension).
Environment (2026-07-29):
10.0.26200(build26200)OpenAI.Codex 26.721.4979.026.721.41059https://www.taobao.com/Observed behavior:
browser.user.openTabs()successfully returned the tab with title淘宝and URLhttps://www.taobao.com/.browser.user.claimTab(...)succeeded.tab.title()andtab.url()succeeded.tab.playwright.domSnapshot(), was immediately rejected with:The same result was reproduced across repeated Browser Use turns and fresh tab claims. No page content was read, and no cart, purchase, messaging, payment, account, upload, or other write action was attempted.
The requested workflow was legitimate procurement work: read-only inspection and comparison of generic monitor-arm mounting hardware, with any consequential shopping action expected to remain separately confirmation-gated. The policy blocks before even read-only DOM inspection.
This closely matches the issue's reported distinction: tab metadata and claiming work, while page-content access is denied by the destination policy layer. A documented reason category and a supported reclassification/override path for user-authorized read-only access would be helpful.
Adding a Windows reproduction for the authenticated Taobao DMP business backend.
Environment:
26.707.3748.026.707.31428https://dmp.taobao.com/index_new.htmlLegitimate read-only use case:
Reproduction:
https://dmp.taobao.com/index_new.htmlmanually in the in-app Browser.https://dmp.taobao.comto the documented website allowlist.Actual result:
The rejection remains unchanged even though the website is explicitly allowed and Full CDP access is enabled. Local inspection of the bundled
browser-client.mjsindicates that the client checks/backend-api/aura/site_statusbefore the local origin-consent path, which is consistent with a server-side domain classification rather than a local permission or CDP configuration problem.This appears to extend the existing Taobao block to an authenticated merchant analytics/advertising backend. Please review the classification of
dmp.taobao.comfor explicitly authorized read-only business workflows, or provide a documented appeal/approval path. At minimum, the UI should explain that the local website allowlist cannot override this policy result.I can reproduce the same issue with AliExpress (
https://www.aliexpress.com/) while using Codex with my own Chrome browser.I can open and use AliExpress normally in the same Chrome session, but Codex Browser Use refuses to interact with it.
I tested both:
https://www.aliexpress.com/Both are rejected before any page interaction with:
BrowserUseSecurityError: site-safety policy blocks this actionCodex does not offer a user approval prompt, so I cannot explicitly allow access to the site.
Codex also reports that it is prohibited from trying the same action through another browser interface, raw CDP, or another domain as a workaround.
This is a normal e-commerce research use case: I asked Codex to search for inexpensive HDD enclosures and storage options. No restricted goods or unusual activity are involved.
The practical problem is that I explicitly gave Codex access to my Chrome browser, can visit the site manually, and want the agent to interact with it, but a server-side site-safety classification silently overrides that permission with no user override and no explanation of why this particular site is blocked.
Please consider:
A hidden server-side domain restriction significantly reduces the usefulness of Browser Use for research workflows, especially when the user cannot override it even for their own browser session.
Adding a current macOS reproduction for VK.
Environment:
Blocked:
Exact result:
Troubleshooting completed:
Legitimate workflow:
Submit prepared, non-political art-gallery image posts from the user's personal account to the community's “Предложенные” moderation queue. The user explicitly authorized the account and destination. Even read-only inspection and the official VK developer-app page are blocked, so local settings cannot fix the route.
This matches the earlier vk.ru reproduction in this issue and confirms it persists in 26.803. Please review VK domain classification or provide a supported user-visible appeal/override for explicitly authorized ordinary workflows.
Adding another reproducible macOS case affecting two official Taobao domains, including a merchant-learning platform.
Feedback session:
01a00314-bf7d-7bc0-b473-debc9f047987OpenAI Support case:
12933396Environment
Affected domains
https://shuyuan.taobao.com/— Wantang Academy / Taobao Alliance Classroom, an official Taobao merchant-learning platformhttps://tbzb.taobao.com/— official Taobao Live siteReproduction
about:blank.Exact result
Browser Use rejected this action due to browser security policy. Reason: The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted. Browser use is not permitted on https://shuyuan.taobao.com.No form submission, purchase, upload, credential access, account change, or other write action was requested. The task was only to read and summarize official merchant-learning materials.
This closely matches the Taobao/1688 behavior already reported here and the read-only false positives in #34118 and #34006. Please review the classification of these official Taobao domains or provide a supported appeal path for explicitly authorized, read-only browsing.
Windows reproduction on 2026-08-18
Codex Desktop: 26.814.5167.0
Chrome plugin: 26.814.41407
Feedback/thread ID: 01a0148c-68e5-7941-9da2-9459f9379a9a
Allowed in the same Chrome session:
Blocked:
The Taobao origins are explicitly set to Allow browsing, and global approval is Always allow.
The rejection occurs before DOM access with site-safety policy blocks this action.
Adding a current macOS reproduction affecting Avito, VK, and Dzen.
Environment
26.818.41509(build6962)01a02a2b-e210-7c03-9def-6921df8663b3Affected origins
https://www.avito.ru/https://vk.com/https://dzen.ru/All three are rejected before the page loads with:
Control and troubleshooting
https://example.com/opens successfully in the same setup, so this is not a blanket network or browser-extension failure.https://vk.comandhttps://dzen.ruare explicitly set to Allow browsing under Settings → Computer Use → Google Chrome → Website permissions.Legitimate read-only workflow
The requested task was to research public Avito classifieds for nutrition and personal-training coaching services. No login, purchase, messaging, listing publication, credential access, or account mutation was requested. VK and Dzen were also tested only to diagnose the domain-specific Browser Use failure.
This adds Avito as another ordinary marketplace affected by the site-safety classification and confirms that the previously reported VK/Dzen behavior persists in app build
26.818.41509. The local Allow browsing setting does not override the result.Please review the classification of these domains or provide a supported appeal/user-override path for explicitly authorized read-only browsing. The UI should also indicate when a higher-precedence site-safety result is overriding the user's visible website permission.