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

[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.

[github-actions]

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

• Codex App of Windows: Custom "Never ask" mode breaks Chrome origin approval flow and incorrectly persists new sites as denied #22019
• Codex Desktop Windows: Chrome plugin connects but navigation blocked because thread networkAccess persists as false #21955

Powered by Codex Action

[LucienMidnight]

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

• Codex App of Windows: Custom "Never ask" mode breaks Chrome origin approval flow and incorrectly persists new sites as denied #22019
• Codex Desktop Windows: Chrome plugin connects but navigation blocked because thread networkAccess persists as false #21955

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.