macOS: Chrome tabs can be claimed, but every real-page action fails policy verification

Open 💬 8 comments Opened Aug 18, 2026 by Wildman-Phoenix

Summary

On macOS Codex Desktop, the bundled Chrome extension can enumerate multiple Chrome profiles, list the correct profile's open tabs, and claim an existing tab, but every interaction with a real webpage is rejected before reaching Chrome with:

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.

The user reports that other Codex tasks on the same Mac can control the same Chrome state. The affected task has no known administrator policy configured.

Environment

macOS 26.5.2 (25F84)
Google Chrome 151.0.7922.138
bundled Chrome-control package 26.814.41407
extension ID: hehggadaopoacecdllhhajmbjkdcmajg
extension version: 1.2.27259.19709
multiple extension-backed Chrome profiles connected
target profile metadata: profile name Nathan, ordering 4 (account details redacted)

Diagnostics that pass

Chrome is running.
Extension is installed, registered, and enabled on the target profile.
Native-host manifest exists and is valid.
Expected extension origins are present.
agent.browsers.list() returns the target extension instance.
browser.user.openTabs() lists the intended existing tabs.
browser.user.claimTab(exactTabInfo) succeeds.
Creating an about:blank tab succeeds.
cua.move() on about:blank succeeds.

Reproduction

Initialize the bundled Chrome browser-control runtime.
Enumerate extension-backed Chrome instances.
Select the intended current instance from its metadata.
List open tabs and select an existing signed-in webpage.
Claim the exact tab object returned by openTabs().
Attempt any real-page interaction:

tab.playwright.domSnapshot()
tab.dom_cua.get_visible_dom()
tab.cua.move(...)
a direct Playwright locator click

The operation is rejected with the policy-verification error above.

The same rejection occurs on a neutral https://example.com/ tab, so it is not site-specific. An existing Gmail tab can hang until the browser runtime times out and resets.

Expected behavior

Once the correct profile and exact existing tab have been discovered and claimed, real-page DOM reads and input should work. If authorization cannot be established, the product should return a specific diagnostic code and actionable recovery path rather than an unverifiable admin-policy message.

Actual behavior

Discovery and claiming succeed, giving the appearance that browser control is active, but no mouse, DOM, click, or download command reaches real webpage content.

Suspected boundary

The defect appears after extension discovery/tab claiming but before Browser Use page-policy authorization or attestation. This is an inference, not a confirmed root cause. The fact that other Codex tasks reportedly work on the same machine argues against a general Chrome, extension, native-host, account, or target-site failure.

UX impact

The UI/control indicator can make the session appear active even though no page input can be delivered. Please distinguish:

extension connected
tab discovered
tab claimed
page readable
input delivered

Related reports

#35311: Chrome route can claim tabs but deeper page reads time out
#26264: discovered Chrome tabs rejected by enterprise browser security policy

No credentials, cookies, email addresses, recording identifiers, or private URLs are included in this report.

View original on GitHub ↗

8 Comments

alexx-ftw · 4 days ago

Cross-platform reproduction: I am seeing the same policy-verification boundary on Linux with the Codex Desktop in-app browser, not the Chrome-extension path described in this issue.

Environment:

Linux x86_64
Chromium user agent 151.0.0.0
bundled in-app browser-control package 26.818.41705

Observed sequence:

Browser runtime selection succeeds.
browser.user.openTabs() returns the intended existing HTTPS tab.
browser.user.claimTab(exactTabInfo) succeeds and returns a controllable tab handle.
The first real-page read after claiming—e.g. a Playwright body.innerText() read and tab.dev.logs() inspection—is rejected before page content is returned.

The reported error is identical:

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.

I reproduced this against both the apex and a subdomain of the same public web application, across separate attempts. Discovery and claiming consistently work; failure occurs at the page-policy/attestation boundary. No cookies, local storage, credentials, private URLs, or account identifiers were inspected or included.

This suggests #39280 may not be limited to macOS, Chrome profiles, or the extension bridge; the shared real-page authorization path may be involved.

Diagnostic attestation: actor_id codex-desktop-canary; turn_id 01a03080-c032-7a13-b76e-b5d03f13e56e.

scole954387 · 3 days ago

Same issue confirmed on macOS

I am experiencing the same policy-verification failure. Codex can discover and claim the correct open Chrome tab, but it cannot read or interact with the page afterward.

Environment

Date observed: August 24, 2026
macOS: 26.5.1 (25F80)
ChatGPT/Codex Desktop: 26.814.41407 (build 6720)
Google Chrome: 151.0.7922.174
Bundled Chrome-control package: 26.814.41407
Codex Chrome extension: 1.2.27268.51612
Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
Chrome profile: Default
Target: an authenticated HTTPS web application; URL omitted for privacy

Observed behaviour

The Chrome connection successfully:

Detects that Chrome is running.
Lists the intended open tab with the correct title and URL.
Claims the exact tab object returned by browser.user.openTabs().

The first attempt to inspect the claimed page using tab.playwright.domSnapshot() is then rejected before any page content is returned.

Exact 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 [REDACTED URL] because the admin-enforced policy could not be verified. Please try again later. This failure may be temporary. The agent may retry after the issue is resolved, but must not bypass browser security controls or use an indirect workaround.

Local diagnostics

The bundled diagnostic checks report:

Chrome is installed and running.
The Codex Chrome extension is installed, registered, and enabled.
No extension disable reasons are reported.
The native-messaging manifest exists and is valid.
The native host name matches com.openai.codexextension.
Both expected extension origins are present.
No missing origins or native-host problems are reported.

This appears to fail after extension discovery and tab claiming, at the page-policy authorization or attestation stage. It does not appear to be a missing extension, disabled extension, invalid native-host manifest, or inability to communicate with Chrome.

Manfred05 · 2 days ago

Same problem!

skalfa-user · 2 days ago

Confirming the same issue on macOS. The behavior is intermittent: Browser Use worked correctly in the same Codex task and controlled an authenticated Chrome tab, but later stopped working while tab discovery and claiming continued to succeed.

Environment:

Google Chrome: 151.0.7922.174

Codex Chrome extension: 1.2.27268.51612

Bundled Chrome-control package: 26.818.61809

Extension ID: hehggadaopoacecdllhhajmbjkdcmajg

Diagnostics that pass:

Chrome is running.

The extension is installed, registered, and enabled in the selected profile.

The native-host manifest exists and is valid.

The expected extension origins are present.

browser.user.openTabs() returns the intended tabs.

browser.user.claimTab() succeeds.

However, every real-page operation fails immediately afterward, including DOM reads, Playwright evaluation, and visible-page inspection:

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.

The failure occurs after the tab has been discovered and claimed, but before any interaction reaches the page. Keeping the tab open, reopening it, waiting, and retrying did not resolve the problem.

The intermittent nature is especially confusing: the same task and browser session can work normally, then suddenly fail at the policy-verification stage without any Chrome, extension, profile, or website configuration changes.

This looks identical to the authorization/attestation boundary described in this issue rather than a Chrome-extension or native-host failure. It would be helpful if Codex exposed the underlying policy-service or network error and provided an actionable recovery path. The current “admin-enforced policy” wording is misleading when no actual administrator block is known.

I can provide additional redacted diagnostics if needed.

kcc989 · 1 day ago

I’m experiencing what appears to be the same policy-verification failure, but through the Codex in-app browser rather than Chrome extension control.

Environment

macOS 27.0 (build 26A5406e)
Codex Desktop
bundled Browser package: 26.820.60940
Browser selected by the runtime: Codex In-app Browser (iab)
Date reproduced: August 26, 2026

Reproduction

Ask Codex to visit https://github.com/.
Codex successfully initializes and selects the in-app browser.
It creates a new tab and attempts tab.goto("https://github.com/").
Navigation is rejected with:

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.

The page never loads, so no DOM inspection or interaction is possible.

I retried after reconnecting to the browser runtime and receiving a new in-app-browser instance ID. The result was identical. This was therefore reproducible across two fresh browser sessions.

This differs slightly from the original report: it does not involve enumerating Chrome profiles or claiming an existing tab. The failure occurs during initial navigation in a newly created in-app-browser tab. That may indicate the affected policy-verification boundary is shared by both the in-app browser and Chrome-control paths, rather than being specific to extension-backed tab claiming.

Please let me know if there are diagnostic logs or identifiers I can collect safely to help isolate the failed policy check.

skfq4qnmyy-art · 1 day ago

Windows cross-platform reproduction (built-in Browser and Chrome control)

I am seeing the same policy-verification failure on Windows, including the Codex in-app browser path. This adds a Windows reproduction to the macOS and Linux reports above.

Environment

Windows 11 Pro 25H2 x64, build 26200.9168
ChatGPT/Codex Desktop MSIX: 26.820.7780.0
bundled Browser-control package: 26.820.60940
embedded Chromium: 151.0.7922.170
reproduced August 25–26, 2026

Observed behavior

The user can manually navigate the built-in browser to the same private HTTPS site, authenticate, and reach application routes.
The origin is explicitly present in Settings → Browser as allowed; the denied-origin list is empty.
Browser-control startup succeeds and the desktop reports the Browser capability as available.
Agent navigation through both @Browser and Chrome control is rejected before the target page loads with:

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.

Multiple complete application restarts and retries have not resolved it.
One automated failure was recorded at 2026-08-25T22:04:07Z. Manual navigation to the same origin succeeded afterward at approximately 2026-08-26T00:50Z and 01:50Z. Fresh automated retries failed identically at 2026-08-26T22:54:35Z, 22:54:55Z, and 22:59:21Z.

Local diagnostics

Codex configuration loads successfully.
Desktop app-server handshake succeeds.
Provider HTTP and WebSocket connectivity checks succeed.
Bundled runtime dependency diagnostics report no problems.
No OpenAI/Codex/ChatGPT policy keys were found under the normal HKCU/HKLM Windows policy registry paths.
Desktop logs repeatedly contain:

DeviceCheck attestation unavailable ... errorCode=1

That log line is correlated with Browser startup, but I am not claiming it is proven causal.

Expected behavior

An explicitly allowed site that loads in the shared built-in browser should be available to Browser control. If the managed-policy or attestation service cannot be reached or evaluated, the error should expose a specific diagnostic code and supported recovery path rather than implying an intentional administrator block.

This looks consistent with the shared real-page policy/attestation boundary described in this issue, rather than a target-site, login, DNS/TLS, Chrome-extension, or local allowlist failure.

The private URL, credentials, cookies, account identifiers, session identifiers, and raw logs are intentionally omitted.

dan-hook · 17 hours ago

Windows corroboration with a clean version boundary:

Browser Use succeeded on app 26.818.8289 / Browser 26.818.41509.
The first identical failure occurred after updating to app 26.820.7780 / Browser 26.820.60940.
It still reproduces on 26.820.9563 / Browser 26.820.71523, including example.com over a cellular hotspot with the corporate VPN disconnected.

Manual in-app browsing works, and no local Codex managed-policy files or registry policy were found. Also, DeviceCheck attestation unavailable ... errorCode=1 appeared immediately before a confirmed successful Browser Use action, so that marker alone does not explain the regression.

webolabo · 11 hours ago

I can confirm the same policy-verification error on Windows 11.

Environment:

Personal Pro account only, with no Work/Business workspace
Codex Desktop 26.820.10647.0
Browser runtime 26.820.80927
Both the built-in Browser and the Chrome extension are affected
The failure occurs on localhost and public websites
No local requirements.toml administrator policy is installed

The feature worked previously on the same account and computer.

Relevant Codex log:
GET /accounts/[redacted]/settings -> 401
{"detail":"Must use workspace account for this operation"}

Tab discovery and claiming succeed, but every attempt to read or interact with
the page is rejected before any browser action is performed.