Set a goal Codex can finish
Persistent objective, measurable proof, stop rule
After this, you'll be able to use Goal mode for long-running Codex work without letting the task drift.
Before you start
Complete Split work with subagents first.
The idea
Goal mode gives Codex a durable objective and a definition of done. The goal text acts as both the starting prompt and the completion criteria, so Codex can keep checking whether it has finished.
Here is the before and after: before, Codex is guessing from a loose request. After, you can use Goal mode for long-running Codex work without letting the task drift.
Now try it use the exercise prompt on one real repo task. Keep the output small enough to check before you accept the change.
You are ready when the Codex action, boundary, and proof all match the task.
Try it (12 min)
Watch out for
- Using Goal mode for a small task that one normal prompt can finish.
- Writing a goal with no measurable proof.
- Telling Codex to keep improving without a stop rule.
- Letting a goal continue after the task needs product or policy judgment.
Paste this into Claude
Turn this long Codex task into a goal: Task: [describe the work] Target outcome: [what should be true when done] Proof commands or checks: [tests, build, screenshot, eval, route check] Stop if: [approval, design decision, policy, data, schema, unknown] Checkpoint cadence: [after each module, after each failing test, every 30 minutes, etc.] Return: 1. The exact /goal text. 2. The checkpoints Codex should report. 3. The proof required before completion. 4. The stop rule.
What a good response looks like
/goal Implement PLAN.md for the profile save fix. Keep edits limited to src/app/profile, src/lib/profile, and related tests. After each edit, run npm test -- profile. Finish only when npm test -- profile and npm run build pass. Stop if the fix requires a schema change, auth middleware change, or new secret.
What good looks like
- The goal text includes outcome and proof
- The stop rule names when Codex should pause
- Checkpoints produce status, not vague reassurance
- The goal does not hide decisions that need a human
When this breaks
- Breaks when the goal lacks completion criteria because Codex keeps making changes after the useful work is done.
- Breaks when stop conditions are missing and Codex crosses into schema, billing, auth, or design decisions without approval.
AI can help with this
Use Codex to help you you can use Goal mode for long-running Codex work without letting the task drift. Start with the exercise prompt and your real input. Ask for one draft, then check it against this proof: The goal text includes outcome and proof. Accept only the version you can verify yourself.
You can now
You can choose when Goal mode is appropriate
- You can write measurable completion criteria
- You can define checkpoint reports
- You can pause work at human-decision boundaries
Key takeaways
Goal mode works when the goal contains the finish line. Give Codex outcome, proof, checkpoints, and a stop rule.
- Use /goal for long-running work with a durable objective.
- Use /plan first when the goal needs shaping.
- Goal text doubles as completion criteria.
- Pause or edit the goal when the work changes.