The /loop Command and Real-Time Channels

The Monitoring Gap

You kick off a deployment, open a new terminal tab, and start typing the next thing — but part of your attention stays on the deployment. You flip back every few minutes to check if it's done, if CI passed, if the PR got comments. That context-switching has a cost. /loop is designed to absorb it.

Where /goal keeps Claude working toward a completion condition, /loop keeps Claude checking on something at regular intervals. It's the watch command for Claude Code: run this prompt repeatedly, report what you find, and continue until the situation resolves or you tell it to stop.

Three Ways to Use /loop

/loop behaves differently depending on what arguments you provide:

Fixed interval: Provide both an interval and a prompt, and Claude runs the prompt on that exact schedule, converting it to a cron expression under the hood:

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

Supported interval units are s (seconds), m (minutes), h (hours), and d (days). Intervals that don't map to a clean cron step — like 7m or 90m — are rounded to the nearest clean interval and Claude tells you what it picked.

Dynamic interval: Provide a prompt without an interval, and Claude chooses how long to wait between iterations based on what it observes. A build that's clearly almost done gets a short wait. A PR that's been quiet for hours gets a long one. The chosen delay and the reason for it appear at the end of each iteration:

/loop check whether CI passed and address any review comments

Bare /loop: Provide neither interval nor prompt, and Claude runs a built-in maintenance prompt on a dynamically chosen schedule. Each iteration works through unfinished conversation tasks, tends to open PRs (checking CI, addressing review comments), and runs cleanup passes like bug hunts when nothing else is pending.

/loop

Add an interval to the bare form to run maintenance on a fixed schedule: /loop 15m.

The Monitor Tool Under the Hood

In dynamic mode, Claude may use the Monitor tool directly instead of polling on an interval. Monitor runs a background script and streams each output line back into the session as it appears. Rather than checking a build status every few minutes, Claude can watch the build process's stdout in real time, which is more responsive and token-efficient than repeated polling.

When Claude uses Monitor for a loop, it still appears in your scheduled task list like any other loop — you can list it or cancel it the same way. The seven-day expiry still applies.

Customizing with loop.md

A loop.md file replaces the built-in maintenance prompt with your own default. Claude looks for it in two locations:

loop.md is ignored whenever you provide a prompt on the command line. It only replaces the built-in default for bare /loop. The file is plain Markdown with no required structure — write it as you'd type the prompt directly. Content beyond 25,000 bytes is truncated. Edits take effect on the next iteration, so you can refine the instructions while a loop is running.

You can also re-run a named skill on each iteration by including it as the prompt:

/loop 20m /review-pr 1234

Managing Loop Tasks

Under the hood, /loop uses three tools: CronCreate to schedule a task, CronList to list all scheduled tasks with their IDs and schedules, and CronDelete to cancel a task by ID. You can interact with these directly by asking Claude in natural language: "what scheduled tasks do I have?" or "cancel the deploy check job."

To stop a /loop while it's waiting for the next iteration, press Esc. This clears the pending wakeup so the loop doesn't fire again. Note that tasks you created by asking Claude directly (rather than via the /loop command) are not affected by Esc — you'll need to explicitly cancel those.

Backgrounding a session with Ctrl+B preserves active loop tasks. The session keeps running in the background, firing the loop at each interval even without a terminal attached.

Two Limits: 7 Days and 50 Tasks

Session-scoped tasks have two built-in limits. First, recurring tasks automatically expire seven days after creation — the task fires one final time, then deletes itself. This prevents forgotten loops from running indefinitely. For automation that needs to run beyond a week, use Desktop scheduled tasks or cloud Routines.

Second, a session can hold up to 50 scheduled tasks at once.

Resuming with --resume or --continue restores tasks that haven't expired: recurring tasks created within the last seven days, and one-shot tasks whose time hasn't passed yet.

Channels: Event Push Instead of Polling

Polling has an inherent inefficiency: Claude runs every N minutes whether or not anything has changed. For some use cases — watching a long build, checking a deployment — that's acceptable. For others, there's a better option.

Channels let external systems push events directly into an open Claude Code session instead of having Claude poll for them. Your CI system can send a failure notification the moment a build fails, and Claude can respond immediately rather than waiting for the next /loop interval. The event lands in the session as a message, and Claude can act on it right away.

The distinction matters most when events are infrequent but time-sensitive. A failed test that needs immediate attention is better served by a Channel push than a five-minute polling interval. Use /loop for steady-state monitoring where you're OK with the polling delay; use Channels when the external system can push and latency matters.