Off the Leash

Local scheduling requires a running process and machine. Sleep can pause execution, while some configurations keep background work running. Explicit cancellation is the dependable way to stop a task; closing a lid is not a universal boundary.

/schedule is the same recurring-automation idea with the leash cut.

It doesn't run in your session. It doesn't run on your machine. It runs on Anthropic's cloud, on a clock, whether your laptop is open, asleep, or shut in a bag at 35,000 feet. Close the terminal — it still fires. End the session — it still fires. That's the feature and the danger in one sentence, and the rest of this post is about both.

What it actually is

The /schedule command manages cloud Routines: saved prompts and configured resources that start sessions on triggers. A routine is durable configuration; each run is an execution to inspect, not a promise that its task completed.

/schedule every weekday at 9am, review open PRs and leave inline comments
/schedule nightly, bump dependencies and open a PR if the tests pass
/schedule clean up the legacy feature flag in one week

Current documentation describes creation and management through /schedule and the web interface for eligible Pro, Max, Team and Enterprise accounts with Claude Code on the web enabled. API and GitHub triggers have their own configuration path. Check the current preview requirements for the intended account.

Under the hood it's the thing ops engineers have wanted from cron for twenty years and never got: a cron job that can think — one that clones your repo, reads the issue tracker, writes code, and opens a PR, then disappears until next time.

How a run actually happens

This is where the cloud model bites, so be precise about it.

• Fresh clone, every time. Each run starts from a clean checkout of your repo's default branch. It does not see your local files, your uncommitted changes, your .env, your running services. If the work depends on something, that something has to be committed or reachable over the network. Push first, or to the routine it doesn't exist.
• Fully autonomous. There are no permission prompts — there's no one sitting there to answer them. The routine runs with exactly the repo and connector access you granted when you created it. It works on claude/-prefixed branches and opens PRs; it won't touch main unless you let it.
• Stateless between runs. A routine has no memory of last night. Run 14 knows nothing run 13 learned. The prompt has to be self-contained and re-derive the world each time — read the open issues, diff the branches, check the logs — because “what did I do yesterday” is not a question it can answer. Write the prompt for a brilliant amnesiac.
• Three ways to wake it. A cron schedule is one. The other two are where it gets interesting: an HTTP API trigger (POST to the routine's fire endpoint with a per-routine token, so your CD pipeline can summon Claude the second a deploy finishes) and GitHub webhooks (run on every PR opened, every merge). The clock is just the default door in.

Cloud schedules have a documented minimum interval and can start after their nominal time. Run allowances, token management and trigger controls can change during the preview. Use the current Routines reference for those limits and test token rotation or revocation before relying on an integration.

The family, finally complete

Three posts, three commands, and they finally line up into one decision. The question is never “which command is best” — it's what wakes the work, and where does it live.

Read it as a flowchart. A stop condition? /goal. A clock, while you're working and watching? /loop. A clock that needs your local files and tools? A desktop task. A clock that has to fire whether or not you exist at that moment? /schedule. The axis that matters most is the one in bold: is your machine the substrate, or isn't it. /loop and desktop tasks are tethered to hardware you own. /schedule is the first one that isn't — and that single fact changes everything about how you have to think about safety.

The leash was load-bearing

Moving execution to the cloud removes dependence on the local process. Replace that dependence with explicit access controls, cancellation and run monitoring. A successful session status does not establish that the task’s acceptance criteria passed.

So you replace it with boundaries that don't depend on you being in the room:

• Scope the access. A routine has exactly the repos and connectors you handed it. Give it the minimum. A docs-drift checker does not need write access to prod.
• Enforce the intended review boundary. Branch protection can restrict changes to protected branches when configured without bypasses. It does not constrain separate deployment credentials or connector writes. Restrict those capabilities and network access separately, and enforce required approval before consequential actions.
• Write a precise prompt. State the permitted files, expected output and stopping conditions, such as opening at most one PR or stopping when checks fail. The agent interprets those instructions; permission and isolation controls must enforce the applicable limits.
• Watch the meter. Every run draws from your subscription. An unattended thing that wakes hourly and fans out into subagents is an unattended thing that spends. Read the run history and your usage the way you'd read a cron job's logs — except this cron job has a credit card.

What it's genuinely great at

Cynicism aside, the use cases are real, and they're the boring-but-valuable kind:

• Nightly backlog grooming — read new issues, label them, assign, post a digest to Slack before standup.
• Alert triage — wire the API trigger to your error tracker; on a spike, Claude correlates the trace to recent commits and drafts a fix PR before you've finished your coffee.
• Post-deploy verification — CD calls the fire endpoint, the routine runs smoke tests against the live deploy and reports back. One caveat: the cloud has to be able to reach your deploy — if it sits behind a VPN or an internal mesh, durable isn't omnipresent.
• Docs-drift detection — weekly, diff merged PRs against the docs and open update PRs for whatever went stale.
• Dependency hygiene — nightly bump, run the suite, open a PR only if it's green.

These are candidate workflows. Some produce pull requests; others produce analysis or a notification when authorized. Define the permitted output and verification for each rather than assuming every routine has the same review boundary.

Hot takes

1. /schedule is the first Claude Code primitive where your machine stops being the substrate. That's the whole feature. Everything good and everything scary about it falls out of that one fact.
2. The leash you loved to hate on /loop was a safety feature. Cutting it is the point of /schedule — which means you now owe the system the guardrails the terminal used to give you for free.
3. Write every routine prompt for a brilliant amnesiac. It is stateless and unattended; “remember what you did last time” isn't available, and neither are you.
4. Choose an explicit action boundary for each routine. A PR-only workflow needs enforced merge restrictions and no independent deployment or messaging authority. Inspect effective grants and any bypass permissions instead of relying on the prompt alone.
5. A useful unattended routine combines a scoped prompt with restricted credentials, effective repository and connector permissions, network controls, cancellation and observable results. Each control has a separate job; the prompt does not replace enforcement.

Sources: Claude Code Routines; Scheduling comparison; GitHub branch-protection scope. Documentation checked September 20, 2026.