›_ Codex Issues
Codex Issues / #21839

Previously-existing sessions with full access require approvals

Open 💬 13 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 ↗

13 Comments

andrewneilson · 2 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 · 2 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 · 2 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 · 2 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 · 1 month 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 · 1 month ago

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

andrewneilson · 1 month ago

Still not fixed in 26.527.60818 (3437) 😞

tecrov · 1 month 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 · 1 month ago

Still not fixed in 26.611.62324 (released today)

andrewneilson · 22 days ago

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

blackjackparis · 7 days 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 · 3 days ago

still not fixed in ChatGPT Version 26.715.21425

andrewneilson · 2 days ago

Still an issue on Version 26.715.31925