Skip to main content

Background Tasks, /loop & Scheduling

Advanced

Not everything is a quick edit. Claude Code can run work that outlives a single prompt: long commands in the background, recurring loops, and scheduled runs.

What you'll learn
  • Tell the three mechanisms apart: background tasks, /loop, and scheduled routines
  • Start a long command without blocking the session — and know why polling it in a tight loop is the wrong move
  • Pick the right one from a single question: does the work outlive the prompt, the session, or neither?
  • Write instructions for a scheduled run that are self-contained, because each run starts fresh
  • Put guardrails under anything that acts unattended

Background tasks​

Kick off a long-running command (a dev server, a test watcher, a build) without blocking the session. Claude keeps working and is notified when the task produces output or finishes. Use it for anything you'd normally background with & — but managed, so Claude can read the output later.

Don't busy-wait

Start the task in the background and continue; let the completion notification bring you back, rather than polling in a tight loop.

Recurring loops (/loop)​

/loop runs a prompt or command on a recurring interval within a session — e.g. "every 5 minutes, check the deploy status." Give it an interval, or let Claude self-pace. Great for babysitting a CI run or polling an external job that the harness can't otherwise notify you about.

Poll a deploy every five minutes, in-session

/loop 5m check the deploy status and tell me the moment it goes green or fails

Omit the interval and Claude paces itself instead of running on your clock.

Scheduled cloud agents​

For work that should happen on a clock, ongoing — "every morning summarize new issues," "hourly, check for news and update the docs" — use scheduled tasks / routines (cron-style). Each run starts fresh, so its instructions must be self-contained.

Choosing between them​

NeedUse
Run a long command, keep workingBackground task
Poll something every N minutes this session/loop
Do something on a schedule, indefinitelyScheduled routine
Guided walkthrough1 of 4
  1. One prompt, but not the session? Background task. The prompt, repeatedly, inside this session? /loop. The session itself, on a clock, indefinitely? Scheduled routine.
Autonomy needs guardrails

Anything that acts unattended on a schedule should be tightly scoped and reversible. Pair it with strict permissions and read Hardening Autonomous Runs.

Check yourself

0/3
  1. You want a summary of new issues every morning, ongoing. Which mechanism fits?
  2. Why must a scheduled routine's instructions be self-contained?
  3. You've started a long test watcher in the background. What should you NOT do next?
Key takeaways
  • Three mechanisms, one question: does the work outlive the prompt (background task), repeat inside the session (/loop), or outlive the session entirely (scheduled routine)?
  • Background tasks are managed, not just backgrounded with & — Claude can read the output later and is notified when they finish.
  • Don't busy-wait. Start it, continue, let the completion notification return you to it.
  • /loop takes an interval, or self-paces if you leave the interval off.
  • Every scheduled run starts fresh, so its instructions must stand alone.
  • Unattended autonomy needs strict permissions and reversible scope — that pairing is not optional.

Next​