Claude Code scheduled tasks: /loop, routines and cron compared

Where each one runs

The first three rows are Anthropic’s own comparison, as its docs give it on October 11, 2026. The last two are the routes outside Claude Code. The shortest interval is one minute for /loop, Desktop tasks and cron, and one hour for a routine.

Anthropic’s own advice follows the same line: “Use cloud tasks for work that should run reliably without your machine. Use Desktop tasks when you need access to local files and tools. Use /loop for quick polling during a session.”

/loop: a schedule inside one session

/loop re-runs a prompt in the session you type it into. It takes an interval, a prompt, or both:

/loop 5m check the deploy       # every five minutes
/loop check the deploy          # Claude picks the gap each time
/loop 20m /review-pr 1234       # a skill as the prompt

With no interval, Claude chooses one after each pass, “between one minute and one hour”. Units are s, m, h and d; seconds are rounded up to a minute, and an interval that does not fit a clean cron step, such as 7m, is rounded to the nearest one that does. You can also ask in plain words for a single reminder (“remind me at 3pm to push the release branch”), which fires once and deletes itself. A session holds up to 50 scheduled tasks.

The limits are what decide whether it fits your job. From the same page:

• It needs the session. “Tasks only fire while Claude Code is running and idle. Closing the terminal or letting the session exit stops them firing.”
• Nothing is caught up. If a task’s time passes while Claude is busy, “it fires once when Claude becomes idle, not once per missed interval.”
• It expires. “Recurring tasks automatically expire 7 days after creation. The task fires one final time, then deletes itself.”
• Resuming brings back only some. claude --resume restores tasks created with the scheduling tool, but a loop where Claude picks the interval is not restored: run /loop again.

One thing lets a loop outlive the terminal. Moving the session to the background with /background carries its loops into a background session, which a separate supervisor process keeps running with no terminal open. That survives closing the terminal and survives sleep. It does not survive the machine shutting down or restarting, and the feature is a research preview. Setting CLAUDE_CODE_DISABLE_CRON=1 switches /loop and its tools off altogether.

So /loop is for watching something while you work: a deploy, a long test run, a pull request waiting on review.

Desktop scheduled tasks: your machine, with the app open

The Claude desktop app has its own scheduler. In the Code tab, open Routines, choose New routine and then Local, or describe the schedule in a session (“set up a daily code review that runs every morning at 9am”). Local tasks need Claude Desktop 1.1.5368 or later. Anthropic’s page puts the condition in one sentence: “A local task runs on your machine with direct access to your files and tools, but only fires while the app is open and your computer is awake.”

The app has a Keep computer awake setting, with a limit the docs state themselves: “Closing the laptop lid still puts it to sleep.” For a run the computer slept through, the page says two things, and both hold. The run at that time is skipped. Then, when the app starts or the computer wakes, “Desktop starts exactly one catch-up run for the most recently missed time and discards anything older”, looking back seven days. A daily task that missed six days runs once.

Each task carries its own permission mode. A task left in Manual mode that reaches for a tool it may not use stalls until you approve it, so an unattended task needs a mode or allow rules that cover what it does. When a task fires you get a desktop notification, and its session appears under Scheduled in the sidebar.

Routines: Anthropic’s cloud, hourly at most

A routine is a saved prompt, one or more repositories and a set of connectors that Anthropic runs for you. Routines “execute on Anthropic-managed cloud infrastructure” and “keep working when your laptop is closed”. They are a research preview, available on Pro, Max, Team and Enterprise plans. You create one at claude.ai/code/routines, in the desktop app (New routine, then Cloud), or from the terminal:

/schedule daily PR review at 9am
/schedule list

/schedule needs a claude.ai subscription sign-in; with an API key as the active credential the command is not offered. A routine can fire on a schedule, on an HTTP request to its own address, or on a GitHub event such as a pull request or a release.

What a routine can reach is the part to check against your job:

• A fresh clone, not your machine. Each run is a new cloud session, each repository “is cloned at the start of a run”, and Claude pushes to branches prefixed claude/ by default. Files on your computer, tools you installed there and anything on your private network are out of reach. MCP servers you added locally do not appear either; a routine uses the connectors on your claude.ai account.
• No one is asked. A routine runs shell commands and calls its connectors “all without stopping for approval apart from some artifact actions”.
• Hourly at most. “The minimum interval is one hour; expressions that run more frequently are rejected.” A run set exactly on the hour “can start several minutes late”.
• It spends your plan. “Routines draw down subscription usage the same way interactive sessions do.” Scheduled runs are capped at 100 an hour per account, and a run over the cap waits.
• Green is not success. A green status means the session started and ended without an infrastructure error. “It does not mean the task in your prompt succeeded.”

That makes a routine the fit for work that lives in a repository and ends in a pull request: a nightly review, a weekly dependency update, a response to each new release. Cloud sessions against a machine of your own covers what the cloud side keeps between runs.

GitHub Actions on a schedule

The Claude Code GitHub Action runs on any GitHub event, a cron schedule included: a workflow with on: schedule, anthropics/claude-code-action@v1 and a prompt. It runs on GitHub’s runners and uses your Actions minutes. Two of GitHub’s own rules apply, as the page notes: scheduled workflows run only from the default branch, and in a public repository GitHub disables the schedule after 60 days without repository activity. With a plain prompt Claude has no shell and no GitHub API access until the workflow grants the tools it needs. The action signs in with an API key stored as a secret, or with the token from claude setup-token, in which case runs use your Claude subscription instead of API billing.

cron or a systemd timer, on a machine that stays on

Anthropic documents a non-interactive mode for scripts and CI, claude -p, and says nothing about cron. Putting the two together is ordinary Linux: the operating system’s scheduler starts Claude Code, it does the work and exits. It runs in your real project folder, with your tools and your network, as often as cron allows, and it needs nothing open. It needs the machine on at the scheduled minute, which is why this route belongs on a desktop that never sleeps, a home server or a cloud server, not a laptop.

# crontab -e
0 7 * * 1-5 cd $HOME/project && $HOME/.local/bin/claude -p "Update CHANGELOG.md from yesterday's commits" --permission-mode acceptEdits --max-turns 20 >> $HOME/claude-cron.log 2>&1

Four things to get right, because nobody is there to notice:

• The full path. cron does not read your shell’s startup files. On an Ubuntu 24.04 server on October 11, 2026, in a home folder with Ubuntu’s stock shell files, Claude Code’s installer put claude in ~/.local/bin, which a login shell had on its PATH and a plain non-login shell did not. The Linux install guide has the detail.
• A permission mode. With no one to answer a prompt, say in advance what is allowed: --permission-mode (acceptEdits writes files without asking, dontAsk denies everything that would have asked), --allowedTools for named tools, and since version 2.1.259 --permission-prompts none, which denies any prompt that would otherwise wait. A run that sets no mode takes the built-in starting mode, “which can be auto, so pass the one you want”.
• A ceiling. --max-turns ends a run that loops, and --max-budget-usd stops one whose estimated API spend reaches a figure.
• A folder you trust. A -p run loads what an interactive session would, and the docs spell out the consequence: it “runs the hooks in a project’s .claude/settings.json and connects the servers in its .mcp.json, even in a folder you’ve never trusted”, with no trust dialog. --bare skips all of that and starts faster, and Anthropic says it “will become the default for -p in a future release”.

Signing in is the other half. A scheduled run uses the sign-in saved for the user it runs as, and an ordinary sign-in can lapse while nobody is looking. For unattended work Anthropic provides claude setup-token, a one-year token you put in the CLAUDE_CODE_OAUTH_TOKEN variable, or an API key in ANTHROPIC_API_KEY. Two details bite here. --bare does not read the token or your subscription sign-in, so a bare run needs the API key. And in -p mode an API key in the environment is always used when present, so a key left in the crontab bills the API even when you meant the run to use your plan.

On what a plan-backed run costs, Anthropic’s help centre said this on October 7, 2026: “Claude Max and Team plans now include monthly API credits, which cover the Claude Agent SDK, claude -p, the Claude API, and Claude Managed Agents. You can still use the Claude Agent SDK, claude -p, and third-party apps with your subscription limits.”

cron runs a job only if the machine is on at that minute, and does not run it later. A systemd timer can: with Persistent=true, its manual says the service “is triggered immediately if it would have been triggered at least once during the time when the timer was inactive”, which it calls “useful to catch up on missed runs of the service when the system was powered down”.

Codex’s equivalents

OpenAI’s desktop app has scheduled tasks with the same split. A task that works on a local project runs on your computer, in the project folder or a new worktree, and the docs say: “Keep the computer on and the app running when a scheduled task needs local files.” Tasks created on the web can use uploaded context and connected tools but cannot work in a folder on your computer, and Team Tasks “run in the cloud through the team’s service account”. A task can also fire on a Gmail, Slack or GitHub event, though one task cannot mix event triggers with a time schedule.

From cron, the command is codex exec, which OpenAI lists for “CI, pre-merge checks, scheduled jobs”. It runs in a read-only sandbox unless you pass --sandbox workspace-write, and it reuses the saved sign-in. Codex CLI on a Linux server has a working crontab line and the PATH problem that goes with it.