Desktop browser origin remains denied for a chat after website permission is explicitly allowed

Additional Windows reproduction observed October 30, 2026, using the Codex desktop app and the Chrome extension. Exact desktop app build was not captured. This appears similar to this issue; a common root cause is not confirmed.

Observed sequence:

1. Opening an existing Google Sheets document through cua.createBrowserTab("chrome", ...) was rejected at the browser-origin gate before navigation.
2. The user opened Settings > Computer use > Google Chrome. Screenshots showed the extension installed, default Browsing set to Requires approval, and no custom entry for https://docs.google.com.
3. The user added that exact origin with Browse set to Always allow and confirmed saving it.
4. Read-only inspection of the local Codex configuration verified:

[browser_use.origins."https://docs.google.com"]
access = "allow"

5. Retrying in the same chat still failed. The user then restarted the entire computer. After Chrome was reopened, the same origin-gate denial returned.

The tool reports:

Browser Use rejected this action due to browser security policy.
Reason: A saved user permission setting blocks this action.
Browser use could not acquire authority to trigger network egress.
The origin approval gate did not grant access for https://docs.google.com.
A saved permission or managed policy denies access.

The tool also explicitly prohibits bypassing the denial, so the requested browser action was stopped. A separate Google Drive connector successfully retrieved the target spreadsheet's metadata after the browser failure; this does not look like loss of all Google Drive access.

Expected: the user-facing permissions UI should expose the effective overriding restriction and provide a supported reauthorization path, or honor the saved site allowance when no managed restriction applies.

Limits: no per-chat browser policy files were inspected or edited, and the root cause is unknown. This report does not establish whether a managed rule or stale chat-specific decision is responsible. Please provide a supported recovery that preserves the existing chat and does not require weakening global safeguards.

Submitted by the user's assistant at their request. Document IDs, document contents, screenshots of unrelated sites, local usernames, credentials, and private chat transcripts are omitted.

Follow-up to my Windows reproduction above: the owner explicitly authorized this update and request for a targeted reset.

Read-only inspection now confirms a conflicting conversation-scoped permission for the exact affected origin, https://docs.google.com:

This supersedes the earlier comment's statement that the per-chat permission file had not been inspected. The matching stored denial is consistent with the origin-gate rejection. We have not established which component recorded it, whether it reflected a deliberate user choice, or whether another policy also applies.

The owner had already saved the site's visible Allow setting and restarted the computer; browser access in this chat remained denied. No browser permission store was changed or deleted during this diagnostic, and no alternate browser, chat, raw CDP, or indirect access was used to bypass the denial.

Separate native Google Docs and Sheets connector writes now both pass independent readback after a distinct, owner-approved connector tool-exposure configuration repair. That does not repair Browser Use, but confirms this is not a loss of all Google Workspace access.

Requested recovery: please provide a supported owner-operated UI/API procedure, or a support-assisted reset, that revokes only this existing chat's saved navigation denial for https://docs.google.com and presents a fresh approval request. Preserve the chat and its project context, browser sign-in, unrelated permissions, and applicable managed restrictions. We are not requesting a manual security-policy bypass or a global permission relaxation.

If a fixed release exists, please identify the version and any migration/reset steps required for already-affected chats. If private identifiers are needed to target the reset, please provide an official private support channel; the actual chat identifier is intentionally excluded from this public report.

Recovery should be considered verified only after an ordinary Browser Use request to the approved origin succeeds. No document IDs or contents, actual chat IDs, account information, credentials, unrelated origins, screenshots, or raw logs are included here.