I was watching a deployment last week. Not watching in any meaningful sense. Just sitting there, hitting refresh, waiting for the staging endpoint to return 200 instead of 502. It took about twenty minutes to resolve, and for most of that time I was doing nothing except hitting a key.
The whole time I kept thinking: this is exactly the kind of work agents are supposed to handle.
The usual workaround is a bash while loop. Something like:
while true; do curl -s staging.example.com && sleep 300; done
It works, in the same way a paper bag works as an umbrella. It does not tell Claude what to do with the result. It does not compose with skills or slash commands. And if you close the terminal, it is gone.
Claude Code v2.1.71, released on March 7, 2026, has a better answer. It is called /loop, and it is the first native, first-class scheduling feature built directly into the terminal workflow. No configuration files. No external tools. No bash gymnastics.
Table of Contents#
- What /loop actually does
- How it works under the hood
- Six patterns worth knowing
- Worktrees and agent teams
- When to use /loop versus the durable alternatives
- Best practices
- FAQ
What /loop Actually Does#
The syntax is:
/loop [interval] [prompt or slash command]
Type the following and Claude schedules a background cron job, confirms the cadence and an 8-character task ID, then runs your prompt automatically every five minutes:
/loop 5m check whether staging.example.com returns 200
The session stays open, you go do something else, and Claude reports back at each interval.
That last part is the part that matters. The agent is not waiting for you to ask again. It is working on a schedule in the background while you work on something else.
The feature ships alongside three new cron scheduling tools: CronCreate, CronList, and CronDelete. These are what power the underlying mechanism. /loop is the user-facing shorthand that handles the intent-to-schedule conversion automatically.
Tasks are session-scoped. They live in the current Claude Code process and vanish when you exit. A session can hold up to 50 scheduled tasks at once. Every task has a 3-day auto-expiration, so if you forget to cancel something, it does not run indefinitely. You cancel manually with /loop cancel [task-id] using the ID Claude gives you at confirmation.
This ephemerality is deliberate. It bounds risk. A forgotten loop cannot quietly burn API credits for weeks. The design assumes that if you are not present to use the output, the task probably should not be running.
How It Works Under the Hood#
Claude parses your interval string and converts it to a standard 5-field cron expression. Supported units are s for seconds, m for minutes, h for hours, and d for days.
Seconds round up to the nearest minute. Cron has one-minute granularity, so /loop 45s do something becomes a per-minute job. Non-clean intervals like 7m or 90m get rounded to the nearest clean value, and Claude tells you what it picked. This matters if you are trying to set something exact.
The scheduler checks for due tasks every second and enqueues them at low priority. The important detail here: tasks fire between your turns, not mid-response. If Claude is generating a reply when a task comes due, the task waits until the current response finishes. This means you will never get an autonomous interrupt in the middle of a conversation. The scheduling is polite about it.
There is a jitter mechanism to prevent synchronized API requests. Recurring tasks fire up to 10% of their period late, capped at 15 minutes. One-shot tasks fire up to 90 seconds early. The offset derives from the task ID, so the same task always gets the same jitter. The documentation recommends picking off-round minutes like 3 9 * * * instead of 0 9 * * * if exact timing matters to you.
All times are interpreted in your local timezone, not UTC. Set CLAUDE_CODE_DISABLE_CRON=1 to disable the feature entirely.
Six Patterns Worth Knowing#
The official documentation at code.claude.com/docs/en/scheduled-tasks identifies four primary use cases. Community practice has expanded the set.
Polling Deployments#
This is the canonical example:
/loop 5m check whether the deployment at staging.example.com returns 200
It fires every five minutes, with Claude verifying status and alerting you to issues. It replaces the manual refresh cycle and the bash while loop.
The real value is that Claude is not just doing the curl check. It is interpreting the result and giving you something actionable. A 502 with a specific error body gets treated differently from a timeout. You can tune the prompt to say what you want back.
Babysitting PRs#
This is where /loop gets genuinely useful rather than just convenient. The command:
/loop 30m /review-pr 1234
chains with other slash commands, running a packaged review workflow on a schedule. Combined with the gh CLI, you can have Claude monitor CI status, read failure logs, identify the problem, make targeted fixes, commit, push, and re-run the workflow automatically.
Anthropic described this pattern in their February 2026 post on "Preview, Review, and Merge with Claude Code." The phrase they used was "auto-fix CI failures" and "auto-merge when all checks pass." One community write-up described the experience directly: "Claude Code detects failures, reads logs, identifies the issue, makes the fix, pushes the changes, and re-runs the workflow, all through natural conversation."
That is a different relationship with CI than most developers have. Instead of getting paged on failures and manually triaging them, you set up a loop at the start of the PR and come back when it is green.
This pattern connects to what the long-running agent harness describes as clean state requirements. A coding agent that finishes each iteration with a commit and progress update is the same discipline as a /loop that commits after each CI fix. The mechanism is different but the principle is identical: leave the environment in a known state after every cycle.
Morning Summaries via MCP#
The scheduled prompt has access to every MCP server configured in the session. A developer documented connecting Slack MCP and Linear MCP to Claude Code for daily summaries: "Claude is not scraping a web page or parsing an export file. It is reading Slack as a first-class data source and writing to Linear as a first-class output."
The setup looks like:
/loop 1d read my Slack messages from the last 24 hours across #engineering, #product, and #leadership channels. Summarize key discussions, decisions, and action items.
Multiple Slack MCP server implementations exist, including the official one at docs.slack.dev/ai/slack-mcp-server/. The pattern extends to any MCP connector: GitHub for PR summaries, Linear for standup notes, Gmail for flagged threads.
The caveat is that you need the session open. If you want this running without a terminal, the durable alternatives handle it better.
Checking Long-Running Builds#
/loop 10m check whether the build in CI has completed and summarize any failures
That is the simple version. The more useful version combines it with a skill that knows how to interpret your specific CI output and suggest targeted fixes rather than generic ones.
This is where the composability of /loop is most visible. You are not writing a monitoring script. You are telling an agent to keep an eye on something and apply its judgment to what it finds.
One-Shot Reminders#
You do not need /loop syntax for single-fire tasks. Describe what you want in natural language: "remind me in 45 minutes to push to staging" and Claude schedules a single-fire cron task. This is a small thing, but it is surprisingly useful during long coding sessions when you want a checkpoint without stopping what you are doing.
Chaining with Skill Invocations#
The documentation is explicit: "The scheduled prompt can itself be a command or skill invocation. This is useful for re-running a workflow you have already packaged."
If you have a /security-audit skill, a /performance-check skill, or a /deploy-checklist skill, then:
/loop 6h /security-audit
runs it twice a day without any additional configuration. The skill handles the complexity. The loop handles the scheduling. Neither needs to know about the other.
This is the right way to think about /loop at scale. It is not a scripting tool. It is a scheduler for workflows you have already defined elsewhere. The five pillars of agentic engineering describes this separation between task definition and task execution as a core pattern. /loop is infrastructure for that separation.
Worktrees and Agent Teams#
Worktree support creates isolated Git worktrees for parallel sessions. /loop itself does not spawn new worktrees per iteration. It re-runs prompts within the same session context. But you can start a session inside a worktree with:
claude --worktree feature-auth
and use /loop within it. Subagents spawned by /loop prompts can use worktree isolation by adding isolation: worktree to their frontmatter, which prevents file conflicts across parallel sub-tasks.
There is a highly-upvoted GitHub issue (#31244, March 5, 2026) describing the desired end-state: Claude Code opens a PR, watches for reviewer comments, resumes with full session context, makes changes, commits, pushes, and replies on the PR automatically. The current workaround combines /loop with gh CLI to poll for PR comments. The gap is that this approach loses conversation context between iterations. The feature request is for something closer to a durable, context-preserving loop. It is not there yet, but the issue has traction.
Agent teams, an experimental feature enabled via CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, can coexist with /loop in a session. Theoretically, a team lead agent could use /loop to periodically coordinate teammate progress. There is no direct documented integration between the two features right now.
When to Use /loop Versus the Durable Alternatives#
/loop occupies a specific niche. Understanding the edges of that niche saves you from using the wrong tool.
Claude Code Desktop scheduled tasks are stored on disk at ~/.claude/scheduled-tasks/, survive terminal closes and restarts, offer a worktree toggle for per-run isolation, and catch up on missed runs when the computer wakes. Use these when your task needs to run for more than 3 days or survive closing the terminal.
Cowork scheduled tasks in Claude Desktop add access to connectors like Slack, Gmail, and Google Drive. Good for daily briefings that aggregate cross-service data. The official support documentation lists "daily briefings: summarize Slack messages, emails, or calendar events from the past 24 hours" as the primary use case. Still requires the Desktop app to be open.
GitHub Actions with Claude Code (anthropics/claude-code-action) provide fully headless, cloud-based scheduling. A marketplace action for "PR Autofix" demonstrates the pattern: bot comments trigger Claude Code to read context, make fixes, commit, push, and re-run CI in an iterative loop. For tasks that need to run in the cloud without your laptop, this is the right tool.
The decision comes down to one question: does the task need to outlive the current terminal session? If yes, use Desktop scheduled tasks or GitHub Actions. If no, /loop is faster to set up and requires nothing beyond the current session.
The token cost framework applies here. Every scheduled prompt costs tokens. A /loop 1m task running for 8 hours is 480 prompts. A /loop 5m task is 96. Pick your intervals deliberately, especially for tasks where the agent is doing real work rather than just checking a status.
Best Practices#
Use reasonable intervals. Five minutes is appropriate for deployment polling. Thirty minutes works for PR review cycles. One hour is usually fine for build status checks. There is rarely a good reason to go below 5 minutes for anything that involves Claude doing actual work.
Chain with packaged skills, not inline prompts.
/loop 30m /review-pr 1234
is cleaner and more reliable than writing a multi-step review workflow inline. Build the workflow as a reusable skill first, then schedule it. This is the same discipline the best Claude Code plugins use: the skill defines the capability, and external tooling handles when to invoke it.
Connect MCP servers before starting loops. If your prompt needs Slack, Linear, or GitHub data, configure those MCP servers at session start. The scheduled prompt will have access to everything available in the session. Servers added after a task is scheduled may not be accessible to that task.
Pick off-round minutes for timing-sensitive tasks. Due to the jitter mechanism, cron expressions at :00 or :30 may fire up to 90 seconds early. Using 3 9 * * * instead of 0 9 * * * ensures you hit your intended window.
Know when to graduate. The documentation is direct about this: if your task needs to survive terminal closes, run for more than 3 days, or catch up after laptop sleep, use Desktop scheduled tasks or GitHub Actions. /loop is the right tool for in-session automation. It is not a replacement for persistent scheduling infrastructure.
Test your prompt manually before scheduling it. A prompt that works well once may behave unexpectedly on the fifth or fifteenth run if the environment has changed. Run it manually a few times first, check that it handles edge cases sensibly, and then put it on a schedule.
What This Changes#
The community was already building this. Bash while loops, continuous-claude, various scheduler plugins, all solving the same problem. What /loop adds is not the capability but the integration. It composes with slash commands and skills. It has a proper task lifecycle with IDs and cancellation. It handles jitter. It respects conversation turns.
The before-you-run-10-claude-agents calculus applies here: mistakes that are annoying at one run become expensive at ten. The 3-day auto-expiration and the low-priority enqueuing are the harness around this feature. They make it safe to use without obsessive monitoring.
The deeper shift is what it implies about how you structure a session. With /loop, a terminal is not just a place where you have a conversation with Claude. It is a place where you set up agents to work in the background while you do something else. The session becomes more like a workspace than a chat window.
That is the direction agentic development has been heading for a while. /loop is a small feature that makes it feel more real.
FAQ#
What is the Claude Code /loop command?#
The /loop command is a built-in skill in Claude Code v2.1.71 that schedules recurring prompts using cron jobs. You specify an interval and a prompt, and Claude creates a background task that re-runs your prompt at each interval automatically. Tasks are session-scoped and auto-expire after 3 days.
How do I cancel a /loop task?#
When Claude confirms a scheduled task, it provides an 8-character task ID. Use /loop cancel [task-id] to cancel it. You can view all active tasks and their IDs with the CronList tool or by asking Claude to list your scheduled tasks.
Can /loop trigger other slash commands and skills?#
Yes. The scheduled prompt can itself be a slash command or skill invocation. /loop 30m /review-pr 1234 will run your /review-pr workflow every 30 minutes. Building your workflow as a reusable skill first and then scheduling it is the recommended pattern.
How does /loop handle cron timing?#
Claude converts your interval to a 5-field cron expression. Seconds round up to the nearest minute. Non-clean intervals like 7m or 90m round to the nearest clean value. A deterministic jitter of up to 10% of the period, capped at 15 minutes, is added to recurring tasks. The jitter offset derives from the task ID, so the same task always fires at the same offset.
What is the maximum number of /loop tasks I can run at once?#
A session can hold up to 50 scheduled tasks simultaneously. All tasks in a session share this limit, including one-shot reminders and recurring loops.
What happens if Claude is in the middle of a response when a /loop task fires?#
The scheduler enqueues due tasks at low priority and fires them between turns. If Claude is generating a response when a task comes due, the task waits until the current response finishes before executing. You will never get an autonomous interrupt mid-conversation.
What is the difference between /loop and Claude Code Desktop scheduled tasks?#
/loop tasks are session-scoped, last at most 3 days, and vanish when the terminal closes. Desktop scheduled tasks are stored on disk at ~/.claude/scheduled-tasks/, survive restarts, catch up on missed runs when the computer wakes, and have no expiration limit. Use /loop for tasks that are part of your current session. Use Desktop scheduled tasks for tasks that need to outlive the terminal.
How do I disable /loop entirely?#
Set the following in your environment:
CLAUDE_CODE_DISABLE_CRON=1
This prevents the feature from being available in any Claude Code session until you unset the variable.