The /goal Command: Goal-Directed Autonomous Runs

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.

Caution

Native support is uneven across tools — this is the most important thing to know. /goal is a first-party command in Claude Code and Codex. Cursor has no /goal command; its closest equivalents are Agent mode and Automations (covered below). Don’t assume a workflow built around /goal ports verbatim to Cursor.

What you’ll walk away with

• What /goal actually does and how the plan → act → test → review loop terminates
• Exactly how to enable and drive it in Claude Code and in Codex
• What to reach for in Cursor, which has no native /goal
• 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:

1. Plan — decide the next concrete step toward the objective.
2. Act — make the change.
3. Test — run the validation commands you defined.
4. 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

Claude Code

/goal is built in. 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 evaluates the stopping condition after each round and ends the run when it’s satisfied.

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.

Codex

/goal shipped in Codex CLI 0.128.0 (April 2026) as an experimental feature and is now a documented use case. Enable it once, then prefix your work with the command.

Turn it on in config.toml:

[features]
goals = true

Or from the shell:

codex features enable goals

Then drive it:

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

Control a run with /goal (show current goal), /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.

Cursor

Cursor has no native /goal command — a community feature request for “Goal Mode like Claude Code’s” is open as of mid-2026. Two existing features cover parts of the job:

• Agent mode runs autonomous, multi-step tasks inside the IDE: it plans, edits across files, runs terminal commands, and iterates — but it’s built around in-context reasoning with diff previews, not an unattended run against a token budget. It stops when it needs your input.
• Automations run an agent on a schedule or in response to events (file saves, commits, test failures), which overlaps more with /loop than with /goal.

For a true goal-directed loop in Cursor today, you either drive Agent mode manually or install a community skill that reproduces the pattern.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Tip

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

Caution

An autonomous loop will do whatever it takes to satisfy the checker, including things you didn’t intend.

• Watch the budget. Codex runs against your weekly quota; a poorly bounded goal can burn it in one sitting. Set a stopping condition that’s actually reachable.
• Constrain irreversible actions. Be explicit about whether the agent may push, delete, or deploy. Don’t let “done when it’s deployed to staging” be a side effect of a loop you walked away from.
• A green test is not a correct one. Loops are excellent at making tests pass — sometimes by weakening the test. Review the diff, not just the exit code.

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.