The /loop Command: Recurring and Self-Paced Prompts

The /loop command re-runs a prompt on a cadence instead of a single stopping condition, in three modes: a fixed interval converted to a cron schedule, a self-paced delay chosen each round based on what the agent observes, or a built-in maintenance routine when no prompt is given. Claude Code and Cursor both ship it as a bundled skill; Codex CLI 0.145 has no equivalent.

The deploy takes about eight minutes. So you wait, type “is it done yet?”, read “still building,” wait, ask again. Or the PR is in review and you keep checking back for CI results and new comments. None of this is hard — it’s just a prompt you’d run on repeat if you could, and being the thing that runs it on repeat is a waste of a developer.

/loop is that repeater. You give it a prompt and, optionally, a cadence, and it re-runs the prompt for you — on a fixed interval, on an interval it chooses based on what it sees, or as a standing maintenance routine. It’s the cadence-based half of autonomous operation; its sibling, /goal, is the condition-based half.

What you’ll walk away with from /loop

The three modes of Claude Code’s /loop — fixed interval, self-paced, and maintenance — and when to use each
The exact syntax, including how intervals map to cron and how to stop a loop
How to replace the default maintenance prompt with your own loop.md
How Cursor’s own /loop skill differs, and what to use instead in Codex
How /loop differs from /goal

The three modes (Claude Code)

/loop is a bundled skill (requires Claude Code v2.1.72 or later). Both the interval and the prompt are optional, and what you supply decides the behavior:

What you provide	Example	What happens
Interval and prompt	`/loop 5m check the deploy`	Prompt runs on a fixed schedule
Prompt only	`/loop check the deploy`	Prompt runs at an interval Claude picks each round
Interval only, or nothing	`/loop`	The built-in maintenance prompt runs (or your `loop.md`)

Fixed interval

Supply an interval and Claude converts it to a cron expression, schedules the job, and confirms the cadence and a job ID:

/loop 5m check if the deployment finished and tell me what happened

The interval can lead as a bare token (30m) or trail as a clause (every 2 hours). Units are s, m, h, d. Seconds round up to the nearest minute (cron’s granularity), and odd intervals like 7m or 90m round to the nearest clean cron step — Claude tells you what it picked. You can pass another command as the prompt, too: /loop 20m /review-pr 1234 re-runs a saved skill each iteration.

That last form has a limit worth knowing before you rely on it. As of v2.1.196, a scheduled fire only executes skills Claude is allowed to invoke on its own. Anything else reaches Claude as plain text and quietly does nothing: built-in commands like /permissions, /model or /clear; skills marked disable-model-invocation: true, including the bundled /verify; skills withheld by a skillOverrides setting or a Skill deny rule; and MCP prompts such as /mcp__github__list_prs. A loop wrapped around one of those looks scheduled and produces nothing.

Fires are also deliberately not punctual. The scheduler adds a jitter offset derived from the task ID, so a given task always drifts the same way: recurring tasks fire up to 30 minutes late (or up to half the interval, for anything sub-hourly), and one-shots scheduled for :00 or :30 fire up to 90 seconds early. If exact timing matters, schedule for a minute that is neither, such as 3 9 * * * rather than 0 9 * * *. A session holds at most 50 scheduled tasks at once.

Self-paced

Omit the interval and Claude chooses the delay itself after each round — anywhere from one minute to an hour — based on what it observed, and prints the reason for each wait:

/loop check whether CI passed and address any review comments

Short waits while a build is finishing, longer waits once things go quiet. For this mode Claude may use the Monitor tool to stream a background script’s output instead of re-running the prompt — often more responsive and more token-efficient than polling.

Maintenance

A bare /loop (no prompt) runs a built-in maintenance routine at a self-chosen interval. Each round it works through, in order: continue unfinished work from the conversation, tend the current branch’s PR (review comments, failed CI, merge conflicts), then run cleanup passes like bug hunts or simplification when nothing else is pending. It won’t start new initiatives outside that scope, and irreversible actions only proceed when they continue something the transcript already authorized.

Replace the default with loop.md. Drop a Markdown file at .claude/loop.md (project) or ~/.claude/loop.md (user) to define your own default prompt for a bare /loop. Write it as if you were typing the prompt directly:

Check the release/next PR. If CI is red, pull the failing job log,
diagnose, and push a minimal fix. If new review comments arrived,
address each and resolve the thread. If everything is green and
quiet, say so in one line.

Edits take effect on the next iteration, so you can refine instructions while the loop runs. Keep the file short: content past 25,000 bytes is truncated.

Stopping and expiry

Press Esc while a loop waits for its next iteration to clear the pending wakeup. In self-paced mode, Claude can also end the loop itself: as of v2.1.202 it calls the ScheduleWakeup tool with stop: true, which cancels the pending wakeup immediately. Before that release, simply not rescheduling was the only way it could stop on its own — and that remains the fallback path. If an iteration neither reschedules nor stops, Claude Code schedules one more wakeup roughly 20 minutes later and ends the loop when that iteration doesn’t reschedule either.

Every loop carries a seven-day expiry — it fires one last time seven days after creation, then deletes itself, so a forgotten loop can’t run forever. Loops are session-scoped; claude --resume or --continue restores any that haven’t expired. Backgrounding a session carries its /loop tasks over to the background session, which keeps firing them without a terminal.

Tool support

Native, as described above. For scheduling that outlives the session, Claude Code also offers Routines (Anthropic-managed cloud, 1-hour minimum), Desktop scheduled tasks (your machine), and GitHub Actions — /loop itself is the in-session, quick-polling option. Set CLAUDE_CODE_DISABLE_CRON=1 to disable the scheduler (and /loop) entirely.

Codex has no /loop command — checked against Codex CLI 0.145, whose codex features list output carries no loop, cron or scheduling flag. Its looping primitive is /goal: set an objective and Codex runs plan → act → test → review on its own until the condition is met. That’s a condition-based loop rather than a scheduled one — there’s no native “every 5 minutes” in the CLI. For time- or event-driven runs, wire Codex into CI or a GitHub/Linear automation.

Cursor ships its own /loop skill, added in Cursor 3.5 (May 20, 2026). It runs a prompt repeatedly on a local schedule until an outcome is reached or you stop it, and when you give no fixed interval the agent decides when — or on what event — to wake itself. Cursor’s own examples are “check deploy status every 5 minutes” and “work on this feature until tests pass,” which is the interesting part: the same skill covers cadence and the outcome-terminated job that Claude Code splits off into /goal.

Two caveats on where it lives. It is a bundled skill, not one of the 35 built-in commands in the CLI slash-command reference, and it is aimed at local long-running agents in the Agents Window. And Cursor documents it far more briefly than Anthropic documents Claude Code’s, so the specifics above — jitter, expiry, loop.md, the cloud-provider caveats — are Claude Code behaviour and should not be assumed to hold here.

Cursor Automations remain the durable option: they run an agent on a schedule or in response to events (file saves, commits, test failures) without an open session, which makes them the analogue of Claude Code’s Routines rather than of /loop.

/loop versus /goal

The two autonomous commands answer different questions:

/loop answers “how often?” — it re-runs a prompt on a cadence and may never terminate on its own (the seven-day expiry is a backstop, not a finish line).
/goal answers “until when?” — it runs flat-out until a verifiable stopping condition is true, then stops.

Use /loop for monitoring and standing maintenance; use /goal for convergent work with a clear definition of done. They pair well: /goal drives a feature to green, then /loop watches the PR it produced.

Guardrails

Where to go next

The /goal command Run an agent until a verifiable stopping condition is met -- the condition-based counterpart to /loop.

Human in the loop Where to keep a person in the decision path when agents run autonomously.