Browser Use reports local default profile network.enabled=false as an admin-enforced denial

Summary

On macOS, a local default permission profile with network.enabled = false causes Browser Use to reject real-page access in both Chrome and the built-in browser with:

The admin-enforced policy blocks this action.

We traced a concrete local configuration input to this denial and verified that changing only that network flag to true restored browser access immediately, without restarting the app.

This report concerns a resolved policy denial, not the distinct “policy could not be verified” error. Related symptom/provenance report: #43822. We have not established that other reporters share this cause.

Environment at verification, 11 September 2026

• macOS.
• ChatGPT/Codex desktop app: 26.908.31748, build 8720.
• App-bundled Codex CLI: 0.154.0-alpha.6.1; runtime logs confirmed the bundled executable was selected.
• Google Chrome: 152.0.7977.84.
• ChatGPT Chrome extension: 1.26.901.11451.

Configuration and observed sequence

Relevant excerpt from the user-level ~/.codex/config.toml (profile name anonymised; unrelated settings omitted):

default_permissions = "browser_repro"

[permissions.browser_repro]
extends = ":workspace"

[permissions.browser_repro.network]
enabled = false

1. With this named default profile, browser discovery and Chrome tab enumeration succeeded.
2. Attempting to read an existing public GitHub tab failed before page inspection with the admin-enforced policy denial. The built-in browser also failed on public pages, including https://example.com.
3. After explicit user approval of the wider network permission, change only enabled = false to enabled = true. The file was backed up, parsed and compared to confirm exactly this one-line change.
4. In the same running app, the previously rejected Chrome tab returned its page accessibility tree.
5. The built-in browser opened https://example.com, followed its “Learn more” link, and returned the IANA destination page.

These are observed before/after results on the affected installation, not a claim that the reduced excerpt has been replayed in a clean installation.

How the setting was introduced

The profile was introduced by a Codex-assisted configuration migration on 10 September at 08:25 BST, while repairing access to specific reporting folders. The migration replaced legacy sandbox_mode / sandbox_workspace_write settings with a named global default profile. It preserved the old network_access = false intention as network.enabled = false.

Browser access had succeeded on 9 September. The first matching browser denial found in the local task history was 10 September at 11:15 BST, before the later app updates. Reporting-folder access was verified after the migration, but browser access was not. We therefore do not attribute this incident to the latest app update.

Diagnostic finding

Read-only inspection of the installed, unmodified bundled browser-service.mjs showed that browser-origin access evaluation combines managed requirements with the network settings of config.default_permissions. An effective enabled === false yields a denial, which is surfaced as “admin-enforced” even when the identified input is user-level configuration.

We found no browser_use override in that user configuration. Absence of locally checked managed files does not prove absence of remote policy.

Workaround and its consequence

Enabling networking removed the identified local blocker and restored both browser surfaces. However, this also permits command network access for tasks using the profile. It is not a browser-only fix and should not be recommended without explaining that scope.

Requested improvement

• Identify the effective denying setting, selected profile and source layer in the error, rather than attributing a local setting generically to an administrator.
• Clarify whether local command-network disablement is intended to disable Browser Use. The permission-profile documentation describes local command boundaries and separate browser controls: https://learn.chatgpt.com/docs/permissions
• If this coupling is intentional, document the migration consequence and provide an actionable diagnostic. If separate controls are intended, correct the coupling while preserving managed policies and normal browser approvals.
• Add regression coverage for legacy-to-named-profile migration and local-versus-managed error provenance.

No private paths, raw configuration, credentials, cookies, client data or private task identifiers are included.

Start by inspecting the installed browser-service.mjs and the permission-profile behavior described in the issue, then review the migration shape in ~/.codex/config.toml and the linked permissions documentation. Trace how local and managed settings produce the reported denial, identify the relevant regression-test entry points, and define done as accurate provenance, documented coupling or separation, and coverage for migration and error handling.