What is a Claude Code routine and how does it differ from an interactive session?

A routine is a saved configuration — a prompt, attached repositories, connectors, one or more triggers — that runs on Anthropic's managed cloud infrastructure with no human present. An interactive session, by contrast, takes place in a developer's terminal with a human supervising each action and validating sensitive steps in real time. A routine keeps running when the laptop is closed, uses persistent credentials, and emits no confirmation prompt during its run.

Does a routine keep running if my computer is off?

Yes, that is its whole point. Routines execute on Anthropic's managed cloud infrastructure, not on the creator's machine. That is what distinguishes them from Claude Desktop's local scheduled tasks, which only run when the machine is awake and the app is open. A routine scheduled for 2 a.m. will execute regardless of the state of its author's workstation.

What default permissions cap the impact a routine can have on a repository?

By default, a routine can only push to branches whose name starts with claude/. This safeguard prevents it from modifying a protected branch or the main branch directly. Network access is also blocked by default, and opens either by allowlist or in full according to need. These settings can be relaxed, which is why it is worth maintaining an internal policy that records why each relaxation was granted.

How do you trace the actions a routine performs and who triggered it?

Every run produces execution logs that can be inspected in the interface. The challenge is not technical but organisational: the three trigger types — human manual, programmatic via API, event-driven via GitHub — must be distinguishable and that distinction must persist in audit trails. A routine fired manually by a developer testing their prompt does not have the same status as a routine fired in production, and that difference must surface in any post-hoc reconstruction of an incident.

Who is accountable in case of an incident caused by an autonomous routine?

The question has no technical answer, it has an organisational one. The practice that holds up over time rests on an explicit RACI matrix: a named Responsible for defining the prompt and scope (typically the developer), a single Accountable across the whole lifecycle (typically the CIO), identified Consulted roles (CISO, Ops), and an Informed line (senior management if the incident is major). Without that framework, an incident surfaces where it makes the most noise, not where the decision ought to be made.

How do you prevent routines from becoming a source of operational debt?

Operational debt settles in when routines run without an identified owner, without a review date, and without a documented sunset procedure. The practice that prevents this is organisational: every active routine must have a named owner, a review cadence (quarterly, for instance), and an explicit path to decommissioning. Prioritising routines on the way in with a MoSCoW matrix — rather than having to clean up under pressure later — avoids accumulating the merely convenient, non-essential routines that generate most of this debt.

What RACI framework should govern a team's routines?

A framework built around five lifecycle moments works well in practice. Defining the prompt and scope: R = developer, A = CIO, C = CISO and Ops, I = team. Authorising deployment: A = CIO, C = CISO, I = Dev and Ops. Supervising runs: R = Ops, A = CIO, I = Dev and business. Responding to an incident: R = Ops and Dev, A = CIO, C = CISO, I = senior management if the incident is major. Quarterly review: R = Dev, A = CIO, C = Ops, I = senior management. The CIO remains Accountable across the whole lifecycle, which materialises the fact that routines are now an infrastructure matter.

Claude Code routines: what changes for a CIO when AI leaves the developer's terminal

Updated on15 May 2026· Published on28 April 2026 | Eric Lamy | 11 min read

Claude Code routines turn a development tool into an autonomous infrastructure resource. The four governance questions every CIO must answer before any deployment.

Claude Code routines are not one feature among others: they move the tool from the developer's terminal into the organisation's infrastructure. This quiet shift places four questions inside the CIO's remit — permissions, decision scope, traceability, accountability — that need to be settled before activating the first routine rather than after the fiftieth.

The first piece in this series closed on a question: how do you govern a system capable of deciding, escalating and acting without immediate human supervision? Claude Code routines make that question concrete. Until now, Claude Code lived in a developer’s terminal, for the duration of a session, with a human validating every sensitive action. Routines move execution onto Anthropic’s cloud infrastructure, where a saved prompt fires on a fixed schedule, an API call, or a GitHub event — and runs to completion without anyone approving its steps.

This is not a product change, it is a category change. A developer productivity tool becomes an infrastructure resource for the organisation. The consequences travel one rung up the org chart: what a dev team used to arbitrate is now arbitrated by a chief information officer.

This second article unpacks the shift in five moves. What routines change technically. Why this is now a CIO matter rather than a dev matter. The four governance questions to ask before any deployment. The invisible risk that poorly scoped routines accumulate over time. And a RACI framework to govern them for the long haul.

What routines change: three triggers, one infrastructure, permissions

A Claude Code routine is a saved configuration: a prompt, one or more code repositories, a selection of connectors, and one or more triggers. It runs on Anthropic’s managed cloud infrastructure, which means it keeps working when the machine of the person who created it is powered off.

Three trigger types coexist. The first is time-based: a routine can run every hour, every night, every week, or on a finer cron expression. The second is programmatic: each routine gets a dedicated HTTP endpoint, protected by a token, to which any external system — a monitoring tool, a deployment pipeline, an internal form — can send a POST request to fire it. The third is event-driven: a routine can react to GitHub events, typically a pull request opening or a release publishing. A single routine can combine all three.

Anthropic positions this as a cloud counterpart to local scheduled tasks: closing the laptop no longer stops the work. Anthropic’s official post announcing routines frames Claude Code as an engineering resource that persists outside human sessions. The feature is still in research preview at the time of writing, which means the API and the limits may still evolve.

MCP connectors — Slack, Linear, Sentry, Gmail, Google Drive and others — are embedded by default in a routine’s execution environment. Network access is configurable: blocked by default, allowlisted to specific domains, or fully open. A useful default safeguard caps the blast radius: Claude can only push to branches prefixed with claude/, which prevents a poorly scoped routine from modifying a protected branch directly.

All of which may read as one more feature in an already rich product. The next section explains why it isn’t.

The shift point: from the developer’s terminal to the organisation’s infrastructure

Take a moment to measure what routines actually move. Before them, Claude Code was an extension of a human: a session open in a terminal, context supplied in real time by the person coding, confirmation prompts on every action that touched the disk, the network, or a repository. Supervision did not need to be thought about — it was the default state. Closing the laptop was enough to suspend everything.

Routines flip that default. The tool keeps running when nobody is online. It uses credentials that were stored once and keep serving on every trigger. It can open pull requests, comment on tickets, post to Slack channels, write to spreadsheets, send emails — without any human validating the action at the moment it happens. Technically it is still Claude Code. Functionally it is something else: an actor that operates inside the information system on windows where nobody is watching.

That shift is not incidental. It moves the subject from one register to another. While Claude Code lived inside a developer’s terminal, its boundaries were team practices — code review, internal standards, professional habits. The moment it runs on the infrastructure, autonomously, with access to production repositories and connectors, it enters another perimeter: the one where you ask the questions you would ask of any new stakeholder capable of acting on the system, whether human or not, internal or external.

This crossing is quiet. No contract is signed, no integration is formalised, no kick-off meeting is scheduled. It plays out in an admin interface, the moment a developer activates a trigger. And it is exactly that quietness that makes it a CIO matter rather than a dev matter. Things that enter an information system without being seen are the things that get governed the least.

The four governance questions to ask before any deployment

Grid of the four governance questions to settle before activating a Claude Code routine: permissions, decision scope, traceability, accountability

Stress-testing routines before letting them run means answering four questions. They are not new — any well-structured CIO office already asks them when it welcomes a third-party system or a provider with production access. What changes is that the actor this time is an agent capable of arbitrating its actions in context, and that activation is too easy for answers to be renegotiated case by case. A default framework is needed, applicable to every new routine before it goes live.

Permissions

What can it read, write, trigger? The question starts with attached repositories, but it continues through the connectors embedded in the execution environment and the level of network access granted. MCP connectors are included by default: a routine that only needs Slack potentially inherits Linear, Gmail and Google Drive too unless they are actively removed. Wide-open network access, granted for convenience during tuning, rarely gets closed again afterwards. The safeguards Anthropic provides — the claude/ branch prefix imposed by default on pushes, for example — are useful but can be relaxed. The most prudent default is least privilege: give the routine only the access it strictly needs, and document why each access is there.

Decision scope

Where does autonomous action end and human escalation begin? Unlike an interactive session, a running routine asks no one anything. There is no confirmation prompt, no in-flight validation. The entire burden of framing rests on the initial prompt and on the environment’s constraints.

Governance ceases to be the approval of each action as it happens. It becomes the scoping of the agent before it runs.

This formulation echoes an observation Mitch Ashley made in DevOps.com on the arrival of Claude Code routines: for teams deploying these agents, the effort no longer sits on reviewing actions but on the scope you leave them when you arm them. The practical consequence is that a vague prompt creates a vague agent. A prompt that specifies what to do, what must not be done, and what to escalate to a human via Slack or a ticket produces routines that hold up over time.

Traceability

Execution logs, the ability to reconstruct who triggered what, the capacity to replay an incident — questions the CIO office has always asked of classical systems apply equally to a routine. With one subtlety: the trigger can be human, programmatic, or event-driven, and the three need to be told apart. A routine fired manually by a developer testing their prompt does not have the same status as a routine fired by a GitHub event in production. Losing that distinction creates an audit blind spot that surfaces the day an incident forces a post-hoc reconstruction of events. The GDPR question surfaces here the moment a routine touches personal data: automated processing without direct human supervision falls under specific regimes that need to be framed before, not after.

Accountability

This is the hardest question and the one most often dodged. When a routine opens a pull request that breaks a critical integration, who answers? The person who wrote the prompt, who left six months ago? The one who approved activation in the interface? The ops team that provided the credentials to the connector that propagated the error? The CIO who authorised routine deployments without a formal policy? This question has no technical answer, it has an organisational one. The final section of this article proposes a framework for it.

The invisible risk: the operational debt of poorly scoped routines

Technical debt is a hidden cost that absorbs 20 to 40% of the IT budget. It is by now well documented, measurable, quantifiable, reducible. Routines introduce a less legible variant, which can be called operational debt: a quiet accumulation of automated processes that keep running without anyone questioning them.

A few easy-to-recognise symptoms: routines that post daily to a Slack channel no one reads anymore; routines whose connector key expired weeks ago but that retry every night; routines written by someone who left the organisation and that nobody dares disable because nobody remembers exactly what they do; routines acting on repositories that have been archived or renamed, generating errors that pile up in Anthropic’s logs without reaching anyone inside the organisation. Each of these cases costs little in isolation. Together they form a layer of entropy stacked on top of the information system, with no matching value.

The comparison with legacy cron scripts is immediate: every CIO has met those scheduled tasks that no one touches because no one knows anymore why they run. The difference is that cron scripts always do the same thing. Routines decide in context — which means their behaviour can drift silently as context changes. A Slack channel renamed, a Linear label repurposed, an internal naming convention evolving, and the routine produces something other than what was expected of it, without any error message signalling the drift. The day the drift becomes visible, diagnosing its origin takes longer than for a script whose code you could re-read in one glance.

The practice that defuses this debt is not technical, it is organisational: every active routine must have a named owner, a review date, and a documented sunset procedure. That also means prioritising on the way in rather than on the way out. The MoSCoW matrix, useful for arbitrating a project’s feature set, works just as well for routine deployments: those that absolutely must run, those that would add real value, those that are merely convenient, and those that aren’t really needed. The first three categories are the only ones that justify the governance cost an active routine requires — and the fourth, which never announces itself as such, is the one that generates most of the operational debt when left to settle in.

What to take away

Claude Code routines are not an individual productivity tool, they are an actor within the infrastructure. That shift does not show on screen — technically it is the same Claude Code as before. It shows in the permissions granted, in the decision scope left to the agent, in the traceability of the actions it performs, in the chain of accountability that activates when something goes wrong. These are the four questions the CIO needs to have settled before authorising the first routine, and which the next deployment should inherit without renegotiating each point.

On the ground, this governance takes the form of an explicit role framework. What is practised for application-level decisions — the roles of the RACI matrix — applies equally to autonomous agents, with one adjustment: the executing actor is no longer human. For a typical alert triage routine, which receives events from a monitoring tool via its API endpoint and posts an on-call summary to Slack, the RACI reads as follows.

RACI matrix for a Claude Code alert-triage routine across five lifecycle steps, showing the CIO as Accountable throughout

The framework itself is not original. It is only RACI applied to a new object. What is new is the object — and it is precisely because the object is new that the framework is worth laying down at the first routine rather than patched together in a hurry at the fiftieth. An organisation that adopts routines without this framework will not govern them any better than the team scripts it already struggled with. An organisation that lays down the framework from day one builds a capability that scales.

This still does not settle the hardest question, the one that will close this series. Claude Code routines offer an autonomy that can act across the full lifecycle of a business application — from corrective maintenance to continuous monitoring, from continuous integration to legacy modernisation. Capability is not a recommendation. At which steps of that lifecycle does agentic AI bring genuine value, and at which does it introduce a risk only human judgement can arbitrate? That is the question this series will close on.

Frequently asked questions

: A routine is a saved configuration — a prompt, attached repositories, connectors, one or more triggers — that runs on Anthropic's managed cloud infrastructure with no human present. An interactive session, by contrast, takes place in a developer's terminal with a human supervising each action and validating sensitive steps in real time. A routine keeps running when the laptop is closed, uses persistent credentials, and emits no confirmation prompt during its run.
: Three trigger types coexist and can combine on the same routine. A time trigger fires the routine at a fixed cadence — hourly, nightly, weekly, or on a finer cron expression. A programmatic trigger exposes a dedicated HTTP endpoint, protected by a token, to which any external system (monitoring tool, deployment pipeline, internal form) can POST. An event trigger fires the routine on GitHub events — typically a pull request opening or a release being published.
: Yes, that is its whole point. Routines execute on Anthropic's managed cloud infrastructure, not on the creator's machine. That is what distinguishes them from Claude Desktop's local scheduled tasks, which only run when the machine is awake and the app is open. A routine scheduled for 2 a.m. will execute regardless of the state of its author's workstation.
: By default, a routine can only push to branches whose name starts with claude/. This safeguard prevents it from modifying a protected branch or the main branch directly. Network access is also blocked by default, and opens either by allowlist or in full according to need. These settings can be relaxed, which is why it is worth maintaining an internal policy that records why each relaxation was granted.
: Every run produces execution logs that can be inspected in the interface. The challenge is not technical but organisational: the three trigger types — human manual, programmatic via API, event-driven via GitHub — must be distinguishable and that distinction must persist in audit trails. A routine fired manually by a developer testing their prompt does not have the same status as a routine fired in production, and that difference must surface in any post-hoc reconstruction of an incident.
: The question has no technical answer, it has an organisational one. The practice that holds up over time rests on an explicit RACI matrix: a named Responsible for defining the prompt and scope (typically the developer), a single Accountable across the whole lifecycle (typically the CIO), identified Consulted roles (CISO, Ops), and an Informed line (senior management if the incident is major). Without that framework, an incident surfaces where it makes the most noise, not where the decision ought to be made.
: Operational debt settles in when routines run without an identified owner, without a review date, and without a documented sunset procedure. The practice that prevents this is organisational: every active routine must have a named owner, a review cadence (quarterly, for instance), and an explicit path to decommissioning. Prioritising routines on the way in with a MoSCoW matrix — rather than having to clean up under pressure later — avoids accumulating the merely convenient, non-essential routines that generate most of this debt.
: A framework built around five lifecycle moments works well in practice. Defining the prompt and scope: R = developer, A = CIO, C = CISO and Ops, I = team. Authorising deployment: A = CIO, C = CISO, I = Dev and Ops. Supervising runs: R = Ops, A = CIO, I = Dev and business. Responding to an incident: R = Ops and Dev, A = CIO, C = CISO, I = senior management if the incident is major. Quarterly review: R = Dev, A = CIO, C = Ops, I = senior management. The CIO remains Accountable across the whole lifecycle, which materialises the fact that routines are now an infrastructure matter.

Eric Lamy

Published on 28 April 2026 — updated on 15 May 2026