Desktop app: permission prompts auto-declined and saved as user choices (browser site block); Messages approvals silently declined in Full access

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):

1. Conversation A asked Codex to search ChatGPT history; Codex called cua.createBrowserTab('iab','https://chatgpt.com').
2. 0.55 s later the tool returned: "Browser Use rejected this action due to browser security policy. Reason: The user declined permission for this action." (reason code user_declined, decision source user_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.
3. At the same second the file ~/.codex/browser/sessions/<conversation>.toml was written with [origins] denied = ["https://chatgpt.com"].
4. Every later attempt in that conversation, in the built-in browser and in Chrome, returned "A saved user permission setting blocks this action ... the user has a saved preference that blocks it" (persisted_user_denied).
5. Adding chatgpt.com under Settings → Browser use → Site permissions (global allow) did not help: the conversation-level record is checked first. Settings shows the site as allowed while the tool reports it blocked.
6. Same sequence in conversation B for www.cvs.com (0.61 s), and an older conversation from 2026-08-27 for mail.google.com.

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-accepts access_browser_origin when 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 denied list 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):

1. User asks Codex to find a text in a specific Messages chat.
2. Codex calls mcp__messages__search_messages. 0.6 s later the plug-in returns permission_filtered: true with: "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..."
3. No approval card appears. The app-server log shows the call tagged approval_policy=Never and no elicitation. Codex tells the user the results were withheld and stops.
4. Before the 2026-09-09 helper update, reads needed no approval and worked in Full access (2026-08-29) and other modes (08-21, 08-31, 09-10).
5. The new Settings → Computer use → Messages → "Read access" list (Always allow / Always ask / Never allow) exists, but nothing in the conversation points the user to it. Send permissions ("Always allowed to send") have no Add control at all; a number can only be added by answering a live send card with "Always allow", which cannot appear in Full access.
6. Follow-up test on 2026-09-13: with the conversation switched to "Approve for me", a send to a chat that is NOT on the "Always allowed to send" list went through with no card shown to the user at all, so the reviewer agent approved an outbound text on its own; the number was not added to the list.
7. The Read access entry is stored under the contact's iMessage address (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 initialize on 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.

Start by reproducing both approval paths while tracing the app-server approval_policy handling, the desktop turn-interrupt routine, and the browser elicitation handler. Inspect ~/.codex/browser/sessions/.toml and the Messages helper behavior described in the report. Done means interrupts do not create persistent user decisions, Full access does not silently suppress Messages approvals, and users receive an actionable permission state.