Claude Code scheduled tasks: /loop, routines, and what runs on its own

Find the situation you are in

• I have never used this and I want to know which of the three I need.
• I want a prompt to repeat while I keep working in the same session.
• I just want a reminder later, once.
• I want work to run while my laptop is closed, or when a pull request lands.
• I want it to run on this machine with my files where they are.
• It printed a message and I want to know which one means what.
• I read that these are called routines and I want to know if that is the same thing.

Anthropic documents the three kinds on three pages, and each page assumes you already know which one you want. That is the gap this page fills. If what you actually need is a single unattended run rather than a timetable, the headless guide owns that: print mode, its flags, and the way a run behaves in a script or in CI.

What a scheduled task is

A scheduled task is a prompt saved so Claude Code runs it without you typing it again. Anthropic's own sentence for the in-session kind is that session-scoped scheduled tasks let Claude re-run a prompt automatically on an interval within a Claude Code session, and the examples it gives are the shape of the whole feature: poll a deployment, babysit a pull request, check back on a long build, or remind yourself to do something later in the session.

Where the work happens is what separates the three. A cloud scheduled task is a saved configuration of a prompt, one or more repositories and a set of connectors, run on Anthropic-managed infrastructure, so it keeps working when your laptop is closed. A desktop scheduled task runs on your machine, with your files, and only while the app is open and the computer is awake. /loop runs in the session you already have, and it fires only while that session is running; a resume brings back the tasks that have not expired or whose time has not passed, which the section on limits goes into. Anthropic puts the choice in one line: cloud tasks for work that should run reliably without your machine, desktop tasks when you need local files and tools, and /loop for quick polling during a session.

The naming is the part that trips people up. Scheduled tasks were previously called routines, and Anthropic keeps the earlier name in several places on purpose. The web address is still claude.ai/code/routines. The CLI command /schedule still answers to /routines. The API trigger is still a /fire endpoint that returns a routine_fire type, and the tag it wraps incoming text in is still <routine-fire-payload>. An organization toggle is still labelled Scheduled tasks (Was Routines). Anything you read about a routine describes this same feature.

One warning belongs at the top. Cloud scheduled tasks are in research preview, and Anthropic says in as many words that behavior, limits and the API surface may change. The in-session tools and desktop tasks are not marked that way. If you are deciding what to build a process around, that difference is worth knowing before you commit.

Choose the right kind

Anthropic repeats one comparison table on each of the three pages, and it answers most of the question on its own. The rows below are the table's, in its own terms.

Read the fourth row twice if you are leaving something running over a weekend. A cloud task is the only one of the three that does not care whether your computer is awake, and /loop is the only one that dies with the session. Anthropic's minimum interval also differs by kind, which matters when you want a check every few minutes: only the in-session loop and a Claude-set desktop schedule go below an hour.

Repeat a prompt inside a session with /loop

The /loop bundled skill is the quickest way to run a prompt on repeat while the session stays open, and Anthropic says plainly that both the interval and the prompt are optional. What you supply decides what the loop does.

When you supply an interval, Claude converts it to a cron expression, schedules the job and confirms the cadence and the job ID. The interval can lead the prompt as a bare token such as 30m, or trail it as a clause such as every 2 hours. The supported units are s for seconds, m for minutes, h for hours and d for days.

Two rounding rules are worth knowing before you trust a timestamp. Seconds round up to the nearest minute, because cron has one-minute granularity. An interval that does not map to a clean cron step, such as 7m or 90m, is rounded to the nearest interval that does, and Claude tells you which one it picked. If the exact cadence matters, choose a number that divides an hour.

Leave the interval out and the loop stops being a fixed schedule at all. Claude chooses a delay between one minute and one hour after each iteration, based on what it just saw: short waits while a build is finishing or a pull request is active, longer waits when nothing is pending. It prints the delay it chose and its reason at the end of each iteration.

A skill can be the prompt, for example /loop 20m /review-pr 1234, but a scheduled fire only runs skills Claude is allowed to invoke on its own. Built-in commands such as /permissions, /model or /clear reach Claude as plain text instead of executing, and so do skills marked disable-model-invocation: true, skills a skillOverrides setting or a deny rule hides, and MCP prompts. If your loop appears to do nothing, that list is the first place to look.

The command has a second name. Anthropic's command reference lists /proactive as an alias for /loop, which is why older material about proactive loops is describing this same skill.

What a bare /loop runs

When you omit the prompt, Claude uses a built-in maintenance prompt rather than one you supplied. On each iteration it works through three things, in this order: continue any unfinished work from the conversation, tend to the current branch's pull request including review comments, failed CI runs and merge conflicts, and run cleanup passes such as bug hunts or simplification when nothing else is pending.

Anthropic bounds that prompt in two ways, and both are good news for an unattended loop. Claude does not start new initiatives outside that scope, and irreversible actions such as pushing or deleting only go ahead when they continue something the transcript already authorized.

You can replace that default with your own instructions in a loop.md file. It defines a single default prompt for a bare /loop, not a list of separate tasks, and Claude Code ignores it whenever you supply a prompt on the command line. It looks in two places and uses the first it finds.

.claude/loop.md     project level, wins when both files exist
~/.claude/loop.md   user level, for any project without its own

The file is plain Markdown with no required structure, and you write it as if you were typing the prompt. Edits take effect on the next iteration, so you can refine the instructions while a loop is running. Content beyond 25,000 bytes is truncated, so keep it under that.

Stop a loop

How you stop one depends on which kind you started, and pressing Esc is only half an answer. While a self-paced loop is waiting for its next iteration, Esc stops it, and a notice confirms the pending wakeup was cancelled. Ctrl+C works there too while Claude is idle, with one exception: not in a background session you have attached to.

A fixed-interval loop is different. To stop /loop 5m you ask Claude to cancel it, for example cancel the deploy check loop. Esc and Ctrl+C do not stop it, and they do not stop a task you scheduled by asking Claude directly either. A loop you never cancel ends on its own when seven days elapse.

A self-paced loop can also end itself. Once the task is done, Claude calls the ScheduleWakeup tool with stop: true, which cancels the pending wakeup immediately. If an iteration ends without either rescheduling or stopping, Claude Code schedules one fallback wakeup about 20 minutes later, and ends the loop when that iteration does not reschedule either.

If you want to leave the session without stopping the loop, attach to a background session, wait until Claude is idle, and press Ctrl+C twice on an empty prompt. The loop keeps running and its next iteration starts on schedule. To stop it instead, press Esc before you detach. Detaching that way needs Claude Code v2.1.295 or later.

Set a one-time reminder

For a single reminder you describe what you want in natural language instead of using /loop. Claude schedules a task that fires once and deletes itself after running, and it pins the fire time to a specific minute and hour using a cron expression, then confirms when it will fire.

remind me at 3pm to push the release branch
in 45 minutes, check whether the integration tests passed

These one-shot tasks follow the same timing rules as the rest, including the shift described under when a task actually fires. A reminder set for the top of the hour can run a little early, which is harmless for a reminder and important for anything that reads a clock.

List, inspect and cancel session tasks

You do not need to remember an ID to manage these. Ask Claude in natural language, for example what scheduled tasks do I have? or cancel the deploy check job, and it works on the list for you.

Underneath, three tools do the work, and their names appear in the transcript whenever a task is created or listed.

Each task carries an 8-character ID you can pass to CronDelete, and a single session can hold up to 50 scheduled tasks at once. The next run time appears in the row under the CronCreate call and again when you ask for a list, and that display needs Claude Code v2.1.299 or later.

When a task actually fires

The scheduler checks every second for due tasks and queues them at low priority. A scheduled prompt fires between your turns rather than while Claude is mid-response, so if Claude is busy when a task comes due, the prompt waits until the current turn ends. All times are read in your local timezone: 0 9 * * * means 9am wherever you are running Claude Code, not 9am UTC.

Fires are deliberately spread out. If every session's tasks ran exactly on schedule they would all call the API at the same moment, so Claude Code shifts each one. Recurring tasks run late, with one exception: a task written */5 * * * * is not delayed. One-shot tasks scheduled on the hour or the half hour run a little early instead.

The rule behind that table is that a recurring task starts each run late by up to half the gap to the next run, and by at most 30 minutes. The cap is the part that governs a long gap: half the gap for an hourly task is 30 minutes and half the gap for a daily task is 12 hours, so the 30-minute ceiling is what a daily task actually drifts by. A one-shot task scheduled for :00 or :30 runs up to 90 seconds early, and one scheduled for any other minute is not shifted at all. When the exact minute matters, schedule it off the hour, as 3 9 * * * rather than 0 9 * * *.

Every recurring session task expires seven days after it is created. It fires one final time, then deletes itself, which bounds how long a forgotten loop can run. If you need it to last longer than that, cancel and recreate it before it expires, or move the work to a cloud or desktop task, both of which are durable.

What a session-scoped task cannot do

The constraints are inherent to running inside a session rather than in a service, and Anthropic lists them. These are the ones that change how you write the schedule.

• Tasks fire only while Claude Code is running and idle. Closing the terminal, or letting the session exit, stops them. Backgrounding the session carries /loop tasks over to it, and a background session keeps running without a terminal.
• There is no catch-up for missed fires. If a scheduled time passes while Claude is busy on a long request, the task fires once when Claude becomes idle, not once per missed interval.
• A self-paced loop in a background session stops if its next wakeup comes due while the session's process is not running, such as after a crash. The transcript says the wakeup will not fire, and you can reply to the session and ask Claude to keep it running.
• Resuming with claude --resume or claude --continue restores tasks scheduled with CronCreate, except recurring tasks that have expired and one-shot tasks whose time has passed. A self-paced /loop is not restored, so start it again.
• A restored recurring task does not fire the runs it missed while the session was not running. Its next run is the first one due after you resume, and the usual shift applies to it.
• Resuming does not restart the background Bash commands and monitors that were running when the session ended. Ask Claude to start one again if you still need it.

One storage detail matters if you keep tasks across sessions with feature-flag fetching off. Claude Code then writes them to the project's .claude/scheduled_tasks.json, and it returns an error instead of scheduling anything if that directory or file is a symlink. A saved task runs only in the project folder where you created it: copy the file into another folder, such as a new worktree, and sessions there will list the copied tasks but never run them.

A saved task can also fail to come back without telling you. Claude Code v2.1.290 fixed scheduled tasks, including /loop with an interval and reminders, silently failing to return on resume once the conversation had been compacted, and that fix covers compactions made from that version on. Earlier this month, v2.1.299 fixed scheduled tasks and loops firing again after every turn, or firing early, during the repeated hour when daylight saving time ends. If you are on an older build and a task disappears after a resume, updating is the first thing to try.

The whole scheduler can be switched off. Setting CLAUDE_CODE_DISABLE_CRON=1 in your environment disables it: the cron tools and /loop become unavailable, and any already-scheduled task stops firing, including one already running mid-session. That is a useful lever on a shared machine and a confusing one if you inherit it in a shell profile without knowing.

If you write a cron expression yourself, the accepted shape is the standard five fields: minute, hour, day of month, month, day of week. Wildcards, single values, steps, ranges and comma-separated lists all work. Day of week uses 0 or 7 for Sunday through 6 for Saturday, extended syntax such as L, W or ? is not supported, and names such as MON or JAN are not accepted. When both day of month and day of week are set, a date matches if either one matches, which is standard vixie-cron behaviour and the opposite of what most people assume.

Cloud scheduled tasks, formerly routines

A cloud scheduled task is the saved configuration described earlier: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically. It executes on Anthropic-managed infrastructure, or on your organization's self-hosted environment when it is routed there. Because it is a configuration rather than a session, it does not need anything open on your side.

Each task can carry one or more triggers, and a single task can combine them. A pull request review task, for example, can run nightly on a schedule, be fired by a deploy script, and also react to every new pull request. A task with only an API trigger runs when you call its endpoint, and a task with only a GitHub trigger runs when a matching repository event occurs, so a schedule is optional rather than required.

Cloud tasks are available on Pro, Max, Team and Enterprise plans. You create and manage them at claude.ai/code/routines, or from the CLI with /schedule. On the Team and Enterprise plans an Owner can turn them off for everyone with the Scheduled tasks (Was Routines) toggle under Organization settings > Capabilities > Remote sessions, and when that toggle is off, existing tasks stop running and nobody can create new ones.

Two facts about ownership catch people out. A task belongs to your individual claude.ai account rather than to a team, so it is not shared with teammates, and its runs count against your account's usage and limits. Anything it does through your connected GitHub identity or your connectors appears as you: commits and pull requests carry your GitHub user, and messages or tickets use your linked accounts for those services. A task created on a work account does not become a team resource.

What a fired prompt counts as is limited on purpose. When a trigger fires, the session receives the saved prompt as its assignment rather than as untrusted content that arrived mid-conversation. The trigger attests only that the prompt was stored ahead of time by an authorized session on your account, so the fired prompt is not live user input and cannot act as approval or consent for anything during the run. Content the session fetches during the run is handled normally.

That distinction matters most for the API trigger. The request body accepts an optional text field for run-specific context such as an alert body or a failing log. It does not arrive as a bare message: it is wrapped in a <routine-fire-payload> block that labels it as untrusted data and tells Claude not to follow instructions inside it unless the task's own prompt says to. Your saved prompt has to opt in explicitly, for example by telling Claude to investigate the alert described in that block, or the text is treated as inert context. Anyone holding the bearer token can send that field, so the wrapper is what keeps a leaked token from becoming a direct instruction.

To use the API trigger you open the task, add an API trigger, copy the fire URL and generate a token. The token is shown once and cannot be retrieved later, the trigger takes effect as soon as it is generated, and a request without it fails with a 401. Send the token in an Authorization: Bearer header to the /fire endpoint, which ships under the experimental-cc-routine-2026-04-01 beta header; Anthropic warns that request and response shapes, rate limits and token semantics may change while the feature is in preview.

The GitHub trigger starts a new session when a matching event happens on a connected repository, and sessions are never reused across events, so two updates to one pull request produce two independent sessions. Supported events are pull requests, releases and issues, each with its actions. Filters narrow which pull requests count, and all of them must match. One filter needs care: matches regex tests the entire field value rather than a substring, so to match any title containing hotfix you write .*hotfix.*, and without the surrounding wildcards you are matching a title that is exactly hotfix. The Claude GitHub App has to be installed on the repository whichever surface you configure the trigger from.

Permission handling is the part that decides whether a run is actually unattended. A run that starts a new session begins in auto mode unless auto mode is unavailable, and a classifier allows or blocks actions that would otherwise wait for you. A run still stops and waits in two cases: an action that matches an ask rule and therefore prompts even in auto mode, and repeated blocks, where one block does not end the run but reaching the repeated-block threshold makes a prompt appear and wait for an answer. You answer it by opening that run from the task's detail page.

None of those hourly limits has overage, which is the sentence to remember when a run does not appear. Separately from the hourly limits, scheduled runs draw down subscription usage the same way interactive sessions do. When a task reaches your usage limit, an organization with usage credits turned on can keep running on metered overage; without them, further runs are rejected until the window resets. While a subscription is paused, its scheduled tasks are put on hold entirely.

A missing or expired GitHub connection does not fail a run immediately. The task skips runs until you reconnect, for up to 72 hours, then turns itself off if you have not. In the history, a finished run's row ends with Error if it failed, Cancelled if it was cancelled, and neither word if it succeeded; the Status filter is where the same three outcomes are named Failed, Cancelled and Succeeded. Both describe how the session ended rather than whether the work got done: blocked network requests and work Claude could not complete show up in the transcript, not on the row. A one-off task turns itself off after it runs and the web interface marks it Completed.

Create a cloud task from the CLI

Run /schedule in any session to create a cloud scheduled task conversationally, or pass a description directly, for example /schedule daily PR review at 9am or /schedule clean up feature flag in one week. Claude walks through the same information the web dialog collects and then saves the task to your account. A task created this way gets a schedule trigger. A GitHub trigger can be added later from the CLI, which needs Claude Code v2.1.225 or later, or from the web; an API trigger and its token can only be added on the web.

Schedule times are the part most likely to be wrong on the first attempt, because the two surfaces read a cron expression differently. When you pick a preset frequency in the web form, you enter the time in your local timezone. When you write a cron expression as five fields with no prefix, you write the hours in UTC, so 0 9 * * 1-5 runs at 9am UTC on weekdays. If the field opens with a CRON_TZ= prefix, keep it and write the hours in its zone, or delete it and write them in UTC. Expressions that run more often than once per hour are rejected.

A run scheduled exactly on the hour can start several minutes late, and Anthropic's advice is to pick a few minutes past the hour instead, such as 9:07. That is the same idea as the shift described under when a task actually fires, applied to a different surface.

What a run can reach is set by the repositories you select, the environment's network access and variables, and the connectors you include, so scope each of those to what the task needs. Each repository is cloned at the start of a run, Claude starts from the repository's default branch unless your prompt says otherwise, and it pushes its work to a branch prefixed with claude/ unless your prompt directs it elsewhere. There is one exception worth knowing for review work: if a GitHub pull request event started the run and that pull request's repository is the task's first repository, the run starts from the pull request's head commit instead. Branch protection rules on GitHub are what limit where a run can push.

Desktop scheduled tasks on your own machine

A local scheduled task runs on your machine with direct access to your files and tools, but it fires only while the app is open and your computer is awake. The app's Scheduled tasks page lists local and cloud tasks together, so the two are easy to confuse at a glance; the switch that makes a task local is Only on this computer under Advanced settings, and clearing the repository or a GitHub or API trigger is what makes that switch available. Local tasks need Claude Desktop 1.1.5368 or later.

The schedule options are Hourly, Daily, Weekdays, Weekly, Manual and Custom, though the creation form only offers the first four: Manual and Custom appear once you open the task's Edit form. Manual runs only when you click Run now, which makes it a way to save a prompt you trigger by hand. Custom takes a cron expression evaluated in your local time, written with numbers rather than names, with Sunday as 0 and not 7, and it rejects an expression that runs more often than once per hour. Ask Claude in a Desktop session instead and it is not held to that limit, and can set a single run at a future time.

Desktop checks the schedule every minute while the app is open and starts a fresh session when a task is due, independent of any sessions you have open by hand. Each task then waits a small delay of a few minutes to stagger API traffic, and that delay is deterministic, so the same task always starts at the same offset. Nothing runs while the app is closed or the computer is asleep, and a run scheduled during sleep is skipped. Keeping the computer awake avoids the sleep case but not the closed lid, which still puts it to sleep.

Missed runs are partly recovered. When the app starts or the computer wakes, Desktop checks the last seven days and starts exactly one catch-up run for the most recently missed time, discarding anything older, so a daily task that missed six days runs once. That is worth writing into the prompt: a task scheduled for 9am might run at 11pm if the machine slept all day, so a prompt that says to review only today's commits, and to skip and summarize if it is after 5pm, behaves better than one that assumes the clock.

Each task carries its own permission mode, and allow rules from ~/.claude/settings.json apply to its sessions too. In Manual mode a run that needs a tool it does not have permission for stalls until you approve it, which defeats the point of a schedule. Anthropic's advice is to click Run now straight after creating a task, answer the prompts and choose always-allow for each one, so later runs do not stop. MCP tools marked requiresUserInteraction prompt on every call and offer no always-allow, so a task that depends on one will stall each time.

On disk, a task is a folder with a SKILL.md inside, at ~/.claude/scheduled-tasks/<task-name>/ or under CLAUDE_CONFIG_DIR if you set it. That file uses YAML frontmatter for the name and description with the prompt as the body, and edits take effect on the next run. The schedule, folder, model and enabled state are not in the file, so change those in the Edit form. Deleting a task archives the sessions it created rather than deleting them, and leaves the folder behind for you to remove.

Two options are worth knowing about. A task can modify its own schedule or prompt from inside a running session through the update_scheduled_task MCP tool, which is how a task reschedules itself when it finds something, for example moving a review earlier when a release branch appears. And a task whose folder is a Git repository can be set to run in its own Git worktree, chosen in the Edit form, so each run starts from a clean tree instead of whatever uncommitted state the folder happens to be in.

When scheduling will not start: what each message means

Most failures here are a missing requirement rather than a bug, and the message usually names which one. The CLI hides /schedule when one of its requirements is not met, so the menu shows No commands match "/schedule" while you type.

If the cause is your sign-in, you can still create and manage tasks at claude.ai/code/routines with a Pro, Max, Team or Enterprise account. If scheduled tasks or the cloud feature behind them are off for your organization, or missing from your roles, the web interface refuses too, so there is nothing to work around.

A task that exists but is not running usually says why under History, in a warning that begins "The last run". These clear once a later run starts, and each one has one fix.

None of that applies to /loop, because a loop is managed from the session rather than from a task page: you list it with CronList and stop it as the stopping section describes, which is also where to look when the key you pressed did nothing. A loop that does nothing at all is usually a skill that reached Claude as plain text.

What other people are reporting

These are open reports in Anthropic's issue tracker as we write this, not Anthropic statements, and none of them describes a fault this page can fix. They are worth reading because together they show where the edges are: the desktop app's own list of tasks, a run that stalls waiting for approval, and a schedule that never fired.

• Issue 102150, open since 2026-10-14: in the Windows Store build, the built-in Routines section of the sidebar is forced hidden on every launch and there is no toggle to show it. 37 reactions, 22 comments.
• Issue 102142, open since 2026-10-14: after the sidebar update, the Code tab's Routines section is hidden and resets to hidden on every launch. 14 reactions, 21 comments.
• Issue 101851, open since 2026-10-13: desktop scheduled tasks stall waiting for a permission approval, which defeats an unattended run. 1 reaction, 4 comments.
• Issue 100741, open since 2026-10-09: a request to show routine runs under their project folder, and to keep completed one-time routines on the Routines page. 7 reactions, no comments.
• Issue 98776, open since 2026-10-01: a request to expose session scheduled tasks, meaning /loop, CronCreate and ScheduleWakeup, to hooks. No reactions or comments yet.
• Issue 99527, open since 2026-10-04: a scheduled routine in a private project never ran. 1 reaction, 2 comments.

The first two are the same fault reported twice on the same build, one from the Windows Store version and one not, and they explain a confusion this page can settle: if the sidebar has no Routines or Scheduled entry, the feature itself is not broken, so use the task's own page or the web interface rather than hunting for a switch. The third is the desktop permission stall this page describes, reported as a bug rather than as expected behaviour. The rest are requests and one outlier, and none of them is fixed, reproduced here, or scheduled.

Where this page stops

This page owns the three scheduling features and the messages they print. Six other pages own the rest, and three of them are Anthropic's own answer for work these features are the wrong shape for.

• One unattended run rather than a timetable, whether in a script or in CI, belongs to the headless guide, which covers print mode, its flags and the bounds that stop a run.
• Reacting to events as they happen, rather than polling on an interval, is what Anthropic's channels are for: your CI can push the failure into the session instead of being asked about.
• Keeping a session working turn after turn until a condition is met is a different command, /goal, and Anthropic points at it from the scheduling page itself.
• A scheduled job inside a CI pipeline, rather than on your machine or Anthropic's cloud, is GitHub Actions, which has its own schedule trigger.
• Automation that fires on a hook or a tool call rather than on a clock is the subject of the hooks guide.
• Everything else about a session, from permissions to context, is covered by the other Claude Code guides.

Omniscio and scheduled work

Omniscio is the desktop app we make for running many Claude Code sessions at once, and it has a scheduler of its own rather than a wrapper around any of the three above. The Cron Jobs screen, headed Scheduled Tasks (Cron) in the sidebar, holds every job you have made or the app has seeded for itself. A job is one of three types: a Script that runs a shell command, a Recipe that runs one of your saved workflows, or a Session that starts a new Claude session with a prompt you wrote, optionally on a specific engine.

The switches are the interesting part for unattended work. Require Approval sends every run to your inbox as an approval before it happens, which is the opposite of the cloud feature's auto mode and the right choice for anything that spends money. Run if missed is opt-in and off by default: when it is on and the app was closed across a fire, one catch-up run happens. Self-Healing hands a job that keeps failing to a fresh session to diagnose and fix. A job can also follow another one with Run After, on success, on failure, or either way. Nothing in the app stops two jobs following each other in a loop, and the library page says so in as many words, so satisfy yourself that a chain ends somewhere.

A session job can do something the tools above cannot: instead of starting a new session or needing one held open, it can wake a session that already exists, cold-resuming that session's process first if it had ended. That is a wake schedule, and it is how an agent puts itself to sleep and comes back later without holding a turn open. The bounds are fixed rather than configurable. Cadence runs from at least 5 minutes apart to at most 24 hours. A session may hold at most 3 wake schedules at once, or 12 for an Overseer session. And a schedule ends by running out rather than by a date: it carries a maximum number of fires, 288 by default, a day's worth at the five-minute floor. A wake schedule never asks for approval, never retries, and never catches up a missed fire.

The Claude sessions the app starts are not interactive ones. Each is launched as claude -p with stream-json input and output, so the app's own scheduler is the thing that owns timing, and a job's or a wake schedule's records are what survive a restart. That is also why the app keeps its own run history: each job keeps one entry per firing for 30 days, and that window is fixed rather than tied to your data-retention setting. If you need a durable record of what a job did, have the job write one.

Fire times are close to the schedule but not exact, on purpose. Three rate controls sit between a schedule coming due and a job starting, all of them there to stop a wave of processes starting at once: a per-job offset of up to 45 seconds that is derived from the job's own id, a calm wait of up to 90 seconds while the whole machine is busy, and a four-second gap between two dispatches. On a loaded machine a start up to about two minutes late is normal behaviour rather than a fault, so compare a log timestamp against the schedule with that in mind.

What the app does not do is create or manage the cloud tasks described on this page. Those live on your claude.ai account and belong to it. The app's scheduler is local to your machine, which is also why its jobs can reach your files and its wake schedules can reach your sessions. If you want the details, the Cron Jobs page and the Session job page in the library cover the screens and every switch: Cron jobs and the Session job type.

If you are running several sessions at once, the features page lists what the app does and the download page has the installers.

Sources

Every Claude Code behaviour on this page rests on one of these pages, and each was read on the date beside it.

• Run prompts on a schedule, for /loop, its interval forms, the maintenance prompt, loop.md, stopping a loop, one-time reminders, the cron tools, jitter, the seven-day expiry, the cron reference and the limitations. Read October 27, 2026.
• Automate work with scheduled tasks, for cloud tasks, the three triggers, the API endpoint and its beta header, GitHub filters, permission behaviour, the hourly limits, usage, and the troubleshooting tables. Read October 27, 2026.
• Schedule recurring tasks in Claude Code Desktop, for local tasks, the six schedule options, missed runs, per-task permissions and the on-disk SKILL.md. Read October 27, 2026.
• Commands, for /loop, its /proactive alias, and /schedule with its /routines alias. Read October 27, 2026.
• Environment variables, for CLAUDE_CODE_DISABLE_CRON. Read October 27, 2026.
• Changelog, for the v2.1.290 resume fix and the v2.1.299 daylight-saving fix. Read October 27, 2026.
• Keep Claude working toward a goal and Push events into a running session with channels, the two pages Anthropic sends a reader to from its scheduling page. Read October 27, 2026.
• Claude Code GitHub Actions, for a schedule trigger in CI. Read October 27, 2026.
• The six issue pages linked above, each read on October 27, 2026, with its state, reaction count and comment count taken from the issue itself.
• Omniscio's own library pages, Cron jobs and Cron job — Session spawn type, for every screen, switch and bound in the Omniscio section. Read October 27, 2026.

Scheduling changes with releases. Anthropic's changelog carries dozens of entries for loops, scheduled tasks and routines, several of them fixes to behaviour described here, and the cloud feature is still in research preview. If a release note mentions any of the three, re-read the page above before trusting a copy of this one from last month.

Common questions

What is the difference between /loop and a scheduled task?

/loop is the in-session one: it re-runs a prompt while the session stays open, and it stops when Claude Code stops. The other two are durable. A cloud scheduled task runs on Anthropic's infrastructure on a schedule, an API call or a GitHub event, and a desktop scheduled task runs on your machine while the app is open. All three are documented, and the cloud kind is the one Anthropic calls a scheduled task in its own heading, having renamed it from routines.

Are routines the same thing as scheduled tasks?

Yes. Anthropic renamed routines to scheduled tasks, and keeps the old name in the web address claude.ai/code/routines, the /routines alias for /schedule, the /fire endpoint and the routine-fire-payload tag, and the organization toggle labelled Scheduled tasks (Was Routines). Anything you read about routines describes the same feature.

Why does /schedule say unknown command?

It needs a claude.ai subscription login. A Console API key, an Anthropic profile or federation credential, or a cloud provider sign-in all outrank it, and so do ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN and an apiKeyHelper setting. It is also hidden inside Anthropic's cloud and when an Owner turns scheduled tasks off for the organization. Manage tasks at claude.ai/code/routines if the CLI will not offer the command.

How long does a /loop task last?

Seven days. A recurring task created with /loop or the cron tools fires one final time seven days after creation and then deletes itself, so a forgotten loop cannot run forever. If a schedule needs to outlast that, use a cloud scheduled task or a desktop scheduled task, both of which are durable.