Claude Code routines and local scheduling modes

The hardest part of scheduling an AI coding task is not writing the prompt. It is putting the task in the wrong place and discovering the mistake after the run was supposed to happen.

Claude Code now gives you several ways to repeat work: cloud routines, local Desktop scheduled tasks, the terminal's /loop, and GitHub Actions. They sound interchangeable because they all accept instructions and a cadence. They are not interchangeable. One runs from a fresh repository clone in Anthropic's infrastructure. One needs your laptop awake. One dies with the terminal session. One belongs in CI, where a failed job can be inspected like any other build.

The useful question is simple: what does this task need to reach, and what happens if it misses a run? Answer those two questions and the choice gets much less confusing.

Pick the execution environment

Use a cloud routine for committed code and unattended work. Claude Code routines run in Anthropic-managed cloud infrastructure, or in an organization self-hosted environment when configured that way. Your computer can be off. A routine can run on a schedule, receive an authenticated API request, or react to GitHub events. That makes it a good fit for a nightly issue sweep, a weekly documentation check, or a post-deploy smoke review.

The catch is the starting state. Each run begins with the repositories you selected, cloned from the default branch. Your uncommitted experiment, local database, private service on localhost, and unpushed branch are outside the routine's view. The environment also controls network access and credentials. Connectors can write to services without waiting for an approval prompt during the run, so adding every available connector is a bad default.

Use a local Desktop scheduled task when the files are on your machine. The local task can read the working folder and use local tools. It persists across restarts, but it only fires while the Desktop app is open and the computer is awake. The official documentation says a missed run is skipped if the machine sleeps. When the app starts or the computer wakes, Desktop may perform one catch-up run for the most recent missed time within the last 7 days. It does not replay every missed interval.

That last detail changes how you write the prompt. A task that says “process the 9am inbox” may run at 11pm after a laptop wakes. A safer instruction says, “Only process messages received today. If this is a catch-up run, report the missed window and do not send anything.” The scheduler cannot infer that policy for you.

Use /loop while you are actively working. /loop 30m run the tests and check the pull request is excellent for a build that is finishing or a review that is receiving comments. It is session-scoped. Close the terminal or start a fresh conversation and the task stops. Recurring loops also expire after 7 days, and missed fires do not turn into a backlog of runs. The session can hold up to 50 scheduled tasks, but that is a ceiling for a working session, not a production scheduler.

The minimum interval is also different. Local Desktop tasks and /loop support intervals down to 1 minute. Cloud routines require a minimum interval of 1 hour. If you need a 5-minute polling loop, keep it local or use a CI or monitoring system designed for that frequency. Do not force a cloud routine into a job it was not designed to run.

Use GitHub Actions when the work is really a build step. Anthropic's scheduling documentation lists GitHub Actions alongside routines and Desktop tasks for unattended automation. CI is the better home for deterministic checks, permissions that belong to a repository, artifacts, and logs that should remain attached to a commit. A Claude routine is more convenient when the task needs open-ended reasoning and can safely produce a draft issue or pull request. Actions are easier to audit when the sequence itself matters.

Here is the short routing rule I use:

  • Committed repository plus laptop may be off: cloud routine.
  • Local branch, local files, or private local tools: Desktop task.
  • A task you are watching during a live session: /loop.
  • A repeatable repository check with CI status and artifacts: GitHub Actions.

If two choices still look plausible, choose based on failure cost rather than convenience.

The failure modes that matter

Before: You create a cloud routine for “check the project every hour.” You assume it sees the same project you have open locally. It does not. It sees a fresh clone, usually from the default branch, and starts a new autonomous session.

After: Commit the exact files the routine needs, select only that repository, and make the prompt name the expected output. For example: “Review issues opened since the previous run. Label only clear bug reports. Open a draft pull request for documentation changes. Do not merge, delete, or message customers.” This turns a vague background agent into a bounded job.

What broke: A routine can reach more than its prompt may suggest. The selected environment controls network access, variables, and setup scripts. Included connectors may expose tools that can write to Slack, Linear, or other services without an approval prompt. The account identity used for those actions is yours. That is a messy audit trail if you give a routine broad access and let it improvise.

What I learned: The cloud option is not “Claude running your laptop remotely.” It is a clean, isolated execution environment with selected repositories and connectors. Treat it like a small service account, even though the UI makes setup feel casual.

Before: You create a local Desktop task for a daily code review and close the app at night. The run never starts. You wake the laptop the next morning and see one catch-up run for the latest missed time, not a review for every day you missed.

After: Turn on the Desktop setting that keeps the computer awake, then run the task manually once. Watch for permission prompts and record which tools it actually needs. If the job must run while the lid is closed, move it to a cloud routine instead. If the job depends on local files, keep it local and make the prompt tolerate a delayed run.

What broke: Local scheduled tasks can operate against uncommitted changes by default. That is convenient for a personal review and risky for an unattended edit. A task with write access can change the branch you forgot was open. An isolated worktree is the safer setting when the run should produce a reviewable patch rather than modify your active checkout.

What I learned: “Local” solves the data-access problem, not the safety problem. Start with read-only instructions, test with Run now, and add write permissions only after you have inspected a few outputs. The Claude Code hook that blocks destructive shell commands is a useful second layer for local sessions.

Before: You use /loop for a job that has to survive the weekend. It works while you are in the terminal, then disappears when the conversation changes or the 7-day expiry arrives.

After: Keep /loop for temporary attention loops: watch CI, poll a deploy, wait for review comments, or remind yourself about a one-time action. Move durable daily or weekly work to a routine or Desktop task. Use CI when the task should have a commit, log, and status check attached to it.

What broke: A fixed interval is not always a fixed wall-clock time. The scheduler can add jitter, and a task waits until Claude is idle if the current turn is still running. A 5-minute check is not a promise that a human will see a result exactly five minutes later. For a deployment gate, the event should come from CI or monitoring, not because the chat loop is open.

What I learned: /loop is a useful assistant to an active session, not a replacement for an event system. Its low setup cost is the point. Its lack of independence is also the point.

A rollout that does not wake you at 2am

Start with a task whose worst failure is a missing report. Weekly documentation drift is a good example. Ask the agent to inspect merged changes, identify docs that may be stale, and open a draft pull request. Do not begin with production deploys, customer email, or automatic merges.

Run the same prompt manually first. Remove assumptions about memory between runs. If the routine needs to know what happened last time, store that state in a file, issue, database, or commit. A fresh cloud session will not remember your previous reasoning just because it has the same name.

Then choose the smallest environment that works:

  • A local branch or private network service means Desktop.
  • A committed repository and GitHub or Slack output means cloud routine.
  • A CI check with deterministic logs means GitHub Actions.
  • A live investigation that ends soon means /loop.

For cloud routines, set the minimum network access, use credentials rather than exposing secrets as ordinary environment variables, and remove connectors the prompt does not need. The current documentation calls routines a research preview. Limits and behavior can change. Routines also draw down subscription usage like interactive sessions, then add a daily run cap. Anthropic's launch post listed caps of 5 runs per day for Pro, 15 for Max, and 25 for Team and Enterprise, with extra usage available beyond those limits. The routines UI is the authority for the allowance on your account.

That cap is why “run every hour” should not be your default. A nightly job consumes less of the allowance and is easier to review. If a task needs frequent event handling, send only meaningful events, or put deterministic filtering in front of the AI step.

The final test is boring and effective. Turn off the laptop. Change the local branch without committing it. Trigger the cloud routine. Open a new terminal session and check /loop. Run the CI workflow against a known fixture. You are not testing whether Claude can follow the prompt. You are testing whether the scheduler can see the same world you think it can see.

That is the real split. Cloud routines trade local access for independence. Desktop tasks trade independence for local access. /loop trades durability for speed. GitHub Actions trades conversational flexibility for build-system accountability. Pick the trade you can explain when the run fails.

Sources