Agent Continuation Atlas

Cadence-driven recurrence

/loop [interval] [prompt]

Claude Code Loop

Schedule a prompt to run repeatedly inside the current Claude Code session. The clock—or Claude’s chosen wake-up cadence—causes the next iteration.

What Loop controls

/loop is a bundled Claude Code skill for in-session scheduling. It registers a recurring prompt, waits, and enqueues that prompt again when the next iteration is due. Each iteration runs between turns rather than interrupting a response already in progress.

This makes Loop especially useful when the external world needs time to change: a build must finish, a deployment must settle, or new review feedback may arrive.

01 / ScheduleSet a prompt and optional interval
02 / WaitKeep the session available
03 / RunClaude executes the prompt
04 / RepeatWait again, finish, cancel, or expire

Three useful forms

Interval + prompt
/loop 5m check if the deploy finished runs the prompt on a fixed cadence.
Prompt only
/loop check the deploy lets Claude select the interval for each iteration.
Interval only or bare
/loop 15m or /loop runs the built-in maintenance prompt, or the configured loop.md prompt.
Poll a deployment every five minutes
/loop 5m check whether the deployment finished.
If it failed, inspect the logs and summarize the likely cause.
If it succeeded, report the release version and stop.
Repeat a packaged workflow
/loop 20m /review-pr 1234

Scheduling behavior

  • The minimum interval is one minute.
  • All times use the machine’s local timezone.
  • Scheduled prompts wait if Claude is already working and run after the current turn.
  • Recurring tasks expire seven days after creation.
  • A session can hold up to 50 scheduled tasks.
  • Fixed schedules include deterministic timing jitter in common cases.

Dynamic loops may avoid polling

For a prompt without a fixed interval, Claude may use its Monitor tool to stream a background process instead. This can be more responsive and token-efficient than repeatedly rerunning a prompt.

It is not a durable daemon

/loop runs on your machine and depends on an open Claude Code session. An unexpired task can be restored when you resume the conversation, but Loop is not the right boundary for automation that must survive independently of that session.

Claude scheduling options by runtime boundary
Option Runs on Open session needed? Use when
/loop Your machine Yes Quick polling during active work
Desktop scheduled task Your machine No Persistent local work with file access
Cloud routine Anthropic cloud No Reliable recurring work without your machine

Permissions and stopping

Each loop iteration inherits the tools and permission policy of the session. Loop does not grant broader authority merely because a prompt repeats.

  • Press Esc while a Loop is waiting to clear its pending wake-up.
  • Ask Claude to list or cancel scheduled tasks when multiple jobs exist.
  • Set CLAUDE_CODE_DISABLE_CRON=1 to disable scheduled tasks entirely.
  • Use an explicit “if complete, stop” instruction when the polling job has a natural end.

Where it fits

Good fits

  • Waiting for a deployment
  • Babysitting a pull request or CI run
  • Periodic checks during a work session
  • Repeating a packaged review skill

Poor fits

  • One continuous implementation task
  • Automation that must survive shutdown
  • Exact wall-clock scheduling
  • An objective with a measurable target but no time dependency

How it differs

Loop is time-driven

Elapsed time triggers the next prompt. That is different from GitHub Autopilot’s continuous task completion and Codex Goal’s condition-driven persistence.

Terminology note: Claude Code also documents its own /goal command. This guide deliberately compares Claude’s /loop scheduling feature because that is the named concept in this atlas—not because Loop is Claude’s only long-running-work mechanism.

First-party sources

Verified against Anthropic documentation