Codex Goal Mode: Why Long Runs Miss the Real Objective

Goal mode solves a specific problem: it keeps Codex working toward a persistent completion objective across iterations. It does not automatically know which unfinished item has the highest product value. If the prompt leaves priority, evidence and escape conditions undefined, the agent can spend hours making a secondary test more complete while the feature that matters remains unfinished.

The four-hour feature that became a test loop

One developer expected a feature to take roughly 45 minutes. The Goal ran for four hours instead. Codex kept extending tests, auditing the implementation and investigating increasingly rare cases. The run consumed additional credits, but the primary deliverable did not advance in proportion to the time spent. In the same discussion, another user described three hours of specifications and plans with no code produced.

An open-ended feature request produced a similar result for another first-time Goal user: a mediocre implementation despite the extended autonomy. The most useful replies did not recommend a longer run. They recommended doing the design work first, letting Codex tighten the Goal before activation, and giving the loop a metric it could evaluate without subjective judgment.

What the failed Goals were missing

“Improve the authentication system” makes almost every nearby activity defensible. Adding types, rewriting helpers, documenting flows and expanding coverage can all look like progress. A useful Goal instead says which user-visible failure must disappear, which command must pass, what may change and what must remain untouched.

A single test is also a weak finish line. It encourages the run to optimize against that test rather than the product. UI work needs a browser flow or screenshot; backend work needs an observable response plus a regression test; performance work needs the same benchmark before and after.

Why the successful long runs worked

Servo calibration turned every iteration into evidence

A robotics user applied Goal mode to servo calibration: change a value, observe the physical result, record it and select the next value. A small neural-network experiment followed the same structure. The objective and the evaluation loop were the same loop, so another iteration meant another useful measurement rather than another speculative edit.

A vector database project assigned one documented phase

Before starting the long run, the developer built detailed specifications, task plans and architecture decision records. Goal mode then received a narrow instruction such as completing Phase 5. Experiments were written to a ledger, and a separate Claude review checked the work periodically. The run lasted more than 23 hours, but duration was not the control mechanism. The phase definition, decision record and external review were.

A ten-hour rewrite required visual proof

A developer who reported a successful ten-hour Goal started from a fresh context and a carefully planned prompt. Other users in the discussion explicitly required PNG screenshots and a final sanity check. The run had a way to distinguish “code exists” from “the result is visibly correct.”

The multiplayer game still needed resets and a human player

A real-time game built on Cloudflare Workers, WebSockets and Durable Objects made an impressive end-to-end demo. It was not produced by one magical Goal, however: the author used three or four Goals and reset the process three times. Human playtesting still decided whether camera shake, animation and timing felt right. Goal mode completed engineering loops; product judgment remained a separate loop.

Plan the route, then run the phase

Planning and persistence are different jobs. The plan decides sequence, dependencies, interfaces and acceptance criteria. The Goal executes one planned phase until the agreed evidence exists.

1. Write the durable plan firstSeparate P0 from later work and record boundaries that must survive context compression.
2. Assign one phase, not the whole product“Complete Phase 2 in plan.md” is controllable. “Finish the service” is not.
3. Require three forms of proofUse a user-observable artifact, an automated check and a preserved behavior.
4. Define the pivot before the failureTwo failed attempts should replace the hypothesis, not trigger a third variation of the same patch.
5. Maintain an experiment ledgerWrite the hypothesis, change, result and next action after every meaningful attempt.

A Goal prompt you can reuse

/goal Complete [P0 deliverable].

Completion evidence:
1. [Artifact a user can inspect]
2. [Test/build/benchmark command and expected result]
3. [Existing behavior that must not regress]

Order:
1. Finish P0 items in the written order.
2. Before P0 is complete, do not perform cosmetic cleanup,
   generalization, rare-edge-case work or unrelated refactors.

Iteration policy:
- After each attempt, update plan.md with hypothesis, change,
  result and next action.
- If the same subproblem fails twice, or the metric fails to improve
  twice, stop that approach and rebuild the root-cause hypothesis.
- If a subproblem does not block P0, move it to the blocked list
  and continue with the next P0 item.

Scope:
- Allowed: [paths]
- Forbidden: [public APIs, schemas, services]

If blocked:
- Record attempted paths, observed evidence, the exact blocker
  and the input required. Then stop.

When to stop the run yourself

• The P0 checklist is unchanged while test and documentation files keep growing.
• Codex is applying a third patch to the same failure without replacing its diagnosis.
• The diff grows while the screen, API response or benchmark the user cares about does not change.
• Out-of-scope refactoring has become larger than the original feature.
• The task lacks credentials, data or external access, but the run starts building speculative workarounds.

The right measure for Goal mode is evidence gained per iteration, not hours elapsed. Longer autonomy requires a tighter contract: an ordered result, several ways to prove it, a narrow change boundary, a pivot threshold and a clean blocked exit. Without those constraints, persistence becomes stubbornness.

Frequently asked questions