Leave Claude Code on Watch with Routines — Scheduled, API, and GitHub Triggers in the Cloud

There are three ways to put Claude Code on a schedule, and only one of them keeps working with your laptop shut. That single difference decides most of what you can sensibly hand over.

This article is about routines: saved Claude Code configurations that run on Anthropic-managed cloud infrastructure, triggered by a schedule, an HTTP call, or a GitHub event. It covers what they can and cannot reach, the trap this site walked into on the first try, and what a real weekly routine produced when it ran.

Only the cloud option can hold the fort

Read that table as a set of trade-offs rather than a ranking. The cloud routine is the only row that survives a closed laptop, and it pays for that by losing access to your local files and by running with nobody there to approve anything.

What a routine is

A routine packages a prompt, one or more GitHub repositories, an environment, and a set of connectors. Each run clones the selected repositories from their default branch and starts a full Claude Code cloud session. Claude pushes its work to branches prefixed with claude/, which are always accepted; pushing anywhere else is checked first and rejected if the branch is protected, carries someone else’s open pull request, or holds commits authored by someone other than you.

Routines are available on Pro, Max, Team, and Enterprise plans. You create them at claude.ai/code/routines, from the Desktop app, or with /schedule in the CLI. They belong to your individual account rather than your team, and anything a routine does through your GitHub identity or your connectors appears as you.

Three kinds of trigger

• Schedule. Hourly, daily, weekdays, or weekly from the preset picker, or a custom cron expression set with /schedule update in the CLI. A one-off run at a specific future timestamp is also a schedule trigger; it auto-disables after firing.
• API. A per-routine HTTPS endpoint. POST to it with the routine’s bearer token and a new session starts, returning a session URL. The optional text field carries run-specific context such as an alert body.
• GitHub. Pull request and release events, with filters on author, title, body, base and head branch, labels, draft state, and merged state.

A single routine can carry any combination. A pull request reviewer can run nightly, fire from a deploy script, and react to every new PR.

One hour minimum, and a few minutes of drift

The minimum interval is one hour; expressions that fire more often are rejected. Times are entered in your local zone and converted, so a routine runs at the same wall-clock time regardless of where the infrastructure sits.

Runs may start a few minutes after the scheduled time because of stagger, and the offset is consistent for each routine. Write prompts that do not assume an exact minute. One-off runs do not count against the daily routine run cap, though they draw on your subscription usage like any other session.

No approvals, by design

Routines run autonomously as full cloud sessions. There is no permission-mode picker and no approval prompts during a run. The session can run shell commands, use skills committed to the cloned repository, and call any connector you included, including write operations, without asking.

That is not a gap to work around; it is the premise. What a routine can reach is fixed by three things you set up front: the repositories you select, the environment’s network access and variables, and the connectors you include. Scope each of them to what the routine actually needs, because during the run nothing else will.

Everything connects by default, and what that cost us

When you create a routine, every connector on your account is included automatically. This site created its first routine from the web form and did not notice. The routine was a read-only repository check that needed no external service at all, yet it started life able to write to every connected tool on the account.

Removing them afterwards takes one pass through the edit form. Doing it at creation takes ten seconds. The habit worth forming is to treat the connector list as a deny-by-default field: clear it, then add back only what the prompt names.

The routine this site actually built

The prompt has to be self-contained. A routine fires into a fresh session with no memory of the conversation where you set it up, so anything you would normally clarify in a follow-up has to be written down in advance: what to check, what counts as a pass, and what to do with the result.

What the run produced

The pre-deploy gate did exactly what it was meant to. The source-link check did not, and the failure is instructive: 27 of those failures were not broken links. They were the Trusted network policy refusing to let the session reach the hosts being checked.

The Default environment uses Trusted network access, which allows only a default allowlist of package registries, cloud provider APIs, container registries, and common development domains. Requests to anything else fail with a 403 and an x-deny-reason of host_not_allowed. A link checker is, by definition, a tool that wants to reach arbitrary hosts.

There are two honest fixes. Change the environment’s network access to Custom and list the domains, which means maintaining a list that grows with every new source you cite. Or accept that link checking belongs on a surface with unrestricted egress and run it locally. This site chose the second and left the routine doing only the checks that need nothing but the repository.

Green means it did not crash

A green status in the run list means the session started and exited without an infrastructure error. It does not mean the task in your prompt succeeded. Blocked network requests, missing connector tools, and task-level failures all sit inside the transcript rather than in the status indicator.

Our 27 link failures came back under a green run. If you only read the status column, the routine looks like it has been quietly working for weeks. Open the run and read what Claude actually did, at least until you trust the prompt.

The CLI helps here: ask /schedule why did my nightly review do nothing this morning and Claude lists recent runs with their status and reads a run log to explain tool errors, permission denials, and the final result. That requires Claude Code v2.1.227 or later.

Usage and caps

Routines draw on subscription usage the same way interactive sessions do, and there is an additional daily cap on how many runs can start per account. You can see remaining daily runs at claude.ai/code/routines or claude.ai/settings/usage.

When a routine hits the daily cap or your subscription limit, accounts with usage credits turned on keep running on metered overage; without them, further runs are rejected until the window resets. That is worth deciding deliberately rather than discovering it in a bill.

What to leave on watch at the 3D printing bench

The rule that falls out of all this is simple: a routine suits work whose inputs are already in the repository and whose output is a report or a branch.

• Checking that every new model file in the repository has a matching print-settings note, and opening a branch that adds the missing ones
• Recomputing a quoting table when the filament price file changes, and reporting the rows whose margin fell below the threshold
• Summarizing what changed in the slicer profile directory over the past week
• Reacting to a merged pull request by regenerating the derived documentation for the parts it touched

What does not suit a routine: anything that needs a file sitting on your desk rather than in git, anything that reaches arbitrary external hosts on the Default environment, and anything whose last step is irreversible. There is nobody there to say no.

The short version

• Routines are the only one of the three scheduling options that runs with your machine off, and they pay for it with no local files and no approvals
• Schedule, API, and GitHub triggers can be combined on one routine; the minimum schedule interval is one hour, with a few minutes of consistent stagger
• Every connector on your account is included by default at creation. Clear the list and add back only what the prompt names
• The Default environment’s Trusted network access blocks arbitrary hosts, which quietly broke our link checker; egress-hungry checks belong on a local surface
• A green run means the session exited cleanly, not that your task succeeded. Read the transcript
• Write the prompt as a self-contained brief, because the run starts with no memory of the conversation that created it

Sources

• Claude Code, Automate work with routines
• Claude Code, Schedule recurring tasks in Claude Code Desktop
• Claude Code, Run prompts on a schedule

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.