Repository navigation
Chrome plugin, browser and computer use refuse to interact with certain sites. #29343
Description
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
Activity
github-actions commentedon Jun 21, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
joshp123 commentedon Jun 21, 2026
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).
Additional Browser Use site-policy matrix from local Chrome-plugin testing
joshp123 commentedon Jun 21, 2026
AI-generated note on the bot-linked potential duplicates (#28764, #28478)
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.
Codex App Browser Use keeps explicit-deny block for allowed calendar.google.com #28764 reports a Windows/Edge extension case where Codex can see and claim a manually opened Google Calendar tab, but page-content access is rejected as if the user explicitly denied
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.
Using the Codex browser extension is blocked by the security policy #28478 is a sparse Chinese-language report saying the browser extension connection is normal, but page access is blocked by security policy. The screenshot clarifies the blocked site as
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.
[-]Chrome plugin and browser refuse to interact with certain sites.[/-][+]Chrome plugin, browser and computer use refuse to interact with certain sites.[/+]mikezio commentedon Jun 22, 2026
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 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
joshp123 commentedon Jun 24, 2026
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
waffensam commentedon Jun 26, 2026
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.
lom200 commentedon Jul 4, 2026
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.
chenlei-github commentedon Jul 15, 2026
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.
zhangjinning1994-prog commentedon Jul 27, 2026
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.28 remaining items
yangchengwu2024 commentedon Sep 30, 2026
Windows Browser Use: request review of WeChat site_status_blocked classification
The user explicitly authorized downloading a shared WeChat video. Two normal Browser Use operations were rejected by the site-status policy before user permission or Auto-review was reached. Please review the classification and provide the applicable reason and a supported resolution.
Observed environment
26.928.2636.0, observed during investigation on 2026-09-30.26.928.21956.never_ask.Actual observations
https://mp.weixin.qq.com/s/ZFNcR1BSQy9-s2lDtd97fwwas rejected.https://channels.weixin.qq.com/finder-preview/pages/feedwas rejected. Signed query parameters are intentionally omitted; the sanitized path alone was not separately tested.Both returned:
Relevant implementation observations
Static inspection of the installed bundle identifies this message as
site_status_blocked, decision sourcesite_status, audit sourceopenai_site_policy. This is separate from persisted user denial, enterprise policy denial, user refusal, and Auto-review denial.The browser service queries
https://chatgpt.com/backend-api/aura/site_status. This bundle interpretsfeature_status.agent === trueas blocked, then rejects before the normal origin-consent path. The raw service response was not captured, so we cannot establish the underlying classification reason or whether these specific denials used cached results.The site-status result is cached by hostname for 24 hours, although the request includes path and query. In the cache-hit branch, a background fetch is launched without writing its successful result back into the cache. Please review the intended cache scope and refresh behavior. This static observation does not prove that stale cache caused these incidents.
Requested source-level resolution
No bypass was attempted during this diagnosis. The browser policy code and local permissions were not modified. This report contains no cookies, credentials, signed playback tokens, account screenshots, browsing history, or unrelated session content. It does not claim that every WeChat page is blocked or that the classification is necessarily a false positive.
songshujun-001 commentedon Oct 2, 2026
Additional macOS / native Chromium reproduction for WeChat Channels (2026-10-02)
Environment
Observed comparison
Exact error
This session has been stopped because Computer Use is not allowed on the current browser URL.
The response additionally instructed the agent to stop and stated that navigating to the URL manually would not permit Computer Use. No rule ID, detected URL, or policy source was supplied. The agent stopped.
Permission evidence
Scope
Additional local findings (read-only investigation on 2026-10-02)
Requested investigation
Please identify the effective URL decision, matching rule/policy source, and the detected origin for this failure. Is this an intentional restriction, a permission-scope mismatch, or a client/runtime defect? If erroneous, please provide the supported remediation and a way to verify it.
Privacy
This report omits credentials, cookies, account names, local profile paths, and full conversation/log files. Minimal request-correlation details can be supplied privately through an official support channel if the account owner authorizes it.
Ryx82 commentedon Oct 3, 2026
标题：Browser Use 对 pan.baidu.com 直接拒绝访问，未提供可见的授权入口
应用内反馈 ID：01a0fcc4-a767-7330-917f-a03d44a88d62
记录日期：2026-10-03（北京时间）
环境：Windows 桌面应用，内置浏览器，Browser Use 已开启。
问题描述
用户希望让 Codex 读取并整理本人的百度网盘目录。内置浏览器能够由用户打开
https://pan.baidu.com/disk/main，但代理尝试绑定该页面时立即被站点安全策略拒绝。实际错误
Browser Use rejected this action due to browser security policy.
The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted.
Browser use is not permitted on https://pan.baidu.com/disk/main.
复现步骤
已核查的情况
请求核查
请确认这次拒绝来自用户网站权限、组织管理策略、产品站点安全策略还是其他原因。
若允许由用户授权，请提供当前 Windows 桌面版本的正式入口。
若属于不可由用户覆盖的限制，请明确说明负责处理的管理方或支持渠道。
范围
本文未包含百度网盘文件名、文件内容、登录凭据或完整应用日志。
尚未取得百度网盘目录清单，尚未移动、重命名或删除网盘文件。
icebabbyy commentedon Oct 6, 2026
Windows reproduction and request for a scoped, user-confirmed read-only exception
Adding another affected user case to this existing issue, rather than opening a duplicate.
Environment verified on 6 October 2026:
26.930.4958.0.10.0.26200.Recorded Browser Use denials on 6 October 2026:
https://login.taobao.com/havanaone/login/login.htm, 10:12:46 UTC.https://www.taobao.com, 10:15:38 UTC.The tool returned:
The error explicitly prohibits alternate browser surfaces, raw CDP and indirect workarounds. We have respected that restriction; these are recorded failures, not a claim of a newly successful live test.
The user reports completing Taobao login manually and explicitly authorizes product research. The intended browser work is narrowly limited to reading product titles, complete SKU/variant labels and prices, images and shipment/specification text from shop/product pages, for preparing inventory drafts in a separate system. The login state has not been independently revalidated through the blocked browser tool.
Could OpenAI provide a supported scoped read-only exception after explicit human confirmation, limited by approved origin and session, with consequential operations separately gated? The request does not include checkout, purchasing, payments, cart changes, messaging, account changes, uploads, or cookie/token export.
If such access cannot be allowed, please provide:
We are not asking for a blanket safety-policy bypass or an undocumented client patch. Manual sign-in and existing browser connectivity are available; what is missing is a supported way for the tool to proceed with the authorized read-only task.
Grif001 commentedon Oct 7, 2026
Windows: VK read-only access blocked on October 7, 2026
Please review the site-safety classification for https://vk.ru/rusgeocomru. The requested workflow is reading public community publications for content monitoring.
Observed error:
Environment recorded during troubleshooting: Windows, Codex Desktop 26.1002.6548.0, CLI 0.162.0-alpha.2. The denial was observed through the built-in browser and Chrome integration. Updating and restarting did not restore access. An unrelated public news site (chipdip.ru/news) could be read through the built-in browser.
Timeline qualification: the October 6 collection record shows a feed-rendering failure without an explicit site-policy denial; the October 7 record shows an explicit security-policy rejection. This does not establish successful access on October 6, an exact policy-change time, or that an app update caused the denial.
Could the team confirm whether this is an intended restriction or a classification defect, explain the applicable reason and scope, and provide a supported review/restoration process? If fixed, please identify the relevant version or server-side change.
Posted with the user's authorization. No cookies, credentials, private content, or raw diagnostic logs are included.
ygf678-rgb commentedon Oct 8, 2026
Adding a macOS / Chrome reproduction affecting the NetEase creator platform, observed on 8 October 2026.
Target origin:
https://mp.163.com.Related NetEase report #40354 concerns a different origin (
campus.163.com); this adds the creator-platform case.The account owner requested preparation of a non-health lifestyle article in their own creator account. The intended workflow is to enter the title and article, upload its illustrations and cover, and leave the final publication action to the owner.
Binding the already-open target tab through the supported Browser Use interface was rejected before page contents were read:
Read-only diagnostics performed:
1.26.901.11451_0.The rejected action was not retried through another browser surface or an indirect publishing route. No safety checks were disabled. Codex has not entered or published the article; any later manual submission by the owner has not been independently verified.
Please clarify the effective policy source and reason for this origin's denial, whether the classification is intentional or erroneous, and the supported review or restoration process. If a fix exists, please identify the relevant product version or server-side change.
This report contains no account identity, article text, local username or paths, cookies, tokens, screenshots, private logs, or chat identifiers.
Posted with the account owner's explicit authorization.
kaneyu8-cloud commentedon Oct 8, 2026
Additional evidence from Codex desktop on Windows, observed during a user-authorized workflow involving public supplier product images and specifications:
The user can manually open this public product page in the in-app browser:
https://detail.1688.com/offer/675082473201.html
The browser tool previously returned:
"Browser Use rejected this action due to browser security policy."
"The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted."
"Browser use is not permitted on https://detail.1688.com/offer/675082473201.html."
This prevents an otherwise authorized product-material collection workflow. Installing a local Chrome material-collection extension does not provide the agent with a supported way to resolve this denial. The currently exposed browser capabilities do not include a site-safety review or permission-management action.
There is also a separate limitation when attempting to open an extension popup: the browser URL policy permits HTTP/HTTPS but rejects chrome-extension:// URLs. This should be distinguished from the 1688 site-safety refusal.
Could maintainers provide a supported review process for a potentially misclassified public supplier site, and clarify whether any user-facing permission setting applies to this specific site-safety denial? No policy bypass has been attempted.
No account credentials, browser cookies, private session logs, screenshots, or local filesystem paths are included in this report.
ChuJiQiQi commentedon Oct 10, 2026
Linux / Chrome: Civitai blocked despite Full access — 2026-10-10
Adding a concrete reproduction to this existing issue.
Environment and requested task
26.930.51102(desktop app version was not collected).sandbox_mode = "danger-full-access"andapproval_policy = "never".Observed failure
Opening the public homepage
https://civitai.comthrough the supported browser tool was rejected before any Civitai page state was returned:The diagnostic also explicitly prohibits alternate browser surfaces, indirect execution, and other workarounds. The agent stopped the Civitai task; no alternate route was attempted. Other sites, including Discord and GitHub, remained accessible through the same Chrome connection. Civitai login and the balance lookup were never completed.
Read-only inspection of the installed browser bundle maps this error to
site_status_blocked, withdecisionSource: "site_status", separately from persisted user denial and approval decisions. The service constructs requests tohttps://chatgpt.com/backend-api/aura/site_status. This identifies the enforcement layer, but does not reveal why Civitai was classified this way or establish that the classification is erroneous.Requested resolution
The user explicitly authorized posting this feedback. No credentials, cookies, account balances, private account identifiers, or raw session logs are included.
daige5680-png commentedon Oct 10, 2026
Additional reproduction: VK Browser Use denied after a user-side origin allow setting
Observed on 2026-10-07 in the Windows desktop application, Codex mode, personal Pro. Running package verified earlier that day: OpenAI.Codex 26.930.7945.0. The attempted route was the built-in browser.
The account owner set browsing for https://vk.com and https://vk.ru to Always allow. A single access attempt after that setting still failed at https://vk.com/search before a user approval or Auto-review prompt. The same browser could open the OpenAI Help Center.
The returned diagnostic stated that the site-safety policy blocked the action, Browser Use was not permitted on that URL, and the agent must not achieve the same result through alternate browser surfaces, raw CDP, indirect execution or policy circumvention. No such workaround was performed.
Please clarify whether this is an intended product restriction or a false positive. If it is a false positive, what supported recovery or review process applies to a personal account? If it is intended, please clarify the applicable scope and document the user-facing behavior. No account credentials, private session data, raw logs or customer information are included here.
Follow-up observations on 2026-10-08: the owner restarted the desktop app. A read-only check found the registered Windows package and the currently running application both at package version 26.930.7945.0. The built-in update check still returned installedVersion 26.930.61225, installedBuildVersion 13232, release channel prod, and status restart_required. These are different version fields; we have not assumed their difference proves a fault. No new VK search attempt was made and no bypass was performed. Please clarify the supported next step without requiring repeated permission changes or repeated restarts with no relevant change.
wangpengsheng326 commentedon Oct 10, 2026
macOS / native Chrome: URL refusal persists after a site-specific allowance (2026-10-10)
Adding a bounded reproduction with the account owner's explicit authorization.
Installed environment (read from local version metadata; loaded process versions were not independently verified):
Task and observations
The requested workflow is read-only: navigate an existing business task, open its linked enterprise contact card in WeChat, and read the company field. No contact addition, messages, requests, or business-data changes are authorized. Earlier official native browser navigation and a separate WeChat screenshot both succeeded.
The user identified the browser handoff page as
https://work.weixin.qq.com/ca/<redacted>and reported saving Always allow for the exact originhttps://work.weixin.qq.comunder Settings → Browser → Agent permissions. That setting is user-confirmed, not independently inspected by the tool.One subsequent check through the official native interface:
returned after 5.1736 seconds:
The agent stopped. No alternate browser surface, direct protocol call, or policy bypass was attempted. The diagnostic did not return the actual rejected URL. Consequently, the user-provided handoff origin cannot yet be conclusively identified as the rejected URL, and the policy source remains unknown. A narrow local log check found no correlated denial event; this does not establish the absence of a policy restriction.
Requested clarification
This comment omits contact identifiers, business account/task identifiers, company names, screenshots, raw logs, chat IDs, local user paths, cookies and credentials. Existing logins and task state have been left untouched.
SkyForThinking commentedon Oct 14, 2026
Additional reproduction: Brazilian AliExpress product page in Chrome (2026-10-14)
I am adding a concrete
pt.aliexpress.comcase to this existing issue with the account owner's authorization. The task was read-only product-price research for a Brazilian livestream selection sheet. The user could open the product normally in Chrome.Environment: macOS; ChatGPT/Codex desktop Browser Use build
26.924.22138;unified-computer-use@openai-bundled; connected Chrome extension.Reproduction:
cua.getState()listed the user's existing Chrome tab forhttps://pt.aliexpress.com/item/1005010182516019.html?gatewayAdapt=usa2bra(8BitDo Pro 3 product). The agent then calledcua.getTab('119913139', {browser:'1'}). It was rejected before page access:The same Chrome connection had successfully bound and interacted with a GitHub tab. No alternate browser surface, raw CDP, or other workaround was used for the rejected AliExpress access.
Read-only local diagnosis: the bundled Browser Use component queries
chatgpt.com/backend-api/aura/site_statuswithsite_urland mapsfeature_status.agent === truetosite_status_blocked. Its local cache key is the hostname, with a 24-hour TTL. The tool response does not reveal whether this specific product URL received a fresh backend decision or reused a cachedpt.aliexpress.comdecision. This is a possible false positive or overly broad host-level result; we cannot determine the backend reason locally.Request: Please review the site-status decision and cache behavior for the Brazilian AliExpress origin, clarify whether the block is intentional, and provide a supported route for correction if the classification is wrong. This prevents a legitimate browser workflow even when the user opens the page themselves. I also sent the reproduction to the official Help Center support chat; it did not provide an engineering ticket number.
No credentials, account email, private chat ID, raw logs, or customer data are included.
edwardchin811227 commentedon Oct 15, 2026
Additional reproduction: 1688 blocked despite Always Allow on Windows (2026-10-15)
I am adding a current 1688 reproduction with the account owner's explicit authorization.
Environment: Windows 10 Home China 22H2 (build 19045); ChatGPT/Codex desktop app; built-in
@Browser.Permission state: The user added
https://1688.comunder Browser → Agent permissions and set both browsing and downloads to Always allow.Reproduction: The agent attempted a read-only navigation using the supported built-in browser interface:
The action was rejected before page access, after the destination was normalized to
https://www.1688.com:The agent stopped immediately. No alternate browser surface, raw CDP, indirect execution, or policy workaround was attempted.
Feedback session ID:
01a13e58-54b6-7cf3-9611-869340c4f36fRequest: Please review whether
1688.comand its operational subdomains (includingwww.1688.com,detail.1688.com, andwork.1688.com) are being incorrectly classified. Please also provide a supported correction or appeal route when a legitimate site is blocked by the site-safety gate. The user-level Always Allow setting currently cannot override this result.No credentials, cookies, account email, customer data, or private business records are included.
crisdosaygo commentedon Oct 15, 2026
I'd make this a diagnostic result the user can act on. "Always allow" and a platform-level site refusal are different decisions, but the current UI makes people keep editing the first one to fix the second.
A refusal should expose the effective origin after redirects, the decision source (user, workspace or product policy), a reason category, and a reference for the supported review path. If the result was cached, include its age and explain how a corrected decision reaches the client.
The new
1688.com→www.1688.comreport is a good regression case: show which origin was actually evaluated, and whether the saved permission applies. The agent can then stop cleanly and give the user the right next step. No need to expose private classifier details or make the user reverse-engineer the bundle to find the responsible layer.alympra commentedon Oct 18, 2026
Additional macOS reproduction: Taobao search rejected after reported manual sign-in (2026-10-18)
Adding the observed reproduction to this existing issue rather than opening a duplicate.
Environment
uname -mprs:Darwin 27.0.0 arm64 arm.26.1007.71326, build20398, bundle identifiercom.openai.codex.155.0.4283.62.Observed behavior
Native Edge returned a readable accessibility tree on a New Tab/search page. After an attempt to navigate to the Taobao homepage, the next accessibility-state request stopped the Computer Use session with:
This diagnostic did not return the detected URL, so the exact native URL that triggered that refusal remains unconfirmed.
Separate, user-requested control checks in the IAB succeeded:
A product search started from Tmall led to an existing
https://s.taobao.com/searchtab withtab=mall. The account owner then reported completing manual sign-in and explicitly asked for another read-only check. The signed-in state could not be independently verified because page access was subsequently refused.IAB tab inventory succeeded and returned the title
保温杯_淘宝搜索and thes.taobao.com/searchURL. Binding that existing tab by its inventory ID with the supportedcua.getTab(tabId, { browser: "iab" })operation failed before page content was returned:Evidence limits and requested clarification
The observed IAB failure explicitly identifies the site-safety gate. It does not reveal the matched rule or explain why this destination was classified this way. Local website-permission settings and managed policies were not inspected, and this report does not claim to rule them out. We also do not claim that the native Edge refusal and IAB refusal have an identical internal error code.
Please clarify whether read-only access to
s.taobao.comis intentionally restricted or eligible for classification review, and provide a supported diagnostic/review route. The UI should distinguish this refusal from website login, user-denied permissions, browser connectivity, and Auto-review decisions.Related reports: #44943, #53349, #54950.
The agent stopped after each explicit policy refusal. No policy bypass was attempted. This comment omits account identities, cookies, credentials, full search URLs/query identifiers, chat IDs, screenshots, and raw logs. Posted with the account owner's explicit authorization.
FrankD-F commentedon Oct 19, 2026
Additional macOS reproduction: jinbao.pinduoduo.com blocked before page access
This adds a macOS reproduction for the distinct Pinduoduo affiliate origin to #29343. Related report #52484 concerns the different merchant origin yingxiao.pinduoduo.com; this report does not assume both origins have the same classification.
Summary
Browser Use refuses access to the Pinduoduo affiliate-link conversion page in the user's installed Google Chrome. The user has expressly authorized the task and reports that the page is already open in their signed-in Chrome profile. The agent never obtained authority to observe page content and did not submit any conversion.
Please clarify whether this is an intended site restriction or a false positive, and provide the supported review/recovery route. This report does not request a security-control bypass.
Environment
Existing reproduction evidence
The previously attempted documented binding was:
It returned:
No further requests to the blocked site, alternate surfaces, raw browser protocols, session resets, or indirect browser-control workarounds were attempted during this investigation.
Diagnostic findings
Requested resolution
No credentials, account IDs, conversation IDs, sheet links, affiliate tracking links, business data, or raw logs are included.