Running Coding Agents Unattended: /loop, /goal, and the Discipline That Keeps It Safe

I handed a coding agent a night’s worth of work and went to bed. The task needed nothing from me. I woke to one finished step and a note describing the step it planned to take next.

The agent had built a clean plan, executed the first step, then stopped and waited for my go-ahead. I told it to continue. It finished the next step and stopped again. Four more times. What I expected to run while I slept turned into three hours of resuming a tool that already knew exactly what to do.

The tool did not fail. The configuration did. An agent that plans the work and then halts after every step runs that way because nothing told it to keep going, and because the operator never set the one condition that defines when to stop. Both halves have fixes, and the fixes ship in the tools already.

Why the agent stops after every step

A coding agent works in turns. It takes a turn, produces output or an action, and returns control to you. Left alone, it treats the end of a turn as the end of its job.

Two separate prompts interrupt an overnight run, and operators conflate them.

The first pauses the agent for per-tool approval: it wants to run a command or edit a file and asks permission. The second pauses it for the per-turn stop: it finishes what it set out to do this turn and hands control back, even when its own plan holds more work.

Approving tool calls automatically solves the first and leaves the second untouched. That distinction explains my three hours. My edits ran without prompting, and the agent still stopped after each step, because approving an action and starting the next turn count as different decisions.

The primitive that fits overnight work: /goal

Claude Code ships a command built for exactly this. /goal sets a completion condition and keeps the agent working toward it without a prompt at each step.

You type the condition:

/goal all tests in test/auth pass and the lint step runs clean

Setting the goal starts a turn immediately. After each turn, a separate evaluator model reads the condition against what the agent has surfaced in the conversation and returns one of three verdicts: not yet met, met, or impossible. On “not yet met,” the agent starts another turn and treats the evaluator’s reason as guidance. The goal clears on its own when the condition holds, when the evaluator judges it unreachable, or when a turn hits an error you have to fix.

Three details decide whether a goal runs clean through the night.

Write a condition the agent’s own output can prove. The evaluator does not run commands or read files on its own. It judges what the transcript shows. “All tests in test/auth pass” works because the agent runs the tests and the result lands in the conversation. “The code is clean” gives the evaluator nothing to read.

Bound it. Add a turn or time clause to the condition, such as “or stop after 20 turns.” An unbounded goal against a condition the agent cannot reach burns the night and the token budget on nothing.

Run it in auto mode. A goal does not change your permission mode. It removes the per-turn stop; auto mode removes the per-tool prompt. You need both for an unattended run. Leave one out and the run stops the way mine did. Auto mode alone approves the actions and still halts after each step. A goal alone keeps taking turns and still pauses on every approval.

Run /goal with no arguments to see the condition, elapsed time, turns evaluated, and token spend. Run /goal clear to end it early. It works non-interactively too: claude -p "/goal CHANGELOG.md has an entry for every PR merged this week" runs the loop to completion in one invocation.

When to reach for /loop instead

/loop solves a different problem. It re-runs a prompt on a time interval rather than driving toward a finish line.

/loop 5m check my PR, address review comments, and fix failing CI

That fits recurring work: watch a pull request, retry a flaky deploy, poll a queue. It stops when you cancel it or the work it checks completes. One limit matters for overnight use. /loop runs on your machine, so closing the laptop ends it. To run a recurring job in the cloud, independent of any open session, create a routine with /schedule.

The rule of thumb holds across the three: /goal for “finish this defined body of work,” /loop for “keep checking this on a cadence,” and a scheduled routine for “run this every night whether or not I sit at the keyboard.” Match the loop interval to how long a cycle takes. A thirty-second loop wrapped around a five-minute test suite overlaps itself and wastes rate limit.

The same capability in other tools

This pattern reaches across the category.

Cursor ships Auto-Run, the setting it formerly called YOLO mode, which lets its agent run terminal commands and edit files without stopping at every prompt, governed by allow and deny lists. Cursor also runs Background Agents that work asynchronously while you do something else.

Windsurf offers Turbo mode, which lets its Cascade agent execute terminal commands automatically unless a command sits on the deny list.

The agent CLIs carry their own hands-free flags for scripted, non-interactive runs.

The names differ and the defaults differ, but the shape holds. Every one of them separates “do not ask me before each action” from “keep working until the job is done,” and every one of them hands you the second only when you define what done means.

Hands-free does not mean oversight-free

The settings that let an agent work through the night let it work in the wrong direction through the night with equal confidence. The capability ships in the box. The discipline does not.

Six controls turn an unattended run from a gamble into a tool.

Define done as a verifiable end state. A test result, a clean build, an empty queue. A fuzzy target never closes, and the agent either runs forever or declares victory on nothing.

Cap the run. A turn limit or a time clause, so a goal that cannot reach its condition stops instead of spending until morning.

Guard the path. Require that existing tests keep passing as part of the condition, or the agent satisfies the goal by breaking something the goal never mentioned.

Work against a clean git state in a sandbox. Commit before you start. An agent editing files unattended should write where you can diff and revert every change.

Keep a kill switch and know you can pull it. Ctrl+C ends a goal or a loop. A control you have never exercised offers false comfort.

Review before you trust. Watch the first cycle to confirm the agent drives straight, then read what it produced before you build on it. The first pass tells you whether the run earned the night.

The takeaway

An agent that stops after every step of a plan it wrote itself did not fail you. It ran with half a configuration. Approving its actions keeps it from pausing on permission. Defining a verifiable goal keeps it from pausing between steps. Bounding, guarding, and reviewing the run keep it from finishing the night pointed the wrong way.

I lost three hours learning that the capability already sat in the tool. Set the goal, run it in auto mode, cap it, guard it, and the overnight work finishes while you sleep, the whole reason you handed it over.