Skip to content

Codex Browser Use rejects allowed localhost URL with “user has requested that URL should not be used” #23014

Open

Description

@LucienMidnight

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

26.513.31313 Observed in logs as platform=win32 release=26.513.31313

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 Pro, Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After a Codex update and config changes, Browser Use / in-app browser automation rejects navigation to explicitly allowed URLs, including http://localhost:5173, with:

Browser Use rejected this action due to browser security policy.
Reason: The user has requested that http://localhost:5173 should not be used.

This happens even though:

http://localhost:5173 is reachable from the machine.
Codex Browser settings show nothing blocked.
The URL was re-added as allowed.
C:\Users\Steve.codex\browser\config.toml contains http://localhost:5173 and http://127.0.0.1:5173 in [origins].allowed.
[origins].denied = [].

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows.
  2. Set config to custom/workspace-write with network enabled:
    sandbox_mode = "workspace-write"
    approval_policy = "on-request"

[sandbox_workspace_write]
network_access = true

[windows]
sandbox = "elevated"
3. In the UI, choose Custom (config.toml) permissions.
4. Run a local dev server on http://localhost:5173.
5. Confirm from shell that it works, e.g. Invoke-WebRequest http://localhost:5173 returns HTTP 200.
6. In Browser/Computer Use settings, ensure localhost:5173 is allowed and not blocked.
7. Ask Codex to open or inspect http://localhost:5173 using the in-app browser / Browser Use.
8. Browser Use rejects the navigation with the security policy message above.

What is the expected behavior?

Browser Use should navigate to http://localhost:5173 after the user has allowed it, especially when it is present in the Browser allowed origins config and not present in denied origins.

Additional information

Local config file:
[origins]
allowed = [ "...", "https://localhost", "https://127.0.0.1", "http://127.0.0.1:5173", "http://localhost:5173" ]
denied = []

  • The local app itself is reachable: Invoke-WebRequest http://localhost:5173 returns HTTP 200.
  • A public test site, https://example.com, also produced the same style of rejection earlier.
  • The exact rejection string appears to come from Browser Use origin approval logic, after an access_browser_origin approval request returns something other than accept.
  • There may be stale persisted permission state involved. Local state showed several adjacent Browser/sidebar route conversations with networkAccess: false, while the active chat thread had networkAccess: true.
  • Important distinction: a popup asking to allow node_repl to run tool js is only tool-execution approval; it does not appear to be the Browser Use origin approval for localhost.

Activity

  1. added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    configIssues involving config.toml, config keys, config merging, or config updates
    on May 16, 2026
  2. LucienMidnight commented on May 16, 2026

    @LucienMidnight
    Author

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

    Powered by Codex Action

    Thanks, these look related. #21955 seems especially close: in my case Browser Use connects and the local URL is explicitly allowed, but navigation is still rejected before load with “The user has requested that http://localhost:5173 should not be used.”

    I’m seeing this with the Codex in-app Browser / browser-use flow on http://localhost:5173, not only the Chrome plugin. My local browser config has denied = [] and includes both http://localhost:5173 and http://127.0.0.1:5173 in [origins].allowed. The local server returns HTTP 200.

    Local state also showed adjacent Browser/sidebar route conversations with sandboxPolicy.networkAccess: false, while the active chat thread had networkAccess: true, so #21955’s persisted networkAccess theory fits my symptoms.

  3. DaiHasegawa commented on Sep 8, 2026

    @DaiHasegawa

    I can reproduce a closely matching failure on macOS with Codex Desktop's in-app Browser.

    Environment

    • macOS, Codex Desktop app, in-app Browser.
    • In Settings > Browser, 127.0.0.1 was explicitly allowed. This field accepts a host, not a path or wildcard.
    • In a separate isolation step, the full URL http://127.0.0.1:3100/sign-up loaded successfully.

    Server health

    • A temporary local fixture was started reliably with PNPM_CONFIG_OFFLINE=true.
    • Port 3100 was listening.
    • Both the fixture API and fixture page returned HTTP 200, and the server log recorded HTTP 200 for both GET requests.

    Rejected operation

    While that server was still healthy, reloading the existing in-app Browser tab was rejected with:

    Browser Use rejected this action due to browser security policy.
    Reason: The browser URL policy blocks this action.
    

    I did not retry through another browser, Playwright CLI, or raw CDP. The temporary fixture was removed afterward and port 3100 was stopped.

    Expected result

    Reloading an existing 127.0.0.1 page should be allowed when that host is allowed in Settings > Browser, especially when navigation to the same full URL had already succeeded.

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 workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions