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

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

1. Initialize the bundled Chrome browser-control runtime.
2. Enumerate extension-backed Chrome instances.
3. Select the intended current instance from its metadata.
4. List open tabs and select an existing signed-in webpage.
5. Claim the exact tab object returned by openTabs().
6. Attempt any real-page interaction:
   • tab.playwright.domSnapshot()
   • tab.dom_cua.get_visible_dom()
   • tab.cua.move(...)
   • a direct Playwright locator click
7. 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.

Start by reproducing the failure after agent.browsers.list(), browser.user.openTabs(), and browser.user.claimTab(exactTabInfo), then compare the real-page methods named in the report: tab.playwright.domSnapshot(), tab.dom_cua.get_visible_dom(), and tab.cua.move(...). Done means claimed real pages can be read and interacted with, or the failure returns a specific diagnostic code and recovery path.