Long tasks do not need more prompting. They need a finish line.
A normal AI coding turn has an ambiguous ending. The agent makes progress, summarizes what it changed, and hands control back. That is useful for a small edit. It is frustrating when the actual job is a migration, a release audit, a failing test suite, or a research brief with ten acceptance criteria. The first hard step gets done, but the full outcome is still somewhere over the horizon.
The usual workaround is manual supervision: read the summary, notice what is missing, type another prompt, and repeat. The problem is not that the model cannot continue. The problem is that the session has no explicit rule for deciding whether the work is complete.
Claude Code Goal Mode gives that decision a name. You set a completion condition with /goal, Claude keeps working across turns, and a separate evaluator checks the condition after each turn. If the evidence is not there yet, another turn begins. The loop stops when the condition is met, not when the first answer sounds finished.
What /goal changes
A goal is different from asking the agent to try hard or work for a long time. Duration is not success. A goal describes the state that must be true at the end, then makes that state the gate between one turn and the next.
Under the hood, Claude Code evaluates the condition after each turn with a small, fast model. That evaluator is separate from the model doing the work, so the worker does not grade its own claim of completion. A negative result comes back with a short reason, and that reason guides the next turn. A positive result clears the goal and records that it was achieved.
Onevium 1.1.19 brings this loop into the conversation surface. The session keeps the condition visible alongside the number of evaluations, elapsed time, and the latest check. Long-running work still behaves like a normal conversation, but you can see why it is continuing instead of staring at an indefinite spinner.
The evaluator only knows what the transcript proves
The evaluator does not independently open files or run commands. It judges the condition from evidence Claude has surfaced in the conversation. That detail changes how a useful goal should be written.
If the condition says only "finish the migration," the evaluator has to interpret what finish means. If it says "every old API call is gone, npm test exits 0, npm run typecheck exits 0, and no fixture files changed," Claude knows what to inspect, what to run, and what results must appear in the transcript.
A good completion condition therefore works like a compact acceptance test. It names the outcome, the proof, and the boundaries that must survive the work.
A strong completion condition has four parts
You do not need a long specification for every goal. Four ingredients are enough to turn an open-ended request into a loop that can converge.
- One measurable end state — all tests pass, every call site is migrated, a queue is empty, or a report contains every required section.
- An explicit check — name the command, query, count, or inspection that proves the state is true.
- Important constraints — say what must not change, which scope is allowed, and which risks require approval.
- A bound — include a turn or time limit when the work could expand indefinitely, such as "or stop after 20 turns and report the blocker."
Completion conditions you can adapt
The best goal is concrete enough to verify and broad enough to let the agent choose the path. These patterns cover many of the long jobs that otherwise turn into a chain of follow-up prompts.
- Migration — migrate every oldClient call to newClient; npm test and npm run typecheck must exit 0; do not modify fixtures; stop after 20 turns if blocked.
- Release readiness — complete every item in the release checklist, attach the build and smoke-test evidence, leave unrelated files untouched, and report any gate that cannot be verified.
- Regression repair — reproduce the failure, add a test that fails before the fix and passes after it, run the focused suite, and show the final diff.
- Repository audit — inspect every package in the workspace, record each finding with a file reference and severity, and finish only when the inventory has no unchecked package.
- Research brief — answer every question in the brief with a primary source, mark unsupported claims explicitly, and include a decision table with risks and unknowns.
Visibility is part of reliability
An autonomous loop is only useful when the user can tell whether it is converging. The completion condition should remain visible. The latest evaluator reason should be readable. Elapsed time and iteration count should make a stuck loop obvious before it burns an afternoon.
That is why Onevium treats Goal Mode as session state rather than a hidden command response. You can move through the rest of the app, return to the conversation, and still see what the session is trying to prove. The progress surface does not make the evaluator smarter; it makes the automation accountable.
Permissions remain separate. A goal can continue across turns, but it does not silently approve sensitive tools. Pair it with the permission mode that fits the task, and keep manual approval for actions whose consequences cannot be safely reversed.
Choose the right runtime for the job
Goal Mode solves one specific problem: keep the current session moving until a verifiable condition is met. Other runtimes solve different shapes of work, and they can be combined without pretending they are interchangeable.
- Goal Mode — use it when one session should keep iterating toward a finish line.
- /loop — use it when a time interval, rather than completion of the previous turn, should trigger the next run.
- Auto mode — use it to reduce per-tool approval prompts inside a turn; it does not start another turn by itself.
- Stop hooks — use them when a reusable script or prompt should enforce completion logic across every session in a project or user scope.
- Ultracode — use it when the work should fan out to multiple agents for parallel research, implementation, or verification.
- Scheduled runs — use them when time, not the previous turn, should start the next job: nightly checks, weekly reports, or recurring monitoring.
- Channel workflows — use them when the result needs to start from or return to Feishu, DingTalk, or Discord.
Keep the loop bounded
The underlying /goal command requires Claude Code 2.1.139 or later, a trusted workspace, and hooks that are not disabled by managed settings. If one of those requirements is missing, Claude Code reports why the command is unavailable instead of starting a partial loop.
A vague goal can loop for the same reason a vague project can: the finish line keeps moving. Prefer one outcome over a wishlist, require evidence rather than confidence, and put exploratory improvements outside the condition unless they are truly necessary.
If a session ends while a goal is still active, Claude Code restores the condition when that session is resumed or continued. The timer and evaluation count start fresh after resume, while a goal that was already achieved or cleared stays finished.
Use /goal with no argument to check the current state, and /goal clear when the condition is wrong, the priorities changed, or the remaining work needs a human decision. Clearing a goal is not failure. It is the correct response when the automation no longer represents the task you want done.
Start with a job you already know how to verify: a test suite, a migration count, a release checklist, or a finite audit. Onevium 1.1.19 makes the loop visible in the desktop conversation, so update to the latest release, set one measurable condition, and let the evidence decide when the work is done.