Interactive vs unattended AI coding sessions

Interactive vs unattended AI coding sessions differ in one thing above all: who is present when the agent makes a decision. In an interactive session you sit at the terminal, see each step and approve or redirect as it goes. In an unattended session the agent works without you, either as a single scheduled or headless task or as a run across several tasks you authorized in advance, and you judge the outcome afterwards. Interactive work buys safety and steering with your attention. Unattended work frees your attention but moves every decision about authority, scope and stopping to before the run, and every judgment about quality to after it. Neither mode is more advanced. The right choice depends on how well the task is specified, how reversible its effects are and how good your checks are. This page compares three working modes on authority, supervision and failure handling. Scheduling mechanics are covered separately in scheduled agent tasks.

Interactive sessions: authority by presence

In an interactive session the authority to act is effectively you. Claude Code asks before many actions depending on its permission settings, and Codex CLI's approval modes decide when it stops to ask; either way, a person is there to answer. You can start in Claude Code's plan mode, read the proposal, correct it and only then let it edit.

Supervision is continuous but shallow. You see every step, which catches obvious wrong turns early: the agent opening the wrong module, misreading the error, deciding to rewrite a test. But watching is not reviewing, and a long session of approvals trains you to approve.

Failure handling is immediate. When the agent goes in circles you stop it, add the missing fact and continue. When it breaks something you see it in the next command.

The cost is your time and focus for the whole duration. Interactive mode fits tasks where the requirements are still forming, where the code is unfamiliar, where a mistake would be expensive to undo, or where you want to learn the codebase alongside the agent. It scales badly: one person can steer only one or two sessions with real attention.

Unattended single tasks: authority decided in advance

An unattended single task is one agent invocation that runs without you: a nightly review job, a headless run through Claude Code's print mode or Codex CLI's codex exec, or a task fired by a scheduler. Everything you would have decided live now has to be decided beforehand.

Authority: what may the run change, if anything? A review task that only reads and reports is low risk. A work task that edits code needs a written scope and should start with the narrowest permissions the CLI offers for that job.

Supervision: none during the run, so the record matters more. You need the prompt it received, what it touched, what it ran and what the checks returned.

Failure handling: a failed run should leave a clear outcome and stop, not retry indefinitely. A run that ended ambiguously, such as one killed mid-write, needs a person to look before anything is repeated. See recovering interrupted agent work.

Unattended single tasks fit well-specified, repeatable work with an independent check: dependency audits, test triage reports, documentation refreshes, small fixes with clear acceptance tests.

Authorized multi-task runs: a budget of decisions

The third mode lets an agent work through several tasks in sequence without you approving each one. This is where unattended work becomes genuinely different, because the run makes decisions between tasks: what to pick next and whether the previous one counts as finished.

Sound designs keep those decisions narrow. The owner authorizes an explicit list of tasks, not a goal. One task runs at a time. There are limits on launches, retries, duration and failures, plus pause and stop controls. The next task is picked only after the previous one passed checks that did not rest on the agent's own say-so. Work the agent discovers along the way is recorded as new tasks but not added to the run, because nobody authorized it.

Supervision is periodic: you review the run's record, not its keystrokes. Failure handling must be conservative: stop at the first unverified completion, and never replay an uncertain step blindly.

This mode fits a backlog of small, well-specified, independently checkable tasks. It fits badly when tasks are vague or interdependent in ways nobody declared. Bounded autonomous runs covers the limits in detail.

Choosing a mode for a given task

Three questions settle most cases.

How well is the task specified? If you cannot write the acceptance check yet, stay interactive. Unattended work with a vague task produces confident, wrong output with nobody watching.

How reversible are the effects? Edits on a branch are easy to discard. Migrations against shared data, published packages and messages to other people are not; keep those interactive or out of agent hands.

How independent is the check? If the only evidence of success is the agent's report, an unattended run has no real gate. A test that fails before the change and passes after it is what makes unattended work reasonable to accept.

In practice modes mix within one feature. You might work interactively to design an interface, hand the mechanical follow-ups to unattended tasks, then review the batch yourself. The page on pair programming vs delegation covers the human side of that switch, and the guide to cards vs scheduled tasks shows what starts an agent in BRAIN FLUID.

QUESTIONS

Is it safe to let an AI coding agent run overnight?

It can be, for narrow tasks. Give it a written scope, the least permission the job needs, a branch that can be thrown away, a time limit and an independent check that must pass. Review the record in the morning before accepting anything. Tasks that touch shared data or external systems should stay interactive.

When should I stop watching an AI agent and let it run on its own?

When you can write down the acceptance check before it starts, the effects are easy to undo, and you have seen the agent handle similar tasks well. If you still find yourself correcting its direction every few minutes, the task is not specified well enough to run unattended. Keep pairing until it is.

What should an unattended agent do when it fails?

Stop and leave a clear record: what it was asked, what it changed, what ran and what failed. It should not retry indefinitely or move on to the next task. If the run ended uncertainly, for example interrupted mid-write, a person should inspect the state before anything is repeated or authorized again.

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?

RELATED HARNESS PAGES

• scheduled agent tasks Scheduled agent tasks done carefully: explicit prompts, readiness and authority checks, and why a started run is not a finished one.
• Bounded autonomy: limits every unattended agent run needs Bounded autonomy: limits every unattended agent run needs, from an explicit task list to launch, retry, time, failure and spend limits.
• AI pair programming vs delegating tasks to agents AI pair programming vs delegating tasks to agents: what each mode needs from you, where each pays off, and the signals that tell you to switch.
• Recovering interrupted AI agent work Recovering interrupted AI agent work: inspect what was written, check what is still running, refuse blind replays and resume with a fresh authorization.