›_ Codex Issues
Codex Issues / #30947

Browser Use rejects all external URLs as enterprise network policy when privileged config bridge is missing

Resolved 💬 5 comments Opened Jul 2, 2026 by dawood-k Closed Jul 25, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Browser Use rejects navigation to all tested external URLs with an enterprise-network-policy message, even after Codex Desktop reinstall and Browser/Chrome plugin refresh. The failure is not site-specific; it reproduces with https://example.com.

This appears related to the Browser Use runtime missing the privileged config bridge (nodeRepl.config), so it cannot read browser config or enterprise policy requirements and seems to fail closed.

Environment

  • Platform: Windows
  • Codex Desktop install source: Microsoft Store / winget package
  • Codex app package version observed: 26.623.11225.0
  • Browser/Chrome plugin cache version observed: 26.623.81905
  • Codex CLI version observed: codex-cli 0.142.5
  • Browser Use backends observed: chrome,iab
  • Chrome extension backend connects successfully
  • In-app Browser backend connects successfully

No private account, workspace, browser history, auth, or local document details included here.

Reproduction

  1. Start Codex Desktop on Windows.
  2. Ensure Browser Use / Chrome extension is installed and enabled.
  3. Connect to Chrome Browser Use or the in-app Browser Use backend.
  4. Attempt to navigate to a neutral public URL:
await tab.goto('https://example.com')

Expected behavior

Browser Use should either navigate to https://example.com or prompt/ask for origin approval if needed.

Actual behavior

Navigation fails immediately with:

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. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

Scope

This is not limited to LinkedIn or Upwork. It reproduces on:

  • https://example.com
  • https://www.linkedin.com
  • https://www.upwork.com
  • https://platform.openai.com

It also reproduced in both Chrome Browser Use and in-app Browser Use.

Diagnostic evidence

Browser Use backends are visible and connected, for example:

  • Chrome, type extension
  • Codex In-app Browser, type iab

But the privileged config bridge is missing:

{
  "hasNodeReplConfig": false,
  "readTomlType": "undefined",
  "readRequirementsType": "undefined"
}

Because the browser client appears to rely on reading both browser/config.toml and enterprise requirements to decide origin/CDP policy, the missing bridge may cause a fail-closed enterprise-policy denial for normal external navigation.

Things tried

  • Restarted Codex Desktop.
  • Restarted Chrome.
  • Refreshed/reinstalled Browser and Chrome plugins through Codex plugin UI/CLI-supported paths.
  • Fully reinstalled Codex Desktop.
  • Verified Chrome extension/native host can connect.
  • Verified neutral canary URL still fails.
  • Temporarily enabled Developer Mode / full CDP access for diagnosis, then disabled it again. It did not expose CDP capability or change the navigation failure.

Additional observation

After reinstall/restart, CODEX_CLI_PATH in config was observed pointing to a stale/missing codex.exe path. Manually correcting it to the current installed CLI path did not fix Browser Use navigation; nodeRepl.config remained unavailable and the same enterprise-policy error persisted.

Related-looking issues

This appears similar to reports such as:

  • #24814
  • #28474
  • #24017
  • #27160

Request

Could the Browser Use runtime/config bridge initialization be checked on Windows? In particular, if nodeRepl.config is unavailable, the current behavior seems to surface as a misleading enterprise network policy block for all external origins, even on https://example.com.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30623

Powered by Codex Action

Valdemarlw · 1 month ago

I can reproduce this on another Windows Codex Desktop install today, so adding fresh evidence rather than opening a duplicate.

Environment:

  • OS: Windows 11, reported by codex doctor as Windows 10.0.26200.
  • Codex CLI: codex-cli 0.142.4.
  • Codex app package observed by codex doctor: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0.
  • Browser plugin/runtime: openai-bundled/browser/26.623.101652.
  • Browser backend selected by Browser Use: Codex In-app Browser, type iab.

Repro performed:

  1. Loaded the Browser plugin runtime and selected iab.
  2. agent.browsers.list() returned Codex In-app Browser.
  3. browser.tabs.new() succeeded.
  4. tab.goto("https://example.com") failed before navigation.

Exact 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. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.

After the failure, the tab remained on about:blank.

Current local browser config:

full_cdp_access_enabled = true
approval_mode = "never_ask"

There is also a backup config from 2026-06-12 on this machine:

approval_mode = "always_ask"
full_cdp_access_enabled = false

[origins]
allowed = [ "https://example.com" ]
denied = []

The current config.toml was last modified on 2026-06-27 at 21:37 local time.
This lines up with the symptom where Browser Use never prompts and rejects unknown origins with the enterprise policy message.

codex doctor --json showed auth and provider/network reachability OK.
It did report a newer CLI patch available (0.142.5 vs 0.142.4) and an unrelated TERM=dumb terminal display failure, but nothing that looks like a general network/auth outage.

0xdevalias · 1 month ago

I found a potentially deeper explanation for this failure mode in a current macOS Desktop build, though I cannot confirm that it is the cause of this Windows-specific report.

One important correction to the earlier diagnostic approach: ordinary model-submitted code receives a deliberately restricted globalThis.nodeRepl without config. Trusted, hash-approved Browser code receives a separate privileged bridge. Therefore, observing globalThis.nodeRepl?.config === undefined from ordinary code does not prove that the privileged bridge is absent.

In my reproduction, I attached a temporary debugger inside the trusted Browser client and observed its two privileged config reads separately:

  • nodeRepl.config.readRequirements() succeeded with { requirements: null }.
  • nodeRepl.config.readToml("browser/config.toml") rejected with Codex TOML directory must not be a symlink.

Here, ~/.codex itself is a symlink. The Browser client catches the exception and fails closed, producing a generic policy/config verification failure even though the trusted bridge exists.

I opened https://github.com/openai/codex/issues/35310 with the full evidence:

If an affected installation in this thread uses a symlinked CODEX_HOME/.codex directory, the same rejection may explain its symptoms; otherwise this remains only an adjacent diagnostic finding.

Also related:

  • #24017
dawood-k · 1 month ago

Update from July 25, 2026:

The original failure is no longer reproducible on the current installation.

I retested both Browser Use backends:

  • Codex in-app Browser (iab)
  • Chrome extension (extension)

Both backends passed the following checks:

  1. Open a fresh tab and navigate to https://example.com/.
  2. Read the page title and visible heading.
  3. Navigate across origins to https://www.iana.org/help/example-domains.
  4. Read the destination page title and visible heading.
  5. Reload the external page.
  6. Open a second fresh tab and navigate to https://example.com/ again.

No enterprise-network-policy rejection occurred. The currently observed Browser plugin version is 26.721.41059; the original report observed 26.623.81905, so the behavior appears to have been resolved by a later app/plugin update.

Correction to the original diagnostic theory: observing globalThis.nodeRepl?.config as unavailable from ordinary model-submitted code does not establish that the trusted Browser runtime lacks its privileged config bridge. The reported navigation failure and error message were real, but the proposed “missing privileged config bridge” root cause was not proven.

The symlink-specific explanation discussed in #35310 also does not match this affected Windows installation.

Closing this as resolved on the current version. If the enterprise-policy rejection returns, I will reopen this issue with the new app/plugin versions and exact reproduction context.

adambdc · 1 month ago

Regression reproduced on macOS with Browser plugin version 26.721.41059—the version previously reported as resolving this issue.

Environment:

  • ChatGPT Desktop: 26.721.41059, build 5848
  • macOS 26.5.2 (25F84), arm64
  • Bundled Codex CLI: 0.146.0-alpha.3.1
  • Chrome extension connected successfully
  • Reproduced: July 28, 2026 at approximately 10:52 AM HST

Observed behavior:

  • Chrome tabs can be enumerated.
  • The existing fal.ai tab can be found and claimed.
  • Reading or interacting with page content is immediately rejected.
  • A fresh navigation to https://example.com/ produces the identical rejection, proving this is not specific to fal.ai.

Exact 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.”

Local checks:

  • Personal Mac; not enrolled in DEP or MDM.
  • No system or user managed Chrome policy files.
  • ~/.codex is a normal directory, not a symlink.
  • No enterprise requirements.toml exists.
  • Browser config has approval_mode = "never_ask".
  • CODEX_CLI_PATH points to an existing executable.
  • Both the configured and bundled Codex executables run successfully.
  • Full CDP access is disabled.

This contradicts the July 25 report that 26.721.41059 resolved the failure. Please reopen this issue or identify the current tracking issue. The error is misleadingly presented as an enterprise policy despite no enterprise requirements being present.