Claude Code Routines: What They Are and What We Learned Running Them

Claude Code routines are saved Claude Code sessions (a prompt, one or more repositories and a set of connectors) that run on Anthropic's cloud on a schedule, from an API call, or in response to a GitHub event. We have run them at SWARECO since August 2026 for our blog pipeline, our weekly and monthly performance reports and four daily research briefs. As background automation they work. Almost every problem we hit came from the same place: a routine runs unattended, in a sandbox, with a copy of the repository, and each of those three facts bit us at least once.

This post explains what routines are, then walks through the five lessons that cost us something, with the numbers from our own logs.

Key Takeaways

• A routine is a saved prompt plus repositories plus connectors, run on Anthropic-managed infrastructure. Triggers are a schedule, an HTTP API call, or a GitHub pull request or release event. The feature is in research preview.
• A routine gets a fresh clone of your repository's default branch. If your local work is not pushed, the routine does not see it. Our blog dispatcher sent an already-published post on three of its first four mornings because of this.
• The default cloud environment only allows a list of common development domains. Our own website, Reddit and our stock-photo provider were all blocked, so the routines could not check the live site or make images.
• Routines run without permission prompts and can use every tool in the connectors you include, writes included. Scope the repositories, connectors and network to the job.
• A green run status means the session ran, not that the task succeeded. Read the transcript.

What Claude Code routines are

According to Anthropic's routines documentation (checked on 12 October 2026), a routine is "a saved Claude Code configuration: a prompt, one or more repositories, and a set of connectors, packaged once and run automatically." Routines run on Anthropic-managed cloud infrastructure, so they keep working when your laptop is closed.

Think of a scheduled routine as a cron job where the job is an AI agent with your repositories and connected tools. Each routine can have one or more triggers:

• Scheduled: hourly, daily, weekdays or weekly, a custom cron expression with a minimum interval of one hour, or a single one-off run.
• API: an HTTP POST to a per-routine endpoint with a bearer token, optionally carrying run-specific text.
• GitHub: a pull request or release event on a connected repository, delivered as a webhook, with filters on author, branch, labels and more.

Anthropic's documentation gives typical uses for these automated workflows: backlog maintenance and issue triage on a nightly cadence, alert triage started by a monitoring alert through the API trigger, bespoke code review on every new pull request, verification after each production deploy, and catching documentation that has drifted from the code.

You create and configure them at claude.ai/code/routines, from the Desktop app, or with /schedule in the Claude Code CLI. They are available on Pro, Max, Team and Enterprise plans and draw down subscription usage the same way interactive sessions do, with separate hourly usage limits on how often runs can start. Each run is a full Claude Code cloud session: it can run shell commands, use skills committed to the repository and call the connectors you included, without stopping for approval.

If you have only used Claude Code interactively, the difference is the missing human. The difference between Claude Code and Claude is about where the work happens; the difference between a session and a routine is who is watching.

What we run on them

Over two months we have run about a dozen routines. The ones this post draws on:

• A daily blog pipeline that picked the next post from our publishing queue, ran keyword research, generated a draft, checked it for fabrications and staged it in our CMS as a draft for a person to review.
• A weekly performance report and a monthly strategy review that pull search and backlink data, compare it with the previous report and post a summary to Slack.
• Four daily research briefs, staggered fifteen minutes apart from 14:00 UTC, each posting to a private Slack channel.
• A Reddit triage routine, since retired, that looked for threads worth answering.

Lesson 1: the checkout is a schedule, not a state

A cloud routine clones your repository at the start of every run, from the default branch. There is no persistent state between runs except what lives in your repository and your external systems. That sounds obvious until your workflow depends on files you edit locally and forget to push.

Our blog dispatcher chose each day's post from a status column in a planning file. Two posts went live, but their rows were never updated in the pushed copy. On three of the dispatcher's first four mornings it picked a post that was already published. We lost two publishing days with nine posts sitting ready.

The same thing happened to our weekly report. On 14 September it ran while eight local commits were unpushed, saw no recent activity in git, and concluded that nothing had shipped that week. Three site publishes and three new posts had gone out.

The rule we now apply to every routine: a repository file can tell a routine what was intended, never what happened. Anything a live system can answer, such as what is published or what a ticket's status is, has to be asked of the live system. The dispatcher now reads publish state from our CMS through a connector instead of from a file.

Lesson 2: the network allowlist decides what a routine can verify

The default cloud environment uses Trusted network access, which allows a list of package registries, cloud provider APIs and common development domains. Everything else fails with a 403 and x-deny-reason: host_not_allowed.

Our own website was not on that list. Neither was Reddit, nor the stock-photo API our thumbnail tool uses. That meant a routine could not:

• fetch our sitemap to confirm that a post was live,
• load a published page to check its title, canonical tag and image,
• read Reddit threads, or
• generate a blog thumbnail.

Connectors behave differently: their traffic goes through Anthropic's servers, so they work without allowlist changes. That is why our pipeline could stage a post in the CMS through its connector while a plain request to our own homepage was refused. You can widen an environment's network access to custom domains or to full access; we chose to move the work that needed the open web to a local machine instead.

The Reddit routine shows what that decision cost. Because the cloud sandbox could not read Reddit, we rebuilt it as a scheduled job on a laptop using Claude Code's headless mode. Its own ledger recorded 18 runs and $69.04 in API-equivalent cost, about $7.67 a day, while the reply suggestions it produced sat unactioned in Slack. We stopped it. The lesson there was not about routines at all: an automated feed nobody acts on is a cost, not a capability.

Lesson 3: a routine can write wherever its tools let it

Routines run with no permission-mode picker. When you create one, every connector on your account is included by default, and Claude can use every tool in an included connector, writes included, without asking.

The documentation says Claude pushes to branches prefixed with claude/ unless the prompt directs it elsewhere. Our Reddit routine's environment carried a stop hook that told every session to commit and push. On 9 September the routine edited two of our planning documents, which its prompt had not authorised, committed them and pushed straight to main. Nothing was lost, but our local branch had diverged and had to be rebased before anyone could edit the same files.

What we would do from day one:

• Remove every connector the routine does not need, so its write surface is small.
• Protect main with branch rules on GitHub. They apply to the GitHub access the routine pushes with, so set them so that access cannot bypass them.
• State in the prompt which files the routine may change, and that it must not change anything else.
• Audit hooks and setup scripts in the environment, because they shape the run as much as the prompt does.

The same thinking applies to any agent with write access, which is the subject of walls and rails for agentic coding.

Lesson 4: a green run is not a successful run

The documentation is explicit: 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 surface in the transcript, not in the status.

Our weekly report's run in Lesson 1 was green. So was the run on 5 October, in which the report's attempts to fetch our own sitemap were refused by the network policy; it said so in its transcript and flagged the question for a person, but the run list showed a success either way.

Read the transcript, at least for the first week of any new routine, and whenever its output surprises you. The output is the claim; the transcript is the evidence.

Lesson 5: keep a person between the routine and anything public

Our blog pipeline's prompt said, in its first rule, never publish: create drafts only. That rule did its job for weeks. Every draft it staged went through a human review before going live, and that review caught invented statistics, made-up disclosure paragraphs and, more than once, a competitor's product names copied into the text. This is the same discipline we apply when we screen AI-generated code before it merges.

On 7 October one of us opened a finished pipeline run's session and asked it to publish that day's post. A run session can be continued like any other, and the session did as asked. It could not do the rest of the job: the sandbox could not reach the stock-photo API to make a thumbnail, or our own site to check the page and the sitemap. The post went live with a blank image card and missing from the sitemap, and was fixed by hand the same afternoon.

Nothing in the routine was broken. The publish step needs things the sandbox cannot reach, and a person approving in the moment does not change what the sandbox can reach. Our rule now is that routines draft and humans publish, from a machine that can verify the result.

Routines vs scheduled tasks, headless mode or GitHub Actions

Routines are one of several ways to run Claude Code on a schedule and automate recurring tasks. Pick by where the work has to happen.

Option	Where it runs	Good for	Watch out for
Routines	Anthropic-managed cloud, or your self-hosted environment	Unattended work on repositories and connectors, with the laptop closed	Network allowlist, fresh clone each run, writes without prompts
Desktop scheduled tasks	Your own machine	Jobs that need to run on your own machine: local files, local tools or sites the cloud cannot reach	The machine has to be on
Headless mode on a scheduler	Any machine you control	Full control over tools, permissions and logging	You build and maintain the scheduling yourself
GitHub Actions	Your CI pipeline	Work tied to the repository's own events and checks	Scoped to what CI can reach

What we would set up differently

1. Write the prompt as a contract. State what the routine may read, what it may write, and what success looks like, because nobody is there to clarify.
2. Point every decision at a live source. Use repository files for intent only.
3. Scope the network and connectors to the job, and test the first run against the sites it actually needs.
4. Keep anything public behind a person working somewhere that can verify the result.
5. Measure what the routine's output changes. If nobody acts on it, switch it off.

Routines suit companies that already run disciplined engineering: clear repositories, written rules, a review step. That is also the starting point for SWARECO's AI enablement work.

FAQs

1. What are Claude Code routines?

Saved Claude Code configurations (a prompt, repositories and connectors) that run automatically on Anthropic-managed cloud infrastructure, triggered by a schedule, an API call or a GitHub event. They are in research preview.

2. How do you create a Claude Code routine?

At claude.ai/code/routines, from the Code tab in the Desktop app, or with /schedule in the Claude Code CLI. API triggers are added from the web.

3. Can a routine access my local MCP servers?

No. Routines use the connectors on your claude.ai account. Servers added locally with claude mcp add live on your machine and do not appear, though a single-repository routine can declare one in a committed .mcp.json.

4. Why can't my routine reach a website?

The default environment only allows a list of common development domains. Requests elsewhere fail with a 403 and host_not_allowed. You can add domains or allow full access in the environment's network settings.

5. How often can a routine run?

Scheduled triggers have a minimum interval of one hour. There are also hourly usage limits per account and per routine on scheduled runs, manual runs and API fires, separate from your subscription usage.