The /goal Command: Goal-Directed Autonomous Runs

The /goal command hands a coding agent an objective and a verifiable stopping condition instead of a single prompt, then runs a plan-act-test-review loop on its own until a checker confirms the condition is met or a budget runs out. Claude Code, Codex and Cursor all document it as a first-party command, though Cursor’s is still marked as rolling out.

You’re three hours into a migration. The agent finishes a turn, you read the diff, you type “good, keep going,” it finishes another turn, you type “keep going” again. You’re not directing anymore — you’re a clock that says tick. The work is clear, the stopping condition is obvious (“all tests green, all call sites migrated”), and yet every step waits on you pressing return.

The /goal command removes you from that loop. You give the agent one objective and one verifiable finish line, and it keeps working — planning, acting, testing, reviewing — until a checker confirms the goal is met or a budget runs out. Your job shifts from typing every step to designing the finish line.

What you’ll walk away with from /goal

What /goal actually does and how the plan → act → test → review loop terminates
Exactly how to drive it in Claude Code and in Codex, and what each one requires
How Cursor’s /goal differs from the other two, and what its reference does not promise
How to write an objective and stopping condition the agent can actually verify
When /goal is the right tool versus /loop

What /goal actually does

A normal agent turn ends when the model decides it has said enough. /goal replaces that with an explicit, checkable condition. Under the hood it runs a loop:

Plan — decide the next concrete step toward the objective.
Act — make the change.
Test — run the validation commands you defined.
Review — a checker asks “is the stopping condition met?” If no, loop back to plan. If yes, stop.

The pattern has an older nickname — the “Ralph loop” — after the idea of re-feeding an agent the same goal until it converges. The difference with /goal is that the loop, the checker, and the budget are built into the tool instead of being something you script by hand.

The whole thing lives or dies on the stopping condition. “Make the app better” never terminates. “Every test in tests/ passes and npm run typecheck exits 0” terminates the moment it’s true.

Tool support

/goal is built in, and has been since v2.1.139. Set an objective with /goal <objective> and the session keeps working turn after turn until the goal is met, rather than stopping after one response. A fast checker model — Haiku by default on the Claude API — evaluates the stopping condition after each round and ends the run when it’s satisfied. Conditions can be up to 4,000 characters; one goal is active per session, and a new one replaces the old.

Two mechanical details decide whether it will run at all. /goal is implemented as a session-scoped prompt-based Stop hook, so it works only in workspaces where you have accepted the trust dialog, and it is unavailable when disableAllHooks is set at any settings level or allowManagedHooksOnly is set in managed settings. In each case the command tells you why rather than silently doing nothing.

A goal that was active when the session ended is restored by --resume or --continue — the condition carries over, while the turn count, timer and token baseline reset. It also works headless, which is the form worth knowing for CI:

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

Use it when the work spans many turns toward a condition you can state precisely — a migration with parity checks, a refactor gated by a test suite, a bug you can reproduce with a command. To run on an interval instead of toward a condition, use /loop; to run unattended on Anthropic infrastructure, use Routines.

/goal shipped in Codex CLI 0.128.0 (April 30, 2026) behind a feature flag, and 0.133.0 (May 21, 2026) made goals stable and enabled by default, backed by dedicated storage that tracks progress across active turns. On any current build there is nothing to set up — just use the command:

/goal migrate every route in src/api to the new handler signature;
done when npm test and npm run typecheck both pass

Verify with codex features list, which reports goals stable true on a default install. The [features] goals = true block in config.toml and codex features enable goals are now only needed to undo an explicit codex features disable goals, or on a build older than 0.133.0 — they are not a setup prerequisite, though some third-party guides still present them as one. Checked 2026-08-28 against learn.chatgpt.com/docs/developer-commands: /goal is listed there as “Set, edit, pause, resume, view, or clear a task goal”, and no /loop appears in that reference.

Control a run with /goal (show current goal), /goal edit (revise it in place, added in 0.131.0), /goal pause, /goal resume, and /goal clear. Codex loops plan → act → test → review on its own and can work for hours without input until your stop condition is met or your weekly quota is exhausted. Since 0.132.0 a continuation stops when it hits a usage limit or the same blocker twice, rather than looping and burning tokens, and 0.147.0 surfaces a blocked goal as stalled in the TUI.

Unlike Claude Code’s session-scoped version, Codex’s goals are persistent: they round-trip through the app-server, survive --resume, and can be paused on one machine and resumed on another.

Cursor’s CLI reference documents /goal [objective] as “Give the agent a long-lived objective to work towards until it’s fully complete. Rolling out.” — checked 2026-08-28 against cursor.com/docs/cli/reference/slash-commands. The “Rolling out” note is part of the entry itself, so treat availability as build-dependent and confirm the command appears in your build’s /help output before you script around it. An earlier version of this article said Cursor had no /goal; that was accurate for Cursor 3.5 and has since changed.

Two things the reference does not give you, and both change how a run behaves:

No documented evaluator. Claude Code and Codex each judge the stopping condition with a separate model call after every turn. Cursor’s entry describes the objective and nothing that checks it, so termination is left to the agent doing the work. When a condition has to be verified independently, the fix is a deterministic gate — a test command, a hook, a CI job — rather than a better-worded objective.
/loop is a skill, not a slash command. It does not appear in Cursor’s CLI slash-command reference (checked 2026-08-28), but Cursor 3.5 (20 May 2026) ships it as a bundled skill: “run a prompt repeatedly on a local schedule, until a certain outcome is achieved, or until you stop it” — see the /loop guide. For cloud-side cadence — polling a deploy, babysitting a PR while your laptop is closed — Cursor’s answer is Automations, which run cloud agents in the background on a schedule or in response to events from GitHub, GitLab, Slack, webhooks, Linear and more.

Agent mode remains the in-IDE alternative for multi-step work: it plans, edits across files, runs terminal commands, and iterates — but it is built around in-context reasoning with diff previews rather than an unattended run against a token budget, and it stops when it needs your input.

Writing a goal the agent can finish

The quality of an autonomous run is decided before it starts, in how you frame the objective. Five rules carry most of the weight:

One objective, one stopping condition. Bundling “migrate the API and improve test coverage” gives the checker two finish lines and it will thrash between them. Split them into two runs.
Make the condition a command. “Looks good” isn’t checkable; npm test exiting 0 is. Hand the agent the exact validation commands that prove progress — they become the gate every iteration must pass.
Point it at what to read first. Name the files, the plan, or the docs that define “correct.” An agent that has to guess the target wanders.
Ask for checkpoints. Request a short progress log each round. It gives you a place to interrupt and makes a long run auditable after the fact.
Bound the blast radius. State what’s out of scope and what it must never touch. A loop with no boundaries will happily refactor your auth layer to make a test pass.

A goal prompt that terminates cleanly:

Goal: migrate all components in src/components/ from the old useStore
hook to the new useAppStore API.

Read first: docs/migration/store.md and one already-migrated example,
src/components/Header.tsx.

Done when: every file under src/components/ imports useAppStore (not
useStore), `npm run typecheck` exits 0, and `npm test` passes.

Each round, append a one-line progress note to MIGRATION_LOG.md.
Do not change the store implementation itself or touch src/auth/.

/goal versus /loop

They sound similar and solve different problems:

/goal runs until a condition is true. The schedule is “as fast as possible until done.” Reach for it for convergent work with a clear finish line.
/loop runs on a cadence. The schedule is “every N minutes” (or a self-chosen interval). Reach for it for open-ended monitoring — polling a deploy, babysitting a PR — where there may be no single finish line.

A common combination: a /goal run drives a feature to “tests green,” then a /loop watches the resulting PR for CI failures and review comments.

Guardrails

Where to go next

The /loop command Run prompts on a schedule or a self-paced interval -- the cadence-based counterpart to /goal.

PRD → Plan → TODO methodology Structure the work before you hand it to an autonomous run.