Windows Codex App: Browser Use blocked by enterprise network policy even for example.com

I have meet this issue exactly recently. I have done the reboot chrome and codex, neither worked. At final i tried remove the chrome extension, re install, and reboot all and seems work now

Same! It used to work but not nowadays!

I can reproduce the same issue on a personal Windows PC as well. This is not an enterprise-managed machine.

Codex Browser and the Chrome plugin are both blocked by the same Browser Use enterprise network policy. The Chrome plugin itself connects successfully to my Chrome profile, but every navigation attempt is rejected.

Observed behavior:

Browser Use rejected this action due to browser security policy.
Reason: Browser Use cannot access https://example.com because enterprise network policy blocks it.

This happens for both public sites and localhost:

https://example.com
https://www.openai.com
http://127.0.0.1:4192
http://localhost:4192

Localhost itself is healthy. PowerShell can access the local server and returns HTTP 200:

http://127.0.0.1:4192/public/admin/index.html

I tried all of the following configuration changes and fully restarted Codex after applying them.

C:\ProgramData\OpenAI\Codex\requirements.toml:

[experimental_network]
enabled = true
allow_local_binding = true
allowed_domains = [localhost, 127.0.0.1]

C:\Users\<user>\.codex\config.toml:

[experimental_network]
enabled = true
allow_local_binding = true
allowed_domains = [localhost, 127.0.0.1]

[sandbox_workspace_write]
network_access = true

I also have localhost origins allowlisted in C:\Users\<user>\.codex\browser\config.toml:

[origins]
allowed = [
  http://localhost,
  http://127.0.0.1,
  http://localhost:4192,
  http://127.0.0.1:4192,
  https://localhost,
  https://127.0.0.1
]
denied = []

After restart, the current session context shows network access enabled and allowed for 127.0.0.1, localhost, but Browser Use still blocks both public URLs and localhost with the same enterprise network policy error.

This looks like Browser Use is not reading the configured network allowlist, or a higher-priority persisted/thread-level policy is overriding it. It also affects the Chrome plugin, not just the in-app Browser.

Additional update after more testing:

After reinstalling/restarting and switching Browser config from approval_mode = never_ask to approval_mode = ask, the Chrome backend is discoverable again and connects successfully.

Chrome plugin diagnostics all pass:

• Chrome is running
• Codex Chrome Extension is installed and enabled
• Extension version: 1.1.5_0
• Native host manifest is correct
• Registry path is correct
• The expected allowed origin is present: chrome-extension://hehggadaopoacecdllhhajmbjkdcmajg/

Codex can connect to the Chrome backend:

browser: Chrome
type: extension
profile: my Chrome profile
connected: true

However, navigation is still blocked for every tested URL:

https://example.com
http://127.0.0.1:4192/public/admin/index.html#dashboard
http://localhost:4192/public/admin/index.html#dashboard

All fail with the same error:

Browser Use rejected this action due to browser security policy.
Reason: Browser Use cannot access <url> because enterprise network policy blocks it.

So at this point the issue does not appear to be Chrome extension installation, native host setup, or localhost reachability. The extension/backend is working, but Browser Use's policy gate is still denying all navigation, including public websites.

My Codex app version is:

OpenAI.Codex 26.519.11010.0

me too

Follow-up after updating to the new Codex Desktop release from yesterday: this is still not resolved on my Windows machine.

Current status after the update:

• Chrome backend is still discoverable and connects successfully.
• Chrome extension diagnostics still pass.
• The machine is still a personal Windows PC, not an enterprise-managed device.
• Browser navigation is still blocked with the same Browser Use security / enterprise network policy error.
• The block still applies even to public URLs and localhost / 127.0.0.1.

I also found a closely related issue: #21955, where Chrome connects but navigation is blocked because network_access persists as false. That sounds very close to this failure mode. If this policy check is reading the thread sandbox network flag, it may be incorrectly blocking Browser Use navigation even when the browser backend itself is healthy.

Additional current reproducer on Windows Store Codex, matching this issue.

Environment:

• Codex Windows app package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Codex Chrome extension popup shows Connected
• Extension version shown in popup: 1.1.5
• Local Chrome plugin cache: openai-bundled/chrome/26.527.60818
• Chrome plugin runtime can connect well enough to list existing Chrome tabs/profiles
• This is a personal/local PC, not an enterprise-managed Codex workspace

Observed behavior:

• Attempting Browser Use navigation to https://example.com/ is rejected with the same class of error:

Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access https://example.com 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.

• Attempting Browser Use navigation to https://www.linkedin.com/ also fails with the same enterprise-network-policy error.
• Adding the sites to the local Browser Use origin allowlist did not change behavior. The local config contained:

[origins]
allowed = [ https://linkedin.com, https://www.linkedin.com ]
denied = []

• A temporary test of a local config.toml permission profile with network enabled = true and allowed_domains = [ linkedin.com, www.linkedin.com ] also did not change the Browser Use rejection, so the effective policy appears to be enforced upstream of the user-editable origin/domain allowlist.

Expected behavior:

For a personal Windows install, Browser Use should either allow ordinary user-requested destinations such as https://example.com/, or the error/UI should expose the concrete policy source and remediation path. The current message says “enterprise network policy” but no enterprise/admin surface exists for this local install.

Is there any available solution to the above issue at present?

My problem seems to have been resolved today after I upgraded the Codex app. 🤔

Same here!

Adding one possible related root cause to check for the enterprise-policy symptom.

In a separate Windows repro, the visible Browser error was also about enterprise network policy, but the underlying failure was not an actual policy deny. The configured Codex CLI path had gone stale after an update, so Browser policy/config reads failed when Codex app-server tried to start from a missing codex.exe path.

It may be worth checking whether CODEX_CLI_PATH or chrome-native-hosts-v2.json paths.codexCliPath points to a missing hash directory on affected machines. I filed the focused path/error-mapping case here: #28474

Adding one possible related root cause to check for the enterprise-policy symptom. In a separate Windows repro, the visible Browser error was also about enterprise network policy, but the underlying failure was not an actual policy deny. The configured Codex CLI path had gone stale after an update, so Browser policy/config reads failed when Codex app-server tried to start from a missing codex.exe path. It may be worth checking whether CODEX_CLI_PATH or chrome-native-hosts-v2.json paths.codexCliPath points to a missing hash directory on affected machines. I filed the focused path/error-mapping case here: #28474

This (finally) solved it for me - thank you! I had a CODEX_CLI_PATH that didn't exist

I’m seeing the same failure on a personal ChatGPT Plus account, on a newer Windows Codex build than the original report.

Environment:

• Codex Windows App package: OpenAI.Codex_26.611.8273.0_x64__2p2nqsd0c76g0
• Codex app/browser plugin metadata reports Browser Use version 26.611.61753
• Codex CLI: codex-cli 0.128.0
• Plan: personal ChatGPT Plus, not Business/Enterprise
• Platform: Windows x64 / Microsoft Store Codex app

Observed behavior:

• Browser Use connects successfully through the bundled Browser plugin.
• browser-client.mjs exists and loads successfully.
• agent.browsers.list() shows both Chrome extension and Codex in-app browser backends.
• Creating a tab works, but navigation through Browser Use is rejected before the page loads.

Exact error when navigating to https://jobspidey.com/login:

Browser Use rejected this action due to browser security policy. Reason: Browser Use cannot access https://jobspidey.com 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.

Earlier reproduction also failed for https://example.com/ with the same enterprise network policy blocks it wording.

Local checks:

• codex features list shows browser_use = true and in_app_browser = true.
• C:\Users\ravik\.codex\browser\config.toml explicitly allows both https://jobspidey.com and https://www.jobspidey.com.
• No local managed config files exist at:
• C:\ProgramData\OpenAI\Codex\requirements.toml
• C:\ProgramData\OpenAI\Codex\managed_config.toml
• Shell network access works outside Browser Use.

One unrelated config hygiene issue was found and fixed: service_tier = "default" was changed to service_tier = "flex", after which codex features list parses normally. The Browser Use policy block still reproduces after restart.

Current session metadata from the Browser backend:

codexAppSessionId: 02cbe7b3-00e0-4e76-83cc-398c6955717c
codexSessionId: 019ed52e-38c6-7222-987d-97e31d355e6c

This looks like the same Windows Browser Use policy false-positive as this issue, still reproducible in build 26.611.8273.0.

I finally resolved this, but the key first step was manually removing the Browser plugin from Codex Settings.

We had spent several days investigating the misleading enterprise network policy blocks it error without success. I eventually opened Settings > Browser and manually removed the Browser plugin.

After removing it, Codex displayed Integrated browser plugin unavailable, but it did not provide any option to reinstall it.

We then discovered that the official Browser plugin was still bundled inside the Windows Codex package, but the openai-bundled marketplace was missing from codex plugin list.

We registered the bundled marketplace:

$codex = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
-Recurse -Filter codex.exe |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1

$pkg = (Get-AppxPackage OpenAI.Codex).InstallLocation
$marketplace = Join-Path $pkg "app\resources\plugins\openai-bundled"

& $codex.FullName plugin marketplace add $marketplace --json

Then we reinstalled Browser officially:

& $codex.FullName plugin add browser@openai-bundled --json

Verification:

& $codex.FullName plugin list

This reported:

browser@openai-bundled installed, enabled

We also found a stale user-level CODEX_CLI_PATH pointing to an old npm installation, so we corrected it:

[Environment]::SetEnvironmentVariable(
"CODEX_CLI_PATH",
$codex.FullName,
"User"
)

During troubleshooting, the first reinstall attempt produced Access denied (os error 5) because a manually restored Browser cache and its latest junction already existed. We backed up and cleared only that stale Browser cache, then repeated the official installation successfully.

After reopening Codex, Browser appeared again in Settings. Browser Use could navigate to public websites and Zapier, and the previous enterprise network policy error disappeared.

In short, the effective sequence was:

1. Manually remove the broken Browser plugin from Settings.

1. Register the missing openai-bundled marketplace.

1. Reinstall Browser using codex plugin add.

1. Correct any stale CODEX_CLI_PATH.

1. Restart Codex and verify Browser Use.

I finally resolved this, but the key first step was manually removing the Browser plugin from Codex Settings.

We had spent several days investigating the misleading enterprise network policy blocks it error without success. I eventually opened Settings > Browser and manually removed the Browser plugin.

After removing it, Codex displayed Integrated browser plugin unavailable, but it did not provide any option to reinstall it.

We then discovered that the official Browser plugin was still bundled inside the Windows Codex package, but the openai-bundled marketplace was missing from codex plugin list.

We registered the bundled marketplace:

$codex = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin" `
  -Recurse -Filter codex.exe |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

$pkg = (Get-AppxPackage OpenAI.Codex).InstallLocation
$marketplace = Join-Path $pkg "app\resources\plugins\openai-bundled"

& $codex.FullName plugin marketplace add $marketplace --json

Then we reinstalled Browser officially:

& $codex.FullName plugin add browser@openai-bundled --json

Verification:

& $codex.FullName plugin list

This reported:

browser@openai-bundled  installed, enabled

We also found a stale user-level CODEX_CLI_PATH pointing to an old npm installation, so we corrected it:

[Environment]::SetEnvironmentVariable(
  "CODEX_CLI_PATH",
  $codex.FullName,
  "User"
)

During troubleshooting, the first reinstall attempt produced:

Access denied (os error 5)

This happened because a manually restored Browser cache and its latest junction already existed. We backed up and cleared only that stale Browser cache, then repeated the official installation successfully.

After reopening Codex, Browser appeared again in Settings. Browser Use could navigate to public websites and Zapier, and the previous enterprise network policy error disappeared.

In short, the effective sequence was:

1. Manually remove the broken Browser plugin from Settings.
2. Register the missing openai-bundled marketplace.
3. Reinstall Browser using codex plugin add.
4. Correct any stale CODEX_CLI_PATH.
5. Restart Codex and verify Browser Use.

I can reproduce this on a personal ChatGPT Plus account with a newer Windows
Codex build.

Environment

• Codex Windows app package: OpenAI.Codex_26.623.11225.0
• Bundled Chrome plugin: 26.623.81905
• Codex Chrome extension: 1.1.5
• Platform: Windows x64, Microsoft Store Codex app
• Account: personal ChatGPT Plus, not Business/Enterprise

Observed behavior

• The Chrome extension backend connects successfully.
• Codex sees the requested Chrome profile and can list its existing tabs.
• The thread's effective sandbox state reports networkAccess: true.
• Command networking to https://example.com/ succeeds with HTTP 200.
• Browser Use nevertheless rejects both https://example.com/ and a LinkedIn

job-search URL before reading the page:

Browser Use cannot access <url> because enterprise network policy blocks it.

No enterprise requirements file or Chrome enterprise domain policy is present.

New diagnostic evidence

Both the process-level and user-level CODEX_CLI_PATH point to:

C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

That path does not exist. This matches the stale-path failure described in
#28474 and strongly suggests that a Codex app update left CODEX_CLI_PATH
pointing to a removed installation. A failed effective-config read is then
surfaced as the misleading enterprise-network-policy denial.

There is also a confusing UI-state symptom: after configuring
approvals_reviewer = "auto_review" and restarting, the materialized thread
state reports approvalsReviewer: "auto_review", but the composer selector
continues to display workspace-network. The UI does not reveal the active
reviewer separately, making it appear that Auto-review was discarded.

Expected behavior

• App updates should refresh or remove stale CODEX_CLI_PATH values.
• Browser Use should report the underlying config/runtime-path failure instead

of labeling it an enterprise policy.

• The composer should expose the active approval reviewer independently from

the filesystem/network permission profile.

I am seeing the same issue on Codex Desktop for Windows.

Codex In-app Browser can visibly open the site when I manually navigate/login, but the agent cannot inspect, screenshot, read DOM, or interact with the page. The same happens with Chrome-control / Codex Chrome extension.

Tested domains:

• https://kiaraspicy.com
• https://higgsfield.ai

Both domains were added to allowed sites, but Browser Use still rejects read-only actions with:

Browser Use rejected this action due to browser security policy.
Reason: Browser Use cannot access https://kiaraspicy.com because enterprise network policy blocks it.

This blocks legitimate read-only workflows:

• logged-in app audit
• screenshots
• DOM inspection
• UI/product research
• network-safe endpoint inventory

The user can manually open and log into the sites in the in-app browser, but Codex cannot access the same visible page state.

Reproduces on a newer Windows build:

• OpenAI Codex 26.707.3748.0 (Microsoft Store)
• Chrome 150.0.7871.114
• Codex Chrome extension 1.2.27203.26575_0
• Personal Windows PC with administrator access; no local requirements.toml or managed_config.toml was found

The in-app Browser Use backend connects. The Chrome-extension backend also connects and can enumerate live Chrome tabs. The native messaging host checker reports Correct: yes, and the Browser Use origin allowlist explicitly contains https://example.com, https://www.iana.org, and http://127.0.0.1:8765.

Nevertheless, both the in-app browser and Chrome Browser Use reject example.com and 127.0.0.1 before page load with “enterprise network policy blocks it”. This reproduces after restarting Chrome and Codex and in a brand-new task.

As a control, a separately configured Playwright MCP can open https://example.com, detect and click “Learn more”, and reach the IANA destination. That confirms ordinary network and local-browser connectivity.

This suggests the Browser Use policy gate remains broken in 26.707.3748.0 and is not caused by the Chrome extension/native-host setup or the local Browser Use allowlist.

Reproduces after a full local recovery attempt on a personal ChatGPT Plus account.

Environment

• Windows 11 x64, Microsoft Store app
• OpenAI Codex AppX: 26.707.3748.0
• Bundled Chrome and Browser plugins: 26.707.31428
• Node runtime: 24.14.0
• Chrome extension backend: connected

Authoritative policy evidence

Direct calls to the same packaged Codex app-server returned:

{"requirements": null}

The relevant effective-config fields were also empty:

{
  "default_permissions": null,
  "network": null,
  "permission_profile_names": []
}

There is no local requirements.toml, managed_config.toml, active browser/config.toml, or matching origin/domain deny entry. CODEX_CLI_PATH is unset at Process, User, and Machine scope.

Recovery steps already completed

1. Repaired the bundled Node/Computer Use runtime after AppX protected-file relocation failed; deployed runtime binaries match the current AppX package by SHA-256.
2. Removed a temporary manually configured node_repl MCP entry and restored the packaged bridge.
3. Removed and reinstalled chrome@openai-bundled using the official codex plugin remove/add commands.
4. Installed the previously absent browser@openai-bundled plugin, leaving both Browser and Chrome installed and enabled.
5. Restarted only the packaged Codex app-server after each plugin change.

After every restart, the Chrome backend was rediscovered and could create/read a real about:blank tab. However, navigation to https://search.bilibili.com/all?keyword=chatgpt was still rejected before page load with:

Browser use cannot access https://search.bilibili.com because enterprise network policy blocks it.

The tab remained at about:blank. The same false denial was previously reproduced with https://example.com and localhost.

The bundled browser client currently converts any exception from its requirements/config read into a deny decision and then labels it codex-network-policy. That appears consistent with an underlying config-bridge failure being surfaced as an enterprise restriction.

Requested fix: treat missing/empty requirements as unconstrained, and report the original policy/config bridge error instead of converting all read failures into an enterprise-network-policy denial.