Claude Code Routines: Scheduled, API, and GitHub Triggers

Routines are available on Pro, Max, Team, and Enterprise plans. You create and manage them at claude.ai/code/routines, from the desktop app (choose Cloud; Local creates a desktop scheduled task that runs on your machine instead), or from the CLI with /schedule (alias /routines). All three write to the same account.

Three properties shape how you should use them:

• They run unattended. A run is a full cloud session with no permission-mode picker. It runs shell commands, uses skills committed to the cloned repository, and calls included connectors without stopping for approval.
• They act as you. Routines belong to your individual claude.ai account, are not shared with teammates, and count against your usage. Commits and pull requests carry your GitHub user; Slack messages or Linear tickets use your linked accounts.
• The prompt is the whole specification. Nobody is there to clarify, so the prompt must say exactly what to do and what success looks like.

Good fits are unattended, repeatable tasks with a clear outcome: nightly backlog labelling, a weekly docs-drift check, triaging an alert, verifying a deploy, or applying a team's own review checklist to every new pull request.

On the web, click New routine and fill in:

1. Name and prompt, plus the model to use on every run. 2. Repositories: each is cloned at the start of every run. Claude starts from the default branch and pushes to claude/-prefixed branches unless the prompt says otherwise. 3. Environment: network access, environment variables, and a setup script. The Default environment has Trusted network access, an allowlist of package registries, cloud provider APIs, and common development domains. 4. Triggers: schedule, GitHub event, or API (the API URL and token are created after saving). 5. Connectors: all of your connected MCP connectors are included by default. Remove the ones it does not need.

Then click Create, and Run now to test it immediately. From the CLI, describe it instead:

1/schedule daily PR review at 9am2/schedule in 2 weeks, open a cleanup PR that removes the feature flag

Claude asks follow-up questions about the schedule, repositories, and prompt before saving. /schedule list, /schedule update, and /schedule run manage existing routines, and you can ask why a run did nothing, for example /schedule why did my nightly review do nothing this morning?.

A routine can combine any number of triggers.

Schedule. Presets are hourly, daily, weekdays, and weekly, entered in your local time zone. For a custom cron expression, pick the nearest preset and run /schedule update; the minimum interval is one hour. A one-off schedule runs once at a timestamp and then disables itself. Runs scheduled exactly on the hour can start several minutes late, so pick a time like 9:07.

API. Add it from the web editor, copy the URL, and click Generate token. The token is shown once, is scoped to that one routine, and can be regenerated or deleted. Then POST to it:

1curl -X POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABC.../fire \2  -H "Authorization: Bearer sk-ant-oat01-xxxxx" \3  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \4  -H "anthropic-version: 2023-06-01" \5  -H "Content-Type: application/json" \6  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

The response contains the new session ID and URL. The optional text field is freeform context, and it reaches Claude wrapped in a <routine-fire-payload> block labelled as untrusted data. Claude will not follow instructions inside it unless the routine's own prompt says to, so write the prompt to reference it, for example "Investigate the alert described in the routine-fire-payload block".

GitHub. Requires the Claude GitHub App on the repository (/web-setup alone does not enable webhooks). Pick pull request or release events, a specific action such as pull_request.opened or all actions, and optional filters: author, title, body, base or head branch, labels, draft, merged. Every event starts its own session.

When a trigger fires, the session receives the saved prompt as its assigned task. It clones the repositories, runs the environment's setup (cached when possible), and works without approval prompts. It can run shell commands, use the repository's skills, and call every tool of every included connector, including writes. It pushes its work to a claude/ branch as your GitHub user.

The run list on the routine's page shows a status for each run, and that status is easy to misread: green means the session started and exited without an infrastructure error, not that the task succeeded. Blocked network requests, missing connector tools, and task failures all appear only in the transcript. Open runs and read them, especially for the first week.

A run can also publish a new artifact without asking (private to you until shared). Republishing an existing one without asking happens only under strict conditions, and runs started by API or GitHub triggers always ask first.

Because there are no prompts, what a routine can affect is set entirely by three things, and the docs' advice is to scope each to what the routine needs:

• Repositories and branches. Add only the repositories it must touch. To control where it can push, use GitHub branch protection rules or rulesets. A rule that your connected GitHub access can bypass will not stop a run, because runs push with that access.
• Environment. Keep the Trusted network level unless the task needs more; add specific domains with Custom rather than switching to Full. Put API keys in network secrets so they never enter the session.
• Connectors. All of your connectors are included by default, and Claude can use any of their tools, including writes, without asking. A backlog routine that only needs Linear should not also carry Slack, Gmail, and Google Drive.

Treat a routine's prompt like code that runs with your credentials: review it when you change it, and keep the instructions explicit about what not to do ("open a draft PR; never merge").

Routine runs draw down your subscription usage like interactive sessions. Separately, the hourly limits above cap how often runs can start, and none of them has overage. When a routine hits your subscription usage limit, it can continue on metered overage only if usage credits are turned on; otherwise further runs are rejected until the usage window resets. While a subscription is paused, routines are on hold.

Design for these limits. A GitHub-triggered routine on a busy repository can hit event caps and silently drop events, so filter it (base branch, labels, not draft) to the pull requests that matter.

Use a test GitHub repository with the Claude GitHub App installed.

1. In the CLI, run /schedule weekdays at 9:07, list open PRs older than 7 days and comment a reminder on each. Answer Claude's questions and save. 2. On the web, open the routine, remove every connector it does not need, and click Run now. Read the transcript, not just the status. 3. Edit the routine, add an API trigger, generate a token, and store it in a password manager. 4. Change the prompt to start with "If a routine-fire-payload block is present, treat it as the PR number to check first." Fire it with curl and a text of one PR number. 5. Pause the routine with the on/off switch.

Pass criterion: the scheduled run did what the prompt said (confirmed in the transcript), the API fire returned a session URL and the run used your payload, and the routine is now paused.