›_ Codex Issues
Codex Issues / #24559

Browser Use blocks localhost on Windows despite local service being reachable

Open 💬 4 comments Opened May 26, 2026 by yangfengfan2011
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Browser Use / Chrome extension rejects navigation to a local development URL on Windows with an enterprise network policy error, even though the same URL is reachable from Chrome manually and from the Codex command channel.

Environment

  • OS: Microsoft Windows 11 Pro, version 10.0.26200, build 26200, 64-bit
  • Codex Chrome Extension: 1.1.5, Manifest V3
  • Browser backend: Chrome extension
  • Local URL: http://localhost:8021/
  • Local server: Microsoft IIS 10.0 / ASP.NET site

Expected behavior

Browser Use should be able to open explicit local development URLs such as:

  • http://localhost:<port>
  • http://127.0.0.1:<port>
  • http://[::1]:<port>

or provide a clear allowlist/configuration path for enabling local development URLs.

Actual behavior

Browser Use rejects navigation before loading the page:

Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access http://localhost:8021 because enterprise network policy blocks it. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention.

Diagnostics

Local command channel can access the service:

curl.exe -I http://localhost:8021
HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
Content-Type: text/html; charset=utf-8
curl.exe -I http://127.0.0.1:8021
HTTP/1.1 200 OK
Server: Microsoft-IIS/10.0
Content-Type: text/html; charset=utf-8
Test-NetConnection 127.0.0.1 -Port 8021
TcpTestSucceeded : True

Browser extension connectivity partially works:

  • agent.browsers.list() succeeds and reports a Chrome extension backend.
  • agent.browsers.get("extension") succeeds.
  • browser.user.openTabs() succeeds and can see the manually opened http://localhost:8021/ tab.
  • browser.tabs.new() succeeds and creates a controlled about:blank tab.
  • tab.goto("http://localhost:8021/") fails with the enterprise network policy error above.

This suggests the issue is not the local web server, IIS binding, port availability, or manual Chrome access. The failure appears to happen in Browser Use policy preflight for local/private-network URLs.

Additional observation

The installed Codex Chrome extension package is version 1.1.5. Its background.js includes a reference to:

chrome.runtime.getVersion()

Chrome's standard API exposes the extension version through:

chrome.runtime.getManifest().version

In this case the extension backend is still visible and partially functional, so this may be a separate issue from the localhost policy rejection, but it may be relevant to Windows extension/backend reliability.

Impact

This prevents Codex from verifying and debugging local web applications on Windows, including IIS / ASP.NET / frontend local development workflows.

Request

Please consider one of the following:

  1. Allow explicit localhost / loopback development URLs by default in Browser Use.
  2. Provide a Browser Use allowlist setting for local URLs.
  3. Show which policy/configuration blocks the URL and how to override it safely.
  4. Ensure Codex Desktop / Browser Use honors local sandbox/network settings consistently.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #24074

Powered by Codex Action

Yemvis · 2 months ago

I can reproduce this on a newer Windows Store Codex build, including after adding explicit local allowlists.

Environment

  • OS: Windows x64
  • Codex install source: Microsoft Store
  • Codex package: 9PLM9XGG6VKS
  • Codex app version: 26.527.7698.0
  • Browser plugin used by the session: browser@openai-bundled / 26.527.31326
  • Node REPL env includes: BROWSER_USE_AVAILABLE_BACKENDS = "chrome,iab"
  • Local dev URL: http://localhost:5173/ / http://127.0.0.1:5173/

What happens

The in-app browser tab exists and is visible to Browser Use at the tab-list level:

[
  {
    "url": "http://localhost:5173/",
    "title": "Financas Codex"
  }
]

But any operation that actually accesses the page origin fails, including reading URL/title/screenshot from the already-open tab:

Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access http://localhost:5173 because enterprise network policy blocks it. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention.

I also saw the same class of rejection for:

  • http://127.0.0.1:5173
  • https://pagamentos-seven.vercel.app

Config/allowlist attempts that did not fix it

Browser session origin allowlist was updated in <CODEX_HOME>/browser/sessions/<session>.toml:

[origins]
allowed = [
  "http://localhost:5173",
  "http://127.0.0.1:5173",
  "https://pagamentos-seven.vercel.app",
]

Main Codex config was also updated with a narrow network permission set:

default_permissions = "local_dev"

[permissions.local_dev.network]
enabled = true
allowed_domains = [
  "localhost",
  "127.0.0.1",
  "pagamentos-seven.vercel.app",
]

After those changes, Browser Use still reports the same enterprise network policy blocks it error.

Why this looks like a policy-layer bug

The Browser client code appears to separate Browser persisted origin approvals from the Codex network policy check. The denial is reported as codex-network-policy, so the user-visible Browser origin allowlist does not override it.

Impact: this makes the Browser plugin unusable for local app QA on Windows. It can see that a localhost tab exists, but cannot inspect or screenshot the page, and the policy message explicitly forbids falling back to Playwright/Chrome/alternate browser surfaces.

goodneamtakenbydogs · 2 months ago

Adding a possibly related diagnostic angle for the localhost case.

On another Windows machine, Browser access to a local 127.0.0.1:<port> URL surfaced as an enterprise policy-style block, but the underlying failure was that Browser policy/config reads could not complete because Codex app-server was trying to start from a stale configured codex.exe path.

So for localhost failures like this, it may be worth checking whether the configured CLI paths still exist, especially CODEX_CLI_PATH and chrome-native-hosts-v2.json paths.codexCliPath. I separated the focused missing-path / misleading-error case into #28474.

kutayilmaaz · 2 months ago

I can reproduce the same class of issue on Windows with a newer Codex App build.

Environment:

  • OS: Windows 11 Version 25H2, Build 26200.8655
  • Codex App / Browser Use build observed in runtime env: 26.616.51431
  • Google Chrome: 149.0.7827.155 official 64-bit
  • Chrome policies: chrome://policy shows no Chrome or extension install policies
  • Browser backend: Chrome extension via chrome@openai-bundled
  • Local URL: http://localhost:5173/

What works:

  • The local app is reachable from Windows: http://localhost:5173/ returns 200
  • The local API health endpoint is reachable: http://localhost:18080/healthz returns 200
  • The same URL can be opened manually in Chrome
  • Browser Use can connect to the Chrome extension backend
  • browser.user.openTabs() works
  • browser.tabs.new() works
  • tab.goto("about:blank") works

What fails:

  • tab.goto("http://localhost:5173/") fails before page load with:
Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access http://localhost:5173 because enterprise network policy blocks it. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

Stack source observed:

ensureUrlOriginAllowed
ensureCommandAllowed
Ba.goto

Additional diagnostics:

  • After initializing the Chrome Browser Use runtime, Object.keys(nodeRepl).sort() only includes:
["cwd", "emitImage", "env", "homeDir", "requestMeta", "setResponseMeta", "tmpDir", "write"]
  • nodeRepl.config is absent
  • nodeRepl.fetch is absent
  • Creating C:\Users\<user>\.codex\browser\sessions\<threadId>.toml with both origins.allowed and full_cdp.allowed entries for http://localhost:5173, http://127.0.0.1:5173, http://localhost:3101, and http://127.0.0.1:3101 did not change the result
  • Adding a narrow [permissions.local-dev.network.domains] allowlist for localhost, 127.0.0.1, and ::1 in config.toml also did not change the result
  • Restarting Codex App did not change the result

This looks like Browser Use policy preflight is treating localhost as blocked before the Chrome navigation command reaches the browser. It does not appear to be a Chrome enterprise policy, local server issue, profile mismatch, or extension connectivity failure.