Skip to content

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

Closed
Closed
Browser Use rejects all external URLs as enterprise network policy when privileged config bridge is missing#30947
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

Description

@dawood-k
dawood-k
opened on Jul 2, 2026

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:

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    browser
    configIssues involving config.toml, config keys, config merging, or config updates
    on Jul 2, 2026

  2. github-actions commented on Jul 2, 2026

    @github-actions
    github-actionsBot
    on Jul 2, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Valdemarlw commented on Jul 6, 2026

    @Valdemarlw
    Valdemarlw
    on Jul 6, 2026

    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.

  4. 0xdevalias commented on Jul 25, 2026

    @0xdevalias
    0xdevalias
    on Jul 25, 2026

    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 #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:

  5. dawood-k commented on Jul 25, 2026

    @dawood-k
    dawood-k
    on Jul 25, 2026 – with ChatGPT Codex Connector
    Author

    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.

  6. dawood-k
    closed this as completedon Jul 25, 2026

  7. adambdc commented on Jul 28, 2026

    @adambdc
    adambdc
    on Jul 28, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbrowserbugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updateswindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions