Most ways of keeping Claude working need you to prompt each step, which defeats the point when you are away from the keyboard. /goal sets a completion condition instead. After every turn a small fast model checks whether the condition holds, and if it does not, Claude starts another turn rather than handing control back to you.
Requires Claude Code v2.1.139 or later, and it works through Remote Control, so you can set a goal and watch it grind from your phone.
Three ways to keep a session going, and how they differ
| Approach | Next turn starts when | Stops when |
|---|---|---|
/goal | The previous turn finishes | A model confirms your condition is met |
/loop | A time interval elapses | You stop it, or Claude decides the work is done |
| Stop hook | The previous turn finishes | Your own script or prompt decides |
/goal is the session-scoped shortcut: you type a condition and it applies to this session only. A Stop hook lives in your settings, applies to every session in scope, and can run a real script for deterministic checks.
Auto mode is a different axis entirely. It approves tool calls within a turn but never starts a new one. The two compose well: auto mode removes per-tool prompts, /goal removes per-turn prompts. On its own, /goal does not change permissions at all, so in the default mode Claude will still stop and ask before running your test command. For genuinely unattended work you need both.
Setting one
/goal all tests in test/auth pass and the lint step is cleanThat starts a turn immediately, using the condition itself as the directive. No separate prompt needed. A ◎ /goal active indicator shows how long it has been running. One goal per session, and setting a new one replaces the old.
Writing a condition that actually works
This is where people get it wrong, and the reason is specific: the evaluator does not run commands or read files. It judges your condition against what Claude has already surfaced in the conversation. So the condition has to be something Claude’s own output can demonstrate.
“All tests in test/auth pass” works, because Claude runs the tests and the result lands in the transcript where the evaluator can read it. “The code is well structured” does not, because nothing in the transcript proves it.
A durable condition usually has three parts:
- 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 testexits 0″ or “git statusis clean”. - Constraints that matter: anything that must not change on the way, such as “no other test file is modified”.
Conditions can run to 4,000 characters. To bound how long it goes, put the limit in the condition itself: or stop after 20 turns. Claude reports progress against that clause each turn and the evaluator judges it from the conversation.
Checking and clearing
/goal with no argument shows the condition, how long it has run, turns evaluated, token spend, and the evaluator’s most recent reason. That reason is the useful part, because it tells you what Claude is aiming at next.
/goal
/goal clearstop, off, reset, none and cancel all work as aliases for clear. Running /clear to start a fresh conversation also removes an active goal.
A goal still active when a session ends is restored on --resume or --continue. The condition carries over, but the turn count, timer and token baseline all reset.
Running it headless
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"With default text output nothing prints until the condition is met, so a goal running many turns looks completely stuck. Add --output-format stream-json --verbose to emit each message as it goes. Ctrl+C interrupts.
What is happening underneath
/goal is a wrapper around a session-scoped prompt-based Stop hook. After each turn, Claude Code sends the condition and the conversation to your configured small fast model, which defaults to Haiku on the Claude API. The model answers yes or no with a short reason. On no, Claude keeps working and treats the reason as guidance. On yes, the goal clears and an achieved entry is recorded.
Evaluation tokens are billed on that small model and are usually negligible next to the main turns.
If you want a different evaluator model, ANTHROPIC_DEFAULT_HAIKU_MODEL changes it. Be aware that Claude Code uses that variable everywhere it needs a small fast model, including conversation summarisation and the haiku alias, not just for goal evaluation.
When it will refuse to run
Because the evaluator is part of the hooks system, /goal needs an accepted workspace trust dialog. It is also unavailable when disableAllHooks is set at any settings level, or when allowManagedHooksOnly is set in managed settings. In each case the command explains why rather than failing quietly.
Pairing it for remote work
The combination that works when you are not at the desk: set the permission mode on the host before you leave, start the session with Remote Control, then set a goal with a bounded condition. Auto mode handles the tool calls, the goal handles the turns, and you check in from your phone to read the evaluator’s reasoning rather than to type prompts.
See permission modes for the half that stops prompts, and scheduled tasks for interval-based work instead.