Claude Code /goal: Set a Finish Line, Walk Away, Come Back Done

You give the task. You go make coffee. You come back an hour later — Claude is done. That’s a marketing pitch every AI company has promised for five years. It’s failed five times.

This time it works better. Not perfectly — but enough to change how you work this Monday.

/goal shipped on May 11, 2026 in Claude Code 2.1.139. One widely-shared Medium piece calls it “the single most underrated AI feature of 2026”. Pasquale Pillitteri calls it “the command Codex invented and Claude Code copied in 11 days”. Both are overstated, but neither is wrong.

What /goal Actually Does

Default Claude Code follows one rule: one prompt → one turn → it waits for you. Even if Claude returns 800 lines of code, it stops and waits.

/goal inverts that. Instead of giving steps, you give a goal — something that can be verified. Claude works on its own across as many turns as needed. After every turn, a fast evaluator model (Haiku) reads the transcript and answers one question: is the condition met?

If no, it says why — and that sentence becomes the next instruction. If yes, /goal clears and control returns to you. No second prompt in between.

In one sentence:

You give a condition. Claude works. Haiku checks the transcript after each turn. The moment it says “yes”, the goal is done.

A Concrete Example

Vague goal:

/goal make this codebase better

This doesn’t work. Haiku has nothing to evaluate. Claude will keep going, the evaluator will keep saying “not measurable”, and tokens will drain. One developer on Reddit reportedly burned through their weekly Max-plan ($200/mo) token allowance in 14 hours of overnight /goal runs on a goal like this.

Measurable goal:

/goal `rg 'legacy_client'` returns no matches under services/checkout;
      `go test ./...` exits 0;
      diff touches only services/checkout;
      or stop after 40 turns

Three measurable conditions plus a hard cap. Haiku reads the transcript, finds the rg result, finds the test exit code, looks at the diff scope, and either says “yes” or names exactly what’s missing.

That’s the difference between “make it better” and “npm test exits 0 and no file outside src/auth/ changes”.

Status checkpoint

Type /goal with no arguments any time and you see:

• the active condition
• elapsed time
• turn count
• token spend
• the evaluator’s last reason

That’s your early-warning system. If after ten turns the evaluator keeps saying “not yet, claude says it ran tests but didn’t show output”, the condition is badly written — stop (/goal clear) and rewrite.

What /goal Doesn’t Do

This matters more than the feature list. Most /goal problems are problems with how people use it, not with the model.

The evaluator can’t run a command. It only sees the transcript. If Claude writes “I ran the tests” instead of actually showing output, Haiku has nothing to grade. Force Claude to print the raw output of whatever you’re measuring — exit code, match count, file contents.

No hard token cap. /goal will keep running until the condition is satisfied or you stop it. Bake limits into the condition itself: or stop after 40 turns, or stop if 90 minutes elapse. The status view (/goal with no args) shows current spend — watch it during the first hour.

One goal per session. A new /goal replaces the previous one. No queues, no nested goals.

Trust mode required. It won’t run in an untrusted workspace. If you have disableAllHooks set, also no.

It’s not the sci-fi autonomous agent. You still need clear scope, sane sandboxing, real measurable outputs. /goal only judges whether what Claude wrote in the transcript matches what you asked for.

/goal vs. Other Autonomous Workflows

/goal isn’t the first attempt at autonomous Claude Code. Here’s a quick decision map:

Short answer: use /goal when you have a measurable end state and want to walk away. Use /feature-dev when you want a better plan and human-driven iteration. Use /loop when you need a periodic pulse, not autonomy.

And the frame from Skills vs. Agents still holds: skills first, agents next. /goal gives you a new way to build an autonomous agent out of work you used to do by hand — but it won’t turn a bad brief into a good workflow.

What to Do This Week

Three small moves, no big program:

1. Check your version. claude --version — if it’s below 2.1.139, upgrade. /goal isn’t there.

2. Pick one task with a verifiable goal. Something you currently iterate on by hand: fix failing tests in one module, add missing type signatures, run the linter and clear warnings. The goal has to be hard-measurable — npm test exits 0, tsc --noEmit exits 0, no warning in output.

3. Issue it with a hard cap. Copy and adapt:

/goal <your condition>; or stop after 30 turns

After the first run, type /goal (no arguments) and check what it cost. Under $1 with the condition passing → you have a new workflow. Over $5 and the condition still hasn’t passed → the condition was vague, rewrite it more concretely.

If you want to figure out how to wire /goal smartly into your workflow — Claude Code, agent boundaries, MCP servers, custom skills — and walk it through a live task, 1:1 AI mentoring is exactly the right fit. One hour, a map of your setup, concrete next steps. For full teams a workshop makes more sense.

Summary

• /goal is the first official Anthropic autonomous-loop primitive in Claude Code (2.1.139+, May 11, 2026).
• Works on verifiable completion conditions — vague goals = expensive loops.
• The evaluator is Haiku, transcript-only, can’t run a command. Force Claude to surface raw output.
• Always bake a hard cap into the condition: or stop after 40 turns.
• Status: /goal (no args). Cancel: /goal clear or aliases.
• For the broader autonomy story, the frame from Skills vs. Agents still holds — /goal adds a tool, not a strategy.

Pick one verifiable goal. Bake the cap. Measure. Then decide whether to scale.

— Jirka

You Might Also Like

• Anthropic’s Last 30 Days: Cowork Is Out of Preview, Opus 4.7 Is Live
• Shift+Tab Is a Trap: Why Your AI Plan Ignores Half Your Codebase
• Loop: An Autonomous Agent in Your Terminal
• Skills vs. Agents: When You Need a Recipe and When You Need a Chef