Repository navigation
Desktop app: permission prompts auto-declined and saved as user choices (browser site block); Messages approvals silently declined in Full access #45237
Description
Activity
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Windows evidence: conversation-scoped denial still overrides a later global Allow
This report adds Windows evidence for Bug 1 in this issue, from a later desktop/browser-plugin version. We independently traced the ongoing denial to the persisted conversation setting. We have not established who or what produced the initial decline in our case, so this is not independent confirmation of the auto-decline mechanism.
Environment
- Windows desktop, x64.
- Installed Windows package:
OpenAI.Codex 26.924.2738.0(ChatGPT.exe). - Bundled Browser / Unified Computer Use plugin:
26.924.22138. - Affected origin:
http://127.0.0.1:8766(a local development service). - Incident date: 2026-09-28. Times below are UTC.
Observed sequence
- At 05:03:15, the desktop log recorded
dom-readyfor the localhost page in the affected task. - At 05:11:55, that task called:
await cua.createBrowserTab('iab', 'http://127.0.0.1:8766/', {visible: false});
- At 05:11:58, the tool returned
The user declined permission for this action.The conversation permission file's modification time matches this event. - The user subsequently allowed the exact HTTP origin in normal Settings. By 09:16:31, both global permission stores reflected that allowance.
- A normal retry in the same task at approximately 09:20 still failed with
A saved user permission setting blocks this action.
This sequence is reconstructed from existing tool receipts, desktop logs, and configuration/code inspection. No additional page access was attempted during the diagnosis.
Effective conflicting configuration
$CODEX_HOME/browser/sessions/<thread-id>.tomlstill contained:[origins] denied = ["http://127.0.0.1:8766"]
Meanwhile,
$CODEX_HOME/browser/config.tomlcontained:[origins] allowed = ["https://127.0.0.1:8766", "http://127.0.0.1:8766"] denied = []
And
$CODEX_HOME/config.tomlcontained:[browser_use.origins."http://127.0.0.1:8766"] access = "allow" downloads = "allow" uploads = "allow"
We verified that the default user
.codexlocation andCODEX_HOMEresolve to the same directory through a junction; this was not a second-profile mix-up. An earlier HTTP/HTTPS mismatch had also already been corrected.Installed evaluator evidence
Read-only inspection of the shipped
browser/26.924.22138/scripts/browser-service.mjsshows:maybeAutoAnswerBrowserUseRequest(minified line 4379) readsthis.config.session(e.preferenceSessionId)and, when that session'sdeniedlist matches the origin, returns a conversation-scoped denial before the global approval branch. The returned source isbrowser-use-persisted-state.Ht(line 1075) maps that source topersisted_user_denied.- The error mapping (line 1007) renders it as
A saved user permission setting blocks this action.
This directly explains the continuing block. The request was stopped by Browser Use before the target application's authentication or business logic; changing the application's permissions would not address it.
Expected recovery and diagnostics
- Surface the effective conversation-scoped decision and its conflict with the global Allow in the permission UI.
- Provide a supported, user-controlled way to inspect and revoke that specific conversation denial.
- When setting a global Allow, explain any conversation denials that remain effective and offer an explicit scoped choice. Deny precedence may be intentional; this report does not request silently weakening other denials or managed policy.
- Include the effective scope/source in the error, rather than leaving users to repeatedly change the global website list.
- Preserve the actual reviewer/decision provenance. In our case the first tool receipt says
user_declined, but we did not obtain the original approval actor metadata and cannot attribute it to a human click, interruption, or automatic reviewer.
The Settings pages inspected by the user did not expose this conversation record or a way to revoke it. This blocked an explicitly authorized localhost UI test and caused troubleshooting at the wrong permission layer.
Only sanitized configuration excerpts and diagnostic findings are included here; no credentials, private task IDs, application data, or full logs are attached. The permission files were not altered during this diagnosis.
Additional Windows reproduction on 2026-10-03: clearing browser data and restarting the app did not remove the conversation-scoped block.
Environment: Windows; Codex desktop app 26.930.31730, build 12947 (last checked by the app updater). Affected origin: http://127.0.0.1:8016.
Read-only inspection found:
Global file,
$CODEX_HOME/browser/config.toml:[origins] allowed = ["http://127.0.0.1:8016"] denied = []
Conversation file,
$CODEX_HOME/browser/sessions/<conversation-id>.toml:[origins] denied = ["http://127.0.0.1:8016"]
The user reports no corresponding blocked-site entry in Settings. After the user cleared browsing data/cookies and restarted the app, a normal retry to the same origin still returned: "A saved user permission setting blocks this action." Both configuration states above remained unchanged. The permission files were not edited during diagnosis.
The origin had been used for an earlier acceptance-testing batch. We have not established who or what created the initial denial; this is evidence of the persisted conflict and failed UI recovery, not proof of the auto-decline mechanism. We also have no evidence that a subscription tier caused it.
Please provide a supported way to inspect and reset this specific conversation-level decision in the app, expose the effective permission scope/source in the error, and identify whether an official fix is available for this Windows build. The user has moved publication ahead while explicitly leaving browser interaction acceptance pending.
No credentials, private project URLs, conversation identifiers, or full logs are included.
Codex app bug report (draft for OpenAI)
Summary: In the Codex desktop app, permission prompts can be answered "declined" by the app itself, and the result is then treated as the user's choice. Two cases: (1) a website prompt in the built-in browser was auto-declined and saved permanently for that conversation, with no way to see or undo it in Settings; (2) in Full access mode, Messages read and send approvals are auto-declined with no card shown, and the plug-in instructs the model not to tell the user how to fix it.
Environment
Bug 1: a website prompt auto-declined and saved as a permanent conversation block
Steps observed (2026-09-08, two separate conversations, both started from the ChatGPT iOS app's Codex remote, both in "Approve for me" mode with helper threads running):
cua.createBrowserTab('iab','https://chatgpt.com').user_declined, decision sourceuser_decision). No prompt was visible to the user, who was typing in another app on the Mac at that moment; nobody answered a prompt in half a second.~/.codex/browser/sessions/<conversation>.tomlwas written with[origins] denied = ["https://chatgpt.com"].persisted_user_denied).Likely mechanism (from the app bundle): the desktop app's turn-interrupt routine replies "decline" to every pending request in the conversation (command approvals, file-change approvals, permissions, user input, option pickers, and
mcpServer/elicitation/request). The browser service then persists a declined origin prompt as a conversation-scoped user decision. In Full access mode the same origin prompts are auto-accepted (the app's elicitation handler auto-acceptsaccess_browser_originwhen approval policy is never and the sandbox is full access), so the failure only appears in Ask / Approve-for-me conversations.Expected: a decline produced by an interrupt should resolve that one request only, never be persisted as a user preference; the error text should not say "the user declined". Conversation-level site decisions should be visible and removable in Settings, and a global "Always allow" should override, or at least surface, a conversation-level block.
Workaround found: empty the
deniedlist in the conversation's browser file (takes effect without restart), or start a new conversation.Bug 2: Messages read/send approvals silently declined in Full access; model told not to explain
Steps observed (2026-09-11, two conversations in Full access):
mcp__messages__search_messages. 0.6 s later the plug-in returnspermission_filtered: truewith: "Read access was not approved. No content was returned. Do not ask the user to approve access or retry. Do not fall back to Computer Use or other tools..."approval_policy=Neverand no elicitation. Codex tells the user the results were withheld and stops.any;-;<email>), while the model searched by phone number; it is unclear whether an allow on one handle covers the other spelling of the same chat.Mechanism: the Codex core rejects plug-in approvals under approval policy never ("MCP tool call requires approval, but approval policy is never"). The helper's own send text acknowledges this ("If the task's current approval_policy is confirmed to be never ... suggest switching the task to Ask for approval or Approve for me"), but the read text forbids any explanation.
Expected: in Full access, either show the read/send card anyway (as the app already does for website access), or return a message that names the fix (Settings → Computer use → Messages → Read access), and allow adding send permissions from Settings.
Related observation
"Browser is not available: iab" from the built-in browser on 09-08 (2), 09-09 (11), 09-10 (9), always early in the day, cleared by quitting and reopening the app. Both auto-declines in Bug 1 happened while the browser service process was starting (fresh
initializeon its app-server connection at the same second).Impact
Two work conversations lost browser access to key sites for three days; Messages lookups fail silently in the default Full access mode; the user was told the wrong party (himself) had declined.
Personal identifiers (names, numbers, addresses) removed from this draft. Local evidence: rollout files under ~/.codex/sessions, the app log store ~/.codex/logs_2.sqlite, and the helper store under ~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService.