Skip to content

Windows: automatic retry after model-capacity error resumes turn but leaves Goal paused #41798

Open

Description

@Chummy26

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.6671.0 (Windows package; running executable product version 151.0.7922.174)

What subscription do you have?

Not included; the issue concerns Goal lifecycle reconciliation after the built-in automatic retry succeeds.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When an active Goal encounters:

Selected model is at capacity. Please try a different model.

Codex starts its built-in automatic retry/backoff. The retry eventually succeeds and the task/turn resumes, but the Goal itself remains paused or stalled instead of being resumed with the turn.

This leaves the lifecycle layers inconsistent:

  • the automatic retry has recovered the model request;
  • the task can briefly continue;
  • the associated Goal is still paused/stagnant;
  • unattended Goal execution therefore does not continue normally.

The capacity error is recoverable, but recovery only restores the turn, not the Goal that owns the long-running work.

What steps can reproduce the bug?

  1. In Codex Desktop, start a long-running task with an active Goal.
  2. Continue until the selected model returns Selected model is at capacity. Please try a different model.
  3. Let Codex use its automatic retry/backoff; do not manually switch models or resume the Goal.
  4. Wait for the automatic retry to succeed and observe the task resume.
  5. Check the Goal lifecycle state and continued execution.

Actual result: the retry resumes the task/turn, but the Goal remains paused/stagnant and does not continue its autonomous loop.

What is the expected behavior?

When automatic retry successfully recovers a model-capacity failure, Codex should atomically restore the complete pre-error lifecycle state:

  • resume the same turn/task;
  • transition the associated Goal back to active;
  • continue the Goal loop from its preserved context without manual intervention.

If Codex cannot safely resume the Goal, it should keep both the turn and Goal paused and show an explicit actionable reason, rather than partially resuming only the turn.

Additional information

This is narrower than the existing capacity reports:

Suggested regression test:

active Goal + active turn
  -> server_overloaded / model at capacity
  -> automatic retry succeeds
  -> same turn active
  -> same Goal active
  -> Goal loop continues without manual resume

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Aug 31, 2026
  2. marc-caramello commented on Aug 31, 2026

    @marc-caramello

    I've ran into this same issue as well. I agree with your suggestion. I would prefer if the goal wasn't paused in this circumstance. I feel like this should definitely be fixed. Because, when the model is usable again, then it should automatically continue running. Exponential backoff retry would be very useful here.

  3. Ang3Lnet commented on Aug 31, 2026

    @Ang3Lnet

    me too

  4. pokeQAAQ commented on Aug 31, 2026

    @pokeQAAQ

    This phenomenon is becoming increasingly frequent since the update

  5. 997sama commented on Sep 2, 2026

    @997sama

    me too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions