Skip to content

Browser Use hardcodes chatgpt.com site_status policy endpoint and breaks/leaks metadata with custom model providers #20614

Closed

Description

@snussik

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

26.429.20946

What subscription do you have?

pro

What platform is your computer?

No response

What issue are you seeing?

Summary

The bundled Codex Desktop Browser Use plugin appears to perform external URL policy checks against a hardcoded OpenAI/ChatGPT endpoint:

https://chatgpt.com/backend-api/aura/site_status

This happens even when Codex is configured with a custom/non-OpenAI model provider. In that configuration, Browser Use attempts to send the target site_url and turn/session identifiers to a third-party endpoint that is not the configured provider. The endpoint returns 403 Forbidden, so Browser Use also fails to open otherwise allowed external URLs.

Environment

  • Product: Codex Desktop app
  • OS: Windows
  • Plugin: browser-use@openai-bundled, 0.1.0-alpha1
  • Model provider: custom provider, not ChatGPT/OpenAI
  • Browser config:
approval_mode = "never_ask"
history_approval_mode = "never_ask"

[origins]
allowed = ["https://*", "http://*"]
denied = []

Observed behavior

When Browser Use tries to navigate to an external URL such as:

https://example.com/

it performs a policy check similar to:

GET https://chatgpt.com/backend-api/aura/site_status
  ?site_url=https://example.com/
  &url_request_source=codex_browser_use
  &conversation_id=<session identifier>
  &turn_id=<turn identifier>

In a custom-provider configuration, this request returns:

HTTP 403 Forbidden

Browser Use then fails closed with an error like:

Browser Use cannot determine if https://example.com is allowed.

What steps can reproduce the bug?

Change OAuth to api with different provider

What is the expected behavior?

Browser Use should not hardcode chatgpt.com as the external URL policy service when Codex is configured with a custom model provider.

Expected alternatives:

  1. Codex host performs the URL policy check and exposes only the result to Browser Use.
  2. Codex host passes a provider-neutral/configured Browser Use policy endpoint to the plugin.
  3. If no policy endpoint is available, Browser Use fails closed with a clear diagnostic and does not send target URLs or turn/session identifiers to an unrelated hardcoded endpoint.

Additional information

Privacy/security concern

In custom-provider deployments, the current behavior creates unexpected egress to chatgpt.com, including:

  • the external URL being opened (site_url);
  • url_request_source;
  • turn/session identifiers when present in runtime metadata.

This is surprising because the configured model provider is not ChatGPT/OpenAI, and local Browser Use origin configuration does not indicate that target URLs and turn identifiers may be sent to chatgpt.com.

Impact:

  • Unexpected third-party egress in custom-provider deployments.
  • Target URLs and turn/session identifiers are sent to a domain that is not the configured model provider.
  • The request currently returns 403 Forbidden in this setup, causing Browser Use to fail closed, but the egress attempt still occurs.
  • Local Browser Use origin allowlist configuration does not make this behavior clear.

Root-cause evidence

The installed bundle contains logic equivalent to:

const policyBase = "https://chatgpt.com/backend-api";
// ...
site_status?site_url=...&url_request_source=codex_browser_use&conversation_id=...&turn_id=...

The plugin package metadata points to:

https://github.com/openai/openai/tree/master/lib/browser_use/plugin

but the installed local plugin contains only the bundled scripts/browser-client.mjs, not the original source files, so users cannot rebuild a provider-neutral patch locally.

Suggested fix

Make the Browser Use URL policy service provider-neutral and host-configured:

Browser Use -> Codex host/provider-neutral policy service -> allow/deny result

Do not silently default to chatgpt.com in custom-provider configurations.

Suggested design:

  • Remove the hardcoded https://chatgpt.com/backend-api default from the Browser Use plugin.
  • Let Codex host pass an explicit policy endpoint, e.g. x-codex-browser-use-policy-endpoint.
  • Keep fail-closed behavior if no endpoint is available.
  • Do not send conversation_id / turn_id to the external policy service unless the host explicitly opts in.
  • Document how [origins].allowed relates to any remote policy check.

Acceptance criteria

  • With standard OpenAI/Codex auth, Browser Use continues to enforce URL policy.
  • With a custom model provider, Browser Use does not send target URLs or turn/session identifiers to chatgpt.com.
  • External navigation either:
    • uses a configured provider-neutral policy endpoint, or
    • fails closed with a clear local diagnostic.
  • localhost, 127.0.0.1, ::1, and file:// behavior remains unchanged.

Activity

  1. added
    appIssues related to the Codex desktop app
    on May 1, 2026
  2. added
    bugSomething isn't working
    custom-modelIssues related to custom model providers (including local models)
    skillsIssues related to skills
    safety-checkIssues related to safety and abuse checks
    on May 1, 2026
  3. github-actions commented on May 1, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  4. Reflyer823 commented on May 8, 2026

    @Reflyer823

    +1,can we turn this check off when using custom model providers ?

  5. self-assigned this
    on May 19, 2026
  6. rafael-oai commented on May 19, 2026

    @rafael-oai
    Contributor

    @snussik, The fail closed is now fail open for site policy checks. Hopefully that change is now visible to you.

    This report looks like Codex generated it and I wonder if the 403 was speculation or actually observed, but I don't see a path that would explain that. If you are using a custom provider, requires_openai_auth should be false and the fetch would not be attempted.

    I'm going to close this for now. Re-open if:

    1. You see the fail-close behavior in a current release (browser-use won't function because it can't reach site_status)
    2. You see evidence that outbound site_status requests are being attempted when you are configured to run with customer provider (and if so, provide sufficient config details so I can attempt to repro).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

appIssues related to the Codex desktop appbrowserbugSomething isn't workingcustom-modelIssues related to custom model providers (including local models)safety-checkIssues related to safety and abuse checksskillsIssues related to skills

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions