Running AI Agents Overnight: Decide What Waits for You

You can leave several AI agents working overnight if you settle three things for every task before you go: what it may finish on its own, where it must stop and wait for a person, and what you will need to see in the morning to judge it. Each of those decisions holds only if some layer enforces it. A line in the prompt that says “don’t merge” is an instruction. A review stage the task cannot close without, or a connector action set to Ask first, is a boundary.

This guide is for the person setting up that night. It covers which work to queue, where each limit is actually enforced, one task followed from assignment to morning review, and a checklist for each end of the night. The work-management examples use Paperclip, and the guide says where Paperclip’s enforcement stops.

The short answer

• Give each task one owner and a stopping point. “Open a draft pull request and stop” is safe to leave running. “Improve the onboarding flow” is not, because nothing tells the agent when it is finished.
• Let work proceed up to a review, not past it. Drafts, branches, research notes, and test runs can complete overnight. Merging, publishing, sending external messages, deleting data, and spending money should wait for a person.
• Put each limit in the layer that can enforce it. The coding runtime governs commands and file edits inside the session, but by default Paperclip runs Claude Code and Codex agents without asking anyone to approve a command, so check those settings. Connector permissions govern the tool calls routed through Paperclip. Your repository governs merges. Paperclip governs task ownership, budgets, and whether a task can close without its review. No layer covers another layer’s job.
• Set a budget as a stop, not a dashboard. In Paperclip, an agent that reaches 100% of its budget is paused and no further heartbeats start.
• Plan the morning before you leave. Know where you will look for stopped work, pending reviews, and budget incidents, and what evidence each task should leave behind.

Sort the night’s work into three lanes

The useful question is not whether agents can be trusted in general. It is what happens if this specific task goes wrong at 3 a.m., and who finds out.

The middle lane is where most of the value is. An agent can spend the night getting a change ready, with the branch, the diff, and a summary of what it touched, so the morning decision takes minutes. What it should not do is complete the step you cannot easily undo.

Why unattended runs drift

An unattended agent can turn a small interpretation error into work that no longer serves the original goal. Agents plan and act in loops, so each output shapes the next decision. If an agent reads “remove outdated files” too broadly and deletes something a build depends on, later steps may treat the broken state as the new baseline and keep working from it. A coding agent might delete a failing test instead of fixing the code it covers. From inside the loop, none of that looks like an error.

Loops between agents drift too. Paperclip’s execution-policy documentation describes the case: when both the implementer and the reviewer are agents, a reviewer whose success criteria have drifted can keep sending work back, spending a run each time. Paperclip counts those rounds. By default, the third consecutive agent request for changes goes to the task’s responsible human, if it has one, instead of back to the implementer (execution policy).

Overnight timing gives each failure more room. A person watching can stop repeated calls after a few minutes or refuse a risky step before it runs. Over eight unattended hours, an agent can keep building on an early mistake and keep spending. That is why the limits have to be enforced rather than requested, and why the morning review needs a record of what happened, not only the final output.

Put each limit where it is enforced

Unattended agent work usually crosses several layers, and each enforces something different. The harness, framework, runtime, and control plane guide covers the layers in depth. For an overnight run, the practical question is which layer holds each of your limits.

Three details matter at night.

By default, no runtime permission prompt stops a Paperclip agent; the only runtime limit is a sandbox, where one exists. Paperclip runs agents with nobody there to answer a permission prompt, so by default nobody is asked. Its Claude Code adapter passes --dangerously-skip-permissions. Its Codex adapter runs on the ACP engine by default, which keeps Codex in its writable workspace sandbox with network access on and denies approval requests; it passes --dangerously-bypass-approvals-and-sandbox only on the classic CLI engine (engine: "cli"). Either way, unless you change that, any shell command or file edit the sandbox allows runs without asking. You have two levers. You can restrict an agent in its adapter settings: dangerouslySkipPermissions: false for Claude Code, or, for Codex on the CLI engine, dangerouslyBypassApprovalsAndSandbox: false (or a sandbox mode you choose). In a headless Claude Code run, an action that would need approval is then refused rather than held for the morning, and Codex stays in its writable workspace sandbox. Or you can run the agent where the worst case is contained. Claude Code’s own permission modes page lists a container, VM, or sandbox runtime as required for fully unattended runs that skip permissions, and Codex documents its sandbox and approval layers separately.

Connector permissions have to be narrowed on purpose. Paperclip’s documentation says active actions on a normal new connection start as Allowed, including writes and destructive actions (action permissions). Before an overnight run, set the Write group to Ask first or Off on every connection the agents can reach, then open up the specific actions a task needs. Paperclip enforces these settings at its gateway, so the runtime’s full-auto mode does not switch them off. They govern tool calls through the gateway only. They do not govern shell commands, and shell git and gh on a GitHub connection are not constrained by them.

Paperclip’s review gate applies to the task, not to each action inside it. When an agent tries to mark a task done, Paperclip moves it to review instead. It does not intercept the commands the agent ran along the way. An approval stage records a decision on the task. It does not stop an agent from running gh pr merge in its shell. Merges are stopped by your repository: branch protection that requires a human review, which the agent’s own identity cannot satisfy or bypass. That is why the review stage, the action-level limits, and the repository rules all need to exist.

One task, from assignment to morning review

This is an illustration. The task, agents, and times are invented. The fields and transitions follow Paperclip’s documented behavior.

Suppose you want a migration guide for an API change drafted overnight. You create a task for a Docs agent:

• Deliverable: a draft pull request with the migration guide. Stop there; do not merge.
• Blocked by: a task where an Engineer agent confirms the list of breaking changes.
• Review stage: a QA agent.
• Approval stage: you.
• Repository: the target branch requires an approving human review before anything merges.

The execution policy on that task looks like this:

{
  "mode": "normal",
  "commentRequired": true,
  "stages": [
    {
      "type": "review",
      "participants": [
        {
          "type": "agent",
          "agentId": "qa-agent"
        }
      ]
    },
    {
      "type": "approval",
      "participants": [
        {
          "type": "user",
          "userId": "you"
        }
      ]
    }
  ]
}

Here is how the night can go:

1. 11:40 p.m. The Engineer agent marks the breaking-changes task done. Every blocker on the docs task is now done, so Paperclip wakes the Docs agent. A cancelled blocker would not count; it has to be replaced or removed (issues API).
2. 12:25 a.m. The Docs agent opens a draft pull request and tries to mark the task done. Paperclip moves it to in_review instead and assigns it to the QA agent.
3. 12:50 a.m. QA finds two endpoints missing and requests changes with a comment. The task goes back to the Docs agent.
4. 1:30 a.m. The Docs agent fixes the draft and resubmits. The task returns to the same QA reviewer, not to the start of the policy.
5. 1:45 a.m. QA approves. Paperclip records the decision and reassigns the task to you. It stays in in_review.

Paperclip requires every agent run on a task to leave a comment, and wakes the agent once more if it does not, so the thread shows what each agent did. Each review decision is stored with its actor, outcome, comment, and run ID (execution policy).

In the morning you open one task. You read QA’s two decisions, look at the pull request, and either approve or request changes yourself. Approving the task records your decision. It does not merge the pull request. What kept the Docs agent from merging overnight was not the “do not merge” line in its task, which is only an instruction. It was the branch rule requiring a human review.

Two other mornings were possible. If QA and the Docs agent had kept bouncing the work, the third consecutive agent request for changes would have landed on the task’s responsible human. If the Docs agent had exhausted its budget at 1 a.m., it would have been paused with the task still assigned to it, and a budget incident would be waiting for you on the Costs page.

Budgets stop the next run, not the current call

Paperclip budgets can be set per agent and for the company, both monthly, and per project as a lifetime cap. At 80% of a budget, Paperclip records a warning and the agent keeps running. At 100%, the agent is paused and no further heartbeats are triggered. Its tasks stay assigned and pick up again when you raise the budget or the month resets (costs).

Read that boundary precisely. The documented behavior is that no new heartbeats start. Treat a budget as a stop on the next run, not a promise that no single run crosses the line. Paperclip also counts the costs its adapters report. Subscription fees and other account-level charges sit in a separate finance ledger, and spend that never reaches Paperclip is not counted at all.

Two practical consequences for overnight work:

• Set the overnight budget low enough that one failed loop is tolerable, then raise it after you have reviewed a few successful nights.
• A budget-paused agent resumes on its own when monthly budgets reset on the 1st of the month (UTC). If tonight crosses that boundary and you do not want the agent to restart, pause it manually.

The Claude Code and Codex sessions guide covers budget scopes and cost attribution in more detail.

Before you leave

• Every task has one owner, a named deliverable, its inputs, and a point where it stops, such as “open a draft pull request” or “post findings as a comment.”
• Dependencies are recorded as blockers, so downstream work starts only when upstream work is done.
• Every task that produces something consequential has a review stage, an approval stage, or both.
• You have checked each agent’s adapter settings, including its engine. By default, Paperclip runs Claude Code and Codex agents without asking anyone to approve a command, so either restrict that in the adapter settings or run the agent in a sandbox or container whose worst case you accept.
• Branch protection, or an equivalent rule, blocks a merge by the agent’s own identity, and deploys need a human approval.
• On every connection the agents can reach, write and destructive actions are set to Ask first or Off unless a task needs them.
• Each agent has a budget sized so that a failed loop is tolerable, and you know whether the month rolls over tonight.
• Scheduled work runs through routines with a concurrency policy you chose. The default coalesces a tick that arrives while the previous run is still going and skips missed windows (routines).
• If you check only one thing, check that nothing hard to undo can complete without a person approving it.

In the morning

• Open the Blocked inbox. Each stopped task shows why it stopped and whose action unblocks it (blocked inbox).
• Work through the tasks waiting in in_review for you. Read the review decisions before the output.
• Check the Costs page for budget incidents, and decide whether to keep each agent paused or raise its budget.
• Treat a done task without a review decision as a claim. If it should have had a reviewer, add the stage before the next run.
• Use the Activity Log, narrowed to agent actions, to see what changed and who changed it. Use the task thread to see why.
• Look at the actual output: the diff, the draft, the data. A clean status is not proof that the run took acceptable steps.

What Paperclip does and does not do here

Paperclip manages the work around agents: who owns each task, how tasks depend on each other, what each agent may spend, which reviews and approvals a task needs before it closes, and the record of what happened. It runs agents through runtimes such as Claude Code and Codex rather than replacing them.

It is not a sandbox for shell commands, and it does not intercept every model call or tool call an agent makes. Command-level limits come from the runtime, tool-call limits from connector permissions, and merge and deploy limits from your repository and infrastructure. Paperclip is also not a tracing or evaluation system; step-level traces of model calls come from a separate tool. For a comparison of platforms that manage agent teams, see 7 Platforms for Managing AI Agent Teams.

Frequently asked questions

Can AI agents run fully unattended overnight?

They can run without anyone watching when each task has a clear owner, deliverable, and stopping point, and when the limits that matter are actually enforced: by runtime settings you have checked (by default, Paperclip’s coding adapters run without permission prompts), by connector permissions, by your repository’s branch rules, and by the task’s review stages. Unattended should not mean unreviewed. The work can finish overnight while the consequential decisions wait for the morning.

What happens if an agent tries something risky while no one is watching?

It depends on which layer the action passes through. A shell command is governed by the runtime, and by default Paperclip’s coding adapters run without the runtime’s permission prompts. Unless you have changed that, a command the runtime’s settings allow runs without asking anyone. A merge from the shell is stopped only by your repository’s branch protection. A tool call through a Paperclip connection set to Ask first waits for a person to approve it. An attempt to close a task that has review or approval stages moves it to review instead of done. An action that none of those layers checks is not stopped by them.

Does a Paperclip budget stop an agent in the middle of a run?

Paperclip’s documentation describes the 100% limit as pausing the agent so that no further heartbeats start. Plan around that: treat the budget as a stop on the next run, and set it low enough that the last run before the pause is affordable.

Is this agent orchestration or agent operations?

Both terms get used. Agent orchestration usually means routing tasks and state between agents inside an application, which a framework handles. Agent operations covers what this guide is about: ownership, limits, review, and the record of what happened. Paperclip works at that second layer. The AI agent control plane guide separates the layers further.

Sources

Checked October 12, 2026.

• Paperclip: execution policy, costs, connector action permissions, issues API, blocked inbox, activity log, and routines
• Paperclip adapters: Claude Code adapter permissions and Codex adapter permissions
• Anthropic: Claude Code permission modes
• OpenAI: Codex agent approvals and security