Repository navigation
macOS: Browser Use reports saved-permission block despite Site permissions allowing Browse for the exact origin #43754
Description
Activity
Tenemos un caso similar con Zoho One en macOS. No sabemos si comparte la misma causa.
Observado el 9 de septiembre de 2026, en la aplicación de escritorio ChatGPT/Codex, versión 26.901.51231, build 8109. Esta es la versión registrada en el incidente original, no una comprobación de la versión instalada hoy.
El usuario puede iniciar sesión y ver
https://one.zoho.com.auen el navegador integrado, pero el agente recibe:A saved user permission setting blocks this action.
Las capturas de Settings > Browser muestran «Requires approval» tanto para la navegación predeterminada como para ese sitio. Sin embargo, no aparece una nueva solicitud de aprobación. El usuario informó que reiniciar la aplicación y abrir una pestaña nueva no resolvió el problema.
El 14 de septiembre también se comprobó Chrome conectado mediante extensión. El inventario detectó la pestaña de Zoho One, pero al seleccionarla el agente recibió el mismo rechazo. La nueva captura de configuración de Chrome mostraba «Requires approval» en la fila de Zoho. No se pudo leer el contenido de la página y la prueba se detuvo sin intentar vías alternativas. La versión instalada ese día no se volvió a comprobar.
Feedback enviado el 9 de septiembre:
01a06cad-07dd-7b50-80bc-046dafe625ce.¿Podrían confirmar si está relacionado con esta incidencia e indicar cómo identificar y corregir el permiso efectivo mediante los controles oficiales? Buscamos recuperar el acceso sin desactivar protecciones ni eludir el bloqueo.
No adjuntamos datos de cuentas, capturas, registros completos ni conversaciones.
I’m experiencing a similar issue in the ChatGPT/Codex desktop app on macOS.
Browser Use repeatedly rejects access to a website with this error:
A saved user permission setting blocks this action.
I’m omitting the affected URL for privacy.
In my case, I previously selected “Always block” in a website access permission prompt. I now want to revoke that decision.
I added an explicit rule for the exact affected origin under Settings → Browser → Agent permissions, first setting Browsing to Require approval, then changing it to Allow. After each change, I asked the agent to retry in the same conversation.
The result is unchanged: access is immediately rejected, and no new permission prompt appears.
The visible site rule and the browser tool’s effective permission decision appear inconsistent. I can’t confirm the underlying cause, but this seems consistent with the conversation-level denial described in #45237 and the macOS behavior reported in #43754.
Is there a supported way to revoke a saved “Always block” decision for an existing conversation? Ideally, the app should expose that decision in Settings and allow users to change it without editing internal files or losing their conversation context.
Reacted by Sarthak JoshiI can reproduce the same mismatch on Windows with the Codex desktop in-app browser (rather than Chrome/macOS).
- A user-supplied screenshot of Settings > Browser > Agent permissions shows the exact origin
https://dash.cloudflare.comset to Always allow for browsing. - In the same conversation, selecting the already-open Cloudflare Dashboard tab through the documented
mcp__cua_replin-app-browser API is still rejected with:A saved user permission setting blocks this action. - The user explicitly authorized access and changed the visible site setting, then requested a retry. The rejection persisted. I cannot confirm whether the effective restriction is conversation-scoped or stale state.
Could you provide a supported way to identify and revoke the effective saved denial when the visible origin rule says Allow? If another permission source takes precedence, exposing that source in the UI/error would make this recoverable without editing internal files or bypassing Browser Use policy.
No credentials, account identifiers, screenshots, logs, or conversation transcript are included here. This blocks an authorized Cloudflare configuration workflow; no alternate browser/API route was used to circumvent the Browser Use rejection.
Reacted by Sarthak Joshi- A user-supplied screenshot of Settings > Browser > Agent permissions shows the exact origin
Additional reproduction: external Chrome remains blocked after restart
Summary
The desktop app's Chrome permission UI shows Browsing = Always allow and no site-specific deny rule, but Browser Use refuses the user-authorized target origin, attributing the refusal to a saved user preference. The same rejection persists after Chrome is restarted and the extension reconnects.
Observed environment
- ChatGPT/Codex desktop app on macOS, controlling external Google Chrome through the browser extension.
- Chrome extension is shown as Installed in the app.
- The connected Chrome browser is detected again after its restart.
- Exact app/browser/OS versions have not been collected.
- The desktop app itself has not yet been restarted.
Reproduction
- In the desktop app's Google Chrome settings, inspect Agent permissions.
- Observe Default > Browsing = Always allow; the supplied screenshot shows no site-specific deny row.
- The user also reports explicitly granting access to the target site.
- Ask the assistant to inspect the user-authorized site through Browser Use.
- Browser Use refuses access before the page can be inspected.
- Restart Chrome, reconnect the same Chrome profile, and attempt the same target origin.
- The same saved-user-preference refusal occurs.
The actual target origin and profile details are intentionally omitted.
Expected result
Browser Use should honor the effective user permission displayed by the app. If another policy layer denies access, the UI and refusal should accurately identify that layer rather than attributing the decision to a nonexistent visible saved user block.
Actual result
Sanitized rejection excerpt:
Browser Use rejected this action due to browser security policy. Reason: A saved user permission setting blocks this action.
Browser use cannot access [redacted target origin] because the user has a saved preference that blocks it.Impact and limits of diagnosis
A user-authorized browser workflow remains blocked. The discrepancy is reproduced across a Chrome restart, but its root cause is unconfirmed; this report does not assert a particular cache, persistence, or policy-resolution defect. Restarting the desktop app has not yet been tested.
The security rejection was respected; no alternate browser surface, raw CDP, credential extraction, or policy bypass was used.
Privacy and evidence scope
This report contains only permission-UI observations, a sanitized rejection excerpt, and reproduction steps. No real site URL, source code, local file path, account/profile identifier, conversation/session identifier, full log, screenshot attachment, token, cookie, key, or unrelated transcript is included. Additional diagnostic data requires the user's approval.
Reference: https://learn.chatgpt.com/docs/chrome-extension#troubleshooting
Additional macOS reproduction: built-in browser permission loop
Reporting at the affected user's explicit request. This concerns the built-in browser, rather than an external Chrome profile.
Environment
- Desktop app installed as ChatGPT.app, using Codex and Browser Use.
- Installed version checked October 8, 2026: 26.1002.52244, build 13536.
- macOS 15.8.
- Observations retained from October 7–8, 2026. No fresh blocked-site retry was performed solely to post this report.
Observed behavior
- The user had the affected repository/CMS pages open and repeatedly authorized the scoped work.
- Selecting an existing GitLab tab through the supported Browser Use interface was rejected before page content became available. The tool attributed the rejection to a saved user permission blocking the origin.
- For a separate CMS origin, the inspected documented local origin configuration contained
access = "allow", while earlier browser attempts had been denied. A user-supplied settings screenshot showed an Always allow CMS entry, although the displayed origin was truncated. - The user reported changing site permissions and restarting the app. The reported access block persisted.
- Authenticated Google Search Console reports remained accessible in the same browser session, so this was not a global browser outage.
- Native Computer Use access to the app's own settings/feedback interface was separately denied for safety reasons. That restriction was respected; no in-app feedback ID was generated.
Important limits
The screenshot does not establish an Always allow rule for GitLab. A local CMS allow does not establish the effective policy or override any higher-priority rule. The exact matching rule and full policy precedence were not exposed. Stale state, conversation-scoped permissions, and a UI/enforcement mismatch remain hypotheses, not proven causes. This report does not reproduce the separate feedback-submission failure in #51383.
Impact and requested action
This blocked authorized work and led to repeated approval, login and restart instructions without an actionable explanation. The user is extremely frustrated by the amount of repeated intervention.
Please triage the inaccessible effective-permission state and provide a supported recovery procedure. The UI/error should identify the exact matched rule and its source, distinguish policy denial from authentication/resource access failure, and confirm when a permitted setting change reaches enforcement. Please also prevent repeated unchanged approval loops.
No credentials, customer domains, private repository paths, local user paths, account identifiers, screenshots, raw logs or chat transcripts are attached. No restriction was bypassed to prepare this report.
Summary
On macOS, the desktop app's Site permissions UI shows browsing allowed for
https://ads.google.com, but an existing Chrome tab on that origin is repeatedly rejected by Browser Use as blocked by a saved user permission.The user explicitly requested troubleshooting and submission of this report. This report was prepared by the assistant from observed tool responses and user-supplied settings screenshots. No advertiser identity, customer IDs, campaign metrics, credentials, screenshots, full logs, or session transcript are included.
Environment
26.901.51231(read from installed application metadata).26.2, build25C56.mcp__cua_repl.Observed sequence
await cua.getTab(existingTabId, { browser: existingBrowserId });ads.google.comset to Always allow.https://ads.google.comwith Custom, and green Browse and Download indicators.The original user-visible settings and the later origin-specific settings both show allow. We cannot establish which permission source the enforcement service actually evaluated.
Actual error
The tool also explicitly prohibits workarounds or policy circumvention. The agent respected that restriction; no alternate browser surface, raw browser protocol, direct service request, or local permission-file edit was used to obtain the blocked data.
Expected
An explicit origin-level Browse allowance should be reflected in the effective browser permission decision, unless a separate overriding restriction applies. If an overriding restriction applies, the UI/error should identify it accurately rather than attribute the rejection to a user preference that the displayed settings contradict.
Please provide a supported recovery procedure and investigate permission-source precedence or stale permission state. Neither cause is confirmed by this report.
Troubleshooting and impact
Computer Use is not allowed to use the app 'com.openai.codex' for safety reasons.This is noted as a reporting limitation, not a request to bypass that protection.Related but not established as the same cause: #29343 (site-policy rejections). This report specifically concerns a saved-user-permission denial despite visible origin-level allow.