/goal is becoming an important command in AI coding tools.
It is not about making the model write a few more lines of code. It solves a more practical problem: when a task has clear completion conditions, can the agent keep going until those conditions are met, instead of stopping after every turn and waiting for the user to say “continue”?
Codex provides /goal in the desktop app, CLI, and IDE, and current releases enable it by default. Claude Code also has a same-name command for work that continues across turns, although the product behavior is not identical.
What problem does /goal solve?
Ordinary AI coding conversations usually work as a one-turn-at-a-time loop:
- The user describes a task.
- The agent analyzes, edits code, and runs tests.
- The agent reports the result.
- The user decides what to do next.
That workflow is fine for short tasks. But for migrations, refactors, test fixes, or issue backlog cleanup, it gets fragmented. The agent may move forward a little, then stop and wait for you to type “continue”.
/goal changes the question from “what should you do next?” to “what final state counts as done?” For example:
|
|
This kind of target naturally fits long tasks because it has a clear endpoint: tests pass, the build succeeds, files are split, a queue is empty, or acceptance criteria are satisfied.
Codex /goal: enabled by default and attached to the current thread
In current Codex releases, features.goals is stable and enabled by default. You no longer need /experimental or a manual goals = true entry. Use it directly:
|
|
Common commands include:
|
|
Codex attaches the goal to the current active thread. A goal must be non-empty and no longer than 4,000 characters. Stable status does not make destructive changes, publishing, permissions, or irreversible migrations safe to run without explicit authorization.
Troubleshoot Failed to set goal
Older advice blamed Defender quarantine, a damaged cache directory, or a missing experimental flag. Those claims are not sufficiently supported and do not match the current default. Do not delete all of ~/.codex or disable security software first.
- Update the Codex desktop app, CLI, or IDE extension.
- Open a new thread and test a short, non-empty goal.
- Keep the goal under 4,000 characters.
- Use
/goalto inspect state,/goal editto change it, or/goal clearbefore resetting it. - Check whether
config.tomlexplicitly setsfeatures.goals = false; no setting is required by default. - Restart the IDE extension host or CLI, then report the Codex version, surface, exact error, and minimal goal if it still reproduces.
Claude Code /goal: multi-turn execution driven by completion conditions
Claude Code’s /goal documentation is more explicit: after the user sets a completion condition, Claude keeps working across turns until that condition is met.
Example:
|
|
Claude Code’s mechanism is roughly:
- After the current turn finishes, control is not immediately returned to the user.
- A small, fast model checks whether the goal condition has already been met.
- If it has not been met, Claude automatically starts the next turn.
- If it has been met, the goal is cleared automatically and the completion status is recorded in the transcript.
This makes Claude Code’s /goal more like “auto-continue until the completion condition is satisfied.” It does not merely pin a target to the conversation; it gives an independent evaluation step the decision of whether to continue.
Claude Code also supports checking status directly:
|
|
The status shows the goal condition, elapsed time, evaluated turn count, token usage, and the evaluator’s latest reason.
To stop early, use:
|
|
stop, off, reset, none, and cancel also work as clearing aliases. After a goal is enabled, if the session is interrupted and later resumed with --resume or --continue, an active goal can be restored. However, elapsed time, turn count, and token baselines are recalculated.
The biggest difference
Both Codex and Claude Code are pushing AI coding from single-turn answers toward long-running task execution, but their /goal commands have different positioning.
| Comparison | Codex CLI /goal |
Claude Code /goal |
|---|---|---|
| Status | stable and enabled by default | documented on a dedicated official page |
| Enablement | available directly in current releases | usable directly in a trusted workspace |
| Goal scope | current active thread | current session |
| Common operations | set / view / pause / resume / clear | set / view / clear |
| Automatic evaluation | docs emphasize attachment and tracking | docs explicitly describe evaluator checks after each turn |
| Auto-continuation | official wording is restrained | starts the next turn automatically when conditions are unmet |
| Best fit | keeping a long-term target in a Codex task | letting Claude Code keep moving toward completion conditions |
In short, Codex /goal is closer to “attach and track a long-term target in the current thread.” Claude Code /goal is closer to “set a verifiable stop condition for the current session and let it keep working until satisfied.”
How to write a good /goal
Whichever tool you use, /goal is not a good place for vague wishes.
Not a great goal:
|
|
A better goal:
|
|
A good goal usually includes three things:
- A clear completed state.
- An executable validation method.
- Boundaries that must be respected.
If the goal is large, add a stop condition:
|
|
This matters. The stronger /goal becomes, the more it needs boundaries. Otherwise, the agent may modify too many files, run too long, consume too many tokens, or keep pushing forward on a question that should have been paused for human input.
When /goal is a good fit
Good fits:
- Test fixes: until specific tests pass.
- Code migrations: until all call sites are updated and compilation succeeds.
- Batch cleanup: until a class of lint or type errors is reduced to zero.
- Documentation completion: until all specified modules have documentation.
- Issue queue handling: until every issue under a tag is handled or clearly classified.
Poor fits:
- The requirement itself is still unclear.
- The task needs frequent product judgment.
- It involves high-risk deletion, data migration, or permission changes.
- Acceptance can only be judged subjectively.
- The task spans many unrelated modules.
A practical rule: if you can write “which command to run, what result to see, and which files must not be touched,” it is a good candidate for /goal. If you can only write “make this better,” ordinary conversation, plan mode, or human review is still safer.
What this means for AI coding tools
/goal points to a clear direction: AI coding tools are moving from interactive assistants toward continuously executable work units.
In the past, using an agent often meant staying nearby. If it got stuck, you prompted it. If tests finished, you told it to continue. If errors appeared, you issued another command. /goal compresses that interaction into a completion condition and lets the agent decide what the next turn should do.
But this also raises the bar for users. Writing prompts is no longer just describing a task; it also means defining acceptance criteria, validation commands, modification boundaries, and stop rules. In other words, the user’s job shifts from “keep telling it to continue” to “define what done means.”
The fact that both Codex and Claude Code have reached /goal shows that long-running agents are no longer only for background tasks or cloud queues. Local terminal coding tools now also need stronger autonomous progress.
Summary
Codex CLI and Claude Code both have /goal, but at this stage they should not be treated as the same feature.
Codex /goal is enabled by default and maintains a long-term target in the current Codex thread. Claude Code /goal more explicitly connects completion conditions with auto-continuation, using an independent evaluator to decide whether to keep going.
For everyday development, this kind of command is best for engineering tasks with clear acceptance criteria. It does not replace product judgment or code review, but it can reduce the repetitive “continue,” “run it again,” and “fix until tests pass” loop inside long tasks.
The real skill is not memorizing the command. It is learning how to write tasks as clear, verifiable, stoppable goals.
References
- OpenAI Codex CLI Slash Commands: https://developers.openai.com/codex/cli/slash-commands
- Claude Code Goal documentation: https://code.claude.com/docs/en/goal