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.

I experienced the same externally visible failure on the Windows Microsoft Store build:

Browser Use cannot access https://example.com/ because enterprise network policy blocks it.

The in-app browser could display the page when navigated manually, but the agent could not navigate, read the title, or inspect the DOM. It happened for every tested domain, including example.com.

In my case, this was not an actual Chrome enterprise policy. It was caused by the Codex/ChatGPT Store package being physically installed on a secondary drive.

Important caveat: I cannot confirm that this issue has the same root cause because the original report does not show the package’s physical installation volume or the bundled-plugin synchronization logs. However, this is worth checking before treating the message as a real organization-managed network policy.

How I diagnosed it

PowerShell initially reported a normal-looking path under C:\Program Files\WindowsApps, but that directory was actually a junction to D:\WindowsApps:

$pkg = Get-AppxPackage -Name OpenAI.Codex |
    Sort-Object Version -Descending |
    Select-Object -First 1

$pkg | Select-Object Version, InstallLocation

Get-Item -LiteralPath $pkg.InstallLocation -Force |
    Select-Object FullName, Attributes, LinkType, Target

The bundled marketplace source also had the Encrypted / Application Protected attribute:

$marketplace = Join-Path $pkg.InstallLocation `
    'app\resources\plugins\openai-bundled\.agents\plugins\marketplace.json'

Get-Item -LiteralPath $marketplace -Force |
    Select-Object FullName, Attributes

& cipher.exe /c $marketplace

The desktop logs repeatedly contained events such as:

plugin_marketplace_folder_write_failed
bundled_plugins_marketplace_resolve_failed
bundled_executable_relocation_failed

There were also copyfile failures while copying files from the protected Store package into:

%USERPROFILE%\.codex\.tmp\bundled-marketplaces\...
%LOCALAPPDATA%\OpenAI\Codex\runtimes\...

My broken state looked like this:

Physical package location: D:\WindowsApps\OpenAI.Codex_...
Application Protected: True
Incomplete bundled marketplace staging directories: 25
Bundled plugin cache: missing
chrome-native-hosts-v2.json: missing
Chrome Native Messaging registration: missing

This explains why the UI and browser pane could exist while agent-side Browser Use failed before it could read page content.

Workaround that fixed it

I used the following procedure:

1. Backed up personal Codex state and Work scripts.
2. Uninstalled ChatGPT/Codex.
3. Changed Windows “Where new content is saved” so new apps were installed on the system drive, C:.
4. After uninstalling and closing ChatGPT and Chrome, moved the generated plugin/runtime state aside instead of deleting the whole .codex directory:

• %USERPROFILE%\.codex\.tmp\bundled-marketplaces
• %USERPROFILE%\.codex\plugins\cache\openai-bundled
• %USERPROFILE%\.codex\chrome-native-hosts-v2.json
• %LOCALAPPDATA%\OpenAI\Codex\runtimes

1. Rebooted Windows.
2. Reinstalled the Microsoft Store app on C:.
3. Verified that the package path was no longer a junction to D:\WindowsApps.
4. Opened a new conversation and tested Browser Use again.

Do not take ownership of or change permissions on D:\WindowsApps or D:\WpSystem. Also do not delete the entire .codex directory, because it may contain authentication, sessions, memories, skills, and other personal state.

Result

I tested before and after using the same Codex/ChatGPT desktop version, 26.721.3404.0.

After reinstalling the package on the system drive:

Application Protected: False
Incomplete staging directories: 0
Bundled Chrome plugin: 26.721.30844
Cached Chrome plugin: 26.721.30844
Native-host resourcesPath: valid

Browser Use then successfully opened and read:

URL: https://example.com/
Title: Example Domain
Content: This domain is for use in documentation examples without needing permission.

Therefore, at least in my environment, the “enterprise network policy” message was the observed Browser Use failure, while the underlying local cause was failed bundled-plugin/runtime initialization from an Application-Protected Store package on a secondary drive.

If the reporter’s package is also physically located on a non-system Store volume, reinstalling it on the Windows system drive may be a useful workaround. If it is already physically installed on C: with no marketplace/runtime copy failures, then this is likely a different cause and still needs investigation by the Codex team.

Fresh reproduction on the current Windows Codex Desktop build. The externally visible error wording has changed from the earlier “enterprise network policy blocks it” message, but the failure still appears to be the same policy-verification class.

Environment

• Codex Desktop package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
• Browser plugin cache: openai-bundled/browser/26.803.41515
• OS: Windows 10.0.26200.0, x64
• Browser backend selected by Browser Use: Codex In-app Browser
• Date reproduced: 2026-08-07

Minimal reproduction

1. Start a fresh Browser Use session in Codex Desktop.
2. Create a new task-owned in-app-browser tab.
3. Navigate directly to https://help.openai.com/.
4. Navigation is rejected before the page can be inspected.
5. Create one fresh tab and retry once.
6. The identical rejection occurs again.

Actual error

Browser Use could not complete this action because a browser security check was unavailable.
Reason: The admin-enforced policy could not be verified, so access was not granted.
Browser use cannot access https://help.openai.com because the admin-enforced policy could not be verified.
Please try again later. This failure may be temporary.

No policy bypass or alternate browser-control workaround was attempted.

Expected behavior

Browser Use should load an ordinary public OpenAI support page, or return an actionable policy source/remediation path. A policy verification failure should not be surfaced as an unexplained admin-enforced denial.

Impact

Browser automation is unusable for the requested task. In this case, the same failure also blocked opening the OpenAI support page needed to report the Browser Use bug through the normal support route.

No workspace paths, account identifiers, session IDs, or private browsing data are included in this report.

Additional Windows reproduction with a proxy-specific root cause.

Environment: personal Windows PC (not enterprise-managed), Codex Desktop, local HTTP proxy on 127.0.0.1:7897, Node runtime v24.15.0.

Observed sequence:

• To work around the first-turn "Reconnecting... 5/5" symptom, I configured Codex to use the local proxy directly via HTTP_PROXY/HTTPS_PROXY.
• Browser Use then reported: "The admin-enforced policy could not be verified, so access was not granted" for ordinary public pages and localhost. The message made this look like an administrator or Chrome enterprise policy.
• Direct access to the auxiliary endpoint ab.chatgpt.com timed out, while the same endpoint was reachable through 127.0.0.1:7897.
• The Node/browser runtime did not reliably use the proxy until NODE_USE_ENV_PROXY=1 was set together with HTTP_PROXY and HTTPS_PROXY in the node_repl environment.
• After that change and a Codex restart, both the in-app browser and the Google Chrome extension could open https://example.com/ and read its DOM successfully. A test of http://127.0.0.1:5173/ returned ERR_CONNECTION_REFUSED only because the local dev server was not running.

This suggests that at least one failure mode behind the "admin-enforced policy" message is unavailable policy verification caused by proxy inheritance/path handling, rather than an actual administrator policy. The error should distinguish policy denial from policy-service network failure and expose the effective proxy/network path. The first-turn reconnect workaround should also not require a global fixed proxy that silently changes the browser runtime's network behavior. Related: #23504.

Additional Windows reproduction with a proxy-specific root cause. Environment: personal Windows PC (not enterprise-managed), Codex Desktop, local HTTP proxy on 127.0.0.1:7897, Node runtime v24.15.0. Observed sequence: To work around the first-turn "Reconnecting... 5/5" symptom, I configured Codex to use the local proxy directly via HTTP_PROXY/HTTPS_PROXY. Browser Use then reported: "The admin-enforced policy could not be verified, so access was not granted" for ordinary public pages and localhost. The message made this look like an administrator or Chrome enterprise policy. Direct access to the auxiliary endpoint ab.chatgpt.com timed out, while the same endpoint was reachable through 127.0.0.1:7897. The Node/browser runtime did not reliably use the proxy until NODE_USE_ENV_PROXY=1 was set together with HTTP_PROXY and HTTPS_PROXY in the node_repl environment. * After that change and a Codex restart, both the in-app browser and the Google Chrome extension could open https://example.com/ and read its DOM successfully. A test of http://127.0.0.1:5173/ returned ERR_CONNECTION_REFUSED only because the local dev server was not running. This suggests that at least one failure mode behind the "admin-enforced policy" message is unavailable policy verification caused by proxy inheritance/path handling, rather than an actual administrator policy. The error should distinguish policy denial from policy-service network failure and expose the effective proxy/network path. The first-turn reconnect workaround should also not require a global fixed proxy that silently changes the browser runtime's network behavior. Related: #23504.

通过阅读你的评论，我解决了问题。
在 C:\Users\antho\.codex\config.toml 的 [mcp_servers.node_repl.env] 下加入：

HTTP_PROXY = "http://127.0.0.1:7897"
HTTPS_PROXY = "http://127.0.0.1:7897"
NODE_USE_ENV_PROXY = "1"

这让 Browser Use 的 Node 运行时也通过你的本地代理访问策略服务。

不知道是否可以在不开启代理的情况下也能进行浏览器的控制？

Fresh Windows reproduction on the current Codex Desktop build, with evidence that this is not Chrome-specific.

Environment

• Codex Desktop package: 26.825.3734.0
• Bundled Browser/Chrome plugins: 26.825.31414
• Codex Chrome extension: 1.2.27268.51612
• Windows x64; Store package status is OK and physically installed on the system drive
• Personal machine with no Chrome/Windows enterprise-policy registry entries
• No HTTP/HTTPS proxy environment configuration

Reproduction

• The Chrome extension/native host connects and Browser Use can enumerate or claim tabs.
• The first navigation or real-page read fails before page content is returned with: “The admin-enforced policy could not be verified, so access was not granted.”
• Codex’s in-app browser fails the same policy check.
• The user reports the same failure with Microsoft Edge, further indicating a shared Codex policy/app-server failure rather than a Chrome-only defect.
• Ordinary network access works and the auxiliary ChatGPT policy host resolves and responds.

Recovery already attempted

Repair, Reset, complete app reinstall, app/browser restarts, and extension reinstall did not resolve it.

Important local finding

The reinstall left a user-level CODEX_CLI_PATH override pointing to a version-hashed codex.exe that no longer exists. The current bundled CLI exists under a different hash and runs successfully. This matches the stale-path root cause reported in the discussion here and in #21955.

I am removing the dead override and restarting Codex to verify the documented repair. Even if that resolves this machine, the app should validate an environment-supplied CLI path before selecting it, and Repair/Reset/reinstall should not preserve a dead override that gets surfaced as an admin-policy failure. The error should identify the missing CLI/config bridge directly instead of reporting an unverifiable enterprise policy.

This blocks authenticated business web workflows across browser backends; no site/customer data is included here.

Verified resolution on this Windows machine.

The root cause was the stale user-level CODEX_CLI_PATH override identified above. It pointed to a version-hashed codex.exe that no longer existed after the app update/reinstall, while the current bundled CLI existed under a different hash.

Repair applied

1. Confirmed the override target did not exist.
2. Removed only the dead user-level CODEX_CLI_PATH override.
3. Broadcast the Windows environment change.
4. Fully restarted Codex so the desktop app and browser runtime no longer inherited the stale process environment.

Post-restart verification

• User-level CODEX_CLI_PATH: unset.
• New Codex app-server process: running the current bundled CLI, whose executable exists.
• Codex in-app Browser: successfully navigated to https://example.com/, read the title, and read the page DOM.
• Chrome extension Browser Use: independently navigated to the same page and read the title and DOM.
• The Edge extension was not connected after restart, so I did not claim a post-repair Edge verification.

This also explains why Repair, Reset, and a full reinstall did not help: they preserved the dead user environment override. Recommended product fix remains to validate an environment-supplied CLI path before using it, ignore or clean up a nonexistent override during Repair/Reset/reinstall, and surface a direct CLI/config-bridge error instead of the misleading admin-policy message.