Browser Use false-positive site_status_blocked for www.avito.ru

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.51511 (CFBundleVersion 7377)

What subscription do you have?

ChatGPT subscription (exact tier is not shown in the Codex App)

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Codex Browser Use incorrectly blocks https://www.avito.ru/profile/extended with site_status_blocked, although the site and the requested page are reachable and the user has explicitly allowed the origin.

Full 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 is not permitted on https://www.avito.ru/profile/extended.

The failure happens before any page interaction. Restarting the desktop app, reconnecting the browser extension, explicitly allowlisting the origin, and enabling full CDP access do not change the result.

Direct read-only HTTP checks return HTTP 200 for both the Avito home page and the profile URL, with no redirect from the profile URL. This appears to be a false positive in the OpenAI site-status classifier rather than a block by Avito.

What steps can reproduce the bug?

1. Connect the Codex desktop app to Chrome through the Browser extension.
2. Enable full CDP access.
3. Explicitly allow https://www.avito.ru for normal origin access and full CDP.
4. Open a signed-in Avito tab.
5. Attempt read-only DOM inspection or navigation to https://www.avito.ru/profile/extended.

Result: Browser Use stops with site_status_blocked before inspecting the page. No user permission prompt or Auto-review is attempted.

Configuration:

• approval_mode = "never_ask"
• full_cdp_access_enabled = true
• https://www.avito.ru explicitly allowed

This was reproduced after a full Codex restart. Session ID and token/context usage are not applicable because the block occurs at the browser policy gate before page interaction.

What is the expected behavior?

Browser Use should honor the explicit user permission and allow read-only navigation and DOM inspection on the user's own signed-in Avito account.

At minimum, a user confirmation or Auto-review path should be offered instead of an unconditional site_status_blocked denial when the origin is reachable and explicitly allowlisted.

Additional information

Environment:

• Codex Desktop for macOS: 26.825.51511 (CFBundleVersion 7377)
• Codex CLI: 0.151.0-alpha.7.2
• Browser/Chrome plugin: 26.825.51511
• Platform: Darwin 24.6.0 arm64 arm

The first private Avito Browser Use attempt was blocked before the first successful read-only Avito API check, so the API integration did not cause the classification.

The requested action is read-only inspection of the user's own Avito Pro cabinet. It does not involve publishing or editing listings, messaging, payments, uploads, or account-setting changes. No account screenshots or private account data are attached.

Start by reproducing the Browser Use flow and tracing the site-safety policy gate that emits site_status_blocked; the issue does not name a source file or test. Done means an explicitly allowlisted, reachable Avito URL can proceed to read-only navigation or DOM inspection, or reaches a user confirmation or Auto-review path instead of unconditional denial.