Why Does Codex Stop Before Long Tasks Are Finished?

One of my biggest frustrations with Codex used to be its handling of long-running tasks. It would make some progress, then stop before the job was finished.

For example, while building the Visual Style Atlas, I asked it to generate examples in more than 140 visual styles.

This should have run without any manual intervention. Instead, Codex would generate a few images, stop, and send a progress update. Even after I repeatedly told it, “Don’t stop or report back. Keep going until every example has been generated,” it still stopped.

I had to keep replying “continue” to get the work moving again. It was a frustrating experience, and there was not much I could do about it.

There are plenty of GitHub issues describing the same problem:

• GitHub Issue #13950: A developer asked Codex to coordinate 200 sub-agent tasks, with at most five running at once. In many runs, Codex stopped after completing only about 10 of the 200 tasks and returned a progress report.
• GitHub Issue #36596: Another developer described an even stranger case. Codex knew there was still work left, knew what the next step could be, and knew that it did not need more user input. The user had explicitly asked it not to stop after commits, tests, or intermediate milestones. Yet Codex kept producing final answers anyway.

For a long time, I took this as evidence that Codex simply was not smart enough.

Codex’s engineering answer to this problem is Goals.

Goals in Codex

#

In May 2026, OpenAI published Using Goals in Codex, which explains Goals and contrasts them with ordinary prompts.

An ordinary prompt handles the immediate request, returns a result, and waits for the next instruction. A Goal, by contrast, keeps a defined objective active until the available evidence shows that the task is complete.

At a high level, the flow looks like this:

flowchart TD
    A["User creates /goal"] --> B["Goal runtime"]
    B --> C["Create and persist thread Goal"]
    C --> D["Start turn 1"]

    subgraph REACT["Inside a turn: ReAct loop"]
        direction TB
        D --> E["Model reasoning"]
        E --> F{"Choose next action"}
        F -->|"Tool call"| G["Run tool"]
        G --> H["Observation"]
        H --> E
        F -->|"Final answer"| I["Current turn ends"]
    end

    I --> J["Goal dispatcher"]
    J --> K{"Goal still active
and may continue?"}
    K -->|"No"| L["Stop automatic continuation / wait"]
    K -->|"Yes"| M["Generate continuation prompt"]
    M --> N["start_turn_if_idle"]
    N --> O["Start the next turn"]
    O --> E

    classDef goal fill:#DBEAFE,stroke:#60A5FA,color:#1E40AF
    classDef agent fill:#D1FAE5,stroke:#34D399,color:#065F46
    classDef decision fill:#FEF3C7,stroke:#FBBF24,color:#92400E
    classDef stop fill:#FEE2E2,stroke:#F87171,color:#991B1B

    class A,B,C,D,J,M,N,O goal
    class E,G,H agent
    class F,K decision
    class I,L stop

In practical terms:

• In prompt mode, the model runs a ReAct loop: it reasons from the prompt and context, decides whether to stop or call a tool, then reasons again after receiving the tool result.
• Goal mode adds a continuation layer around that loop. When the inner ReAct loop ends, the outer layer checks the Goal’s completion status and decides whether another turn should begin.

I recently used a Goal while improving the Visual Style Atlas, and I wish I had tried it sooner. Apart from hitting a usage limit, Codex kept going without stopping.

It solved the frustrating problem of long tasks ending early—although it also seemed to use more tokens than before.

That raised another question for me: inside a ReAct loop, why would an LLM choose to stop when it apparently knows the task is not finished?

Why Long-Horizon Tasks Are Hard for LLMs

#

I have not found public research that identifies the root cause of this behavior in Codex specifically. I did, however, find several experiments that approach the broader problem from different angles: training, execution, and termination.

Training: Why Do More Steps Make a Task Harder to Train?

#

The paper On Training Large Language Models for Long-Horizon Tasks asks a focused question: if the decision rule stays the same, but the number of actions required for success increases, does performance get substantially worse?

The researchers constructed controlled tasks, similar to Sudoku, that followed the same decision rules but required different numbers of steps:

• Task A: make one Sudoku move.
• Task B: make dozens of consecutive Sudoku moves until the board is solved.

They found that simply increasing the task horizon was enough to make training unstable. They traced that instability to exploration difficulties and credit-assignment challenges.

Exploration difficulties

Suppose each step has two possible choices: one right and one wrong.

The probability of getting three consecutive steps right is (1/2)³ = 12.5%.

For ten consecutive correct steps, it falls to (1/2)¹⁰ ≈ 0.098%.

As the number of decisions grows, fully correct trajectories become extremely rare, making it difficult for a model to receive useful positive feedback.

Credit-assignment challenges

Suppose a task fails after 20 steps. Which step caused the failure?

Was it step 3? Or step 12?

With only a failed outcome to work from, it is hard to assign responsibility across the entire trajectory. That makes even negative training data difficult to use.

So as a task’s horizon grows, obtaining useful training feedback becomes significantly harder.

Execution: Where Do Long Tasks Break Down?

#

The paper The Long-Horizon Task Mirage? Diagnosing Where and Why Agentic Systems Break asks where, and why, agents start to fail on long tasks.

The researchers designed a diagnostic framework, evaluated GPT-5-series and Claude-4-series models across four kinds of environments, and collected more than 3,100 execution trajectories:

• Web: browser tasks
• OS: operating-system tasks
• Embodied: physical-world tasks, such as robotics
• Database: database tasks

They then analyzed failed trajectories and grouped the observed issues into seven categories:

Failures during execution accounted for 72.5% of the total, while agent-design issues accounted for 27.5%. As tasks got longer, planning errors, catastrophic forgetting, and memory limitations became more prominent.

What I had dismissed as “not smart enough” can have many different causes. For example, if Codex stops after processing the fifth image, we might ask:

• Can it still restate the original task? Perhaps it has hit a memory limit or catastrophically forgotten a constraint.
• Does it know the actual progress so far? Perhaps its environment perception is off, or earlier mistakes have accumulated.
• Does it incorrectly believe the task is complete? Perhaps it has made a false assumption.
• Does it know what to do next? Perhaps the failure is in instruction following or action planning.

Termination: Can an Agent Tell When to Continue and When to Stop?

#

So far, we have focused on agents that stop when they should keep going. The inverse question matters too: can an agent recognize when it really should stop?

For example:

• The user’s goal contains conflicting requirements.
• The available tools cannot complete the goal.
• A key condition turns out not to hold halfway through execution.
• Continuing could cause an irreversible error.
• And so on.

AgentAbstain: Do LLM Agents Know When Not to Act? investigates this question. The researchers created 263 task pairs across 42 executable environments and 17 frontier models. The best model achieved only 59.5% paired accuracy: it got both the “should act” and “should abstain” versions right only 59.5% of the time.

For tasks with clear completion criteria and costly errors, relying on an LLM’s judgment alone may not be enough. We may need an external verification mechanism.

Returning to the problem of long tasks ending too early, When May an Agent Stop? Evidence-Carrying Termination for Tool-Using LLMs proposes Evidence-Carrying Termination (ECT).

Under ECT, deciding that a task is complete requires three things:

flowchart TD
    A["Task requirements"] --> D["Deterministic verifier"]
    B["Tool-execution evidence ledger"] --> D
    C["Completion certificate"] --> D
    D --> E{"Does evidence cover every requirement?"}
    E -->|"Yes"| F["Allow COMPLETE"]
    E -->|"No"| G["Reject completion / CONTINUE"]
    G --> H["Agent fills the evidence gap or resumes execution"]

• Task requirements: which outputs must exist.
• Tool-execution evidence: the status and results of tool calls.
• Completion certificate: evidence that matches the agent’s claim that the task is finished.

In the experiment, the researchers created 48 synthetic tasks and injected eight classes of faults:

• Declaring completion without required evidence
• Citing evidence for another object
• A tool appearing to succeed while internally failing
• A mismatched data range or date
• Missing required output
• A tampered final computed value
• Citing non-existent evidence
• Repeated calls despite an available recovery path

In the reported experiment, the rate of premature, unsupported completion was 60.6% without ECT and 0% with it.

The experimental setup is idealized, so these numbers are not a real-world success rate. Still, the result suggests that stricter external checks can substantially reduce premature completion claims that are not backed by enough evidence.

My own experience with Codex Goals points in the same direction.

Takeaways

#

1. Stopping early is a common failure mode in long-running LLM-agent tasks.
2. There is still no public research that explains the root cause of this behavior in Codex specifically.
3. Training, execution, and termination decisions can all break down on long tasks.
4. Repeating “don’t stop” in a prompt is not a reliable solution.
5. For long tasks with explicit completion criteria, Codex Goals offer a practical engineering solution.