Claude Code routines: real-world automation while you sleep

Home » Python » Claude Code routines: real-world automation while you sleep

Close your laptop, head to bed, and let Claude Code keep working while you sleep for DevOps automation. At two in the morning, it can open your repo, pull in the top-priority bug from Linear, craft a patch, push it to a fresh branch and open a draft pull request. When you sit down with your first coffee, the fix is already waiting for review instead of living in somebody’s TODO list.

That’s the core idea behind Claude Code routines: turning Claude from a reactive coding assistant into a proactive background worker that runs in Anthropic’s cloud. You define what it should do once (prompt, repos, connectors and triggers), and from then on it quietly handles repetitive, clearly defined dev tasks on a schedule, on demand via API, or whenever GitHub fires a specific event.

What exactly are Claude Code routines?

A “routine” in Claude Code is a saved automation that bundles three things: a prompt describing the job, one or more Git repositories, and a set of connected tools (connectors/MCP servers). On top of that, you wire one or more triggers so that the same configuration can fire in different ways: at fixed times, via HTTP, or off GitHub events.

The crucial detail is where routines run: entirely in Anthropic-managed cloud infrastructure. There’s no need for a running laptop, a long-lived terminal session, or your own server. Each time a routine is triggered, Claude spins up a full Claude Code session in the cloud, with access to the repos, environment and connectors you’ve allowed.

Every run behaves like a normal Claude Code session, but unattended, reflecting patterns for building AI agent teams. The agent can execute shell commands, use any committed skills or CLAUDE.md configuration in your repo, call external services through MCP connectors, and push branches back to GitHub. There is no “approval” prompt in the middle of a run – once started, the agent follows the instructions in your prompt from start to finish.

Ownership and identity also matter here: routines belong to your individual claude.ai account, are not shared with teammates, and count against your daily routine run allowance. Anything they do via your GitHub identity or connected services shows up as you – commits, pull requests, Slack messages, Linear issues and so on all carry your user.

How routines compare to cron jobs, GitHub Actions and local automation

On paper, routines sound a bit like “cron jobs with AI sauce” or smarter GitHub Actions, and that’s exactly how a lot of developers first described them. But there are important differences in how they decide what to do and where they run.

A classic cron job is dumb but predictable: you point it at a script on your own machine or server, it runs at set times, and that’s it. If the script hits an unexpected state, it simply fails or silently misbehaves. There’s no reasoning, no context, no adaptation – just “run this file at this time.”

GitHub Actions are more sophisticated but still rigid. They’re great at reacting to repo events like pushes or PRs and following a fixed YAML workflow: build, test, lint, deploy. However, even complex workflows can’t improvise when reality diverges from what you encoded; the steps either pass or fail according to the script.

Claude Code routines land in between those worlds: you still have automatic triggers and repeatable execution, but instead of a static script, you get a full Claude Code agent session behind the scenes. The routine reads your prompt plus fresh context (repo state, connectors, trigger payload) and decides how to get to the desired outcome at run time.

This makes routines ideal for repetitive work that nonetheless requires interpretation, similar to AIOps practices – tasks like triaging alerts, tailoring code review to your internal checklist, or updating docs when APIs change. You could script all that in bash and YAML, but you’d end up rebuilding half an AI agent by hand.

Supported triggers: schedule, API and GitHub events

Routines come to life through triggers. Each routine can have one or more triggers attached, and any trigger that fires will start a new session using the same prompt, repos and connectors. That means you can, for example, run nightly triage jobs and also kick off the exact same logic via API when monitoring fires an alert.

The scheduled trigger is the simplest to grasp. From the web UI you can pick hourly, daily, weekdays or weekly presets, with times expressed in your local timezone and transparently converted under the hood. There’s intentional staggering, so a run might start a few minutes after the wall-clock time, but that offset stays consistent for that routine.

For custom cadences, the CLI adds more power. You can run /schedule in any Claude Code CLI session to create a scheduled routine in a conversational way, or pass a plain-language description like /schedule daily PR review at 9am. Then, using /schedule update, you can set an explicit cron expression – with one hard limit: minimum interval is one hour, anything more frequent gets rejected.

There’s also one-shot scheduling for tasks that need to happen later, but only once: a cleanup PR after a deployment window, a follow-up job after an upstream change lands, or a reminder to refactor some code a week from now. These runs fire a single time, then the schedule automatically deactivates and the UI marks it as “Ran.” Interestingly, one-off runs don’t count against your daily routine run cap, though they still draw on your normal subscription usage.

The API trigger turns a routine into an HTTP endpoint. Once you add an API trigger from the web UI, Claude generates a URL and a bearer token unique to that routine. Sending an authenticated POST to the /fire endpoint spins up a fresh session and returns a JSON payload containing the new session ID and a direct URL to watch or continue that run in the browser.

The request body can include a free-form text field that becomes extra execution context: for example, you might send the raw JSON payload of a monitoring alert, a failing log excerpt, or a short description of what needs to be investigated. Routines don’t automatically parse structured payloads – Claude receives them as literal strings and interprets them according to your prompt instructions.

The API surface is explicitly in research preview, guarded by a beta header like anthropic-beta: experimental-cc-routine-2026-04-01. Anthropic reserves the right to evolve this during the preview, while maintaining compatibility with a couple of earlier versions to give teams time to adjust. It’s available only for claude.ai users; it’s not part of the general Claude Platform API surface.

GitHub triggers are where things get really interesting for active codebases. Once you install the Claude GitHub app and connect the relevant repos, you can configure a routine to react to GitHub events: pull requests being opened, updated, closed or labeled; releases being created, published, edited or deleted; and other categories exposed by the app. Each matching event creates its own session – there is no session reuse between events for GitHub-triggered routines.

Filters let you be extremely selective about what actually fires a run. For PR events you can constrain by author, title, body, base branch, head branch, labels and various boolean states (draft vs. ready, merged vs. open, from fork or not). Each filter pairs a field with an operator such as equals, contains, starts with, is any of, is none of, or matches regex. All filters are ANDed together, so they must all match for the routine to start.

Practical use cases where routines shine

The official docs ship with a series of sample use cases that hit the sweet spot for routines: unattended, repeatable work with a clear definition of success. Beyond those, early adopters and industry analysts have already mapped out additional patterns that slot naturally into modern DevOps pipelines.

Nightly backlog grooming is a straightforward win. With a scheduled trigger set to run on weeknights, your routine can use a connector (Linear, Jira, etc.) to pull issues created since the last run, infer the relevant code areas, apply or tweak labels accordingly, assign the right owners, and then post a tidy summary into your team’s Slack channel. The next morning, the backlog is already sorted instead of being a mess of untriaged tickets.

Alert triage via the API trigger is another high‑impact pattern. Your monitoring or error tracking tool calls the routine endpoint whenever a threshold is exceeded, sending the alert payload as text. The routine parses the stack trace, correlates it with recent commits in the attached repo, drafts a PR with a proposed fix and a backlink to the alert, and tags the on‑call engineer. Rather than starting from a blank terminal, on‑call staff review and adjust a first draft solution.

Customizable code review with GitHub triggers is already popular inside Anthropic. A routine subscribed to pull_request.opened can enforce your team’s internal review checklist: run tests, scan for security pitfalls in specific directories, enforce style rules and performance guidelines, then leave inline comments and an overall summary. Human reviewers can then focus on architectural decisions instead of mechanical nits.

Deployment verification fits perfectly with API-triggered routines. After each production deploy, your CD pipeline can POST to the routine with deployment context. The routine executes smoke tests against the new build, combs error logs for fresh regressions, and posts a clear yes/no verdict in your release channel before the deployment window closes.

Docs drift and SDK porting are two more tedious jobs that routines can offload. A weekly schedule can scan merged PRs since the previous run, identify doc references to APIs that changed, and open PRs in your docs repo with suggested updates for a human editor to refine. Another routine can fire on PRs merged into an SDK repo and translate the change into an equivalent patch for a sibling SDK in another language, opening the matching PR automatically.

Creating and managing routines from web, desktop and CLI

You can create routines from the web app, the desktop app or the CLI, and all three write to the same cloud account. A routine created from your terminal shows up immediately in claude.ai/code/routines, and vice versa.

The web UI offers the most complete configuration surface to help speed up software development. From claude.ai/code/routines you hit “New routine,” choose a name, and define the prompt that will guide the agent. This prompt is crucial, because routines run unsupervised – unlike an interactive session, there’s no chance for you to jump in and say “actually, don’t do that.” It has to be explicit about scope, success criteria and what to do when things go wrong.

After the prompt, you select the repositories to attach. Each one will be cloned fresh at the start of every run, typically from the repo’s default branch unless your prompt directs otherwise. By default, Claude can only push to branches prefixed with claude/, which is a deliberate safety measure to keep routines from accidentally modifying long‑lived or protected branches. You can override this per repo by enabling “Allow unrestricted branch pushes,” but that should be a conscious decision with proper reviews in place.

Next comes the environment configuration. Every routine runs in a cloud environment that defines network access policy, environment variables and any setup scripts required to make your project runnable (installing dependencies, seeding databases, etc.). The default environment uses “Trusted” network access, which whitelists common package registries, major cloud provider APIs, container registries and typical dev domains, while blocking arbitrary hosts with a 403 and x-deny-reason: host_not_allowed. If your routine needs to talk to additional domains, you must add them to the allowlist or rely on MCP connectors (which tunnel via Anthropic’s servers and don’t require separate host whitelisting).

Connectors are the bridge out to external systems

Routines can use any MCP connectors associated with your claude.ai account, such as Slack, Linear, Google Drive or other services, which helps in controlling API sprawl. When you first create a routine, all currently connected MCP servers are included by default, but the recommended practice is to remove anything unnecessary so the agent only sees the tools it truly needs. Locally added CLI MCP servers (via something like claude mcp add) live only on your machine and won’t show up as connectors unless you also declare them in .mcp.json in a cloned repo or wire them up through claude.ai/customize/connectors.

Trigger configuration happens in the “Select a trigger” section of the routine editor. Here you can add, edit or remove scheduled triggers, API tokens and GitHub event triggers. For API, the token-generation modal lets you create, regenerate or revoke the bearer token. For GitHub, the form guides you through selecting repos, event categories and any filtering logic.

Once created, routines are controlled from their detail page. Clicking a routine opens its overview: repos, environment, connectors, prompt, schedule, API tokens, GitHub triggers and a chronological list of past runs. From there you can trigger “Run now” without waiting for the next schedule, pause or resume schedules with a simple toggle, rename or edit configuration, or delete the routine entirely. Deleting a routine doesn’t remove past sessions – those remain in your session list for auditing and review.

Repos, permissions, environments and network access

Routine execution depends heavily on GitHub access and repo cloning. If you create a routine from the CLI using /schedule, Claude checks whether your claude.ai account is connected to GitHub and prompts you to run /web-setup if not. That flow handles authentication so that routines can clone repos and act as your GitHub identity when pushing branches or opening PRs.

Branch protection is built in by default. As mentioned, Claude will only push to branches starting with claude/ unless you explicitly allow unrestricted pushes for a given repo. This is meant to prevent those “3am automation gone wild” incidents where some mis-specified prompt pushes straight to main. Teams that want more control typically keep that safety net in place and enforce code review and CI checks on claude/* branches like any other contribution.

Environments also control how much of the internet a routine can see, a concern tied to fault tolerance strategies. The default Trusted mode focuses on dev‑friendly domains: package registries, cloud APIs and similar. Outbound calls to other hosts fail fast with a clear deny reason. Since MCP connectors tunnel via Anthropic infrastructure, they don’t require additional domain entries – but if you remove a connector from the routine’s config, the agent will not be able to hit that external system during the run.

Environment variables matter for secrets. API keys, tokens and configuration details that routines need must be stored in the environment rather than baked into prompts or code. This keeps sensitive data centralized and easier to rotate. Because each routine inherits its environment on every run, a single variable change can propagate to all upcoming runs automatically.

Usage limits, billing and organizational controls

From a billing perspective, routines consume your subscription like interactive sessions do. Each run uses tokens and compute against your plan limits, and on top of that, Anthropic enforces a daily cap on the number of routine runs per account. Your current usage and remaining daily routine runs are visible in claude.ai/code/routines or your general usage page.

Organizations on Team or Enterprise plans can optionally enable “additional usage”. With that turned on, routines can keep running past the daily cap on a metered, over‑usage basis. If additional usage is disabled and you hit the daily run limit or your subscription quota, further routine runs will be rejected until the window resets. One-off scheduled runs are a special case: they don’t count toward the daily routine-run cap, but still draw from your normal plan usage.

Admin-level control over routines is quite strict. Team and Enterprise admins can globally disable routines for all members via a toggle in claude.ai/admin-settings/claude-code. When that switch is off, existing routines stop running and users are blocked from creating new ones. Since it’s an organization-level server-side setting, individual users can’t override it in local or personal configs.

From a governance and audit perspective, remember that routines act as you. If a routine opens a PR at 2am, the author is your GitHub account. That’s powerful but also something security and compliance teams care about. Clear prompts, tight scopes and robust review policies around claude/* branches go a long way toward keeping things safe.

Debugging and troubleshooting are handled through the same session view you know from interactive Claude Code. If something fails – whether due to environment issues, network denials, bad prompts or upstream changes – the failed run is still a normal Claude Code session. You can open it, inspect the command history, see diffs, and even keep chatting with the agent to finish the job manually or refine future prompts.

Looking at the bigger picture, routines move Claude Code from “assistant you talk to” to “worker you deploy”. They don’t replace humans, nor are they a full substitute for deterministic tools like GitHub Actions where predictability and exact semantics matter most. But for that wide swath of repetitive, context-heavy work – triage, review, documentation hygiene, cross‑SDK synchronization – they free developers from the grind and let an always‑on agent handle the night shift. With careful prompt design, disciplined use of connectors, and sane repo permissions, they can become a dependable part of your DevOps toolkit rather than just another flashy AI demo.

Artículo relacionado:

Diseño y construcción de equipos de agentes de IA: de la estrategia a la puesta en producción