/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 CLI has already added an experimental /goal command in its official docs. Claude Code has also published its own /goal documentation, describing it as an automation capability that can keep working across multiple turns. The names are the same, but the product direction is not exactly the same.

What problem does /goal solve?

Ordinary AI coding conversations usually work as a one-turn-at-a-time loop:

1. The user describes a task.
2. The agent analyzes, edits code, and runs tests.
3. The agent reports the result.
4. 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:

1

/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错

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: experimental and attached to the current thread

OpenAI’s Codex CLI documentation marks /goal as experimental. It is not a stable default capability and requires features.goals to be enabled first.

There are two ways to enable it:

1

/experimental

Or add this to config.toml:

1
2

[features]
goals = true

Once enabled, you can use it like this:

1

/goal Finish the migration and keep tests green

Common commands include:

1
2
3
4

/goal
/goal pause
/goal resume
/goal clear

According to OpenAI’s docs, Codex attaches the goal to the current active thread and keeps tracking that target while a larger task continues.

One detail matters here: the official wording for Codex /goal is restrained. It emphasizes setting an experimental goal for long-running work and attaching the goal to the current thread, but it does not describe, in the same level of detail as Claude Code’s docs, an independent evaluator that automatically checks every turn and starts the next one. So for now, it is better to treat Codex /goal as an experimental long-task goal mechanism, not a fully stable unattended execution mode.

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:

1

/goal all tests in test/auth pass and the lint step is clean

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:

1

/goal

The status shows the goal condition, elapsed time, evaluated turn count, token usage, and the evaluator’s latest reason.

To stop early, use:

1

/goal clear

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.

In short, Codex /goal is closer to “attach an experimental long-term target to 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:

1

/goal 把项目优化一下

A better goal:

1

/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件

A good goal usually includes three things:

1. A clear completed state.
2. An executable validation method.
3. Boundaries that must be respected.

If the goal is large, add a stop condition:

1

/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题

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 still experimental, requires features.goals, and is better understood as a way to maintain 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