[Desktop] After restart, Full Access session occasionally reverts to per-action approval and cannot be recovered — breaks long autonomous agent runs

Open 💬 5 comments Opened Jul 21, 2026 by felix021

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

ChatGPT Desktop (macOS), "Powered by Codex & OWL", Version 26.715.52143 (Released Jul 20, 2026)

What subscription do you have?

ChatGPT Pro ($200/month plan)

What platform is your computer?

Apple M2 MacBook, macOS 14.8.5 (Build 23J423)

What issue are you seeing?

After fully quitting and relaunching ChatGPT Desktop, there is a chance that a session previously set to Full Access comes back with its permission level reverted to Ask for approval, and from that point the session's permission level is stuck — no matter what I do in the UI (switching to another level and back to Full Access, using /permissions, etc.), I cannot switch it back to Full Access. As a result, in that session the agent asks for manual approval on every single action, so it can no longer work fully autonomously for long stretches — which is exactly the workflow I enabled Full Access for in the first place.

Once a session enters this state it cannot be recovered; I have to manually save the context/progress, start a new session, and re-grant Full Access. This has happened several times across recent versions. It tends to occur with long-running tasks, but I have not found a deterministic reproduction.

Steps to reproduce

In ChatGPT Desktop, set a Codex session to Full Access and let it run autonomously for a while.
Fully quit the app (Cmd+Q) and relaunch it.
Reopen the same Full Access session.
(Triggered with some probability) The permission level now shows Ask for approval, and the agent starts requesting manual approval for every command / file change.
Try switching the permission to another level and back to Full Access, or use /permissions — none of these switch it back to Full Access; the session stays at the approval-required level.
Only starting a new session and re-granting Full Access restores normal behavior; the old session cannot be recovered.

Note: non-deterministic, intermittent; no stable reproduction found; observed more often with long-running tasks.

Expected behavior

After restart, the previously granted permission level (Full Access) should be preserved.
Even if it reverts, it should be possible to switch the permission back to Full Access within the same session and have it take effect immediately, rather than the level being stuck.

Actual behavior

After restart, the session's permission level reverts to Ask for approval.
The session's permission level is stuck and cannot be switched back to Full Access, so the agent cannot run autonomously for long periods; the session must be abandoned and a new one started.

Workarounds attempted (none worked for the affected session; only a new session works)

Switching the permission to another level and back to Full Access in the UI
Using /permissions to reset

Additional context / Related issues

Parts of this are covered by existing issues, but none of them captures the full combination seen here — "triggered by restart" + "the session's permission level is stuck and cannot be switched back to Full Access" — and none reports it on the current version:

#24036 — global permission mode resets to Default after restart, but there the user can still change it back per-session. My case: the per-session level is stuck and cannot be switched back to Full Access.
#19006 — the permissions button gets stuck in a frozen state and the level cannot be changed. Similar "cannot change" symptom, but not tied to a restart trigger, and the control is fully uninteractable.
#33114 — upgrading to Full Access does not take effect during an active session. Similar "change does not apply", but about upgrading mid-session, not a restart-triggered revert.
#28988 / #23393 — Full Access still repeatedly asks for permission. Similar "asks for approval", but those are usually recoverable by toggling.

Local info

Earliest version where I noticed this: not recorded
Thread id of an affected session: not retained

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#33886

Powered by Codex Action

felix021 · 1 month ago

Thanks for the triage. The bot flagged #33886 as a potential duplicate — I read it and it does look like the same root cause: a long-running Goal/thread gets its permission reverted from Full Access to on-request and then can't be switched back, on the same 26.715.x Desktop version family.

The difference is the trigger:

#33886: triggered by switching ChatGPT accounts and resuming the thread.
This issue (#34453): triggered by a plain app restart (quit + relaunch), with no account switch.

Since most users never switch accounts but everyone restarts, I think the restart-only path is worth tracking on its own — but happy to merge/close and follow under #33886 if the maintainers prefer.

One caveat on my end: I don't have the ThreadSettings writeback telemetry or a thread id for an affected session (unlike #33886's detailed timeline).

felix021 · 1 month ago

I found a concrete affected thread and inspected its local rollout plus Desktop logs.

Affected thread

019f5f3c-5a5f-7720-b8ec-f3cf5377ae2f

Environment:

ChatGPT Desktop: 26.715.52143 (build 5591)
Bundled Codex CLI at the restart boundary: 0.145.0-alpha.18
No account switch at this boundary: auth.json had not changed since July 13, and the July 21 Desktop log contains no account-switch/login/logout event.

Timeline

All timestamps below are Asia/Singapore on 2026-07-21.

08:43:15  Existing long-running turn starts with:
          approval_policy=never
          sandbox_policy=danger-full-access
          permission_profile=disabled

09:02:04  Desktop launches and starts a new app-server process.

09:02:21  thread/resume completes. The Desktop derives:
          approvalPolicy=on-request
          sandboxPolicy=workspaceWrite
          hasCurrentPermissions=false
          hasExplicitPermissions=false
          hasLatestThreadSettings=false
          hasLatestTurnParams=false
          approvalPolicySource=default
          sandboxPolicySource=default

09:02:23  A new Goal turn actually starts with:
          approval_policy=on-request
          sandbox_policy=workspace-write
          permission_profile=managed

09:20-09:42
          The affected Goal surfaces at least:
          - 3 file-change approval requests
          - 4 command-execution approval requests

10:14:48  Reopening/resuming the thread still resolves from thread_settings to:
          approvalPolicy=on-request
          sandboxPolicy=workspaceWrite

10:16:56  The older pre-restart interrupted turn resumes with:
          approval_policy=never
          sandbox_policy=danger-full-access

11:24:02  Another thread/resume still resolves the persisted thread settings as:
          approvalPolicy=on-request
          sandboxPolicy=workspaceWrite

The current persisted heartbeat state for this thread is also:

activePermissionProfile: null
approvalPolicy: on-request
approvalsReviewer: user
sandboxPolicy: workspaceWrite

The last successful thread_settings_applied event before this restart was still Full Access (never + :danger-full-access). I found no successful Full Access settings writeback for this thread after the restart.

An additional signal is the split state at 10:16: the older interrupted Goal turn retained never/danger-full-access, while the Desktop's persisted per-thread state remained on-request/workspaceWrite. This looks consistent with stale or missing permission state across the thread/Goal resume boundary, similar to the state divergence described in #33886.

One limitation: the available logs do not contain click-level telemetry, so they cannot prove whether a particular Full Access UI toggle was attempted and dropped. They do confirm the restart-triggered Full Access → on-request transition, the resulting repeated approvals, and the restricted state persisting across subsequent resumes.

lx32056127 · 26 days ago

I can reproduce the same permission-state divergence on Windows, with a newer Desktop build, and with an abnormal/interrupted long-running turn as the trigger (no account switch required).

Environment

ChatGPT Desktop for Windows: 26.721.41059
Bundled Codex CLI: 0.146.0-alpha.3.1
Affected thread: 019fb7b4-9b3d-7910-845b-e0fa85951f00

Local rollout evidence

The affected thread ran with Full Access for many hours. The last snapshots before the abnormal interruption were:

2026-08-01 16:59:32  thread_settings_applied  approval_policy=never
2026-08-01 16:59:32  turn_context             approval_policy=never
                                               sandbox_policy=danger-full-access
                                               permission_profile=disabled
2026-08-01 18:15:47  same running turn        approval_policy=never
                                               sandbox_policy=danger-full-access
                                               permission_profile=disabled

There is no subsequent task_complete or turn_aborted event for that turn. When the same thread was continued later, Desktop applied restricted settings:

2026-08-02 00:24:41  thread_settings_applied  approval_policy=on-request
                                               permission_profile=managed/restricted
2026-08-02 00:24:42  turn_context             approval_policy=on-request
                                               sandbox_policy=read-only
                                               permission_profile=managed
2026-08-02 00:35:33  same continued turn      approval_policy=on-request
                                               sandbox_policy=read-only
                                               permission_profile=managed

After manually selecting Full Access again, the log changed back at 00:45:15 to approval_policy=never with the disabled/unrestricted legacy profile.

This extends the report in two ways:

It also occurs on Windows and remains present in Desktop 26.721.41059.
A plain abnormal turn interruption/failure followed by continuing the same thread is sufficient; an app restart or account switch is not the only trigger.

As a local mitigation I changed the persistent Codex config to the current permission-profile form:

approval_policy = "never"
default_permissions = ":danger-full-access"

and removed the legacy sandbox_mode key because the current permissions documentation says not to mix default_permissions with the older sandbox settings. This validates with codex --strict-config, but it cannot repair the already-diverged per-thread state, so the resume/writeback path still appears to need a product fix.

Pzixel · 24 days ago

I have this. This is what agent told me to do:

To re-enable it without losing this task:
Press Stop on the current run.
Select Full access beneath the composer.
Send “continue the active goal” in this same task.

It worked.