Codex Desktop /goal resume after quota exhaustion leaves old thread stuck on manual approvals while new threads auto-review normally
What version of the Codex App are you using (From “About Codex” dialog)?
Observed in local logs as:
app_server.client_name="Codex Desktop"
app_server.client_version="26.506.31421"
What subscription do you have?
No response
What platform is your computer?
Windows 10 x64, Codex Desktop app.
What issue are you seeing?
A long-running /goal thread hit the 5-hour usage quota. At that point the UI indicated that the review/auto-review capability was unavailable. After pausing, waiting for quota recovery, and continuing the same goal thread, that old/resumed thread stayed stuck on manual approvals: commands that should normally go through automatic approval review kept requiring explicit user approval.
Switching the thread to full access did not restore automatic approval behavior for that thread. Creating a new Codex Desktop conversation did restore normal behavior: a low-risk escalated command in a fresh thread was allowed without the same stuck manual approval behavior.
This appears thread/session scoped rather than global: the affected resumed goal thread remains broken, while a newly created thread works normally.
What steps can reproduce the bug?
- Start a Codex Desktop thread using a
/goal/ goal continuation workflow. - Let the goal run until the 5-hour usage quota is exhausted.
- Observe that the UI reports the review/auto-review capability is unavailable or degraded.
- Pause the thread and wait for quota recovery.
- Resume/continue the same goal thread.
- Trigger an action that normally goes through automatic approval review.
- Observe that the old resumed thread remains stuck requiring manual approval.
- Create a fresh Codex Desktop thread and trigger a comparable low-risk approval request.
- Observe that the fresh thread's approval/auto-review path works normally.
What is the expected behavior?
After quota recovery and thread resume, the old goal thread should restore the same approval reviewer behavior as a fresh thread, or explicitly reinitialize/re-negotiate the reviewer state.
If auto-review is unavailable during quota exhaustion, that degraded state should not persist indefinitely after quota recovery for only the resumed thread.
What do you see instead?
The old resumed /goal thread continues to require manual approval even after quota recovery and even after changing access mode, while newly created threads can use the normal approval/auto-review path.
Additional information
Related but not exact duplicates:
- #18522 covers old/resumed Codex Desktop threads having stale approval/authorization state while new threads work.
- #21536 covers
/goalbehavior around quota exhaustion. - #21975 discusses fallback behavior for auto-review deny/abort, but this report is about the reviewer path apparently not recovering in a resumed goal thread after quota exhaustion.
Privacy-preserving local evidence, summarized from logs without raw log/database upload:
Affected old thread:
- app_server client: Codex Desktop 26.506.31421
- thread/resume events observed: 3
- thread/goal/set events observed: 106
- ExecApproval submissions observed after resume: 17
- PatchApproval submissions observed after resume: 3
- ApprovedForSession decisions observed: 15
- ApprovedExecpolicyAmendment decisions observed: 5
- autoApprovalReview / auto_review log events for affected thread: 0
Fresh replacement thread:
- created after the issue was observed
- did not reproduce the stuck manual-approval behavior in a low-risk approval test
One warning was also present during resume, likely unrelated but included for completeness:
thread/resume ... shell_snapshot: Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell
No raw local paths, usernames, project names, auth data, or full logs are included here.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗