Condition-driven persistence

/goal <objective>

Codex Goal

Give Codex one durable objective with a verifiable stopping condition. It can keep making scoped progress across turns until the condition is achieved or the work becomes genuinely blocked.

What Goal controls

A Codex goal makes an objective durable within a thread. Instead of treating one normal response as the natural boundary, Codex can continue across turns, validate progress, and keep working until the stated end condition is satisfied.

The goal is a contract, not just a topic. Strong goals say what to achieve, what remains out of scope, how progress is verified, and exactly when to stop.

01 / ContractSet objective, bounds, and proof
02 / ProgressWork through scoped checkpoints
03 / ValidateRun the defined evidence loop
04 / ResolveAchieve the condition or report a blocker

Write a goal that can finish

A good goal is bigger than a single prompt and smaller than an open-ended backlog. Use four ingredients:

  1. Objective: name one coherent outcome.
  2. Boundaries: identify what must not change.
  3. Evidence: name the commands or artifacts that prove progress.
  4. Stopping condition: describe the observable state that means “done.”
A decision-complete migration goal
/goal Migrate this project from the legacy router to the new router.
Preserve every public URL and keep the legacy path available for rollback.
After each checkpoint, run the contract and browser tests.
Stop only when both suites pass and the migration notes are complete.

Avoid “make the whole codebase better”

Loose backlogs and subjective finish lines invite scope drift. If an objective cannot be verified, turn it into a normal exploratory conversation before creating a goal.

Inspect and control the run

/goal <objective>
Sets the durable objective and begins goal-driven work.
/goal
Shows the current goal and its progress state.
/goal pause
Stops automatic progress while preserving the goal.
/goal resume
Restarts work toward the preserved objective.
/goal clear
Removes the goal when it is done or no longer valid.

Useful progress updates name the current checkpoint, what was verified, what remains, and whether external input is required. If progress becomes vague, tighten the contract or evidence—not the amount of motivational language.

Feature availability

If /goal does not appear in the command list, enable the goals feature in the Codex configuration or with the CLI.

Enable goals in config.toml
[features]
goals = true
Enable goals from the command line
codex features enable goals

The validation loop matters

Goal works best when the environment can produce trustworthy evidence. That could be a passing test suite, a benchmark threshold, a visual match, a deployment status, or a reviewable artifact.

Weak finish line

“Finish the migration and make sure it looks good.”

Verifiable finish line

“All contract tests pass, Playwright matches the reference screens, and rollback instructions are documented.”

Permissions still apply

A durable objective does not erase sandboxing, approvals, repository scope, or destructive-action safeguards. Give the smallest authority that can complete the validated work.

Where it fits

Good fits

  • Large migrations with parity checks
  • Refactors with testable invariants
  • Prototypes with defined acceptance criteria
  • Prompt optimization against an eval target

Poor fits

  • Unrelated backlog items
  • Subjective goals with no evidence
  • Work awaiting an unresolved product decision
  • Periodic checks where time is the real trigger

How it differs

Goal is condition-driven

Claude Loop wakes because time passed. GitHub Autopilot continues a delegated task until the agent calls it complete. Codex Goal makes the user-defined objective and stopping condition durable across turns, with explicit status and lifecycle controls.

First-party sources

Verified against OpenAI documentation