Claude Code /goal.

Claude Code is Anthropic's terminal-native coding agent — an interactive REPL that reads and edits files in your repo, runs shell commands, calls MCP servers, and runs as a CLI, a desktop app, a VS Code / JetBrains extension, or on the web at claude.ai/code. Install the CLI globally with npm:

Docs: code.claude.com/docs · Commands reference: code.claude.com/docs/en/commands

/goal attaches a completion conditionto the current session. After each turn, the condition and the conversation so far are handed to a small fast model (Haiku by default) that returns a yes-or-no decision and a short reason. A "no" tells Claude to keep going, with the reason as guidance. A "yes" clears the goal and records an achieved entry in the transcript.

In other words: you set the finish line once, and a separate evaluator — not the model doing the work — judges when to stop. A live ◎ /goal active indicator shows how long the goal has been running.

Use it for bounded work with a verifiable end state — migrating call sites until tests pass, draining a labelled issue queue, splitting a large file until each piece is under a size budget. Skip it forbrainstorming, exploratory edits, or anything whose "done" you can't describe in one sentence.

One command, three behaviours depending on the argument:

• /goal <condition> — set or replace the active goal; a turn starts immediately, no separate prompt needed
• /goal — show the status of the active goal (or the most recently achieved one)
• /goal clear — remove the active goal before its condition is met

Aliases for clear: stop, off, reset, none, cancel. Running /clear to start a new conversation also removes any active goal.

Under the hood, /goal is a thin wrapper around a session-scoped prompt-based Stop hook. Each time a turn ends, your condition plus the full transcript go to the small fast model and come back with yes/no + reason. The evaluator doesn't call tools— it doesn't run commands, doesn't open files, doesn't hit your shell. It only judges what Claude has already surfaced in the conversation.

This single fact decides whether a goal will work. If you'd need to run something independently to verify the condition, the evaluator can't. Phrase the condition as something Claude's own output can prove.

The official docs list three things a durable condition has:

• One measurable end state — a test result, a build exit code, a file count, an empty queue
• A stated check — how Claude should prove it, such as npm test exits 0 or git status is clean
• Constraints that matter— anything that must not change on the way there, e.g. "no other test file is modified"

Conditions can be up to 4,000 characters. Use the space: a strong goal reads like a small task brief, not a wish.

/goal only runs in workspaces where you've accepted the trust dialog, because the evaluator is part of the hooks system. It's also unavailable when disableAllHooks is set at any settings level, or when allowManagedHooksOnly is set in managed settings. In those cases the command tells you why instead of silently doing nothing.

It works the same way in interactive sessions, in non-interactive mode with -p, and through Remote Control. Setting a goal with -p runs the loop to completion in a single invocation:

Interrupt with Ctrl+C to abort a non-interactive goal before the condition is met.

Running /goalwith no argument shows status — the condition, how long it's been running, how many turns the evaluator has reviewed, the current token spend, and the evaluator's most recent reason. If no goal is active but one was achieved earlier in the session, you get the achieved condition plus its duration, turn count, and token spend.

On --resume or --continue, the condition carries over but the turn count, timer, and token-spend baseline all reset. Achieved or cleared goals are not restored.

/goal vs /loop: Both keep a session running between prompts, but the trigger is different. /loop re-runs on a time interval (or self-paced) and stops when you stop it or when Claude decides the work is done. /goal re-runs the moment the previous turn finishes and stops when a separate model confirms the condition holds.

/goal vs Stop hooks: /goal is a session-scoped Stop hook — just with a one-line shortcut for setting it. A real Stop hook lives in your settings file, applies to every session in scope, and can run a script (deterministic) instead of a prompt (model-judged). Reach for a real hook when the same check should apply to every session, or when you want deterministic evaluation.

/goal vs Codex /goal: Same word, different design. Codex's version is a persisted "task contract" with explicit pursuing / paused / achieved / unmet / budget-limited states and pause/resumesubcommands. Claude Code's version is leaner: one condition, evaluated after every turn by a separate model, no pause/resume, no budget gate, and a single clear. If you want pause semantics or persistent multi-session goals, use Codex; if you want a one-line shortcut to a transcript-judged Stop hook, Claude Code is the lighter tool. The full Codex story is in the Codex CLI /goal guide.

/goal vs Auto mode: Auto mode removes per-tool prompts within a turn. /goal removes per-turn prompts. They're complementary — enable both for fully unattended work.