Codex Desktop /goal resume after quota exhaustion leaves old thread stuck on manual approvals while new threads auto-review normally

Resolved 💬 4 comments Opened May 11, 2026 by millionart Closed Jun 10, 2026

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?

  1. Start a Codex Desktop thread using a /goal / goal continuation workflow.
  2. Let the goal run until the 5-hour usage quota is exhausted.
  3. Observe that the UI reports the review/auto-review capability is unavailable or degraded.
  4. Pause the thread and wait for quota recovery.
  5. Resume/continue the same goal thread.
  6. Trigger an action that normally goes through automatic approval review.
  7. Observe that the old resumed thread remains stuck requiring manual approval.
  8. Create a fresh Codex Desktop thread and trigger a comparable low-risk approval request.
  9. 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 /goal behavior 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.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗