Skip to content

Browser-use blocks an explicitly authorized, user-owned Naver Blog page #43241

Open
Open
Browser-use blocks an explicitly authorized, user-owned Naver Blog page#43241
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't working

Description

@meddigi
meddigi
opened on Sep 6, 2026

Summary

In the Codex desktop app on Windows, browser-use refused to inspect a public Naver Blog post that was already open in the right-side browser, even after the user explicitly authorized access and stated that they own the blog and its content.

Target URL:
https://m.blog.naver.com/jimin2mam/224396560040?referrerCode=1

Steps to reproduce

  1. Open the public Naver Blog post in Codex's right-side in-app browser (the same page was also open in Chrome).
  2. Ask Codex to read the post text and original images in order to create a promotional YouTube Short.
  3. Explicitly confirm that the user owns the blog/content and authorizes its use.
  4. Attempt to inspect the page with browser-use.

Actual behavior

The browser tool returned:

Browser use is not permitted on https://m.blog.naver.com/jimin2mam/224396560040

It also instructed the agent not to obtain the same content through another browser surface, CDP, Playwright, screenshots, or other workarounds. The agent complied and did not bypass the restriction.

Expected behavior

Codex should be able to inspect the text and images of a public page that the user has opened and explicitly authorized, or provide a clear, actionable explanation identifying whether the denial comes from a site permission, organization policy, or safety classification.

Additional checks

  • Chrome DevTools MCP 1.8.0 initialized successfully and returned its tool list; this did not change the denial.
  • Any custom URL-specific block rule added during troubleshooting was removed.
  • No article body text or original images were obtained after the refusal.
  • No passwords, cookies, authentication tokens, phone numbers, or full session logs are included in this report.

Request

Please review whether this is a false-positive site-safety denial and document a supported way to restore access without broadly disabling security controls.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    browser
    on Sep 6, 2026

  2. github-actions commented on Sep 6, 2026

    @github-actions
    github-actionsBot
    on Sep 6, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. leixyou commented on Sep 20, 2026

    @leixyou
    leixyou
    on Sep 20, 2026

    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 Naver Blog.

    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.

  4. smartkimji-beep commented on Oct 15, 2026

    @smartkimji-beep
    smartkimji-beep
    on Oct 15, 2026

    Additional macOS reproduction — requesting a site-safety review

    Submitting at the affected user's explicit request. This appears to match this issue, but the underlying classification cause is not known.

    Environment

    • macOS 26.5.2, Apple silicon (arm64), local Codex task in the ChatGPT desktop app, using the built-in browser.
    • Installed app bundle at report preparation: 26.1007.71326 (build 20398), bundle ID com.openai.codex.
    • An earlier diagnosis recorded 26.1007.30912 (build 20156). The exact running build at the latest failed request was not captured, so these version observations should not be treated as proof of a regression between builds.
    • Observations/recheck: October 15–16, 2026, Asia/Seoul.

    Primary failure
    Opening an affected public mobile Naver Blog post through the normal browser tool returned:

    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://m.blog.naver.com/[blog-id]/[post-id].

    The bracketed blog/post identifiers above are redacted. This is the exact error wording apart from that URL redaction. The tool also instructed the agent not to circumvent the restriction. No article body or images were obtained from this failed request.

    Checks already completed

    1. The user reports that browsing was already set to Always allow; downloading was Requires approval. They changed the displayed permissions to Always allow. A subsequent direct request to the same original post through the same built-in browser still returned the primary error above. Per-domain exceptions and all effective managed policies were not independently verified.
    2. A control test on a Google official blog post successfully read its article text and visually inspected loaded product imagery. This establishes that browser reading is not universally broken; it does not establish Naver accessibility.
    3. Selected approval/browser keys in the local user configuration did not reveal an explicit deny setting. Checked project/system requirements-file locations were absent. This was a limited local check, not a complete effective-policy audit.
    4. The user reports that earlier blog editing/uploading had worked. Historical logs first show the explicit site-safety denial during a later navigation to a mobile Naver post. This does not establish why the policy outcome differed.

    Separate observations, not established causes

    • An earlier attempt to open another Naver post was rejected by Auto-review as circumvention of the existing restriction. The subsequent direct original-post recheck instead failed at site safety, before Auto-review.
    • Trying to inspect the Codex app's settings through Computer Use returned: "Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons." Therefore the permission state above is explicitly attributed to the user's report.
    • Browser runtime output also contained Statsig/telemetry HTTP 403 errors for OpenAI-related telemetry requests, including during the successful Google control test. These were not HTTP responses from Naver, and their causal relationship to the site-safety denial is unknown. Request query strings and full traces are omitted.

    Requested review
    Please determine whether the Naver URL/origin is receiving an incorrect site-safety classification, or identify the applicable policy layer and supported remediation. Please clarify why ordinary site permission is insufficient here and how an authorized user can request a classification review without disabling safety protections. If more diagnostics are needed, please specify the minimum required fields and a private submission channel.

    This report intentionally excludes the personal blog path, account email, session transcript, credentials, cookies, local file paths, and full logs. No bypass mechanism is requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions