Repository navigation
[macOS Desktop] Browser Use reports saved permission block despite site access allow #47506
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
- macOS built-in Browser blocks PropFinder despite explicit Browsing: Always allow #47131
- [macOS][Computer Use] App approval dialog never appears and Finder/Safari access is denied #46276
Powered by Codex Action
Additional diagnostic evidence: another existing task on the same desktop successfully opened the same affected CMS origin through the Codex in-app browser on 2026-09-23. Its recorded Browser Use result contains the CMS accessibility tree (navigation and authenticated manager interface), not merely tab inventory or a navigation-completed event.
The affected task previously received
A saved user permission setting blocks this actionfor this origin despite an exact-originaccess = "allow"configuration. These observations were not simultaneous controlled tests, so they establish differing observed task behavior, not its root cause. We have not established whether task-scoped approvals, managed policy, or inconsistent state explains it.Please identify the effective denial source for the feedback ID already provided and advise a supported recovery procedure that preserves task history and browser data. No raw logs, customer data, site identifiers, or credentials are included in this comment.
Follow-up on 2026-09-25: the same affected task still receives "A saved user permission setting blocks this action" when attempting a read-only lookup of the already-open CMS tab through the supported in-app browser API.
The owner created a local project pointing to the existing working folder, and its registration was verified. A subsequent access check from the original task still failed with the same saved-permission rejection. This was NOT a test from a new project-bound task, and we are not claiming that project-scoped access was tested or that the original task was migrated.
The earlier observation that another existing task accessed the same origin remains historical evidence, not a simultaneous comparison today. The root cause is still unknown. No alternate-browser, indirect execution, or policy bypass was attempted. No site data was changed.
Please help identify the effective permission rule causing the rejection for the feedback ID in the original report, and provide a supported recovery procedure that preserves task history and browser data.
Check in your ~/.codex/browser/session/.toml if there isnt something blocking the site, like:
[origins] allowed = [ ... ] denied = [ " https://outlook.cloud.microsoft/" ]Thank you @globlit — this pointed us to a concrete saved denial. Read-only inspection on 2026-10-01 found the affected thread file at
~/.codex/browser/sessions/<affected-thread-id>.toml(pluralsessions). Its[origins]section contains:denied = ["https://chagatay.com.ua"]
This contrasts with the previously verified exact-origin
access = "allow"in the main config and the owner's visible allow settings. We have not established why the session denial was created or why the UI changes did not clear it. No session/config files were edited, no browser data was deleted, and no alternate-browser bypass was attempted.Could a maintainer provide the supported owner-facing procedure to revoke this specific saved session denial and request access again, while preserving this thread, browser logins, and browsing data? Please also clarify which UI controls this session-level entry. The feedback ID is already in the original issue.
I can provide additional evidence from another affected macOS installation on 2026-10-01:
- ChatGPT / Codex Desktop: 26.928.21956.
- macOS: 15.7.9. Platform: Darwin 24.6.0 arm64 arm.
- Surface: built-in browser in an existing Work conversation.
- Origin: https://www.instagram.com.
- Error: “A saved user permission setting blocks this action”.
The owner set browsing to “Always allow”, opened the site manually, and fully restarted the app. Access from the affected conversation remained blocked.
Read-only inspection found:
# ~/.codex/config.toml (relevant section only) [browser_use.origins."https://www.instagram.com"] access = "allow" # ~/.codex/browser/config.toml [origins] allowed = ["https://www.instagram.com"] denied = [] # ~/.codex/browser/sessions/<redacted-session-id>.toml [origins] denied = ["https://www.instagram.com"]
No permission files were edited and no workaround was used to access the blocked site. We are requesting a supported, user-facing procedure to revoke this saved session denial and request access again.
Reporting is also affected: two /feedback submissions were accepted but failed to upload diagnostic attachments. Neither result dialog displayed a session ID.
- 2026-10-01 09:08:31 UTC: request ID
19026d97-d2c7-4f6c-959d-136d12585fad. - 2026-10-01 10:05:59 UTC: request ID
8f9ca0b5-0b88-453f-a02a-ed55d7d25d69.
Both app-log entries show method
feedback/upload, error code-32603, and:failed to upload feedback: feedback report was accepted, but some attachments failed to uploadThe internal log for the FIRST submission additionally shows:
feedback attachment upload failed; continuing status=429 feedback event uploaded to Sentry thread_id=no-active-thread-[redacted] uploaded_attachments=0 attachments_failed=trueThe source of that HTTP 429 response is not established. These records do not establish a VPN/proxy/firewall block. We have not verified an attachment HTTP status for the second submission.
Please advise a supported recovery procedure and a private route for any further diagnostics needed. This comment omits account identifiers, the real conversation ID, user-specific paths, credentials and conversation transcripts.
Additional reproduction on macOS on October 1, 2026, reported at the affected user's request.
The desktop app's Agent permissions screen shows both Default → Browsing: Always allow and a site-specific entry for the affected HTTPS application → Browsing: Always allow. The user supplied a screenshot confirming these settings. Downloads remain Requires approval; the attempted operation only reads an existing page.
Observed sequence in an existing conversation:
- The user opens a hosted application in the built-in browser and completes its normal sign-in flow.
- The application renders its authenticated admin page for the user.
- The agent attempts to select/read that already-open tab using the documented
cua.getTab({ url: "https://<redacted-host>/admin/people" }, { browser: "iab" })API. - Browser Use immediately rejects it with the following message (hostname redacted):
Browser Use rejected this action due to browser security policy. Reason: A saved user permission setting blocks this action. Browser use cannot access https://<redacted-host> because the user has a saved preference that blocks it.The same rejection persisted on a fresh attempt after the user supplied the screenshot showing Always allow. Earlier attempts against this application's origin through the Chrome extension also returned the saved-preference denial. The identity-provider sign-in pages could be read during the sign-in flow, but the application origin was subsequently denied. No page contents were returned on the rejected reads.
Impact: an authorized review of a user-owned application cannot proceed through Browser Use, while the settings UI offers no visible explanation for the effective denial. This report does not establish whether stale conversation state, permission precedence, or another restriction causes it.
Expected: honor the effective permission or clearly identify the overriding restriction and provide a supported recovery action. A saved-user-preference error should correspond to a setting the user can inspect and change.
No company hostname, account details, credentials, screenshots, logs, or conversation transcript are attached. Exact application version was not established for this reproduction. No in-app feedback ID was generated.
I can reproduce the same Browser Use permission-state inconsistency on a newer macOS desktop installation, using the official Chrome extension integration.
Environment
- Installed ChatGPT desktop app:
26.928.20755(build12246), read from application metadata during investigation. - macOS:
26.0.1(build25A362). - Google Chrome:
154.0.8037.98. - Browser surface: Chrome extension; Chrome profile: User 1.
- Account: personal environment, Pro 200 account (confirmed by the account owner).
Permission configuration and scope
I explicitly allowed
https://open.feishu.cnin the desktop app's site-permission settings. This visible allow state is reported by me as the account owner; the assistant did not independently capture or verify the settings screen. It should not be confused with Feishu's own application API permissions.The failed Browser Use request targeted
https://open.feishu.cn/app/<redacted>, under the same origin. The specific Feishu application identifier is omitted because it is unnecessary for diagnosing this issue.Observed behavior
The supported Browser Use API rejected access to an existing tab on this origin. After the browser connection was re-established, the request to create a tab at this origin was also rejected:
await cua.createBrowserTab(browserId, "https://open.feishu.cn/app/<redacted>");
The rejection occurred at the Browser Use permission check, before this request was allowed to open the page. I can manually access the Feishu pages and have supplied screenshots, so the reported failure is distinct from Feishu account or API permission errors.
The complete tool error was preserved and checked against the original local task record:
Browser Use rejected this action due to browser security policy. Reason: A saved user permission setting blocks this action. Browser use cannot access https://open.feishu.cn because the user has a saved preference that blocks it. The agent must not attempt to achieve the same outcome via workaround, indirect execution, raw CDP or browser commands, alternate browser surfaces, or policy circumvention. Proceed only with a materially safer alternative that does not require this blocked browser action; if none exists, stop and request user input.Latest recorded rejection:
2026-10-03T10:58:09.590Z(2026-10-03 18:58:09.590, UTC+08:00).The issue persisted after reconnecting Browser Use. No alternate browser surface, raw CDP, indirect execution, or permission-file changes were used to bypass the rejection. This is an existing-session reproduction, not a clean-install reproduction.
Expected behavior and investigation request
The visible origin-level permission and effective Browser Use decision should agree. If another rule overrides the visible allow state, the UI/error should identify that rule and provide a supported recovery path.
Please investigate which permission source/rule is actually being evaluated and whether there is a supported way to clear or resynchronize the effective saved permission state. The internal cause is not established by this report.
This reproduces the symptoms reported here on
26.928.20755; the original issue reports26.915.31945, and #43754 describes a similar macOS exact-origin mismatch on26.901.51231. These reports support treating this as a permission-state inconsistency bug reported across desktop versions. They do not establish that26.928.20755introduced a version regression or that all reports have the same internal cause.Uploaded feedback
Feedback has now been uploaded from the affected session using
/feedback. The app returned this uploaded thread ID and instructed me to mention it in an existing issue:Uploaded thread:
01a10123-66e8-7e62-bcde-84de1a910266Please correlate this reproduction with the uploaded thread diagnostics.
- Installed ChatGPT desktop app:
Additional affected macOS installation, reported at the user's request. Follow-up diagnostics completed on 2026-10-05 (Asia/Seoul).
Environment
- ChatGPT / Codex desktop app:
26.930.31730, build12947. - macOS
27.0.1, Apple Silicon (arm64). - Browser surface: built-in browser, in an existing conversation.
- Affected origin:
https://appstoreconnect.apple.com.
Observed behavior
The user can manually open App Store Connect. Browser inventory returns the tab title and its
https://appstoreconnect.apple.com/appsURL, but an agent request to read the tab through the supported Browser Use API (domSnapshot()) is rejected:A saved user permission setting blocks this action.
The fuller error attributes the block to a saved user preference for this exact origin. The rejection persisted after the user set the exact site's browsing permission to Always allow, restarted the desktop app, and rebooted the Mac. No fresh approval prompt was offered in these retries.
Read-only diagnostic evidence
The settings screenshot and saved configuration agree on allowing the origin:
- Main user configuration: the exact-origin
browser_use.originsentry hasaccess = "allow"anddownloads = "allow". - Global browser approval configuration:
approval_mode = "never_ask"; the origin is inorigins.allowed;origins.denied = []. - The affected conversation's browser session configuration separately contains this exact origin in
origins.denied.
This establishes conflicting global and conversation-specific saved settings. It is consistent with the saved-permission rejection, but does not establish why the conversation denial was created, why the user-facing change left it present, or the full policy precedence used by the enforcement service. Cloud/MDM policy was not exhaustively audited. This is an existing-conversation reproduction, not a clean-install reproduction.
Requested improvements
- Show the effective permission and its source in the UI and rejection message, distinguishing conversation-specific saved decisions, global settings, and managed restrictions.
- Provide a supported per-site action to revoke a saved conversation denial and request approval again, while preserving conversation history and browser sign-in data and respecting administrator restrictions.
- Make the scope of Always allow explicit and reconcile contradictory saved state when the owner changes permissions; cover this flow across app restart and machine reboot.
The block prevents an authorized App Store Connect workflow from proceeding even at the read-only page-inspection stage. No upload was attempted through the blocked path.
No permission files were modified and no alternate browser, direct-service, or protocol workaround was used to obtain the blocked page. This comment omits account details, local usernames/paths, conversation IDs, credentials, screenshots, and raw logs. No in-app feedback upload ID is available for this report.
- ChatGPT / Codex desktop app:
Also reproduced on macOS 26.5.2 with desktop app 26.930.51102 (build 13100), using the built-in browser.
The affected origin is http://127.0.0.1:5173, a local development server without authentication. Settings show Browsing “Always allow,” and the exact-origin configuration contains access = "allow". Nevertheless, cua.getTab returns “A saved user permission setting blocks this action.”Toggling the browser plugin and restarting the desktop app did not resolve it. A new thread did resolve the issue
Additional reproduction on Linux (Omarchy 4.0.4, x86_64), observed 2026-10-06 in the desktop app's Codex experience.
The affected origin is https://app.netbird.io. The owner can open the NetBird peers page manually. A screenshot supplied by the owner confirms Settings → Browser → Agent permissions shows:
- Default browsing: Always allow
- Default downloads: Always allow
- https://app.netbird.io browsing: Always allow
- https://app.netbird.io downloads: Always allow
Read-only access using the supported browser tool still fails before page content is returned. The exact rejection is:
A saved user permission setting blocks this action. Browser use cannot access https://app.netbird.io because the user has a saved preference that blocks it.
Observed reproduction:
- Open https://app.netbird.io/peers in the in-app browser.
- Set the default and exact-origin browsing permissions to Always allow.
- Ask Codex to inspect the open peers tab.
cua.getTab({ url: "https://app.netbird.io/peers" }, { browser: "iab" })is rejected with the saved-preference error above.- The owner reports removing/reconfiguring the site permission and restarting the desktop app multiple times. The same denial persists.
- After a restart cleared the open tab,
cua.createBrowserTab("iab", "https://app.netbird.io/peers", { visible: true })also returned the same saved-permission rejection.
The Chrome extension subsequently became visible in the browser inventory, but NetBird access through Chrome was not attempted because the denial explicitly prohibited switching browser surfaces as a workaround. No raw CDP, direct browser automation, credential extraction, or permission bypass was attempted.
Expected: honor effective Always allow settings, or identify the actual denying policy and offer a usable approval/recovery path. The visible settings and the denial attributed to a saved user preference currently conflict.
The cause is unknown; this report does not establish stale cache versus another effective policy. App build/version and subscription were not collected. No raw logs, credentials, private fleet inventory, or account identifiers are included. A settings screenshot is available if needed.
Additional macOS reproduction (10 Oct 2026): ChatGPT/Codex desktop app 26.1007.21159 (build 20052), built-in browser, existing Codex conversation.
The user can open their deployed web app manually in the built-in browser. The user set Default Browsing and a site-specific rule to Always allow (screenshots supplied in the conversation), then removed and re-added the exact HTTPS origin after the first failure. A normal supported
cua.getTab({ url: "https://<redacted-cloud-run-host>/" }, { browser: "iab" })retry still fails before page access, with no approval prompt:Browser Use rejected this action due to browser security policy. Reason: A saved user permission setting blocks this action. Browser use cannot access https:// because the user has a saved preference that blocks it.
The tool explicitly prohibits workaround, indirect execution, alternate browser surfaces and policy circumvention, so none were attempted. We have not established the source of the saved denial. This resembles the conversation-scoped stale denial reported in #45237, but that is a hypothesis, not a diagnosis of this case.
Please identify the effective blocking permission source and provide a supported way for the user to clear a stale denial without losing this long-running conversation or weakening other browser restrictions. The current Settings UI reports Allow while enforcement says a saved user preference blocks access.
What version of the Codex App are you using (From “About Codex” dialog)?
26.915.31945
What subscription do you have?
Not confirmed; can provide privately if required.
What platform is your computer?
macOS
What issue are you seeing?
Browser Use cannot read an already-open website tab and returns:
A saved user permission setting blocks this actionThe owner can manually open and sign in to the website. The owner changed both default and site-specific browsing permissions (Always allow and approval-required settings were tried) and restarted the desktop app, but the agent still receives the saved-permission rejection without an approval prompt.
Read-only inspection confirms the exact-origin rule in the local config.toml currently has access = "allow", uploads = "allow", downloads = "allow". We understand that allow does not override other effective policy/approval checks. The actual source of the denial is unknown; stale state, managed policy and a product defect are hypotheses, not established causes. Other sites have remained accessible through the same browser tool.
Please help identify which effective rule produces this rejection and provide a supported recovery path without deleting browsing data or task history.
What steps can reproduce the bug?
Observed reproduction in the affected existing task:
Feedback ID from the in-app report: 01a019f8-e33f-7691-84d5-9c3f7e6104fb.
Reproduced on 2026-09-23. This is an existing-session reproduction, not a clean-install reproduction.
What is the expected behavior?
Either honor the effective permission or show a usable approval prompt. If a higher-priority policy denies access, identify its source clearly and explain the supported way for the owner/administrator to resolve it.
Additional information
The help-center AI could not register an engineering investigation and suggested filing an issue with the feedback ID. Full logs, customer data, local paths and credentials are intentionally omitted. No security-policy bypass was attempted. Please use a private channel if further sensitive diagnostics are needed.