Repository navigation
Chrome Browser Use blocks explicitly allowed WeChat Channels admin page #35549
Description
What version of the ChatGPT / Codex app are you using?
ChatGPT desktop / Codex app: 26.721.41059
Chrome Browser Use plugin: 26.721.41059
What platform is your computer?
macOS 26.2 (Build 25C56), Apple Silicon (arm64)
What issue are you seeing?
The official Chrome Browser Use plugin can enumerate my existing Chrome tabs, but it refuses to inspect or interact with my own signed-in WeChat Channels admin page:
https://channels.weixin.qq.com/login.html
My use case is read-only: I need Codex to open my own WeChat Channels backend and collect the URL of each video I have published. This does not require publishing, editing, deleting, uploading, messaging, or changing any account data.
The domain is explicitly allowed in the local Browser Use configuration, including origin access and full CDP access:
approval_mode = "never_ask"
full_cdp_access_enabled = true
[origins]
allowed = ["https://channels.weixin.qq.com"]
denied = []
[full_cdp]
allowed = ["https://channels.weixin.qq.com"]
denied = []Other tabs such as GitHub, Feishu documents, and YouTube can be inspected successfully in the same Chrome session.
Actual behavior
browser.user.openTabs() successfully returns the WeChat Channels tab title and URL.
However, claiming the tab and requesting a DOM snapshot is rejected immediately with:
Browser Use rejected this action due to browser security policy.
Reason: Browser use is not permitted on https://channels.weixin.qq.com/login.html.
The agent must not attempt to achieve the same outcome via workaround, indirect execution,
raw CDP or browser commands, alternate browser surfaces, or policy circumvention.
The rejection occurs before any page-level browser action is executed. The bundled browser-client.mjs performs an OpenAI aura/site_status preflight before checking the user's local origin consent, so an explicit user allowlist entry cannot override this result.
Steps to reproduce
- Install and connect the official Codex Chrome plugin.
- Sign in to a WeChat Channels account owned by the user.
- Add
https://channels.weixin.qq.comto the allowed website/origin list. - Enable Full CDP access for the same origin.
- Open the WeChat Channels admin tab.
- Ask Codex to read the user's own published-video list and collect each video's URL.
- Observe that tab enumeration succeeds.
- Observe that DOM inspection and all further Browser Use actions are blocked by the security-policy preflight.
Expected behavior
When the user owns the account and explicitly allows the origin, Browser Use should support read-only inspection of the WeChat Channels admin page, including collecting URLs for the user's own published videos.
At minimum, this workflow should provide a recoverable user approval prompt or a documented explanation. A central hard block should not silently override an explicit per-site allow decision for a read-only task.
Additional context
This appears domain-specific because Browser Use works on other external websites in the same session. The requested workflow has no content mutation or external communication side effect.
Please review the channels.weixin.qq.com site classification as a possible false positive and consider allowing explicitly authorized, read-only Browser Use operations on this domain.
Activity
AHPEventCollection commentedon Sep 5, 2026
补充一个Windows11＋Opera的同域名案例，发生于2026年9月6日
环境：Codex桌面应用，浏览器控制工具mcp__cua_repl.js，本地Browser插件目录版本26.901.41123，桌面应用版本本次未核实
用户要求使用已登录的Opera会话，为自己的音乐节目准备四个平台的投稿表单，停在最终发布或定时发布按钮前，不提交发布
微博、B站、小红书均可完成上传和填写；视频号在接管已有标签页时立即被拦截，尚未上传、填写或点击发布
触发调用：
目标地址：https://channels.weixin.qq.com/platform/
工具返回：
用户表示该站点手动访问正常，且此前曾由工具操作成功；这些为用户提供的历史信息，本次未独立复现历史成功状态，也未核实本地站点允许列表
除拦截本身外，还存在恢复流程问题：错误没有说明具体原因、作用范围、有效期、是否允许稍后通过相同接口重试，也没有提供可用的只读限制状态查询接口或可执行的申诉入口
用户多次要求检查当前是否恢复，助手将错误的停止要求理解为禁止再次接管标签页，导致无法验证恢复状态；助手又先后提出未经证实的设置原因、解除确认和官方允许重试条件，造成很长的无效对话，这部分也应作为错误信息与代理恢复行为的问题排查
请核查该域名的分类是否误拦截，并明确提供限制原因、范围或有效期、支持的恢复或复核流程，以及是否允许在用户明确要求后通过原接口进行一次状态复检
本报告不请求绕过安全策略，未附账号凭证、Cookie或完整会话日志
qins commentedon Sep 11, 2026
Adding a macOS + Chrome reproduction from September 11, 2026. This appears to be the same issue, so I am adding evidence here rather than opening a duplicate.
Environment and requested workflow
26.903.71938(directory version; the desktop app and Chrome versions were not independently recorded).Observed failure
Browser tab enumeration returned the WeChat Channels tab title and URL, but
cua.getTab(...)was rejected before page inspection, file upload, form filling, or publishing:The user then reported removing the restriction in the Chrome extension. The exact setting and persisted configuration were not independently inspected. After the browser connection changed, the agent rediscovered the active Chrome connection and retried the same supported tab-access operation once. It returned the same site-safety rejection. Thus, this is evidence of a persistent block after a user-reported settings change, not proof of the exact local allowlist contents.
Read-only implementation findings
Inspection of the installed
browser/26.903.71938/scripts/browser-service.mjsfound:https://chatgpt.com/backend-api/aura/site_statuscheck.ensureUrlOriginAllowedawaits URL policy checking before origin consent checking.site_status_blocked,persisted_user_denied, andguardian_denied. The observed error matches the first, explicitly stating that neither a user permission prompt nor Auto-review was attempted.qq.comin that bundle.A text search of the tracked files in public
openai/codexcommit02a8f038b87ad34d4a1dc5058eda26972ed7aa6calso found noqq.com,channels.weixin.qq.com, orsite_status. This does not establish the server-side classification rules or whether other QQ subdomains are affected.No plugin files were modified, no policy endpoint was directly queried to enumerate domains, and no alternate automation path was used to bypass the denial.
Requested clarification
Could maintainers please:
The absence of an actionable explanation caused repeated settings changes and troubleshooting, while the actual task never reached the upload step. Credentials, cookies, account identifiers, local personal paths, and full session logs are omitted.
janiezhang52-lab commentedon Sep 16, 2026
Additional owner-authorized macOS + external Chrome case, observed on September 16, 2026:
The account owner submitted in-app feedback and provided the submission confirmation. Feedback ID:
01a0907f-31b6-7291-967e-eac4173a2725. This confirms feedback submission only, not recovery of site access.Installed versions, checked from application/extension metadata while preparing this report:
ChatGPT desktop app (
com.openai.codex):26.908.70816, build9275.Google Chrome:
152.0.7977.83.ChatGPT Chrome extension:
1.26.901.11451.An access attempt to
https://channels.weixin.qq.comreturned: “The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted. Browser use is not permitted on https://channels.weixin.qq.com.” The remaining error text prohibited alternate routes and policy circumvention.The same browser connection can enumerate tabs and successfully read an already-open public OpenAI documentation page. This was not a general connection timeout.
The user checked the application's website permissions and reported no separate blocked entry for this site or related WeChat domains. The assistant did not independently inspect those settings.
The user previously reported completing login, and a permitted tab inventory showed the WeChat Channels backend. The user then added an explicit allow rule for
https://channels.weixin.qq.comthrough the official settings UI and reported saving it. Saving the rule was user-reported, not independently verified by reading the application's settings.Chrome briefly disappeared from the browser inventory. After the user opened the ChatGPT extension side panel, the same extension instance reconnected. A single subsequent attempt through the original
cua.createBrowserTabinterface to open the site root returned the same site-safety rejection. This is a fresh rejection after the reported permission change and connection recovery. No login page or backend content was reached; the current authentication state is unverified.Could a maintainer clarify whether the original site-safety rejection is expected, and provide the supported review or recovery route? If reevaluation is supported, please identify the documented interface and conditions; if it is not, please explain the restriction's scope and an actionable support route. This also relates to the recovery deadlock tracked in #43068.
No workaround was attempted. This report does not claim a permanent ban or a confirmed implementation-level cause. No account identifiers, credentials, cookies, private screenshots, or raw session logs are included.
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 WeChat Channels.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.Guanbin-Huang commentedon Sep 23, 2026
Adding a macOS + Chrome reproduction observed on September 23, 2026.
Environment
1.26.901.11451.26.915.31945.https://channels.weixin.qq.com.Verified observations
Browser is not available: chrome.https://example.com/succeeded with the visible title/contentExample Domain.cua.createBrowserTabinterface returned:The intended workflow was an explicitly user-authorized upload and publication of a short test video to the user's own WeChat Channels account. No page inspection, login verification, upload, or publication was completed after the denial. The working control page and recovered connection distinguish this failure from the earlier unavailable-browser error; they do not establish why this domain was classified as blocked.
No safety checks were disabled, no plugin files were patched, and no alternate automation route was used to bypass the denial. No local website allowlist change is claimed as independently verified in this reproduction.
Requested clarification / fix
channels.weixin.qq.comclassification intentional, or can it be reviewed as a possible false positive?This comment contains no account identifiers, credentials, cookies, media, private screenshots, local personal paths, browser instance IDs, or raw session logs. The account owner explicitly authorized posting this reproduction to the existing issue.
shangguanqianxin commentedon Sep 24, 2026
Adding a user-authorized macOS + Codex desktop + Chrome reproduction from September 24, 2026. This is the same domain-level denial, so I am adding it here rather than opening a duplicate.
https://channels.weixin.qq.com/platform/post/list; no public posting was requested.cua.getTab({url: "https://channels.weixin.qq.com/platform/post/list"}, {browser: "chrome"})was rejected before any page inspection or upload. The error said Browser Use is not permitted on that URL and prohibited alternate browser surfaces, raw CDP, browser commands, and indirect execution for the same outcome.Could maintainers clarify the scope and duration of this site-safety denial, the supported review/recovery path, and whether a separate existing CLI automation is actually meant to be disallowed after a Computer Use refusal? No credentials, account identifiers, local paths, media, or session logs are included.
ailing137 commentedon Oct 10, 2026
Adding an owner-authorized Windows + Edge reproduction observed on 2026-10-10. This is the same WeChat Channels site-safety denial, so I am adding current evidence here rather than opening a duplicate.
Verified scope and comparison
26.1007.2314.0and core0.162.0-alpha.17.2. Installed Browser Use bundle:26.1007.21434. These versions are context, not proof that this update caused the site classification.https://channels.weixin.qq.com/platform/post/list, an already-open official creator page.Two distinct rejections
cua.getTab(existingTabId, {browser: existingEdgeBrowserId})interface was rejected before page inspection, upload, or submission. The returned classification text was:Read-only inspection of the installed bundle maps the first exact message to
site_status_blocked/decisionSource: "site_status"and marks it non-retryable. This distinguishes it from saved-user-permission and guardian-denial classifications. No policy endpoint was directly queried, and no plugin, safety flag, cache, binary, or security check was modified.Request for actionable resolution and delivery
Please review whether this creator-page classification is intentional or a false positive. If access can be restored, please identify the supported review/recovery entry point, the responsible component, and a target delivery/review milestone. If access remains unsupported, please explicitly document its scope and the permitted recovery conditions.
The current error requires the agent to stop, while neither the user nor agent has an observable signal or supported status-only interface to determine when reevaluation is permitted. This is also the recovery deadlock tracked in #43068. Please provide a concrete policy-status / review mechanism that does not require accessing the blocked page, instead of requiring users to repeatedly increase permissions or restart.
Acceptance after an applicable supported resolution: the original agent can access the official list, check duplicates, upload the existing authorized video once, schedule it, and read back the same title and scheduled time; actual publication remains a separate readback. Until then, the Channels action stays blocked and unrelated healthy workflows remain in service.
No account identifiers, local personal paths, tab IDs, cookies, tokens, media, private screenshots, or full logs are included. We are not requesting a security bypass or claiming an account ban, a permanent policy, or a confirmed upgrade regression.
sqzy0026-droid commentedon Oct 11, 2026
Additional Windows + Chrome reproduction observed on 2026-10-11 (Asia/Shanghai).
Please review whether this creator-page classification is intentional or a false positive, and provide:
Acceptance after a supported resolution begins with successful access to the original creator page through the original official integration. Upload, scheduling, and published-state/metrics readback must then be separately verified. No restoration or publication is claimed here.
No credentials, cookies, account identifiers, private screenshots, unrelated tab metadata, raw logs, or full conversation history are included.
imgongdao commentedon Oct 16, 2026
Subject: Request to Review WeChat Channels Website Access Restrictions in ChatGPT Work
Hello OpenAI Team,
I'm reporting a potential website safety classification issue affecting ChatGPT Work.
Website:
https://channels.weixin.qq.com/platform
Problem:
Related GitHub Issue:
#35549
My use case is legitimate content management for my own WeChat Channels account, including uploading videos, managing drafts, and scheduling publications.
I would appreciate clarification on three questions:
Is this domain intentionally restricted by OpenAI's browser safety policy, or is this a potential false positive?
Can OpenAI review the domain classification and consider allowing explicitly authorized AI agent operations?
Is there an official review, allowlisting, or appeal process for websites incorrectly classified as unsafe?
I fully understand the importance of browser security policies and am not requesting a workaround or security bypass.
I would simply like this website to be reviewed so legitimate, user-authorized automation can be supported.
Thank you!
bcjanthony commentedon Oct 18, 2026
macOS + Chrome reproduction on 2026-10-18: explicit site consent persists, access still denied
The account owner explicitly authorized this public, sanitized report. The requested workflow is to publish the owner's own finished videos through the official WeChat Channels assistant. The failure happens before page inspection, not during media upload or Tencent review.
Installed versions, read from local application metadata today (not a claim that these are the latest releases):
Verified this run:
https://channels.weixin.qq.comstill has persistedaccess = "allow". The owner had already selected Always allow on October 16; this run independently re-read that exact setting.cua.createBrowserTabnavigation tohttps://channels.weixin.qq.com/platformthrough the original Chrome integration was rejected before any page content was returned.It also stated that the site-safety gate did not grant access for that exact origin. No account identity, login state, published-work list, or upload capability could therefore be verified. No media was selected, uploaded, or submitted.
The tool prohibited indirect execution, raw CDP, alternate browser surfaces and policy circumvention. None was attempted. No safety flag, policy endpoint, plugin file, credentials or browser storage was changed or queried to bypass the decision.
Request to maintainers:
The acceptance criterion is normal access through the original integration, followed by separately verified account identity, duplicate checking, single submission, scheduling and later public-state confirmation. This report does not claim a Tencent account penalty, confirmed internal root cause, permanent ban, or restored publishing.
No creator account IDs, local paths, tab identifiers, cookies, credentials, private media, screenshots, conversations or raw logs are included.