/goal in Claude Code: Autonomous Mode and Agent View in 2026

Ailoot reference documentation: ailoot.ai/docs/.

What is /goal in Claude Code?#

Previously, Claude Code stopped after each response and waited for your next prompt. This worked for short tasks, but broke down on long ones: an API migration, fixing 12 failing tests, refactoring an 800-line file—these tasks require 20–30 iterations, and each one brought you back to the terminal.

/goal solves this problem with a simple idea: separate “the one who does the work” from “the one who decides what’s finished.” The main agent writes code. A separate evaluator (the fast Haiku model) reads the conversation after each turn and answers one question: “Has the condition been met?” If not, the agent starts another turn. If yes, control returns to you.

Anthropic’s official documentation defines it this way:

The mechanism that makes long autonomous runs possible is the combination of /goal + Agent View, introduced in the same release on May 11, 2026.

Why is autonomous mode needed: what was there before and after May 11, 2026?#

The idea of “leaving AI to work overnight” had existed since the fall of 2025, when Cursor Composer and Cline auto mode could already run in the background. But before May 11, 2026, Claude Code required a manual wrapper for this: a cron task that called claude -p every N minutes, or a wrapper that watched git status and launched the next prompt.

This DIY approach regularly led to disasters. On May 22, 2026, a developer left such a script running overnight and woke up to a $6,000 bill. The root cause: Anthropic silently changed Claude Code’s cache TTL from one hour to five minutes without an announcement. Cron called production every 30 minutes—the cache had time to expire between runs. Each run rebuilt an 800,000-token history from scratch. Writing fresh data to the cache costs much more than reading from an active one.

The developer wasn’t doing anything exotic—he was using the tool exactly as Anthropic advertised it.

/goal solves this problem with a built-in architecture:

1. Supervisor process that keeps the session outside your terminal and survives closing the window and the laptop going to sleep.
2. Haiku evaluator—an inexpensive model checks each turn; the evaluator’s tokens cost pennies.
3. Hard turn limit in the condition—you can explicitly write or stop after 20 turns, and the session is guaranteed to stop.
4. Worktree isolation for background sessions—changes go to a separate branch without touching your working copy.

The difference from the “write your own bash script” approach is that Anthropic makes all these mechanisms first-class parts of the tool, not third-party hacks.

How to enable /goal in 3 steps#

Step 1. Update Claude Code to 2.1.139 or newer.

Check the version:

claude --version

If it’s below 2.1.139, update:

claude update
# or force it through npm
npm install -g @anthropic-ai/claude-code@latest

Releases between May 12 and 19, 2026 fixed important bugs in the first version. In 2.1.140, they fixed a silent hang where disableAllHooks blocked the evaluator. In 2.1.143, worktree.bgIsolation: "none" and a fix for stop hook loops arrived. In 2.1.144 (May 19), --resume for background sessions and agents --json for scripting were added. The minimum is 2.1.143.

Step 2. Type /goal with a condition.

Open a regular Claude Code session and enter the command:

/goal all tests in test/auth pass and the linter is clean, or stop after 15 turns

You don’t need to send a separate prompt afterward—the command starts the first turn immediately. The condition can be written in Russian, English, or a mix; the model understands both languages. The length limit is up to 4,000 characters.

Step 3. Monitor via the live overlay.

After /goal starts, a live panel appears at the bottom of the terminal:

/goal active · 3 turns · 12m elapsed · 18,400 tokens · last: tests in test/auth/login.test.ts still fail

What it shows:

• Turns—how many turns have been completed
• Elapsed—how much time has passed since launch
• Tokens—total tokens spent (the main figure for budget monitoring)
• Last—the evaluator’s last reason for saying “not yet”

A useful trick: if the evaluator returns the same reason three turns in a row, that’s a sign you’re in a loop. Then press Ctrl+C or enter /goal clear (synonyms: stop, off, reset, cancel), rephrase the condition, and launch again. This is the main sign of looping: “stuck on one reason three times—this is a loop, exit.”

How to write a good condition: 5 rules + 5 examples#

Anthropic’s documentation describes three required elements of a good condition:

A ready-made template covers all three elements in one line:

/goal [do the work] until [measurable end state] without [constraints that must be observed]

Five rules that trip most people up:

Rule 1. The end state must be verifiable by a command, not by taste.

Not “make it look good,” but npm test exits 0. Not “improve UX,” but Lighthouse Performance score above 90. The evaluator reads only the transcript—it doesn’t run commands or look at screenshots. If the result can’t be recorded in text, the evaluator will never say “yes.”

Rule 2. Constraints must be explicit and narrow.

Without constraints, Claude might fix tests by deleting the tests themselves or commenting out failing assertions. Specify without modifying any file outside /auth, without removing existing assertions, without bumping major versions of dependencies.

Rule 3. A hard turn limit is required.

Add or stop after N turns to every condition. It’s a lifeline against an endless loop. Without a limit, a loop running for an hour burns more tokens than doing the same task manually. Budget for it.

Rule 4. Describe WHAT, not just HOW.

If you didn’t mention visuals in the condition, Claude won’t create them. If the condition requires only “tests pass,” Claude might comment out complex tests. Describe WHAT you want, not just HOW you’ll verify it.

Rule 5. Make Claude show evidence in the chat.

The evaluator doesn’t run commands—it only reads what Claude has already shown. If the condition requires “npm test is green” but Claude didn’t show the npm test output in the transcript, the evaluator will say “not yet” forever. Add the phrase “show the output of <command> in the conversation” to the condition.

Five working examples for common tasks:

1. API migration:
/goal every call to getUser() has been replaced with fetchUser(), npm test passes, npm run build is green, no other API names have been touched, or stop after 30 turns

2. Fixing tests:
/goal all failing tests in test/auth are now green (npm test shows 0 fails in the chat), without changing assertions or deleting tests, or stop after 20 turns

3. Code quality (file size):
/goal src/legacy/UserService.ts has been split into files under 200 lines each, all imports are updated, npm run build is green, or stop after 25 turns

4. Closing the backlog:
/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a worktree branch, open a PR. Continue until the queue is empty or 6 issues have been processed

5. Security audit:
/goal every npm audit vulnerability with severity >= high is fixed, all existing tests pass, no breaking API changes, or stop after 15 turns

5 examples where /goal really works#

Anthropic’s documentation gives four types of tasks for which /goal is a good fit:

Here are five examples with ready-made conditions—take them and adapt them to your project.

Example 1. Migrate a module to a new API.

Scenario: you’re moving from REST to GraphQL, or replacing the old getUser() function with the new fetchUser(). The task is mechanical but touches 30–50 files.

Condition:

/goal every getUser() in src/ has been replaced with fetchUser(), all calls updated to the new interface (id instead of userId), npm test passes, no files outside src/ touched, or stop after 30 turns

Why it works: the end state can be checked with grep -r getUser src/ | wc -l (should be 0) and npm test exits 0. The constraint protects test files.

Example 2. Fix failing tests.

Scenario: after a library update, 15 tests broke. You know the fix is mechanical—update mocks and adjust assertions to the new format. You don’t want to do it by hand.

Condition:

/goal all failing tests in test/ are now green, npm test shows the results in the chat with 0 failures, without deleting tests or commenting out assertions, or stop after 25 turns

Another example of the same kind of condition:

Fix all failing tests until npm test returns 0, without changing any file outside the /auth directory

Example 3. Break up a god class.

Scenario: one file with 1,200 lines contains everything—the model, service, utilities, and API client. You want to break it up according to the “one file, one responsibility” principle, update all imports, and keep tests passing.

Condition:

/goal src/legacy/UserService.ts has been split into files under 200 lines, each file handles one responsibility (model, repository, api-client, validator), all imports are updated, npm run build is green, existing tests pass, or stop after 25 turns

Example 4. Close the issue backlog overnight.

Scenario: you have an open-source repository with 20 issues labeled good-first-issue. You want Claude to work through them overnight.

Condition:

/goal process every issue labeled 'good-first-issue': read the description, implement a fix in a separate worktree branch worktree-issue-N, open a PR with a description. Continue until the queue is empty or 6 issues have been processed, or stop after 80 turns

The number 6 wasn’t chosen at random—it’s a realistic ceiling for one night on a Pro plan.

Example 5. Security audit.

Scenario: npm audit shows 8 high-severity vulnerabilities. You want Claude to fix them without updating major versions.

Condition:

/goal every npm audit vulnerability with severity high+ is fixed, npm audit shows 0 high in the chat, all existing tests pass, no breaking API changes, no major version bumps to packages, or stop after 15 turns

What NOT to do with /goal:

Don’t use /goal for tasks where “done” means “looks good,” “feels right,” “well designed,” or “fun.” The evaluator reads only the transcript—it doesn’t run tools and can’t assess how the result works.

When /goal burns money for nothing: 3 anti-patterns#

Anti-pattern 1. Vague condition without a hard turn limit.

The most common mistake is a condition like “improve the code” / “make it good” / “optimize it.” Without a turn limit, that agent will keep running until it burns through your quota.

One developer reported burning $200 over a 14-hour session with vague conditions: a weak condition that makes the evaluator keep saying “not yet” can run for 50, 100, or 500 turns before you notice.

$200 over 14 hours on a vague condition is the entire weekly limit on the Max plan. You wake up in the morning with no quota and no useful result.

Safeguard: end every condition with or stop after N turns (15 for easy tasks, 50 for hard ones, and 100 maximum for overnight runs).

Anti-pattern 2. Recursive loop with broken caching.

The story from May 22, 2026: $6,000 overnight because Anthropic quietly changed the cache TTL from one hour to 5 minutes. The developer wasn’t using /goal directly, but the logic was the same: an autonomous loop with a 30-minute cron timer rebuilt an 800,000-token history from scratch every time.

The root problem was that external automation didn’t know about the provider’s internal changes. The same thing could happen with /goal if you run it for 8 hours without supervision: token use grows nonlinearly, and the prompt cache doesn’t work the way you think.

Safeguards:

1. Don’t run /goal for 8+ hours without interim checks.
2. Enable usage limits in Settings → Usage (a new safeguard after the $6,000 incident).
3. Open claude agents twice overnight—peek with Space and check that the turn count isn’t growing faster than expected.
4. For expensive model chains (Opus 4.7), set a stricter turn limit—30 maximum.

Anti-pattern 3. Creativity through /goal.

The general rule: the evaluator optimizes exactly what you measure. If the condition doesn’t mention visuals, there won’t be any. If it only mentions tests, it might comment out assertions.

Safeguard: don’t use /goal for anything that relies on taste (design, copy, UX). Return to a regular session or Plan Mode—they keep you in the decision loop.

What is Agent View and how to open the dashboard#

If /goal is the command “work until you’re done,” Agent View is the control room where you can see all those commands at once. Anthropic describes it this way:

Command to open it:

claude agents

A TUI opens—a text dashboard inside the terminal. The session list is on the left, and the peek pane with the latest message from the selected row is on the right.

Six session states:

Main shortcuts:

↑ / ↓             move through the session list
Space             peek pane (view without attaching)
Enter / →         attach to a session (enter it)
←                 detach (leave without killing it)
Ctrl+T            pin (protect the session from auto-stopping)
Ctrl+X            stop the session; press again within 2 sec to delete
Ctrl+R            rename
Ctrl+S            toggle grouping (state ↔ directory)

How to start a background session:

From interactive Claude Code:

/bg fix the failing test test/auth/login.test.ts

Or directly from the shell:

claude --bg "fix the failing test test/auth/login.test.ts"

Or with a name (so it appears in Agent View under a recognizable label):

claude --bg --name "flaky-test-fix" "fix test/auth/login.test.ts"

The background session is automatically added to Agent View—launch with --bg, open claude agents, and you’ll see it in the list.

The main feature: sessions survive the laptop going to sleep and the window closing:

But shut down the laptop or manually reboot, and the background sessions end in Failed. Overnight runs with many background agents only work on a laptop that isn’t turned off.

Worktrees: how Claude isolates parallel sessions#

Worktrees solve the main problem with parallel autonomous work: what if two sessions try to edit src/auth.ts at the same time? Before 2.1.139, such sessions could literally overwrite each other’s changes. With Agent View, Anthropic introduced automatic isolation:

How it works in practice:

# Launched three background sessions:
claude --bg --name "fix-tests" "fix the failing tests in test/"
claude --bg --name "add-oauth" "add Google OAuth according to the plan in plans/oauth.md"
claude --bg --name "split-userservice" "split UserService.ts into modules"

# File structure after launch:
.claude/worktrees/
├── fix-tests/             # separate repo copy on branch worktree-fix-tests
├── add-oauth/             # separate copy on branch worktree-add-oauth
└── split-userservice/     # separate copy on branch worktree-split-userservice

Each session works in its own copy. When the task is done, you merge the needed branches into main.

Dangerous pitfall—deleting a session deletes its worktree.

If you kill a session in Agent View (press Ctrl+X twice), its worktree disappears. All uncommitted changes are lost. Before deleting a session in Agent View, always commit or push.

Opt-out (for rare cases):

If you have a repository where git worktrees don’t work (for example, a setup with symlinks or a large monorepo with a slow checkout), you can disable isolation:

// .claude/settings.json
{
  "worktree": {
    "bgIsolation": "none"
  }
}

Then background sessions will edit your working copy directly. This opt-out arrived in 2.1.143 after complaints from teams with large monorepos.

Parallelism burns quota:

That means a Pro plan ($20/month) is enough for 1–2 parallel sessions overnight, not ten. If you want to run many agents in parallel, you need Max or Enterprise.

Combining /goal + Plan Mode + subagents for long tasks#

A typical failure is to immediately type /goal build a new feature. This doesn’t work because the evaluator doesn’t know what a “finished feature” looks like. You need a plan with checkboxes that the evaluator can verify one by one.

Layer 1. Plan Mode writes a phased plan.

In Plan Mode, ask Claude to create a detailed change plan divided into 5–7 phases with verifiable checkboxes. Save it as plans/2026-05-24-google-oauth.md. Each phase has 3–7 checkboxes with concrete actions.

Layer 2. Subagents divide the work by phase.

If the plan can be parallelized (for example, the phases are independent—a backend endpoint + frontend form + DB migration), you can launch each phase in a separate background session via claude --bg --name "<phase>". Each session gets its own worktree.

Layer 3. /goal runs the cycle until the checkboxes are complete.

/goal all phases 1–7 in plans/2026-05-24-google-oauth.md are complete and marked [x], all tests in test/auth pass (npm test shows 0 failures), npm run build is green, or stop after 50 turns

After each turn, the evaluator reads the plan, checks which boxes are complete, and if anything remains, the agent continues.

This combination relies on three components:

• the right context in plans/—the evaluator reads it
• the plans/ folder stores the plan between sessions (second brain)
• CLAUDE.md sets the rules the agent follows

Without CLAUDE.md, /goal may suggest a solution that breaks the architecture. Without a plan in plans/, the evaluator doesn’t know the success criteria. Without subagents, there are no parallel phases; everything is sequential.

How to compare /goal with Codex, Cursor, and other agent modes#

/goal adds a separate completion check after each turn. Other products have different modes, and a local CLI, hosted cloud task, and supervised editor session are not interchangeable comparison units. In particular, do not describe all Codex CLI work as a cloud container or assume one validator model and one billing method for every Codex run.

Use the same repository snapshot and task with the same acceptance checks. Record these dimensions for each candidate:

A claim that one tool uses a fixed multiple more tokens needs those conditions and measured counts for the same successful outcome. A benchmark percentage likewise needs its benchmark version, model, harness, and run settings; Terminal-Bench percentages without those details are not a substitute for that evidence. This article provides no independent cross-tool benchmark.

Choose based on the workflow you need: supervised edits, a bounded background task, or a multi-turn task with an explicit completion condition. Test the installed product’s supported mode rather than assuming an entire competitor lacks autonomous operation. Keep permission approval separate from task continuation: automatically approving a tool call does not by itself establish that the user’s goal has been met.

/goal vs /loop:

/loop is another command from the same release, and it launches periodic tasks at a time interval (every N minutes). /goal is condition-based (until it is met). Use /loop for cron-like tasks and /goal for discrete goal achievement.

From Anthropic’s documentation:

Pre-launch /goal checklist: 7 items#

Checklist before every /goal run:

1. Claude Code version 2.1.139+—check with claude --version and update if lower. The minimum recommended version is 2.1.143 (May 15, 2026), which fixes stop hook loops.

2. The condition includes a verifiable end state—instead of “improve it,” specify npm test exits 0. If you can’t come up with a bash command to verify the result, /goal isn’t for this task.

3. There is a hard turn limit—every condition specifies or stop after N turns. Use 15 for easy tasks, 50 for hard ones, and 100 maximum for overnight runs.

4. Constraints are explicit and narrow—without modifying files outside /auth, without removing existing assertions, without bumping major versions. Without them, Claude may fix tests by deleting the tests themselves.

5. All important changes are committed or pushed—if you’re not working in a worktree (for example, worktree.bgIsolation: "none"), Claude edits your working copy. Any mistake could mean losing unsaved work.

6. Usage limits are enabled in Settings → Usage—a new safeguard after the $6,000 incident. Set a limit per day, per session, and per month.

7. Agent View claude agents is open in a separate window—for long tasks, peek with Space once an hour. If the turn count grows faster than expected or the evaluator repeats the same reason for three turns, press Ctrl+C and rephrase the condition.

One additional item—never run /goal with --dangerously-skip-permissions on someone else’s or unfamiliar code. That combination disables all checks and lets the agent do whatever it wants in your project. The author of this analysis uses it only in a fresh worktree where there is nothing to lose.

/goal is a powerful feature, but it isn’t magic. It works exactly as well as you can formulate the condition. If you can describe “done” in words so that a command can verify it, /goal will do the rest. If you can’t, return to a regular session or Plan Mode.

You can continue exploring Ailoot at ailoot.ai.