How to run Claude Code unattended overnight

FlowConversational

❯_

Do this with Claude CodeCopy a prompt that links the cckit docs so Claude learns the CLI, then follows these steps.

Copy as Markdown

Before you start

Install cckitQuickstart: your first lifecycle

This tutorial

Advanced8 min readNeedscckit installed & initializedan unblocked backlog

What you’ll do: clear an unblocked backlog unattended, a few issues at a time. cckit orchestrates parallel worktrees and drives each issue through to merged. You always dry-run first so you can see the launch plan before anything is created, then let it run and only get pinged on a genuine blocker.

Steps

1. Read the board, then pick the work. Have Claude sync the board first and show you what’s ready — you choose which issues run, rather than naming numbers up front.

   Prompt to paste

   Read the board and show me what's unblocked right now. I'll tell you which of those to run in
   parallel. Show me the launch plan before anything is created, then run them a few at a time.

   cckit sync --llm                        # read the board; decide from what's actually ready

2. Dry-run, then launch with a cap. Pass the issues you picked (a dry-run creates nothing):

   cckit orchestrate --dry-run <issues…>   # resolve + print the launch plan; create nothing
   cckit orchestrate --cap 3 <issues…>     # launch, at most 3 concurrent; the rest queue

3. Or let autopilot pick the work. For a fully unattended run, autopilot auto-selects ready issues itself — no numbers to name:

   cckit autopilot --cap 3                 # auto-pick unblocked issues and drive them through

   Prompt to paste

   Clear the unblocked backlog unattended, a few at a time. Sync the board, auto-pick what's ready,
   and drive each to merged. Only stop and ping me on a genuine blocker — otherwise summarize what
   merged.

Which verb for which case

Same board, three routes — let what’s ready decide: one issue → the single-issue lifecycle; a set of related sub-issues → an effort or a wave; a whole backlog with nobody watching → cckit autopilot.

How it works

orchestrate takes a specific set of issue numbers and runs them in isolated worktrees, capped so only N run at once and the rest queue. autopilot is the hands-off version: it picks the next unblocked issues itself and keeps going. The dry-run is the safety rail — it resolves the plan and prints exactly what would launch without creating a single branch, so you approve the shape before committing to it.

Always dry-run first

Unattended runs create real branches, worktrees, and PRs. Seeing the plan first is how you (and the agent) catch a wrong issue or a bad cap before it fans out.

Troubleshooting

It stopped on a blocker. That’s by design — unattended runs ping you only on a genuine blocker rather than guessing. Resolve it, then re-run; the merged work isn’t repeated.

Too many worktrees at once. Lower --cap. A smaller cap trades wall-clock for less load and fewer merge conflicts on a busy repo.

A queued issue never started. It was blocked by one still in flight. cckit sync shows what’s gating it; it starts automatically once its blocker merges.

Related tutorials

Run issues in parallel with a wave The attended version — fan out and gate a single wave.

Break a big feature into an effort Create the backlog of sub-issues to clear.

Drive Claude Code headless in CI Run with no human at all, consuming JSON.