Repository navigation
[Bug] Chrome Browser Use blocks DOM reads for explicitly allowed WeCom documentation URLs #34006
Description
Codex version
Codex Desktop on macOS.
Browser/Chrome plugin runtime build observed during reproduction: 26.715.31925.
Subscription
Not relevant to the reproduction.
Platform
macOS with the Codex Desktop app and the bundled Chrome Browser Use integration.
What issue are you seeing?
Codex Browser Use cannot read the DOM of two public WeCom documentation pages, even though both origins are explicitly configured as Allow browsing.
Affected URLs:
- https://open.work.weixin.qq.com/help2/pc/21661
- https://developer.work.weixin.qq.com/document/path/101463
The pages open and render normally in Chrome.
Browser Use can:
- Discover both existing Chrome tabs
- Claim both tabs
- Read each tab's URL
- Read each tab's title
However, calling playwright.domSnapshot() for either page fails with:
Browser Use rejected this action due to browser security policy.
Reason: Browser use is not permitted on <URL>.
The rejection occurs in the URL-policy checks before DOM access:
throwIfBlocksUrl
→ ensureUrlPolicyAllowed
→ ensureUrlOriginAllowed
→ ensureCurrentTabOriginAllowed
→ ensureCommandAllowed
→ domSnapshot
Both origins are configured under:
Settings → Computer Use → Google Chrome → Website permissions
They are set to Allow browsing.
The global website approval setting is Always allow, full CDP access is enabled, and the Codex app has been fully restarted. The result remains unchanged.
Steps to reproduce
- In Codex Desktop, enable the bundled Chrome Browser Use integration.
- Under Google Chrome website permissions, add the following origins as Allow browsing:
https://open.work.weixin.qq.comhttps://developer.work.weixin.qq.com
- Enable full CDP access.
- Fully restart Codex.
- Open these pages in Chrome:
https://open.work.weixin.qq.com/help2/pc/21661https://developer.work.weixin.qq.com/document/path/101463
- Ask Codex to claim the existing tabs and read their DOM.
- Observe that tab discovery, claiming, URL reads, and title reads succeed.
- Observe that
playwright.domSnapshot()is rejected by Browser Use URL policy for both pages.
Expected behavior
Because both public origins are explicitly set to Allow browsing, Browser Use should permit read-only DOM access to these pages.
At minimum, the allowlist should be applied consistently to read-only DOM operations after tab discovery and tab claiming have succeeded.
Actual behavior
Browser Use rejects the DOM command before accessing the page, stating that Browser Use is not permitted on the URL.
This appears to be either:
- A Browser Use safety-policy false positive, or
- An allowlist propagation/origin-matching issue affecting DOM commands.
No form submission, page modification, file upload, authentication, or sensitive-data access is involved. The requested action is read-only access to public documentation.
Activity
github-actions commentedon Jul 18, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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 WeCom docs.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.