Two changes in Claude Code v2.1.139 are worth more than the rest of the release notes combined. The /goal command lets you set a completion condition and have Claude keep working across many turns until the condition holds. Agent view is the CLI dashboard that finally puts every background session on one screen.
Together they fix a class of workflow problems that anyone running Claude Code across multiple long tasks has been silently working around. This article walks through what each one actually does, how the two fit together, and the gotchas worth knowing before you point a /goal loop at a 30-turn migration.
What Claude Code /goal actually does
The /goal command takes a condition in plain language and keeps Claude working until that condition is met. The shape of the loop:
/goal all tests in test/auth pass and the lint step is clean
Setting the goal starts a turn immediately. The condition itself is the directive, so you do not send a separate prompt. After each turn finishes, a small fast model (Haiku by default) reads the condition and the conversation so far and returns a yes-or-no decision plus a short reason. A "no" tells Claude to keep working and passes the reason as guidance for the next turn. A "yes" clears the goal and records an achieved entry in the transcript.
That two-model split matters more than it looks. The agent doing the work does not also get to decide when it is done. Anthropic calls out the trade-off explicitly in the official docs. When a single model judges both what to do and when it is finished, you get mission drift. A separate evaluator pulls that decision out of the agent and forces it to live in a different model run. Cheap insurance against an agent declaring victory too early.
The condition can be up to 4,000 characters. You can bound the run with a clause like "or stop after 20 turns". Claude reports progress against that clause each turn and the evaluator judges it from the conversation.
/goal works in interactive mode, in -p for headless, in the desktop app, and through Remote Control. The -p form runs the loop to completion in a single invocation, which is exactly what you want for the CI patterns I walked through in my guide on Claude Code CI/CD and headless production usage.
Writing a condition that holds up
The evaluator only sees the conversation. It does not call tools, does not read files, does not run commands. So a good condition is 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 for the evaluator to read. "The code is clean" does not work, because cleanliness is not measurable from a transcript.
A condition that survives 30 turns tends to have three components: a measurable end state (a test result, a build exit code, an empty queue, a file count under a budget), a stated check (the literal command Claude should run to prove the state holds, such as npm test exits 0 or git status is clean), and any constraints that must not change on the way there. The last one is the part people forget. Without it, the agent will gleefully reach the end state by deleting whichever inconvenient test was failing.
A few examples that hold up across many turns:
/goal every call site of fetchUser in src/ now uses fetchUserV2,
all tests in test/users pass, and no other test file is modified
/goal CHANGELOG.md has an entry for every PR merged this week.
Prove it by listing the PRs and showing the matching CHANGELOG lines.
Stop after 15 turns if the list is incomplete.
/goal split src/server.ts into focused modules under 300 lines each.
npm test exits 0 and npm run typecheck exits 0.
No public exports change.
The last one is the kind of refactor that used to require babysitting Claude every five minutes. With /goal, you set it, walk away, and either come back to a clean diff or come back to a transcript explaining exactly why the evaluator kept saying no.
Agent view, and why it changes the day-to-day
Before agent view, multiple background sessions in Claude Code meant juggling terminal tabs. You started a session, sent it to the background with /bg, opened a new terminal, started another one, and tried to remember which window had which agent. By the third or fourth concurrent session, the system worked against you.
Agent view replaces that with a single command:
claude agents
You get a list where every row is one Claude Code session, surfacing four signals at a glance: the session ID, whether it is waiting on you, the last assistant response, and the timestamp of the last interaction. From the list, you reply, attach to a session interactively, or send a new instruction without losing context.
The agent view also adds new CLI flags for sessions dispatched into the background: --add-dir, --settings, --mcp-config, --plugin-dir, --permission-mode, --model, --effort, and --dangerously-skip-permissions. Each background session is configured independently. You can run one agent with high reasoning effort against your monorepo and another with a tight permission mode against an experimental sandbox, and the agent view treats them as peers.
/resume also picks up background sessions now. Anything started via claude --bg or via the agent view appears alongside interactive sessions in the resume list, marked with bg. The result is that the boundary between "a session I am in" and "a session I started and walked away from" stops mattering.
This pairs naturally with the multi-agent patterns I covered in my piece on Claude Code subagents and parallel work without chaos. The subagent model gave you parallelism inside one session. Agent view gives you parallelism across sessions. Both layers compose.
/goal versus /loop versus Stop hooks
/goal is one of three ways to keep a Claude Code session going across turns. The distinction is what fires the next turn.
/goal fires the next turn after the previous one finishes, and stops when a model confirms the condition is met. /loop fires on a time interval, regardless of completion, and stops when you stop it or Claude decides the work is done. A Stop hook fires after every turn and stops when your own script or prompt says so.
/goal is the right choice when you have a verifiable end state and you want the model to keep iterating until it holds. /loop is the right choice for periodic work where the trigger is wall-clock time, like polling a queue every 5 minutes. Stop hooks are the right choice when your stopping rule is complicated enough to need a script of its own, or when you want it applied across every session in scope.
The internals matter too. /goal is, under the hood, a session-scoped prompt-based Stop hook with a fixed evaluation prompt. If you find yourself writing the same /goal condition every day, promote it to a real Stop hook in your settings file and stop typing it. The patterns are covered more fully in my Claude Code power user guide on skills, hooks, and subagents.
Production gotchas worth knowing
Background sessions consume quota exactly like interactive ones. Ten agents in parallel burn quota ten times faster than one. That sounds obvious until your dashboard shows you blew through a day's worth of usage by lunch because you forgot one of those sessions was stuck in a retry loop. Agent view helps because you can see all of them at once, but the discipline is on you.
The evaluator can be fooled. It only sees the conversation. If Claude declares "all tests pass" without actually running the tests, the evaluator may believe it. Two defenses: require the literal command output in the condition ("npm test exits 0 and the last line of output is Tests: passed"), and review the transcript before trusting an achieved goal. The evaluator is good. It is not infallible.
The trust dialog matters. /goal only runs in workspaces where you have accepted the trust dialog, because the evaluator is part of the hooks system. It is also unavailable when disableAllHooks is set or when allowManagedHooksOnly is set in managed settings. In each case, the command tells you why instead of silently doing nothing.
Resuming a goal partially resets state. A goal still active when a session ended is restored on --resume or --continue. The condition carries over, but the turn count, timer, and token-spend baseline all reset. If you were bounding the run with "stop after 20 turns", resuming gives the agent another 20 turns. Plan for it.
Agent identity does not extend to memory. Background agents share the workspace and any saved files, but Claude Code itself does not consolidate cross-session memory the way Claude Managed Agents does (which I covered in the Dreaming piece earlier this week). The wins from running many agents in parallel are coordination wins, not learning wins. If you want the latter, the Managed Agents stack is the path.
When /goal pays off most
The shape of work where /goal earns its keep:
A migration with a measurable end. Every call site of an old API converted to the new one. The condition writes itself: "every call site of fetchUser in src/ uses fetchUserV2, all tests in test/users pass."
A refactor with budget constraints. Splitting a god file into smaller ones, each under N lines, without breaking the build. Conditions can express budgets.
A backlog with a clear empty state. Working through labeled issues until the queue is empty. The condition is literally "the queue is empty".
A long-running validation. Running benchmarks until variance settles below a threshold. The model can iterate on the configuration and the evaluator checks the threshold.
The shape where /goal is the wrong tool: open-ended creative work, anything where the end state is judged by taste rather than a measurable check, anything where you are not actually willing to walk away. If you find yourself watching the agent every few turns, /goal is overhead. Use it for the work you would otherwise have to babysit, not for work you wanted to babysit anyway.
Closing thoughts
The two features together feel less like a release and more like a missing layer. /goal removes the per-turn prompt. Agent view removes the per-session terminal. What is left is closer to "I have a fleet of agents, here is the shape of work for each one, ping me when something needs me."
That mental model lines up with where the broader Anthropic stack is heading. Claude Managed Agents already shipped outcomes (the cousin of /goal for managed runs) and multiagent orchestration the same month. Claude Code is catching up on the developer-machine side. The same pattern in two places usually means it is the right pattern.
The piece worth investing in now is the discipline. Write conditions that are measurable. Constrain the things that must not change. Watch quota on parallel sessions. Trust the evaluator but read the transcript. The features are sharp tools, and sharp tools cut faster in both directions.