Mastering Claude Code · ~7 min

Scheduling & Cloud Routines

Stop babysitting a terminal at 9am. Recurring work belongs on a schedule — and the only real decision is which machine runs it.

Claude Code gives you two scheduling surfaces with one clean dividing line: where the run executes. Local scheduling stays inside your session; cloud routines run on Anthropic infrastructure. Everything else — cadence, file access, permission gates — follows from that one choice.

1 Local scheduling: /loop and the cron tools

Session scheduling re-runs a prompt automatically inside an active session. The interactive entry point is the /loop bundled skill — pass an optional interval and a prompt, and Claude converts it to a cron expression:

Units are s, m, h, d; seconds round up to the nearest minute. Under the hood, agents and skills drive the same machinery with three tools: CronCreate (schedule a task), CronList (list tasks with IDs), and CronDelete (cancel by 8-character ID). Expressions are standard 5-field cron — wildcards, steps (*/15), ranges, comma lists — with a 50-task-per-session cap.

For a deferred one-off, just describe it: remind me at 3pm to push the release branch schedules a single-fire task that auto-deletes after running. A few execution facts worth holding: tasks fire between turns (never mid-response), in your local timezone, with deterministic jitter, and no catch-up — a fire missed while Claude is busy runs once when idle, not once per missed interval.

2 Cloud routines: durable, but a different machine

A Routine is a saved Claude Code configuration — prompt, repos, connectors, environment — that runs on Anthropic-managed cloud infrastructure on a schedule, an API call, or a GitHub event. Create one from the CLI with /schedule. It is the cloud counterpart to /loop and CronCreate, and the deployment choice is a clean trade: cloud fixes host-uptime and env-drift failures but breaks working-tree fidelity, the permission gate, and sub-hour cadence.

Choose cloud when all hold: cadence is hourly or slower (sub-hour cron is rejected), work runs against the default branch (each run clones fresh from it — in-flight feature work is invisible), no mid-run human approval is needed, and every required resource is reachable from the cloud environment. Move scheduled work to the cloud when the local box is the failure point — laptops that sleep, reboots that drop cron, dev-env drift, rotated secrets.

3 The cloud trade has teeth

The same "always on, no prompts, acts as creator" posture that makes routines durable is what opens their failure surfaces. Three are worth memorizing:

• Identity collapse — routines act as the creator on every connector and on GitHub. Commits, PRs, Slack messages, Linear tickets all carry one person's name: a single point of attribution and credential compromise.
• The autonomous-run trifecta — a routine combining a private-data connector, an untrusted-input source (web fetch, issue bodies), and an egress connector (push, Slack) closes the lethal trifecta with no prompts to interrupt the chain. There is no human-in-the-loop surface during a run, so the confirmation-gate posture simply cannot apply.
• Working-tree drift — an audit reading STANDARDS.md from main never sees your unmerged feature-branch edit. The cloud snapshot is the default branch at clone time.

The rule of thumb writes itself. A weekly dependency audit against main fits cloud cleanly — autonomous PR posture is the point. A hotfix loop watching CI on your current feature branch does not: it needs the live branch, 5-minute granularity, and the in-session prompt on git push.