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:
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.
What version of the Codex App are you using (From “About Codex” dialog)?
Observed in local logs as:
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
/goalthread 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?
/goal/ goal continuation workflow.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
/goalthread 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:
/goalbehavior around quota exhaustion.Privacy-preserving local evidence, summarized from logs without raw log/database upload:
One warning was also present during resume, likely unrelated but included for completeness:
No raw local paths, usernames, project names, auth data, or full logs are included here.