Chrome plugin discovers open tabs, but `claimTab` rejects every normal site as blocked by "enterprise network policy"

The Chrome plugin connects successfully and can enumerate tabs from my normal Chrome profile, including each tab's current title and URL. However, attempting to claim any returned tab fails before the documented per-site permission prompt appears.

This is reproducible with a neutral public page:

1. Install and enable the ChatGPT Chrome Extension and Chrome plugin.
2. Confirm the extension is connected.
3. Open https://example.com/ in Chrome.
4. Ask Codex to claim the existing Example Domain tab.
5. Codex successfully calls openTabs() and receives the exact tab object with title Example Domain and URL https://example.com/.
6. Codex passes that exact returned object to claimTab().

Actual result:

Browser Use rejected this action due to browser security policy. Reason: Browser use cannot access https://example.com because enterprise network policy blocks it.

Expected result:

Codex should claim the tab, or display the documented per-site permission prompt allowing me to approve example.com for the task. No permission prompt appears.

The same rejection occurs for YouTube, GitHub, localhost, private LAN addresses, and authenticated internal sites. This is not a Chrome-extension connectivity failure: tab enumeration remains reliable and tab metadata updates correctly.

Environment

• OS: Windows 11 Pro 64-bit, build 26200
• PC management: WORKGROUP; not domain joined
• Chrome: 150.0.7871.116
• Codex Windows app package: 26.707.8168.0
• Current Chrome plugin: 26.707.61608
• Earlier affected Chrome plugin: 26.707.51957
• Current task ID: 019f62f9-f52b-7820-94cc-1fe12bb5222f

Checks already completed

• Chrome is running.
• The ChatGPT Chrome Extension is installed, enabled, and communicating.
• openTabs() succeeds and sees the correct tabs from the normal Chrome profile.
• The failure occurs at claimTab(), before page inspection or interaction.
• example.com reproduces the issue, so it is not limited to banking, authentication, private IP addresses, or a particular site category.
• No Chrome or Chromium enterprise-policy registry keys exist under HKCU or HKLM.
• Windows reports that the PC is not domain joined.
• No domain allowlist/blocklist entries were found in the local Codex global-state file.
• Restarting/reinstalling and opening fresh tasks did not resolve the issue.
• The error reproduced with Chrome plugin 26.707.51957 on July 12 and 26.707.61608 on July 14.

Timeline and related task IDs

• June 6: a Chrome-controlled tab became about:blank#codex-browser-sidebar-attach-token=..., leaving the prior tab binding stale. A newly created browser tab worked afterward.
• June 30 onward: Browser Use began returning the generic enterprise network policy blocks it rejection for public, localhost, LAN, and authenticated sites.
• July 12: the extension found the pfSense tab but claimTab() was policy-blocked in two separate tasks using Chrome plugin 26.707.51957.
• 019f5822-940e-7a22-8597-703be50f8099
• 019f582a-02ce-78f2-baa4-9cd589ee92b8
• Likely original deleted troubleshooting task: 019f5818-a16d-7d42-8cac-f8174af7f343
• July 14: current clean reproduction against https://example.com/ using Chrome plugin 26.707.61608.

Suspected failing layer

The native extension connection and Chrome tab-discovery path are working. The failure appears to be in the Browser Use URL-policy/authorization check applied when an existing Chrome tab is claimed. A personal, unmanaged Windows machine is being treated as though a blanket enterprise network policy blocks every host, and the normal host-permission prompt is never offered.

Privacy note

The current task contains private LAN and self-hosted domain names in earlier tab-list output. Please review the task before sharing the full session. The reproduction itself only needs example.com, the exact error above, the environment versions, and the task ID.