Claude Code /loop Command: How to Use It for Smarter Coding Workflows in 2026

If you have used Claude Code for more than a few sessions, you have probably run into a moment where you wished the AI would just keep going — watching a build, polling for a change, re-running something every few minutes — without you having to babysit it. That is exactly what /loop is for.

This guide explains how /loop works, when it makes sense to use it, and how to wire it into real development workflows — from monitoring CI runs to running iterative refactors across a large codebase.

What is /loop in Claude Code?

/loop is a built-in slash command in Claude Code that tells the agent to repeat a task on a schedule — or to self-pace its own iterations — instead of stopping after one turn. It is designed for situations where you need something to happen repeatedly: checking a status, continuing a long-running refactor, polling an external system, or watching for a condition to become true.

At its simplest, the command looks like this:

/loop <interval_in_seconds> <your prompt here>

For example, to check the status of a CI run every 60 seconds:

/loop 60 Check if the GitHub Actions workflow has finished. Report the status and stop looping if it passed or failed.

Claude will re-run that prompt every 60 seconds, using all its available tools (Bash, file reads, web fetches), until either the condition resolves or you interrupt it.

The Two Modes: Fixed Interval vs. Self-Paced

There are two ways to use /loop, and understanding the difference matters for how you frame your prompts.

Fixed-interval loop

Pass a number of seconds as the first argument. Claude wakes up at that interval, runs your prompt, and goes back to sleep. This is the right mode for polling external systems — CI pipelines, deploy statuses, API health endpoints — where there is a real-world clock driving when things change.

/loop 120 Run npm test and report which tests are failing. Stop if all tests pass.

Self-paced (dynamic) loop

Omit the interval and Claude decides its own cadence based on context — how much work is left, how long each iteration takes, and what makes sense for the task. This is useful for open-ended agentic work where you want Claude to keep going without a fixed clock — for example, refactoring a list of files one by one, or working through a backlog of issues.

/loop Go through each file in src/components/ and add missing TypeScript types. Work through them one at a time, commit after each file, and stop when all are done.

5 Real Development Scenarios Where /loop Shines

1. Watching a CI run

You push a branch and need to know when the pipeline finishes — without alt-tabbing to GitHub every five minutes. Set a loop at a sensible interval (CI runs rarely change faster than every 2–3 minutes) and have Claude report the result and stop automatically.

/loop 90 Run: gh run list --branch my-feature --limit 1 --json status,conclusion,url
Report the status. If conclusion is "success" or "failure", report the full result and stop looping.

2. Iterative refactoring across a large codebase

When you have 40 files that need the same treatment — adding prop types, migrating to a new API, renaming a constant — doing them manually is tedious. With a self-paced loop, Claude works through the list sequentially, commits after each file, and reports progress so you can pick it back up if something goes wrong.

/loop Find all .tsx files that still use the old useAuth hook from @/hooks/auth-v1.
Migrate them one at a time to the new useSession hook from @/hooks/session.
Run TypeScript after each file to confirm no errors, then commit. Stop when none remain.

3. Monitoring a deploy

Production deploys can take 5–15 minutes and have a habit of failing in ways that are obvious if you are looking, but easy to miss if you step away. Loop Claude against your health endpoint or deploy CLI while you grab coffee.

/loop 60 Run: curl -s https://myapp.example.com/api/health | jq '.status'
If status is "ok", tell me the deploy succeeded and stop.
If you see errors three times in a row, stop and show me the last response.

4. Progressive test fixing

You have a suite of failing tests and want Claude to fix them incrementally — one failure at a time — rather than trying to fix everything at once and creating a mess of conflicting changes.

/loop Run the test suite with: npm test -- --bail 1
Pick the first failing test, read the error, fix it, and run again.
Commit after each passing test. Stop when the full suite is green.

5. Watching for a file or log change

During development you sometimes want to know when a specific log entry appears, a seed file finishes writing, or a build artifact is produced — without wiring up a real file-watcher script.

/loop 30 Check if the file dist/bundle.js exists and is larger than 10kb.
If yes, run a quick size report (ls -lh dist/) and stop looping.
If not, tell me it is not ready yet.

How /loop Fits Into an Agentic Workflow

/loop is not magic — it is a scheduling layer on top of the same Claude session. Each iteration has full access to your project files, bash commands, and web tools. The key architectural insight is that Claude also inherits context from previous iterations within the same loop: it remembers what it found last time, which files it already processed, and what the current state is.

This makes loops composable with other Claude Code patterns:

• With CLAUDE.md: Rules in your CLAUDE.md file apply inside every loop iteration automatically. If you have defined commit conventions or file restrictions, they carry forward.
• With subagents: You can ask Claude to spawn subagents inside a loop for parallelism — for example, processing multiple files concurrently in each iteration.
• With hooks: Claude Code hooks fire on every tool call, so tool-level safety checks apply inside loops just as they do in normal sessions.

Cache Warming and Why Interval Choice Matters

There is a practical performance consideration that changes how you pick your interval: the Anthropic prompt cache has a 5-minute TTL. If your loop sleeps for longer than 5 minutes (300 seconds), the next wake-up reads the full conversation context uncached — which is slower and uses more tokens.

A useful mental model for picking intervals:

• 60–270 seconds: Cache stays warm. Right for polling CI runs, health endpoints, or any external state that changes fast.
• 300+ seconds: Cache miss on each wake-up. Only worth it if the thing you are waiting for genuinely takes that long to change. A deploy that takes 12 minutes is worth two 270s sleeps, not 12 one-minute polls.
• Avoid exactly 300s: It is the worst of both worlds — you pay the cache miss without getting a meaningfully longer wait.

When NOT to Use /loop

/loop is a power tool and it has the failure modes of power tools. A few things to watch for:

• Infinite loops without exit conditions: Always tell Claude explicitly when to stop. "Stop when tests pass" or "Stop if you see three failures in a row" — without a condition, a loop will run until the session context fills up.
• Destructive operations: Loops that modify files or push commits amplify mistakes. Ask Claude to show you a dry-run first, or scope the work to one unit per iteration with a manual confirmation checkpoint.
• Background work the harness can already track: If you spawn a background task via the Agent tool, Claude Code is notified automatically when it completes — no polling loop needed. Only use /loop for external systems the harness cannot observe.
• Tasks that need your input between steps: If you need to review and approve changes before the next iteration runs, a loop is the wrong structure. Use a normal conversation with manual follow-ups instead.

Writing Good Loop Prompts

The quality of your loop depends almost entirely on how precisely you describe the stop condition and the per- iteration action. A weak loop prompt produces an agent that does something every N seconds until you interrupt it. A strong loop prompt produces an agent that solves the problem and gets out of the way.

The Bigger Picture: Autonomous Development Patterns

/loop is one piece of a broader shift in how software gets written in 2026. The mental model is moving from "I write code, AI assists" to "AI works, I review and steer." Loops enable the longer-horizon version of that: instead of directing Claude on every step, you describe the outcome and let it iterate toward it autonomously.

This only works safely if you build in checkpoints — explicit stop conditions, per-iteration commits, and progress reports that give you visibility without requiring you to hover. The founders and developers who get the most out of agentic AI are not the ones giving the most detailed instructions. They are the ones who write tight exit conditions and trust the AI to fill in the middle.

The right use of /loop is not to automate everything. It is to automate the boring waits and the repetitive passes, so your attention stays on the parts that actually need a human in the loop.