Claude Code Recurring Execution: /loop vs /schedule vs CronCreate Compared

If you want Claude Code to repeat a task, such as checking a build, syncing a task board, or sending a daily report, you have several options that look similar but behave very differently. The differences matter because they decide where the task runs, whether it survives after you close your session, and which tools and credentials it can reach. Choosing the wrong one usually shows up as a task that silently fails to access a CLI or stops when your laptop sleeps. This article compares /loop, /schedule, CronCreate, and the newer Routines feature so you can pick the right mechanism for your task before you set it up.

Summary

	/loop	/schedule	CronCreate
Where it runs	Local (current session)	Remote (Anthropic cloud)	Local (current session)
Persistence	Stops when the session ends	Independent of the session; persistent	Stops when the session ends
Tool access	Full (Bash, Read, MCP, etc.)	Limited (MCP connectors only)	Full
Interval setting	Fixed interval (5m, 2h) or automatic pacing	Cron expression (minimum 1 hour)	Cron expression
Auth/tokens	Local environment variables available	Not available; accessible only through MCP connectors	Local environment variables available

Two rows drive most decisions: where the task runs, and whether it needs local credentials. Everything else follows from those two.

1. /loop: Recurring Runs Inside a Session

Usage

/loop 5m /오늘할일          # every 5 minutes
/loop 2h /오늘할일          # every 2 hours
/loop /오늘할일             # no interval → Claude paces automatically

Features

/loop repeats a slash command inside the current conversation session. It runs only while that session is open, so closing the terminal ends it. Because it runs locally, every local tool is available to it, including Bash, the Gmail CLI, and Notion MCP. If you omit the interval, Claude chooses the wait time itself based on the situation, using ScheduleWakeup.

The key consequence is that /loop inherits the access of your local session. If a command works when you run it by hand in that terminal, it generally works inside the loop too. That makes it the most straightforward option for tasks that depend on local authentication.

Good fit

• Deployment monitoring (“check until the build finishes”)
• PR watching (“let me know when the review runs”)
• Periodic checks during active work (“check email every 2 hours”)

Limitations

• Session ends means the loop ends.
• It is not suited to monitoring over a day or longer.
• Token consumption accumulates as the session gets longer.

The third limitation is worth planning around. A loop that runs for hours inside one long session keeps adding to that session’s context, so it is best reserved for work you are actively supervising.

2. /schedule: Remote Scheduled Agent

Usage

/schedule  → interactive setup

Features

/schedule runs an independent remote session (CCR) on Anthropic’s cloud. You schedule it with a cron expression, with a minimum interval of 1 hour. Because it runs remotely, it keeps working even when your local machine is off. Each run uses a separate git checkout and a sandboxed environment, so it does not touch your local working copy.

Accessible tools

• Git repositories (only the ones you specify)
• MCP connectors (only those connected in claude.ai; currently only Notion is available)
• Bash, Read, Write, Edit, Glob, Grep

Not accessible

• Local environment variables (tokens defined in ~/.zshenv)
• Local CLI tools (gh, supabase, Google Workspace CLI, etc.)
• The local file system

The boundary is clear: anything that depends on your local machine’s credentials or installed tools is out of reach. Only what is reachable through a git repository or a connected MCP connector is available.

Good fit

• A daily morning Notion cleanup report
• Weekly codebase analysis
• Regular PR or issue creation

Limitations

• Locally authenticated tools, such as the Gmail CLI, cannot be used.
• MCP connectors must be connected in advance.
• The minimum interval is 1 hour.

3. CronCreate: Cron Inside a Session

Features

CronCreate works like /loop, but it lets you define precise schedules with cron expressions. It works only within the current session, which makes it effectively the cron version of /loop. It inherits the same local tool access and the same session-bound lifetime.

Good fit

• Tasks that need precise timing, such as “once at the top of every hour”
• Cases where you want /loop’s behavior but prefer a cron expression to a fixed interval

Decision flow

I need to run something repeatedly
  ├─ I can keep a session open
  │    ├─ Simple interval → /loop
  │    └─ Precise cron → CronCreate
  └─ It has to run automatically without a session
       ├─ No local tools needed → /schedule (remote)
       └─ Local tools needed → /loop + keep session alive
                               or an n8n workflow

Start with the question of whether a session can stay open. If it can, the choice between /loop and CronCreate comes down to whether you think in intervals or in cron expressions. If it cannot, the question becomes whether the task needs local tools. If it does not, /schedule is the cleaner option. If it does, you either keep a session alive or move the job to an n8n workflow.

Practical use cases

Gmail → Notion Kanban sync

For this sync, I chose /loop 2h with the today’s-tasks command, running locally. The Gmail CLI needs local authentication, and the Notion MCP is also reachable from the local session. /schedule was not an option because the Gmail MCP connector was not connected.

Morning Notion Kanban cleanup

/schedule (remote) is possible for this task. It needs only the Notion MCP connector and no local tools, so a remote run fits.

Deployment monitoring

I used /loop 5m locally. Checking a deployment needs local tools such as curl and the gh CLI, and the short interval suits a task that needs frequent checks while a deployment is in progress.

These three cases show the same logic applied to different constraints. The first needs local credentials, so it stays local. The second needs only cloud-accessible services, so it can run remotely. The third needs local tools on a short cycle, so a session-bound loop is the natural fit.

4. Routines (New in April 2026, Research Preview)

Official documentation: https://code.claude.com/docs/en/routines

Overview

Routines are presented as a superset of the existing /schedule. They are automation agents that run on Anthropic’s cloud and are managed through a web UI.

Three trigger types

Trigger	Description	Example
Schedule	Cron-based recurring runs (minimum 1 hour)	Daily 9 a.m. backlog cleanup
API	Issue an HTTP POST endpoint and call it from outside	Trigger verification from a deployment pipeline
GitHub	React to events such as PR opened or release	Automatic code review when a PR opens

You can combine several triggers in one Routine, for example a nightly schedule plus PR events plus API calls. The addition of API and GitHub triggers is what separates Routines from /schedule, which supports cron only.

Differences from /schedule

	Routines	/schedule (existing)
Triggers	Cron + API + GitHub	Cron only
Setup UI	Web (claude.ai/code/routines)	Interactive CLI
GitHub events	PR and release filtering supported	Not supported
API trigger	Dedicated endpoint and token issued	Not supported
MCP connectors	All connected connectors available	Only those specified at creation
Environment variables	Managed in Environment settings	Not supported
Setup script	Dependencies can be installed before the run starts	Not supported

The table makes the upgrade path clear. Routines add event-driven triggers, richer connector access, and the ability to prepare the environment before a run. The trade-off is that it is still in research preview.

Key features

• Autonomous execution: Runs completely automatically, with no permission confirmation prompts.
• Managed as sessions: Each run is an independent session, so you can review results, create PRs, or continue the conversation.
• Branch restriction: By default, pushes go only to branches with the claude/ prefix. This can be disabled.
• Connector integration: Connects to external services such as Slack, Linear, and Google Drive through MCP connectors.

GitHub trigger filters

PR events can be filtered in detail:

Filter	Purpose
Author	Filter by PR author
Base/Head branch	Filter by target or source branch
Labels	Only PRs with specific labels
Is draft / Is merged	Exclude drafts, or include only merged PRs
From fork	Only PRs from external contributors

These filters matter most for review and documentation workflows, where you want the automation to act on a narrow set of PRs instead of every event.

API trigger usage

curl -X POST https://api.anthropic.com/v1/claude_code/routines/{trigger_id}/fire \
  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "배포 완료. 스모크 테스트 실행해줘."}'

The response returns a session ID and URL, which you can open in a browser to monitor the run in real time.

Limitations

• It is in Research Preview, so the API and behavior may change.
• Daily run limits apply and vary by plan.
• GitHub triggers have an hourly cap.
• Routines run in the cloud, so they cannot access local files or environment variables.
• Gmail and other MCP connectors must be connected in claude.ai before a Routine can use them.

Practical use cases

Case	Trigger	Action
Backlog cleanup	Schedule (nightly)	Read issues, assign labels and owners, post a Slack summary
Code review	GitHub (PR opened)	Review against the team checklist, leave inline comments
Deployment verification	API (CD pipeline)	Run smoke tests and scan error logs, report to Slack
Documentation sync	Schedule (weekly)	Scan merged PRs, open a PR updating changed API docs
Alert response	API (monitoring tool)	Analyze the stack trace, auto-create a fix PR

The API and GitHub triggers are what make these cases possible. A /schedule job can only wake up on the clock, while a Routine can respond when something happens.

Full comparison (as of April 2026)

	/loop	CronCreate	/schedule	Routines	launchd
Where it runs	Local session	Local session	Remote	Remote	Local system
Persistence	Ends when session closes	Ends when session closes	Persistent	Persistent	Persistent
Triggers	Interval	Cron	Cron	Cron + API + GitHub	Cron
Local tools	All	All	MCP only	MCP only	All
Responds to external events	X	X	X	O (API/GitHub)	X
Setup difficulty	Low	Medium	Medium	Low (web UI)	High (plist)

The table gives the whole picture at a glance. launchd is included as the local-system option configured with plist files, which is the one choice here that does not depend on a Claude Code session at all.

Bottom line

Choose based on three questions: Can the task run with a session open? Does it need local tools or credentials? Does it need to react to external events? If a session is fine and the timing is simple, use /loop. If you need precise cron timing inside a session, use CronCreate. If the task must run unattended in the cloud and only needs connected MCP services, use /schedule. If it must respond to GitHub events or API calls, use Routines, keeping in mind that it is still in research preview and subject to daily and hourly limits. The mistake to avoid is treating the cloud options as drop-in replacements for local ones, because any task that depends on your local machine’s tokens or CLIs belongs in a local mechanism.

Sources

• https://code.claude.com/docs/en/routines
• https://api.anthropic.com/v1/claude_code/routines/{trigger_id}/fire