[Browser Use] Owner-authorized WeChat service-account admin blocked; supported API access and recovery path unclear

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

macOS desktop Codex task.
Installed Codex app version when preparing this report: 26.903.61454, read from the installed application's Info.plist.
The exact app build at the earlier Browser Use denials was not captured, so the reporting-time version should not be assumed to be the original reproduction version.
Observed on September 10, 2026.

Observed Browser Use denials

The original tool outputs were checked for these paths, with query parameters omitted:

https://mp.weixin.qq.com/cgi-bin/home
https://mp.weixin.qq.com/cgi-bin/appmsg

The home-page refusal included:

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.
Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

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:

Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.

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:

Is the owner-authorized WeChat administration denial expected, or does it require classification review?
What is its scope, and what supported signal or process would permit re-evaluation or resumption?
Is a narrowly scoped, owner-authorized integration through WeChat's documented official server-side APIs permitted? If so, under what supported conditions can an agent implement and use it without violating the earlier prohibition?
If the workflow is unsupported, please state that clearly and distinguish it from missing account permissions, authentication problems, or an implementation bug.

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.

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 calls https://chatgpt.com/backend-api/aura/site_status and 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): wrap node_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.toml or local managed_config.toml was 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.

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 permitted

No 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, build 26200.
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 /feedback flow completed, and the receipt explicitly shows 反馈已提交 / Feedback submitted.

Feedback ID: 01a1212e-ecf4-7111-adde-786e60c6f0cf

Please 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:

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）

账号所有者已明确授权提交本反馈。正常需求是在自有公众号、视频号发布已批准的宣传内容；但失败发生在绑定/读取现有后台页面时，尚未上传或提交。

受影响站点及已观察路径（已移除全部会话参数）：

环境：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.

Follow-up on 2026-10-14: working controls, no claim of policy recovery

Rechecked the same Windows installation. The configured desktop updater reports 26.1007.21434, build 13901, prod, up_to_date; MSIX 26.1007.2314.0; bundled CLI 0.162.0-alpha.17.2. Chrome is now 155.0.8059.40, with ChatGPT extension 1.26.901.11451.

A benign Baidu test through the original Chrome extension completed text entry, click, navigation and result reading. Separately, the installed Windows Computer Use plugin completed a File Explorer read/click/type/folder-navigation test. These controls show that neither all extension actions nor all native actions are unavailable.

The previously refused WeChat/Baijiahao actions were not repeated in this follow-up because no applicable official recovery basis has been identified. Therefore, this is not a new reproduction or a claim that upload/save/publish recovered. Native Explorer success does not authorize native-browser access to a refused site.

Please confirm the supported status and recovery path for owner-authorized mp.weixin.qq.com administration, including any required client/extension/service version. A generic extension reinstall is not established as a remedy for the explicit site-policy denial. No safety setting, helper, browser route, account data or proxy configuration was changed.

This update contains only generic diagnostics, software versions and aggregate timings; no raw logs, screenshots, credentials, private paths, chat contents or identifiers are attached.

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.

Additional macOS evidence: visible browsing permissions allow access, while Computer Use has stopped an owner-authorized WeChat task

Observed while preparing a WeChat Mini Program owned and managed by the user. The intended administration domain is mp.weixin.qq.com. The user initially requested Chrome and later clarified that they were using Safari. No browser was accessed again solely to prepare this report.

Observed restriction

An earlier Computer Use attempt stopped the session with this exact message:

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.

The call did not return the current URL or backend page content, so the exact URL evaluated at the original failure is not independently verified. A subsequent attempt to read browser state was rejected by Auto-review because the session had already received the explicit safety stop. No further browser retry was made after that rejection.

October 13, 2026 observations

Installed desktop app metadata: ChatGPT.app 26.1007.30912, build 20156. This is the installed version at diagnosis time, not a verified version at the original failure or of the currently running process.
User-supplied screenshots of Settings > Browser show the built-in Browser enabled. Agent permissions contains only a Default row, with Browsing and Downloads both set to Always allow. No custom site row is visible. Enable full CDP access is also enabled.
These screenshots show the built-in Browser settings. They do not establish the effective policy for native Safari/Chrome Computer Use, override site-safety checks, or prove that the previously stopped task is cleared to resume.
Read-only inspection found no explicit matching browser_use/computer_use denial in the personal configuration. The project configuration and the checked local managed-requirements file were absent. The browser general configuration contains only full_cdp_access_enabled; no origin allow/deny list was found there. The session file corresponding to the identifier available to the execution environment was absent. These checks do not exclude other app-side, remote, managed, or session-state policy sources.
Tencent Cloud was also part of the planned setup, but no Tencent Cloud page was successfully observed. This report does not claim that Tencent Cloud is independently blocked.

Request for a supported resolution

Could maintainers identify the policy source for this exact Computer Use URL stop and clarify whether owner-authorized WeChat administration is supported? If a classification error, URL-detection issue, or saved denial is involved, please provide an official review/reset process and a clear signal that the original task is allowed to resume. If this workflow is intentionally unsupported, please state its scope and distinguish it from ordinary user browsing permissions.

The session's stop was respected. No permission files were changed, and no alternate browser surface, raw browser protocol, credential extraction, or indirect service request was used to perform the denied administration work. This report requests clarification and a supported recovery path, not disabling safety checks.

Related exact native Safari stop: #52729

No account names, AppIDs, tokens, cookies, private page content, screenshots, local user paths, chat IDs, or raw logs are included.

Additional Windows Chrome extension evidence — 2026-10-13

An owner-authorized, read-only check of a WeChat Mini Program admin console is blocked before page inspection. The requested work is to verify saved privacy-guide and service-category settings.

Environment and time

Observed: 2026-10-13 approximately 23:28, Asia/Shanghai (UTC+08).
Windows desktop package version from the installed package path: 26.1007.2314.0.
Bundled CLI: 0.162.0-alpha.17.2.
Browser path: official Chrome extension, not the in-app browser.
Affected origin: https://mp.weixin.qq.com; generic path: /wxamp/home/guide (all query parameters omitted).
Subscription/workspace management status has not been independently verified.

Exact refusal

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 refusal also explicitly prohibited alternate-surface or indirect execution of the blocked action. That boundary was respected.

Connection failure was isolated from this denial

A previous failed to write kernel assets ... os error 3 initialization error stopped recurring after a full desktop restart. The official browser tool then successfully enumerated Chrome tabs and read an about:blank tab. The WeChat navigation subsequently returned the site-safety refusal. The same official Chrome connection could later access the OpenAI Help Center.

Read-only policy diagnostics completed around 23:43

The user's earlier settings screenshot showed default browsing as Always allow; this is not proof of the effective platform policy.
Chrome extension enabled and official native-host manifest checks passed.
The personal config.toml had no browser_use section.
The documented Windows system %ProgramData%\OpenAI\Codex\requirements.toml file was absent.
Official codex doctor --json loaded configuration but explicitly did not inspect active-thread overrides or identify the rule responsible for this refusal.
A separate official stdio App Server diagnostic process ran only initialize, configRequirements/read and config/read: requirements=null, and no browser_use / browserUse in returned effective configuration. No task/turn was created; the diagnostic process was closed.
That independent CLI process is not a snapshot of the active desktop Browser Use policy. These checks do not exclude app-side, platform, remote or managed policy.

Please help determine:

Which policy layer actually rejected this request, and whether this owner-authorized read-only workflow is intentionally unsupported or requires classification review.
A supported way to obtain the effective rule source, rule identifier or correlation/diagnostic identifier for this refusal.
The official re-evaluation or access-restoration process, including a clear condition for resuming the original task. If unsupported, please state that boundary explicitly.

The report was also submitted to the official Help Center. Its AI support explicitly confirmed that it had not created a human ticket and could not escalate that conversation, and pointed to this repository for a trackable report. Adding the new evidence here avoids another duplicate issue.

This report contains no account email, AppID, credentials, cookies, session/chat IDs, private URLs or query parameters, private page content, user filesystem paths, screenshots, or raw log bundle. No safety settings were changed and no alternative execution path was used to perform the denied WeChat action.

Additional macOS Chrome evidence — 2026-10-15 (Asia/Shanghai)

The user authorized publishing an original article to their WeChat Official Account and asked for this feedback to be submitted after the browser action was blocked. This adds a current reproduction to the existing administration issue.

Environment

macOS 27.2, Apple Silicon (arm64).
Installed desktop app metadata at diagnosis time: ChatGPT.app, version 26.1007.30912, build 20156, bundle identifier com.openai.codex. This is installed metadata, not an independently verified version of the process at the original denial.
Browser route: Chrome extension in a local Codex desktop task.

Observed behavior
Chrome discovery and tab enumeration succeeded, including an existing Official Account article editor. Selecting that existing editor through the normal Browser Use API was rejected before page inspection. Affected generic URL (all query parameters omitted): https://mp.weixin.qq.com/cgi-bin/appmsg.

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/appmsg.

The refusal also prohibited alternate-surface and indirect execution of the blocked action. No workaround was attempted.

Checks and limits

The user checked Settings > Computer Use > Chrome > Manage and reported no WeChat-related blocklist rule.
Read-only checks found no relevant browser-deny entry in the personal config.toml; the documented /etc/codex/requirements.toml file was absent. These checks do not rule out app-side, remote, managed or session policies.
A separate attempt to inspect desktop settings through native Computer Use was rejected for com.openai.codex. Therefore the assistant could not submit an in-app feedback bundle. This is a separate restriction, not proof of a shared cause.
Daily article preparation can continue locally; upload and automatic publication have not resumed.

Could maintainers please identify the policy source and reason for this denial, clarify whether owner-authorized Official Account administration/publication is supported, and provide an official review/recovery process with an observable condition for safe resumption? If it is intentionally unsupported, please state the boundary clearly.

This report contains no account name, AppID, credentials, cookies, query parameters, private page content, local user paths, chat IDs, screenshots or raw logs.

Same block on the WeCom admin console (work.weixin.qq.com) – owner-authorized, requesting review

I am the owner/admin of a WeCom (企业微信 / WeChat Work) organization.
https://work.weixin.qq.com/wework_admin/frame is Tencent's official enterprise admin console, equivalent to admin.google.com or admin.microsoft.com, on Tencent's own qq.com domain.

What happens: "site-safety policy blocks this action… Browser use is not permitted on work.weixin.qq.com". The block fires before any permission prompt. "Always allow" and full CDP access make no difference.

Also blocked: open.work.weixin.qq.com (official developer docs), doc.weixin.qq.com
Not blocked: exmail.qq.com (Tencent enterprise mail) – so this looks like a broad *.weixin.qq.com rule rather than a judgment about the admin console itself.

Expected: show the normal permission prompt so the account owner can approve, or provide a documented review/appeal path or a workspace-level allowlist for business admin consoles.

Related: #34006, #29343

Environment: ChatGPT desktop app 26.1007.30912, macOS 27.2

Additional Windows in-app browser observation: WeChat minigame account-registration workflow (2026-10-17)

The user authorized help registering a new WeChat minigame account. Opening https://mp.weixin.qq.com/ through the normal in-app browser entry point was rejected before the agent could observe page content:

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 could not acquire authority to observe page content.
The site safety gate did not grant access for https://mp.weixin.qq.com.
Site safety policy blocked this URL.

Environment captured during the investigation:

Windows x64, Microsoft Windows NT 10.0.19045.0.
Installed Windows package: OpenAI.Codex 26.1013.3656.0, obtained from package metadata, not the About dialog. The exact package version at the first denial was not separately captured.
Codex built-in browser (iab). Subscription tier not collected.

Observed sequence and limits:

The agent attempted to open the official homepage above and received the site-safety denial.
The user-provided website-permission screenshot showed default Browse = Always allow and no custom site rows. A normal retry in the same browser after the settings change returned the same denial.
The user reports being able to open the official registration URL manually in the same built-in browser: https://mp.weixin.qq.com/cgi-bin/registermidpage?action=index&weblogo=1&lang=zh_CN . The agent has NOT tested access to that exact path, so this report does not claim an exact-path denial.
The same browser successfully reached the OpenAI Help Center and exchanged support messages.

Read-only checks found no browser_use rules in the user configuration and no project config or documented local managed/requirements files at the checked locations. This does not exclude cloud-delivered or other effective policies. Searched desktop logs did not reveal a classification reason or diagnostic reference for this denial.

A local loopback proxy and TUN are in use. Local DNS returned non-global fake-IP addresses for both mp.weixin.qq.com and help.openai.com, while the latter remained accessible to Browser Use. The proxy/DNS contribution is unconfirmed; this is not evidence of a root cause. No network change or alternate access route was used to bypass the denial.

Please clarify whether the registration workflow is intentionally unsupported or requires site-classification review, and provide the supported review/resumption process. If Always allow cannot affect this gate, please make that boundary and an actionable diagnostic reference visible to users.

The official Help Center AI received the report but explicitly stated it could not escalate to a human, create a case/reference number, or promise email follow-up. No human support ticket or in-app feedback bundle has been verified for this reproduction.

This adds the registration workflow and current Windows package evidence to the existing report rather than opening a duplicate issue. It requests a supported resolution. No email address, account identifiers, AppIDs, credentials, cookies, private screenshots, local usernames/paths, session IDs, or raw logs are included.

Additional macOS Chrome evidence — 2026-10-18 (Asia/Shanghai)

The account owner authorized this sanitized public follow-up. The intended task was to inspect their own WeChat Official Account backend; no publishing or deletion was requested during this diagnosis.

Observed permissions and connection behavior

The user's settings screenshot shows the Chrome extension installed, default website Browse and Download permissions set to Always allow, website tools enabled, and full CDP access enabled. The visible custom exception was for cloud.weixin.qq.com and was allowed. Upload permissions were not shown. These observations do not establish the effective managed or platform policy.
Browser inventory succeeded and listed the intended mp.weixin.qq.com/cgi-bin/appmsg tab (all query parameters omitted here).
Standard observation of the existing backend tab timed out after 30 seconds. A separate attempt to open/observe a public documentation page also timed out after 30 seconds.
A subsequent native Chrome inspection returned:

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.

Evidence limits

This refusal returned neither the evaluated URL nor page content, nor a policy identifier/classification reason. The backend path above is the previously inventoried intended tab, not a URL returned by the refusal.
The generic timeouts and explicit URL prohibition are separate observations; a shared root cause has not been established.
Exact application/extension versions for this reproduction were not captured.
Backend browser operations stopped at the explicit refusal. No alternative browser, raw CDP, cookies, or safety-disabling patch was used afterward to perform the blocked action.

Could maintainers clarify whether this is intended policy or a classification/integration defect, identify the controlling policy layer, and provide the supported review/resume condition? Please distinguish a policy restriction from a connection failure in the UI, and avoid making already-enabled local permissions the only recovery instruction.

This is a GitHub follow-up only: no in-app feedback bundle or feedback session ID is attached. No login tokens, cookies, account identifiers, private screenshots, article content, or raw diagnostic logs are included.

Follow-up version check (after the reproduction)

The configured desktop updater reports up_to_date for app 26.1013.40934, build 20770, release channel prod.
Chrome's registered extension manifest reports 1.26.1005.11759. The OpenAI Chrome Web Store listing currently reports the same version, updated October 15, 2026.
These are reporting-time checks, not versions captured alongside the original refusal. No app/extension update, reinstall, or further blocked-site attempt was performed.

Read-only local policy audit — 2026-10-18
The inspected user browser configuration contains an allow rule for the cloud-hosting domain and no deny rule. The system managed-policy directory and standard managed-preference directories were absent; the inspected user application preference file contained neither documented managed TOML payload key. These checks do not establish effective cloud-managed/platform policy. A targeted scan of today's desktop logs found no matching policy-reason event; this is an observability limitation, not proof no policy was applied. No configuration, safeguard, or backend state was changed. Please identify the effective policy source and supported re-evaluation condition.

Additional Windows Chrome reproduction with submitted in-app feedback (2026-10-19, Asia/Shanghai)

The affected user explicitly authorized this sanitized public follow-up and publication of the feedback ID below.

Scope and environment

The intended workflow is read-only research using public WeChat Official Account articles. No publishing, messaging, account changes, or other website writes are requested.
Windows installed package, checked during this investigation: OpenAI.Codex 26.1013.4894.0.
Bundled Chrome Browser Use client: 26.1013.40934. This is the bundled client version, not an independently verified Chrome Web Store extension version.

Working control and separate denial

Chrome session naming and user-tab enumeration succeeded.
In a temporary Chrome tab, navigation to https://example.com/, accessibility-text reading, clicking its Learn more link, and reading https://www.iana.org/help/example-domains all succeeded.
Normal Browser Use navigation to https://mp.weixin.qq.com/ was then rejected before page content was returned. The sanitized tool response included:

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 could not acquire authority to observe page content.
The site safety gate did not grant access for https://mp.weixin.qq.com.
Site safety policy blocked this URL.

No account search, article-list request, or article-body read was performed after the refusal. No WeChat HTTP/API error was obtained, so this result does not establish expired authentication or WeChat frequency limiting. The temporary test tab was closed.

An earlier nodeRepl.fetch request failed connection problem no longer reproduced after a restart. Helper proxy-environment configuration and bundled-component updates occurred during that recovery; their separate contributions were not isolated. Successful ordinary-page controls establish browser connectivity, not restored WeChat access.

Bounded local checks and limitations

TOML parsing found no browser_use table in the user or current-project config, including their configuration profiles.
The documented Windows system requirements file and legacy managed-config file were absent.
These checks do not exclude saved application permissions, cloud-managed requirements, or platform classification. We have not established the exact policy source or a universal block across devices/accounts.
No alternate browser, raw CDP, safety-disabling patch, or indirect request was used to perform the denied access.

Submitted feedback
The user manually completed the in-app /feedback flow. Its receipt explicitly displays 反馈已提交 / Feedback submitted.

Feedback ID: 019efc67-3c6d-7372-93ef-4e52ab893be9

Please correlate this report with that feedback. The receipt does not enumerate the uploaded attachments; we are not asserting which logs or chat content were included.

Could maintainers clarify:

Is this an intended site restriction, a classification error, or an authority/session-lookup failure?
What supported review process and observable resumption condition apply to public, read-only article research? Please distinguish the platform homepage from public article URLs; the latter were not separately tested in this reproduction.
If a fix exists, which release or rollout contains it? If unsupported, please expose that boundary and an actionable diagnostic reference rather than directing users back to repeated login/reinstallation.

This comment requests supported diagnosis and recovery, not a bypass. It contains no account identifiers, credentials, private URL parameters, local user paths, screenshots, article contents, or raw logs. Only the feedback ID is intentionally disclosed with user authorization. Related public-article report: #34118.

[Browser Use] Owner-authorized WeChat service-account admin blocked; supported API access and recovery path unclear #44451

Description

Summary

Environment

Observed Browser Use denials

Separate feedback-entry limitation

Official integration context

User impact and requested resolution

Privacy and authorization

Activity

github-actions commented on Sep 10, 2026

leixyou commented on Sep 20, 2026

yanzeming0713-creator commented on Sep 21, 2026

licx04030-art commented on Sep 22, 2026

iamtornado commented on Oct 1, 2026

aa18666164709-ux commented on Oct 3, 2026

Observed environment

Actual denial

Independently verified on October 3

Requested supported resolution

xmhuangzhijun-hue commented on Oct 9, 2026

Additional Chrome / Windows report with in-app feedback ID (2026-10-09)

Steps corresponding to the reported failure

Environment captured while preparing this report

Expected behavior and requested investigation

Submitted diagnostic feedback

royal0913 commented on Oct 10, 2026

English: Windows reproduction affecting WeChat Official Accounts and Channels (2026-10-10, UTC+8)

Affected sites and observed paths

Authorization, settings and observations

Actual denial and impact

Requested clarification and supported resolution

Separate Help Center observation

Privacy and scope

补充 Windows 微信公众号与视频号复现（2026-10-10，UTC+8）

lvkangtao-ai commented on Oct 11, 2026

Windows Chrome extension: current reproduction plus working-site controls (2026-10-11)

Follow-up on 2026-10-14: working controls, no claim of policy recovery

liu2791316409-jpg commented on Oct 11, 2026

felipe85082886-code commented on Oct 13, 2026

f4zjwy6j94-star commented on Oct 13, 2026

Additional Windows Chrome extension evidence — 2026-10-13

zhaohaitao329 commented on Oct 15, 2026

Additional macOS Chrome evidence — 2026-10-15 (Asia/Shanghai)

Tim1023 commented on Oct 15, 2026

guozhencode commented on Oct 17, 2026

jinxycandotailwhip commented on Oct 18, 2026

Additional macOS Chrome evidence — 2026-10-18 (Asia/Shanghai)

zhangtianyi163 commented on Oct 19, 2026

Additional Windows Chrome reproduction with submitted in-app feedback (2026-10-19, Asia/Shanghai)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions