Repository navigation
[Browser Use] Owner-authorized WeChat service-account admin blocked; supported API access and recovery path unclear #44451
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
- Windows: "Feedback upload not confirmed" while reporting a Browser Use site-safety block #43436
- Browser-use blocks an explicitly authorized, user-owned Naver Blog page #43241
Powered by Codex Action
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 admin.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.补充 Windows 内置浏览器复现 / Additional Windows in-app browser reproduction
中文：
在 Windows Codex 桌面端，用户明确授权操作自有微信小程序后台后，通过正常内置浏览器入口打开 https://mp.weixin.qq.com/，仍在页面读取和权限提示之前被拒绝。相同的内置浏览器可正常访问 OpenAI 文档和 Help Center。与本 issue 的 macOS 服务号案例相比，本次是 Windows 内置浏览器、小程序后台工作流，且已做只读配置核对：用户及项目配置中没有找到匹配该站点的拒绝条目；官方文档列出的两处本地托管配置文件不存在。这不能排除云端或其他托管策略。当前运行应用的确切版本、账户套餐及策略来源尚未确认，不将它们作为已知事实。
英文 / English:
On Windows Codex desktop, after the user explicitly authorized administration of their own WeChat mini-program, opening https://mp.weixin.qq.com/ through the normal in-app browser entry point was denied before page inspection or a permission prompt. The same in-app browser successfully accessed OpenAI documentation and the Help Center.This adds a Windows in-app browser / mini-program workflow to the macOS service-account case. Read-only checks found no matching site-deny entry in the user/project configuration, and the two local managed-configuration files documented for Windows were absent. These observations do not exclude cloud or other managed policy. The exact running app version, subscription tier, and policy source have not been verified.
Exact error / 原始错误（无账户信息）:
The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted. Browser use is not permitted on https://mp.weixin.qq.com.希望确认该限制是否有意设置、由哪一层策略决定，以及支持的复核或恢复路径；如果该站点不受支持，请在产品中明确说明。本反馈不请求绕过安全策略。未使用其他浏览器、CDP、代理或间接请求去完成被拒绝的后台操作。
Please clarify whether this restriction is intentional, which policy layer determines it, and the supported review/recovery route. If the site is unsupported, please make that boundary explicit in the product. This report does not request bypassing safeguards. No alternate browser, CDP, proxy, or indirect request was used to carry out the denied administration action.
已向官方 Help Center 发送中英双语说明，但该 AI 对话表示无法转接人工或生成可追踪的 case reference，因此在现有相关 issue 下补充复现，避免重复建单。本公开补充不包含邮箱、登录令牌、AppID、私有页面、会话 ID 或原始诊断包。
A bilingual report was sent through the official Help Center, but that AI conversation stated it could neither transfer to a human nor create a trackable case reference. This reproduction is therefore added to the existing related issue rather than opening a duplicate. No email address, login tokens, AppID, private page content, session IDs, or raw diagnostic bundles are included.
I can reproduce the same Browser Use site-safety denial on Windows 11 with the current ChatGPT/Codex desktop build 26.915.4065.0 and the Edge extension.
The affected owner-authorized tab is https://mp.weixin.qq.com/cgi-bin/home. The local Browser Use configuration explicitly allows the exact origin; the local allowed list includes it, the denied list is empty, and full CDP is enabled. Edge tab discovery, claiming, title, and URL inspection work. DOM inspection or screenshots are rejected before page content is read with the same “site-safety policy blocks this action; no user permission prompt or Auto-review was attempted” behavior.
This is not a WeChat HTTP/API response: the refusal happens before page-level access. The requested action is read-only draft/editor verification; no publish, delete, upload, credential entry, or account-permission change is requested.
Please review the mp.weixin.qq.com site classification and document a supported, owner-authorized route for read-only administration checks. No account name, credentials, tokens, article content, screenshots, session IDs, or private URLs are included here.
+1 — I encountered the same behavior in the local in-app browser on Windows on October 1, 2026.
I explicitly authorized a read-only audit of my own WeChat Official Accounts and referenced an already-open backend tab. Opening the WeChat administration site and connecting to the explicitly selected backend tab were both rejected before page content could be read.
The refusal for the backend homepage included the following (query parameters omitted):
The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted. Browser use is not permitted on https://mp.weixin.qq.com/cgi-bin/home.In the same session, the browser tool could enter a search query on Baidu, click the search button, and load the results. No WeChat backend account data was read, and no account changes were made. I did not switch browsers or use an indirect route to bypass the restriction.
The app build, local allow/block settings, and any managed policy were not independently verified, so I cannot confirm the underlying cause. Could you clarify whether this is an intended restriction or a classification error, and what supported review or recovery route is available for an owner-authorized, read-only workflow?
No account names, credentials, login tokens, private query parameters, screenshots, or session identifiers are included in this report.
Additional Windows in-app Browser evidence: exact origin is allowed in configuration, but WeChat administration is still rejected before consent
补充 Windows 内置浏览器证据：配置已允许精确站点，公众号后台仍在权限确认前被拒绝。
The owner explicitly authorized operating their own WeChat Official Account. This adds independently checked local permission evidence and a working-browser comparison to #44451. No new issue is needed.
Observed environment
- Windows desktop app; desktop package version recorded during the same-day component diagnosis:
26.930.3930.0. - Built-in Browser plugin
26.930.31730, installed through supported bundled-plugin management. Installed files match the bundled source. - Exact Windows build and subscription tier are not included in this report.
Actual denial
The original Browser tool result from October 2, 2026 was re-read, including
isError: true. Its message, with no account-specific URL parameters, was: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://mp.weixin.qq.com/cgi-bin/home. 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 user had already signed in manually, saved an Always allow exception for the exact origin, and restarted the app. The refusal persisted in the post-restart tool observation. This is a Browser tool-policy response, not a WeChat HTTP/API error.
Independently verified on October 3
The relevant actual user configuration contains:
[browser_use.origins."https://mp.weixin.qq.com"] access = "allow" downloads = "allow"
No system
requirements.tomlor localmanaged_config.tomlwas present in the documented Windows locations checked. No project configuration file was present. This does not rule out cloud-delivered requirements or another effective policy layer.Normal Browser operation is working: in the same task, the in-app browser read a separate permitted site, entered the authorized full text, clicked its submit button, returned the result, and captured screenshots. A separate missing bundled-plugin component was repaired through supported plugin management. That repair is not being presented as a restoration of WeChat site access.
A bounded October 2–3 app-log search found WeChat page navigation/DOM-ready records but no explanatory site-safety rule or classification reason. This does not prove that a relevant rule is absent from all runtime sources.
This October 3 follow-up only re-read existing evidence, inspected documented local configuration, and confirmed the functioning Browser on permitted pages. It did not retry the denied backend, alter policy checks, invoke private classification endpoints, or use another browser/mouse/API route for the denied action.
Requested supported resolution
- Identify the controlling policy/classification for this exact origin and explain why the saved Allow rule does not enable the owner-authorized workflow.
- Confirm whether the restriction is intentional or needs classification review.
- Provide a supported review/revalidation/recovery path and the applicable signal that would permit normal Browser operation to resume.
- If this workflow is unsupported, expose that limitation and the appropriate review channel in the permission UI.
用户愿意配合任何明确、适用的正式设置步骤。现有“始终允许”、正常登录和重启已完成；请不要再把缺失用户授权作为原因，也请区分网站访问许可、普通网页点击与微信公众号发布API权限。
This requests a supported diagnosis and recovery, not bypassing safeguards. The public report excludes account names, AppIDs, credentials, cookies, article text, private screenshots, local usernames/paths, session/feedback IDs, and full logs. No claim of an official fix, acceptance, or successful publication is made.
- Windows desktop app; desktop package version recorded during the same-day component diagnosis:
Additional Chrome / Windows report with in-app feedback ID (2026-10-09)
Chrome's default browser access permission is set to Always allow, and there is no blocked rule for
mp.weixin.qq.com. However, asking the browser tool to access https://mp.weixin.qq.com/cgi-bin/home returns:Browser use is not permittedNo authorization prompt appears. These are the user's reported observations; the underlying policy/classification has not been determined.
中文原始描述：
Chrome 默认浏览权限为“始终允许”，没有 mp.weixin.qq.com 的禁止规则，但访问公众号后台 https://mp.weixin.qq.com/cgi-bin/home 时，浏览器工具返回“Browser use is not permitted”，且没有授权弹窗。请排查权限设置与实际拦截不一致的问题。
Steps corresponding to the reported failure
- In the desktop app's browser permission settings, set Chrome's default access to Always allow.
- Confirm there is no blocked rule for
mp.weixin.qq.com. - Ask Codex to open https://mp.weixin.qq.com/cgi-bin/home using Chrome.
- The browser tool reports the above denial without showing an authorization prompt.
Environment captured while preparing this report
- Codex Windows installed package:
26.1002.7124.0(read from the installed Windows package; the exact build at the earlier failure was not captured separately). - Windows 11 x64, version
10.0.26200, build26200. - Installed Google Chrome:
154.0.8037.99.
Expected behavior and requested investigation
The browser permission UI and the effective access decision should be consistent. If a separate enforced site policy takes precedence over Always allow, please make that restriction and its supported review/recovery route clear in the UI and error message.
Please investigate why the configured permission does not permit this workflow and why there is no authorization prompt.
Submitted diagnostic feedback
The in-app
/feedbackflow completed, and the receipt explicitly shows 反馈已提交 / Feedback submitted.Feedback ID:
01a1212e-ecf4-7111-adde-786e60c6f0cfPlease correlate this additional Chrome report with that diagnostic feedback bundle.
English: Windows reproduction affecting WeChat Official Accounts and Channels (2026-10-10, UTC+8)
The account owner explicitly authorized this feedback and the underlying publishing workflow. The task is to publish approved promotional content to the owner's own WeChat Official Account and Channels account. The denial occurs while selecting or reading an existing administration tab, before uploading content or submitting a post.
Affected sites and observed paths
All session-specific query parameters have been removed:
- https://mp.weixin.qq.com/cgi-bin/appmsg
- https://mp.weixin.qq.com/cgi-bin/frame
- https://channels.weixin.qq.com/platform/post/list
- https://channels.weixin.qq.com/platform
Environment: Windows, Codex desktop app, Chrome through the official Browser Use integration. The latest desktop/extension build numbers have not been independently verified.
Authorization, settings and observations
- The owner explicitly approved the business workflow and enabled full local access.
- The owner's website-permission screenshot showed Browse and Download set to Always allow for both WeChat origins. The Upload column was not shown; its setting is therefore unknown.
- The owner reported updating ChatGPT/Codex and AiToEarn. After explicit authorization, standard cua.getTab calls to select the existing WeChat administration tabs still returned direct site-safety denials for both destinations.
- Browser tab inventory was readable. The ordinary AiToEarn page was also readable, with both WeChat channels showing Online and the extension showing Ready. These checks establish connection availability and access to some pages, not that WeChat publication permissions or destination-policy restrictions have been resolved.
- On October 7, 2026, a different video received a Published successfully receipt through AiToEarn. Direct Browser Use access to the WeChat backend was also blocked at that time. This historical third-party receipt is not proof that the same Browser Use interface previously succeeded, and we have not established a regression caused by a particular update.
Actual denial and impact
The latest two WeChat tab-selection attempts returned the following common error:
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.The tool also prohibited achieving the same blocked result via workarounds, indirect execution or alternate browser surfaces. The agent did not use another browser, APIs, AiToEarn or WorkBuddy to carry out the denied publishing workflow. Neither current post has been uploaded or submitted by the agent.
Earlier attempts separately encountered Auto-review rejecting a retry. Those are distinct from the direct site-safety results above and should not be conflated.
Requested clarification and supported resolution
- Identify the controlling policy and reason for both WeChat origins, and clarify whether this is an intended restriction or requires classification review.
- Explain why Always allow does not permit access before a user confirmation, and provide the supported review/resumption process, applicable conditions and relevant versions.
- If the workflow is unsupported, make that boundary visible in the website-permission UI so users are not repeatedly directed to authorize, restart or change browsers.
- Clarify whether the prohibition on indirect execution extends to an independently authorized publishing service or WorkBuddy. If an official API or publishing-service route is supported, document the conditions under which it may be used.
Related reports: this issue's Official Accounts reports and the September 14 and September 25, 2026 Channels reports in #29343. Other users' reports are not official root-cause confirmation, and this report does not claim a fix exists.
Separate Help Center observation
On October 10, 2026, the current Chrome session returned ERR_EMPTY_RESPONSE when opening help.openai.com and the official contact-support article. Reloading also failed. No support chat was reached and no support ticket number was obtained. This is a separate observed page-loading problem; we do not assert that it shares the cause of the WeChat denial.
Privacy and scope
The account owner authorized this submission. It contains no account identifiers, email addresses, credentials, cookies, session parameters, private screenshots, video contents, request/session identifiers or raw logs. This requests diagnosis and a supported resolution, not disabling or bypassing safeguards.
补充 Windows 微信公众号与视频号复现（2026-10-10，UTC+8）
账号所有者已明确授权提交本反馈。正常需求是在自有公众号、视频号发布已批准的宣传内容；但失败发生在绑定/读取现有后台页面时，尚未上传或提交。
受影响站点及已观察路径（已移除全部会话参数）：
- https://mp.weixin.qq.com/cgi-bin/appmsg
- https://mp.weixin.qq.com/cgi-bin/frame
- https://channels.weixin.qq.com/platform/post/list
- https://channels.weixin.qq.com/platform
环境：Windows，Codex 桌面应用，Chrome 官方 Browser Use 连接。最新客户端/扩展构建号未独立核实，不作推断。
已完成的操作与证据：
- 用户已明确批准业务操作，并启用本地完全访问。
- 用户提供的网站权限截图显示两个微信域名 Browse、Download 为 Always allow；Upload 列未显示，不推断其值。
- 用户报告已更新 ChatGPT/Codex 和 AiToEarn。明确授权后，通过标准 cua.getTab 绑定原微信后台标签页，两次仍直接返回 site-safety 拒绝。
- 浏览器库存可读取，AiToEarn 普通页面可读取，两个微信渠道显示 Online、扩展 Ready。此对照只能证明连接和部分页面可用，不能证明微信发布权限或站点策略已经解除。
- 2026-10-07 另一条视频曾由 AiToEarn 显示 Published successfully；当时直接读取微信后台也受限，因此不将历史第三方回执说成同一 Browser Use 接口的成功，更不声称已确认某次更新造成回归。
最新两次微信读取共同错误：
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.工具同时禁止通过 workaround、indirect execution 或 alternate browser surfaces 完成同一受限动作。代理没有改用其他浏览器、API、AiToEarn 或 WorkBuddy 执行受限发布。本期两条仍未由代理上传或提交。早先另有 Auto-review 拒绝重试，不能与上述直接 site-safety 回执混为一谈。
请求维护方明确：
- 两个微信域名的控制策略、拒绝理由，以及属于预期限制还是需要分类复核。
- 为什么已设 Always allow 仍在用户确认前被拒绝；支持的正式复核、恢复条件与适用版本是什么。
- 若此工作流不受支持，请在权限界面明确显示，避免反复要求用户授权、重启或更换浏览器。
- “indirect execution”禁止范围是否包括用户明确授权的独立发布服务/WorkBuddy；如有受支持的官方 API 或发布服务路线，请说明正式允许条件。
关联：本 issue 的公众号报告，以及 #29343 中 2026-09-14、2026-09-25 视频号报告。其他用户报告不是官方根因确认，本反馈不声称已有修复。
官方 Help Center 另行尝试：2026-10-10 当前 Chrome 打开 help.openai.com 及官方联系支持说明页返回 ERR_EMPTY_RESPONSE，重载仍失败；没有进入支持聊天，也没有支持工单编号。这是单独观察的网页加载问题，不认定与微信限制同一根因。
This is an owner-authorized Windows reproduction affecting both WeChat Official Accounts and Channels. Existing authenticated tabs are denied before permission prompts or uploads, despite explicit consent and visible Always allow browsing settings. Please clarify the controlling classification and supported review/resumption path. This requests diagnosis and a supported resolution, not disabling or bypassing safeguards.
本文不包含账号、邮箱、凭据、Cookie、会话参数、私有截图、视频内容、请求/会话标识或原始日志。
Windows Chrome extension: current reproduction plus working-site controls (2026-10-11)
Observed on 2026-10-11 (Asia/Shanghai, UTC+08). Windows 11 Pro, version/build 10.0.26200 / 26200. Desktop updater reported 26.1007.21434, build 13901, prod, up_to_date earlier the same day; MSIX package 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2. These are separately versioned components.
Chrome product version checked today: 154.0.8037.98. Installed ChatGPT Chrome extension manifest version: 1.26.901.11451.The owner authorized checking their publishing workflow. After the owner opened the intended signed-in Chrome profile, the normal Chrome extension connection became available. In that same connection:
Target Actual test result Baidu search Entered a query, clicked search, and read results successfully. Sohu creator Signed-in dashboard and article editor opened; title, body, image, cover and publishing controls were readable. No content was submitted. Zhihu creator Signed-in creator dashboard and article editor opened; title/body/image/publishing controls were readable. No content was submitted. https://mp.weixin.qq.com/ Immediate Browser Use site-safety refusal before the editor could be inspected. https://baijiahao.baidu.com/ Same refusal, with the denied path reported as /builder/theme/bjh/login. Authentication state could not be determined from this denial. Exact WeChat error excerpt:
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://mp.weixin.qq.com.The refusal also explicitly prohibited workaround/alternate-surface execution. We stopped those site operations. No native input, alternate browser or API was used to carry out the denied publishing actions. The working Sohu/Zhihu editor observations are not claims that uploads, draft saving or publication have been validated.
The user supplied an app-settings screenshot showing Chrome default browsing as Always allow and an origin exception for WeChat. A current read of the local origin entry exposed only downloads=allow; that file observation is not proof of an effective browsing/upload permission. The effective policy source remains unknown. No settings were broadened during this diagnosis.
Please identify whether the denials on these exact publishing origins are intentional restrictions or classification errors, and provide the supported review/recovery route or an explicit unsupported-capability statement. Please distinguish saved user permissions from the policy that rejected the action before a permission prompt. We are not requesting that safety checks be disabled.
Submitted on the account owner's explicit request. This comment contains no account names, personal paths, credentials, cookies, private query parameters, screenshots, raw logs or conversation content.
Additional Windows in-app Browser evidence: successful owner-authorized draft saves on September 30 and October 4, followed by the same site-safety denial on October 10–11, 2026.
The affected path is https://mp.weixin.qq.com/cgi-bin/home. The tool reports: “The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted.” Historical successful saves were verified from independent draft IDs and manual-save receipts. This establishes intermittent success and denial, not a confirmed regression caused by a particular update.
Current desktop version from local diagnostics: 26.1007.2314.0; bundled Browser Use: 26.1007.21434; bundled CLI: 0.162.0-alpha.17.2. A fresh normal in-app Browser attempt in the current diagnostic chat still returned the same refusal. Browser discovery and documentation calls work; no backend write was performed.
Read-only inspection of the installed Browser Use code shows a 24-hour hostname-keyed site-status cache. An offline test using the original cache class and synthetic responses showed that an unexpired cached denial is retained even after a synthetic backend response changes to allow. This is an independently reproduced implementation behavior, not proof that it caused the actual WeChat denial. The local doctor report does not expose the actual site-status response or cache-hit status.
Please correlate the denial with the service-side decision and distinguish a current classification denial from a cached denial. Please provide the applicable reason/scope, a supported diagnostic or revalidation route, and a supported recovery condition for an owner-authorized workflow. No policy changes, alternate-browser workaround, private endpoint calls, or credential extraction were used to carry out the denied operation.
Summary
An owner-authorized workflow for a self-owned, verified WeChat service account is blocked by Browser Use site-safety policy when opening the administration home and article-management pages. The user is building an internal illustrated-article editor and wants a supported connection to their own account, not to bypass safeguards.
Related: #34118 concerns public, read-only WeChat articles. This report adds the distinct authenticated owner-administration case and asks for clarification of permitted official API integration.
Environment
Observed Browser Use denials
The original tool outputs were checked for these paths, with query parameters omitted:
https://mp.weixin.qq.com/cgi-bin/homehttps://mp.weixin.qq.com/cgi-bin/appmsgThe home-page refusal included:
The article-management path returned the same class of refusal.
These are tool-policy denials, not WeChat API responses. No WeChat API request was made to circumvent them. No alternative browser, raw browser protocol, or command-line route was used to perform the blocked administration/publishing actions.
Local allow/block settings and any organization-managed policy were not independently verified. The precise classification reason, its scope, and whether the result is intended or erroneous remain unknown.
Separate feedback-entry limitation
While preparing a supported feedback route, selecting the installed Codex app through native Computer Use returned:
This prevented the assistant from opening the in-app feedback UI for the user. It is a separately observed native-app restriction, not proof of a shared root cause or of a universal native-app failure. This GitHub report contains no in-app feedback bundle.
Official integration context
The user supplied account-permission screenshots indicating access to image upload, draft management and publication. These screenshots were not uploaded here, and permissions were not independently verified through live API calls.
The following public WeChat documentation was read successfully:
These document server-side service-account capabilities. Their existence does not establish that the current agent may switch to API execution after this particular refusal. That permission boundary is exactly what needs clarification.
User impact and requested resolution
The workflow is stuck in an approval loop: the owner has authorized the work and is willing to perform administrator verification, but the refusal says it occurred before user permission review and gives no actionable review/resume condition.
Please clarify:
The request is for a supported route or a clear capability boundary, not disabling safeguards or evading a policy decision.
Privacy and authorization
The account owner explicitly authorized this public report. It contains only the affected generic paths, sanitized error text, reporting-time app version, and functional impact. No account name, AppID, credentials, cookies, photographs, article content, private screenshots, local user paths, conversation/session IDs, or raw logs are attached.