You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Windows Browser Use blocks m.blog.naver.com without an actionable review path; agent selects iab despite requested Aside CLI #54886
Codex on Windows used the built-in browser (iab) although the user explicitly requested the installed Aside browser CLI. Opening a Naver Blog post was then blocked by the Browser Use site-safety gate, with no user approval prompt and no actionable explanation of the classification.
Please review whether this is an incorrect site-safety classification and improve the tool selection / recovery messaging. This report does not request disabling or bypassing the safety gate.
Environment
Windows desktop app
App version reported in local configuration: 26.1013.40934
Aside CLI installed and executable: 1.26.1008.1938
Observed steps
User requested reading a Naver Blog post using Aside.
Agent instead called cua.createBrowserTab("iab", "https://m.blog.naver.com/<blog>/<post>", {visible:true}).
Browser Use rejected the call before any permission prompt.
A later retry using the same built-in browser was rejected again.
Agent explained that alternative execution was also prohibited; the requested reading task remained incomplete.
Exact tool 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. Browser use could not acquire authority to observe page content. The site safety gate did not grant access for https://m.blog.naver.com. Site safety policy blocked this URL. 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.
Expected behavior
Select the user-requested browser integration when available, or explain its unavailability before selecting another browser.
If the site must be blocked, provide an actionable supported review/reporting path.
Investigate the classification for m.blog.naver.com; the tool response does not disclose the specific reason, so a false positive is suspected but unconfirmed.
Evidence and privacy
The reporter's assistant inspected the retained local session and confirmed the tool calls/error above. No screenshots were collected; the literal call/error are the available evidence. Account identifiers, local paths, full post URL, conversation ID, credentials, and unrelated session content have intentionally been omitted from this public report.
Additional occurrence on 2026-10-20: an explicitly authorized edit to an existing, user-owned Naver Blog post was stopped while opening its mobile page for a readability check.
Environment: Windows desktop app; installed Windows package OpenAI.Codex 26.1013.4894.0.
This occurrence does not involve an Aside selection request. The planned edit was only to add one blank line between paragraphs and move an existing answer-link block above the references. The browser call to https://m.blog.naver.com/<blog>/<post> was rejected before page observation. No content was observed and no post edit, save, publish, or clipboard operation occurred in this attempt.
The returned error explicitly stated:
The site-safety policy blocks this action; no user permission prompt or Auto-review was attempted.
The site safety gate did not grant access for https://m.blog.naver.com.
It also expressly prohibited achieving the same outcome through alternate browser surfaces or other workarounds. We complied and did not retry through another URL or browser.
The user asked us to contact OpenAI and request prompt review and restoration if this is a false positive. We submitted the details to the official Help Center support chat. Its AI initially recommended switching browser/URL, which conflicts with the explicit tool refusal. After we pointed out the conflict and requested a human, it stated that human escalation and a human-ticket number were unavailable in that chat and referred us to Codex feedback / this issue tracker.
Please have the responsible team review the classification and provide a supported recovery or appeal path. If the denial is intentional, please explain the applicable reason and what action, if any, the user can take. The current “stop and request user input” wording offers no actionable input or approval step, leaving a routine authorized workflow blocked.
Email, full blog/post URL, conversation ID, account details, and local paths are omitted from this public follow-up.
Activity
github-actions commentedon Oct 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jihyun0715-debug commentedon Oct 20, 2026
Additional occurrence on 2026-10-20: an explicitly authorized edit to an existing, user-owned Naver Blog post was stopped while opening its mobile page for a readability check.
Environment: Windows desktop app; installed Windows package
OpenAI.Codex 26.1013.4894.0.This occurrence does not involve an Aside selection request. The planned edit was only to add one blank line between paragraphs and move an existing answer-link block above the references. The browser call to
https://m.blog.naver.com/<blog>/<post>was rejected before page observation. No content was observed and no post edit, save, publish, or clipboard operation occurred in this attempt.The returned error explicitly stated:
It also expressly prohibited achieving the same outcome through alternate browser surfaces or other workarounds. We complied and did not retry through another URL or browser.
The user asked us to contact OpenAI and request prompt review and restoration if this is a false positive. We submitted the details to the official Help Center support chat. Its AI initially recommended switching browser/URL, which conflicts with the explicit tool refusal. After we pointed out the conflict and requested a human, it stated that human escalation and a human-ticket number were unavailable in that chat and referred us to Codex feedback / this issue tracker.
Please have the responsible team review the classification and provide a supported recovery or appeal path. If the denial is intentional, please explain the applicable reason and what action, if any, the user can take. The current “stop and request user input” wording offers no actionable input or approval step, leaving a routine authorized workflow blocked.
Email, full blog/post URL, conversation ID, account details, and local paths are omitted from this public follow-up.