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.

OpenAI’s long-running work guide asks for an outcome, constraints and verification. The cases below show how to apply those ideas when work drifts. For command syntax and lifecycle controls, use the separate Goal commands guide.

The four-hour feature that became a test loop

Reddit user SierraBravoLima reported a roughly four-hour Codex run for a small feature, with repeated tests, audits and rare cases, and two credit top-ups along the way. The author thought 5.5 would have done it in 45 minutes; that was an estimate, not a timed comparison. The post does not establish whether this run used /goal. Another commenter in the same thread reported three hours of specifications and planning without code.

In a separate discussion explicitly about Goal mode, SnooPeripherals5313 said open-ended feature creation tended to produce poor results. 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.

Goals can drift without priorities, completion evidence and a rule for changing approach

“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.

Successful long runs used bounded phases, measurements and review

A robotics user used Goal mode to calibrate servos

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. Each measurement let the agent judge whether the change brought it closer to the target and choose the next adjustment. Repeating the process produced useful feedback instead of another speculative edit.

A vector database developer assigned Goal mode one documented phase

Before starting the long run, the developer wrote detailed specifications, task plans and architecture decision records, then gave Goal mode a narrow instruction such as completing Phase 5. Experiments were recorded in a ledger, and Claude reviewed the work separately at intervals. Throughout the run of more than 23 hours, the defined phase, decision record and external review kept the work within scope and guided the next step.

One user reported an orderly ten-hour run; others recommended screenshots

Reddit user sjoti reported ten hours on a single Goal without the work becoming a mess. In the same discussion, Sorry_Risk_5230 recommended a fresh context and a well-planned prompt, while noodlessentme described requesting PNG screenshots and a sanity check. Those separate users’ suggestions provide a practical way to distinguish code being written from a result that 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. 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 handled the engineering work, while a person assessed how the game felt to play.

Use the plan to set the sequence and the Goal to implement and verify one phase

Use the plan to record the sequence, dependencies, interfaces and acceptance criteria. Then assign Codex one planned phase through Goal mode and have it work until it can demonstrate the agreed result.

1. Write the durable plan firstSeparate P0 from later work and record boundaries that must survive context compression.
2. Assign one defined phase“Complete Phase 2 in plan.md” gives Codex a bounded assignment; “Finish the service” leaves the scope open.
3. Require three forms of proofShow the result a user can inspect, record the automated check and its result, and verify that the existing behavior still works.
4. Tell Codex to change its diagnosis after two failed attemptsAfter two failed attempts, Codex should form a new root-cause hypothesis before trying another patch.
5. Maintain an experiment ledgerWrite the hypothesis, change, result and next action after every meaningful attempt.

A Goal template that defines the result, scope and stopping conditions

/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 still work, and the check that verifies it]

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.

Pause when tests and documentation grow but P0 stays unfinished

• 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.

If Codex is waiting for permission, inspect the access it needs before rewriting the objective. In May 2026, Goal user gerrry reported repeated authorization messages overnight. A similar issue, #22833, was closed on May 30 after a contributor reported a change allowing the agent to stop at an impasse. If messages repeat in your current run, use /goal pause in CLI, inspect the last tool error or approval request, then decide whether to provide access or narrow the task. In the desktop app, use the pause button in the goal progress row. Starting a Goal keeps the existing sandbox and approval boundaries.

Judge Goal mode by whether each iteration brings the primary deliverable closer to working and produces check results that demonstrate it. If P0 is unchanged while secondary work grows, pause the run and narrow the next attempt to one result with a clear condition for changing approach. Keep the existing change boundaries and name the evidence that will show that result is complete.

If the same procedure keeps appearing in your prompts, the Skills authoring guide explains how to package it for reuse.

Frequently asked questions