What is goal mode? Claude Code, Codex, Cursor, Grok

Goal mode is a session that keeps working toward a condition you wrote, without you sending the next prompt. You name what done looks like. The agent takes a turn, a check looks at the result, and another turn starts if the condition is still open.

It is not plan mode. A plan is a design you approve before the edits. A goal is the loop after you already know the finish line. The slash commands entry lists /goal among the other / commands. This page is how the loop actually stops.

How goal mode works

A normal turn ends when the model decides it is done, or when it needs you. A goal adds a reason to start again. The reason is the condition. “Migrate the auth module” is a weak condition, because nothing in it can fail a check. “The auth tests pass, and the public endpoints stay the same” can fail a check.

Who runs that check depends on the tool. Claude Code asks a separate model that does not call tools. Grok Build asks a panel of reviewer subagents once the work looks done. Codex and Cursor document the command and the completion criteria, and they don’t describe a separate judge.

The loop does not widen what the agent is allowed to do. Permission modes and the sandbox stay where you left them.

Goal mode in each tool

All four document /goal. The stop rule and the extra commands are not the same.

Claude Code

/goal sets a completion condition. After each turn, a model checks whether the condition holds. If it is not met yet, Claude starts another turn. The goal clears when the condition is met, when the model judges it impossible, or when a turn fails on an error you have to fix. Those errors include an authentication failure Claude Code manages itself, an exhausted credit balance, a context overflow auto-compaction couldn’t clear, and a model that isn’t available.

One goal is active per session. A new /goal replaces the old one. Setting it starts a turn immediately. The condition itself is the directive. A ◎ /goal active indicator shows how long it has been running. /goal with no arguments shows the condition, the elapsed time, how many turns have been evaluated, the current token spend, and the evaluator’s latest reason.

/goal clear removes it. stop, off, reset, none, and cancel are aliases for clear. /clear also removes an active goal, because it starts a new conversation.

The evaluator does not run commands or read files. It judges what is already in the conversation, so the condition has to be something Claude’s own output can show. The condition can be up to 4,000 characters. You can bound a run in the condition itself, for example by saying to stop after a number of turns.

A goal does not change your permission mode. In Manual mode, Claude still asks before tool calls your settings don’t allow. Auto mode is what lets those turns run without a prompt per tool. The two are separate. Auto mode alone does not start the next turn. /goal does.

The check is a session-scoped prompt-based Stop hook. It runs on the small fast model configured for your provider. ANTHROPIC_DEFAULT_HAIKU_MODEL changes that model, and Claude Code also uses the same variable for the haiku alias and for some other background tasks, including session titles. /goal is unavailable when hooks are disabled.

In -p, the loop runs until it finishes in that one invocation. Ctrl+C stops it.

See Keep Claude working toward a goal.

OpenAI Codex

In the CLI, the desktop app, and the IDE extension, /goal starts Goal mode. The goal text is both the first prompt and the completion criteria. /goal alone views the current goal. /goal edit revises it. /goal pause, /goal resume, and /goal clear pause, resume, and remove it.

The objective has to be non-empty and at most 4,000 characters. For a longer spec, the command reference says to put the details in a file and point the goal at that file.

If /goal is missing from the slash list, the follow-a-goal use case says to turn it on. Set goals = true under [features] in config.toml, or run codex features enable goals.

Starting a goal does not grant broader access. Codex keeps the same sandbox and approval policy, and it pauses when it needs a decision. If the outcome is still fuzzy, the long-running-work page says to start with /plan, have it interview you, and only then run /goal.

Each chat has its own goal. Two chats can run at once. The page tells you not to let them write the same files.

See Long-running work, the slash commands, and Follow a goal.

Cursor

The Agent overview says each message is a new job, and /goal gives the agent a long-lived objective to work toward until it is fully complete. The CLI slash-command reference has /goal [objective] and marks it as rolling out. If you don’t see it, the overview says to try a new chat.

In the CLI, Ctrl+C pauses the goal. The overview also points at a custom mode when you want a playbook, and at the built-in /loop skill when you want a prompt on an interval. /loop is a schedule. /goal is a finish line. Stop the loop when you want the interval to end.

The overview doesn’t document a separate reviewer model, a token budget flag, or a /goal clear spelling. The CLI changelog describes the feature as durable: an active or paused status, continued across idle and headless runs, paused on Ctrl+C, and still rolling out.

See Cursor Agent and the CLI slash commands.

Grok Build

/goal gives Grok an objective and lets it work across many rounds. After every round it checks progress and decides whether to keep going, stop because it needs you, or treat the goal as done. When the goal looks done, a panel of reviewer subagents checks the work against the evidence. The goal is complete only when most of them agree. If they find gaps, Grok keeps working. If it gets stuck on the same gaps, it pauses and shows you what is missing.

The docs’ weak example is a migration with no way to tell it is done. The strong example names the test suite and the boundary:

/goal Migrate the auth module to the new API, verified by the auth test suite passing, without changing public endpoints.

/goal or /goal status shows the goal, its status, tokens used, and time elapsed. /goal pause and /goal resume pause and continue. /goal clear removes it. Add --budget and a token count on the start command to cap what that goal may spend.

The spec-driven development entry uses this strong shape as the Grok half of a written check. How to use Grok Build walks through the same commands on a form-validation task.

See Grok Build commands.

Details checked against each vendor’s documentation in November 2026.

A real example

You want the newsletter signup to keep rejecting an empty email, and you don’t want a second required field added while the agent is in there. Grok Build’s documented shape is the one to copy, because it puts the check and the boundary in the same line:

/goal Keep the newsletter form rejecting an empty email, verified by the form tests passing, without adding a second required field.

On Claude Code the same finish line is the argument to /goal. Run it in auto mode only if you already want those test commands approved. Otherwise you will sit on the permission prompts the goal does not waive.

On Codex, /goal sets it and /goal with no text shows it. /goal clear removes it in Claude Code, Codex, and Grok Build. Cursor’s documented pause, in the CLI, is Ctrl+C.

If you are about to leave the machine, a goal is the feature those pages describe for a finish line you can check. What would make an overnight agent useful? is the prior question: what you want to decide in the morning, and whether the steps are already known.

When to use goal mode

Use it when the end state is a command you can rerun. A test suite, a lint step, a file that must exist, an empty queue. Claude Code’s own examples are a migration until the call sites compile and the tests pass, a design doc until the acceptance criteria hold, and a split until each file is under a size you named.

Use plan mode first when you don’t yet know the finish line. Codex’s long-running page says to interview in /plan, then start the goal from the result.

Skip it for a question. “What does this function return?” is one turn. A goal will keep going because the condition never becomes a check. Skip it when you can’t name a boundary. An open-ended “clean this up” is how a long run edits files you didn’t mean to touch.

Pitfalls

The judge in Claude Code only sees the transcript. A condition like “the tests pass” works when Claude actually ran the tests and the output is in the conversation. A condition the transcript never demonstrates can stay “not yet” or be marked impossible for a reason you can’t see in the files.

Claude Code will not raise your permissions to finish the goal. A test command you haven’t allowed still prompts in Manual mode, and the loop waits. Grok’s reviewers can also pause the goal and hand you the gaps. Neither tool treats “keep going” as “approve everything.”

Codex and Claude Code both cap the goal text at 4,000 characters. A long spec belongs in a file the goal points at, which is what the Codex command reference says to do. Cursor doesn’t document that cap, and it does say the command is still rolling out. If /goal is missing, the overview’s advice is a new chat, not a flag you can pass.

A token budget is a Grok Build flag, --budget. Claude Code shows token spend in /goal status and does not document that flag. A long goal still draws the plan allowance down. The tokens entry is how you see that spend.

Two goals writing one checkout will step on each other. Codex says to keep parallel chats off the same files. A goal does not create a separate checkout for you.

Related on flaviocopes.com

• How to use Grok Build shows /goal, /goal status, pause, resume, clear, and --budget on a real validation task.
• How to use the Codex CLI includes /goal in the CLI session, next to plan mode.
• What would make an overnight agent useful? is the decision to make before you leave a long run going.
• Spec-driven development is the written check a strong /goal line is an instance of.

Related glossary entries

• Plan mode: Plan mode makes a coding agent research and propose a plan before it edits code. How it works in Claude Code, Codex, Cursor and Grok Build, and when to use it.
• Permission modes: Permission modes decide what a coding agent can do without asking. The modes in Claude Code, Codex, Cursor and Grok Build, and what YOLO mode really skips.
• Spec-driven development: Spec-driven development writes the behavior and the check before an agent edits. How plan mode and goals support that in these four tools.
• Slash commands: Slash commands are the /name controls inside a coding agent session. How they work in Claude Code, Codex, Cursor and Grok Build, and how to add your own.

All AI glossary entries →

Want me to talk about your product? You can sponsor this site.