›_ Codex Issues
Codex Issues / #21839

Previously-existing sessions with full access require approvals

Open 💬 17 comments Opened May 8, 2026 by andrewneilson

What version of the Codex App are you using (From “About Codex” dialog)?

First appeared in 26.506.31004 (2604)
Still occurring in 26.513.31313 (2867)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

After the 26.506.31004 (2604) update, the in-progress sessions I had that were set to either full access or auto-approve enabled are now requiring approval for many actions. I can't say if it's for everything, but examples are curl, psql, and git switch commands.

This also occurs if the app restarts for any other reason.

I've tried switching the permissions back and forth to no effect.

This was an extremely noticeable change.

<img width="211" height="54" alt="Image" src="https://github.com/user-attachments/assets/7a074ffa-40ea-4e5f-a0f6-47c3f3c37c06" />

<img width="478" height="170" alt="Image" src="https://github.com/user-attachments/assets/6ac8a5e8-7860-4fdb-b788-e4fdcf8d42d0" />

<img width="286" height="102" alt="Image" src="https://github.com/user-attachments/assets/dd2a2e76-f161-446b-8a11-f235f319eaaf" />

<img width="640" height="264" alt="Image" src="https://github.com/user-attachments/assets/fe784470-634e-46e8-9daa-91223a447c1c" />

What steps can reproduce the bug?

I haven't taken an exhaustive look at this, but it's been inconsistent. So far, this is occurring in one pre-existing "full access" session from before the update as well as a session I forked off of that one that also has "full access".

This also occurred after codex restarted following a crash in the middle of a bunch of parallel sessions.

What is the expected behavior?

Full access means no need to approve actions.

Additional information

I wish I had more info. If you have ideas of other things I can look at then let me know.

View original on GitHub ↗

17 Comments

andrewneilson · 3 months ago

This is either fixed in 26.506.31421 (2620) or it was a transient issue affecting only some of my sessions. I'll reopen if it comes back.

blixt · 3 months ago

This is happening to me a lot in Version 26.506.31421 (2620) for a session I've had running in yolo mode for over 50 hours. Updated today and now it just keeps asking for everything over and over, including git add etc. effectively killing my long running goal session.

andrewneilson · 3 months ago

This is still a problem on 26.513.31313 (2867). Now it's after I restarted codex due to a crash I'm having to approve everything.

andrewneilson · 3 months ago

There may have been an update here in 26.513.31313 (2867). I had a session with this problem again that started showing Custom access instead of "Full Access" and I was able to switch it 🤞

<img width="197" height="37" alt="Image" src="https://github.com/user-attachments/assets/b4c20891-33d1-40b3-bb0f-09490ece223c" />

fragmede · 3 months ago

This is happening to me on Codex Version 26.519.41501 (3044), M4 max. macOS 15.7.6.
Had a conversation with full permissions, upgraded codex, resumed conversation, that conversation behaves like it is in default permissions, no matter which permission mode is selected.
The conversation had remote control enabled. I also tried changing permissions mode on my phone. Did not affect getting prompted.

andrewneilson · 3 months ago

didn't happen today despite I think 2-3 codex crashes throughout the day (unrelated 😅 ). Maybe fixed?

andrewneilson · 2 months ago

Still not fixed in 26.527.60818 (3437) 😞

tecrov · 2 months ago

Still is not fixed in Version 26.602.30954
Feedback ID: 019e810c-8717-7ac3-9770-1007c039c2d0
This has happened about 100 times today.
Note that I am using a Chat, not a project in Codex. It worked fine for days, but, I think, yesterday, it started asking for approvals. It is writing code, etc. I have another Chat (not a project) that is doing similar work and does not ask me for approvals at all.

andrewneilson · 2 months ago

Still not fixed in 26.611.62324 (released today)

andrewneilson · 2 months ago

Still not fixed in Version 26.623.42026 • Released Jun 26, 2026

blackjackparis · 1 month ago

Still reproducible in the ChatGPT desktop app 26.707.62119 (build 5211), bundled Codex CLI 0.144.2, on macOS 26.5.1 (25F80).

This occurred after restarting the app and resuming an existing long-running objective. The composer showed Full access, but the active goal turn retained its older workspace-write / on-request runtime context and repeatedly requested approval for writes under ~/.codex/skills/.

The rollout contains a direct mismatch:

  • 2026-07-13T20:51:18.323Z, thread_settings_applied:
  • approval_policy=never
  • active_permission_profile=:danger-full-access
  • 2026-07-13T20:54:42.114Z, later context for the same active turn:
  • approval_policy=on-request
  • sandbox_policy=workspace-write

Uploaded session / thread ID: 019f51af-a4af-7cf1-a9d5-c5e80ebeabee
Affected turn ID: 2504c7df-8a8d-4ffd-9237-b7b26d8acd2f

The in-app feedback/upload request for this session completed successfully without an error.

This looks like the desktop restart/resume variant of the stale goal permission context described in #22090. That issue is closed, but the behavior remains reproducible in this newer desktop build. The current workaround is to stop/pause the objective and start a fresh runtime turn after selecting Full access.

andrewneilson · 1 month ago

still not fixed in ChatGPT Version 26.715.21425

andrewneilson · 1 month ago

Still an issue on Version 26.715.31925

andybergon · 1 month ago

Confirmed another variant on macOS in an existing Codex Desktop task.

  1. The task had previously completed under Full Access. Eight recorded turn contexts used approval_policy=never with sandbox_policy=danger-full-access.
  2. The same task was later resumed through a delegated turn without an intentional permission change.
  3. Its first two resumed turn contexts instead used approval_policy=on-request with sandbox_policy=workspace-write.
  4. A linked-worktree rebase then produced approval prompts for routine Git commands, including rebase, add, and checkout.
  5. These were not agent clarification requests. The run made no request_user_input calls and resolved four additive conflicts without asking the user to choose conflict semantics.

The prompts later became less frequent, but the persisted task state remained on-request with a managed sandbox. The apparent recovery therefore was not a verified restoration of Full Access.

This looks like stale permission context on resume rather than rebase-specific behavior. Related current reports include #34453 and #33886.

andrewneilson · 20 days ago

This is STILL a problem in Version 26.730.61639

Dude 😭

mattLummus · 8 days ago

+1 still occurring

ckgresla · 3 days ago

Still occurring