Repository navigation
Codex App of Windows: Custom "Never ask" mode breaks Chrome origin approval flow and incorrectly persists new sites as denied #22019
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.506.31421
What subscription do you have?
plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
When Codex is running in a custom mode configured to never ask for permission, @Chrome fails to surface the browser-origin access prompt for a new website. Instead of pausing for approval, the Chrome/Browser Use flow treats the result as a non-accept response, interprets it as if the user explicitly denied access, and persists the site into the thread-level denied list. After that, all later attempts to access the same origin in the same thread are rejected immediately without prompting again.
What steps can reproduce the bug?
- Enable a custom mode configured to never ask for permissions.
- Start a new Codex thread.
- Run
@Chrome open https://example.comwith a domain that has not been accessed in that thread before. - Observe that no browser-origin approval prompt is shown.
- Retry the same command in the same thread.
- Observe that access is immediately rejected as if the user had denied it.
Evidence
A thread session file is created/updated under the browser sessions directory and the origin is persisted in denied, for example:
xxxxxx.toml
[origins]
denied = ["https://example.com"]
What is the expected behavior?
When @Chrome accesses a new origin, Codex should either:
- show a browser access approval prompt, or
- if prompts are suppressed by mode, avoid converting the lack of prompt into a persisted user denial.
A site should only be written todeniedif the user explicitly rejects access.
Additional information
Root cause hypothesis
The custom “never ask” mode appears to suppress or short-circuit the frontend approval UI for access_browser_origin, and the backend/plugin interprets the missing approval as a denial instead of as “no explicit user decision.”
One-line version
Custom mode breaks Chrome origin approval flow: the browser access prompt is not surfaced or not returned as accept, so Browser Use persists the origin as denied in the thread session state.
Activity
pych-ky commentedon Aug 28, 2026
I can reproduce this on macOS with ChatGPT/Codex Desktop 26.820.60940 and the official Chrome extension.
Even with website access set to “Allow for all sites,” the first read attempt for a new origin can be treated as a decline and persisted in the thread-level
[origins].deniedlist. Subsequent attempts in the same thread are then rejected immediately without showing a new permission prompt.I reproduced this across multiple unrelated origins. Reinstalling the extension/plugin did not clear the persisted denied state.
julianbarron-lgtm commentedon Sep 7, 2026
We are seeing a closely matching persistent-origin-denial problem on Windows desktop package 26.901.5280.0 (internal app 26.901.41600, CLI 0.153.4).
Feedback/session ID:
01a0738f-6484-7c01-80bc-373205f6f4d9. The feedback/upload RPC completed without an RPC error on 2026-09-07 at 14:53:36.647 UTC; the user reported the UI as uploaded. We do not have a support-case number.The current task resolves
approval_policy=neverandapprovalsReviewer=user. Global browser settings now useapproval_mode=never_askanddownload_approval_mode=never_ask, with explicit allows for CONAGUA, INEGI and SEMARNAT and no global denials. However, six HTTPS origins remain in the conversation-specificorigins.deniedlist. Read-only inspection of the installed browser service shows that the conversation deny is checked before the global allow. Restarts and changing global permissions did not remove those records.A normal request to help.openai.com returned a user-denied result in approximately 0.640 seconds and persisted that origin. We cannot establish whether a human, the noninteractive policy, or another component emitted the initial decline. A later ordinary Browser Use navigation to github.com succeeded in this same conversation. Thus the browser is not wholly unable to access the network; the saved denials remain the specific recovery problem.
Could you provide a supported way to review and revoke this conversation's stale origin denials, retaining its history and files? Also, can you confirm whether switching to interactive approvals prevents new automatic denials in this version? We have not tested that hypothesis or manually altered the permission records.
The affected origins are geomatica.semarnat.gob.mx, www.inegi.org.mx, datos.conagua.gob.mx, persistent.oaistatic.com, sigagis.conagua.gob.mx and help.openai.com.