Claude Code-Routinen: Deinen Coding-Agenten nach Zeitplan in der Cloud ausführen

Die drei Bausteine haben jeweils einen klaren Job:

• Prompt. Der wichtigste Teil, weil die Routine jeden Schritt ohne deine Freigabe ausführt. Der Prompt muss die gesamte Aufgabe und die Definition von „fertig“ tragen.
• Repositories. Claude klont sie zu Beginn jedes Laufs und arbeitet darin.
• Connectors. Die Integrationen in deinem claude.ai-Konto, etwa Slack oder Linear, aus denen die Routine lesen und in die sie während eines Laufs schreiben kann. Eine Routine fürs Support-Triage könnte z. B. einen Slack-Kanal lesen und Issues in Linear anlegen.

Connectors für Routinen werden auf der claude.ai-Plattform hinzugefügt, ebenso wie MCP-Server. Lokale Konfigurationen werden nicht übernommen.

Eine Routine kann auf drei Arten ausgelöst werden: nach Zeitplan, per API-Aufruf oder via GitHub-Event. Eine einzige Routine kann alle drei kombinieren.

Routinen versus /loop

Zwischen /loop und /schedule gibt es einen Unterschied, weil beide verschiedene Probleme lösen.

Eine /loop-Aufgabe lebt in deiner aktuellen Session. Sie wird nur ausgelöst, während Claude Code auf deiner Maschine läuft und im Leerlauf ist; das Schließen des Terminals stoppt sie. Das ist gut, um z. B. einen Build zu pollen, den du gerade beobachtest.

Mehr Infos zu /loop und anderen wichtigen Befehlen findest du im Tutorial Claude Code Terminal.

Eine Routine läuft in der Cloud und ist unabhängig von jeder Session:

Es gibt auch eine dritte, lokale Option. Geplante Desktop-Aufgaben laufen auf deinem eigenen Rechner für Arbeit, die lokale Dateien und Tools braucht. Sie laufen nur, wenn die Maschine wach ist, benötigen aber nicht die geöffnete Claude-App.

Die Routine, die wir bauen

Das mentale Modell steht. Jetzt brauchst du etwas, woran die Routine arbeiten kann. Für dieses Tutorial haben wir das pr-review-demo-Repo erstellt – ein kleines Python-Projekt mit einem offenen Pull Request.

Es enthält ein cartlib-Paket für den Warenkorb: Es speichert Preise als ganzzahlige Cents, wendet Mitglieder- und Mengenrabatte an und addiert die Umsatzsteuer des Bundesstaats für den Endbetrag. Das Paket auf dem Main-Branch ist korrekt.

Der offene Pull Request fügt einen Gutschein für kostenlosen Versand hinzu – mit einem Bug, den wir absichtlich eingebaut haben. Es ist ein Einheitenfehler über zwei Dateien hinweg, der in keiner einzelnen Datei auffällt und nur sichtbar wird, wenn du den Wert durch beide verfolgst. So hat die Routine im Rest des Tutorials eine echte Aufgabe.

Forke das Repo, um auf deiner eigenen Kopie mitzugehen. Es ist Wegwerfmaterial, und die Muster lassen sich auf jedes Repository übertragen, das du einer Routine zuweist.

Voraussetzungen zum Mitmachen

Du brauchst ein claude.ai-Konto im Pro-, Max-, Team- oder Enterprise-Plan mit aktiviertem Claude Code im Web. Routinen findest du unter claude.ai/code/routines.

Der /schedule-Befehl authentifiziert über deinen claude.ai-Login, nicht über einen Anthropic API-Key oder Bedrock-, Vertex- oder Foundry-Auth. Außerdem brauchst du ein aktuelles CLI – führe claude update aus, wenn deins veraltet ist.

Es gibt außerdem zwei getrennte GitHub-Voraussetzungen. Erstens gewährt /web-setup Klonrechte, die die geplante Routine braucht. Zweitens ermöglicht die separat installierte Claude GitHub App den später behandelten GitHub-Trigger.

Claude Code-Routinen mit /schedule bauen

Mit einem Ziel-Repo baust du die Routine über das CLI. Führe /schedule in einer beliebigen Session aus. Du kannst eine Beschreibung direkt übergeben:

/schedule daily PR review at 9 am

Claude führt dich dann durch dieselben Felder wie das Web-Formular: Name, Prompt, Repository, Umgebung, Connectors und Zeitplan. Es bestätigt den Zeitplan in deiner lokalen Zeitzone und konvertiert ihn für dich – 9 Uhr wird zur passenden Cron-Expression, ohne dass du eine schreiben musst.

Wenn dein Konto noch keine GitHub-Verbindung hat, fordert dich Claude auf, /web-setup auszuführen. Führe es aus und dann erneut /schedule, um nahtlos weiterzumachen.

Einen Prompt schreiben, der ohne dich läuft

Der Prompt entscheidet, ob diese Routine gelingt oder scheitert.

Eine normale Session ist ein Gespräch – du kannst Claude unterwegs korrigieren. Eine Routine hat niemanden, der sie korrigiert. Sie startet kalt, läuft bis zum Ende und kann keine Rückfragen stellen. Der Prompt muss Aufgabe, Repository und das Bild eines erfolgreichen Laufs klar benennen.

Vergleiche diese beiden. Der erste lässt zu viel offen:

Review the open PR.

Er nennt weder Repo noch Review-Kriterien, hat keinen Ort für Kommentare und keine Definition von „fertig“. Ein kalter Lauf kann diese Lücken nicht schließen. Der zweite Prompt beantwortet alles:

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Dieser Prompt nennt das Repo und formuliert die Invariante: alle Beträge in Cents. Er verweist auf die zwei relevanten Dateien und definiert „fertig“ als Inline-Kommentar plus Merge-Urteil. So hat der Lauf ein Ziel, das er allein erreichen kann. Füge ihn ein, wenn /schedule fragt, was der Agent tun soll.

Standardmäßig sind all deine Connectors enthalten, eine frische Routine erreicht also bereits alles, was mit deinem Konto verknüpft ist. Das ist fürs Erste okay; später beschränkst du den Zugriff.

Wenn du den Ablauf abschließt, speichert Claude die Routine und bestätigt, dass sie aktiv ist – mit Repository, Zeitplan, Modell und nächster Laufzeit.

Die Routine erscheint außerdem in der Liste unter claude.ai/code/routines. Öffne die Detailseite, um alles auf einen Blick zu sehen: Status, Repository, Zeitplan, Connectors, den vollständigen Prompt und einen Jetzt ausführen-Button.

Klicke auf Jetzt ausführen, um sie sofort zu starten, statt bis 9 Uhr zu warten.

Den Lauf lesen

Der Lauf startet mit einem frischen Klon deines Repositories vom Default-Branch. Alles, was du committed hast, ist da. Alles, was du nur lokal eingerichtet hast, nicht – die Routine sieht das Repo also so, wie es deine Teamkolleginnen und -kollegen sehen würden.

Nach Abschluss zeigt die Laufhistorie einen grünen Status. Grün bedeutet: Die Session lief und beendete ohne Infrastrukturfehler. Es heißt jedoch nicht, dass die Aufgabe aus deinem Prompt erfolgreich war. Hinter einem grünen Haken können sich drei Fehlerarten verbergen, die nur im Transkript sichtbar sind:

• Eine Netzwerk-Anfrage, die die Umgebung blockiert hat.
• Ein Connector-Tool, das die Routine erwartete, aber nicht erreichen konnte.
• Ein Aufgabenfehler: Der Lauf endete sauber, tat aber das Falsche.

Öffne also den Lauf zur Bestätigung. Klicke auf einen Lauf, um ihn als vollständige Session zu lesen: Du siehst, was Claude getan hat, prüfst den Diff, öffnest einen Pull Request oder führst das Gespräch fort.

Im Demo-Repo zeigt das Transkript den Fund: Claude liest checkout.py und entdeckt, dass der Gutschein als 5 statt 500 gesetzt ist. Es erklärt, dass dadurch 5 $ als 5 Cent angerechnet werden – der Kunde wird pro Bestellung um 4,95 $ zu viel belastet – und gibt den Ein-Zeilen-Fix. Anschließend postet es das Review über den GitHub-Connector direkt im PR.

Claude Code-Routinen per CLI verwalten

Sobald eine Routine existiert, verwaltest du sie mit demselben Befehl. /schedule list zeigt alle, /schedule update ändert eine, und /schedule run startet sie sofort.

Es gibt Presets für stündlich, täglich, werktags und wöchentlich. Für ein benutzerdefiniertes Intervall, etwa alle 2 Stunden oder jeden 1. des Monats, wählst du zuerst das nächstliegende Preset. Danach setzt du mit /schedule update die Cron-Expression direkt. Das Mindestintervall beträgt 1 Stunde; schnelleres wird abgelehnt.

Routinen zählen außerdem gegen das tägliche Laufkontingent deines Kontos; während der Research Preview haben GitHub-Events stündliche Limits. Events über dem Limit werden verworfen, nicht eingereiht. Die aktuellen Werte variieren je nach Plan und sind unter claude.ai/code/routines sichtbar.

Das CLI erstellt nur geplante Routinen. GitHub- oder API-Trigger fügst du in der Web-App hinzu.

Claude Code-Routinen per GitHub und HTTP auslösen

Der Zeitplan löst deine Routine nach Uhr aus. Zwei weitere Trigger erlauben es GitHub oder deinen eigenen Systemen, dieselbe Routine zu starten. Eine PR-Review-Routine kann also nachts laufen, auf jeden neuen PR reagieren und zusätzlich aus einem Deploy-Skript starten – alles gleichzeitig.

Beide fügst du hinzu, indem du die Routine unter claude.ai/code/routines bearbeitest.

Auf Pull Requests mit einem GitHub-Trigger reagieren

Der GitHub-Trigger erfordert die Claude GitHub App, installiert auf dem Repository, das du abonnieren willst. Fehlt die App, fordert dich die Trigger-Einrichtung zur Installation auf. Beachte, dass /web-setup von oben nur Klonrechte gewährt. Es installiert die App nicht und liefert keine Webhooks – dieser Schritt ist damit nicht abgedeckt.

Sobald die App installiert ist, fügst du den Trigger hinzu und wählst ein Event. Die Events fallen in zwei Kategorien, Pull Requests und Releases. Innerhalb der Kategorie wählst du eine konkrete Aktion. Die UI bietet gängige Presets wie „PR opened“, „PR merged“ und „Release published“ sowie „Custom“ für den Rest.

Danach schränkst du mit Filtern ein. Für Pull Requests kannst du nach Autor, Titel, Body, Base-Branch, Head-Branch, Labels, is-draft und is-merged filtern. Alle Bedingungen müssen zutreffen, damit die Routine feuert.

Der Operator matches regex prüft das gesamte Feld, nicht nur Substrings. Um jeden Titel zu matchen, der hotfix enthält, schreibe .*hotfix.*. Ein schlichtes hotfix matcht nur einen Titel, der exakt so lautet – und sonst nichts.

Der GitHub-Trigger feuert bei einem neuen Pull Request, gefiltert auf den Main-Branch und eine bestimmte Autorin bzw. einen bestimmten Autor.

Für das Demo-Repo setzt du das Event auf „Pull Request geöffnet“ und lässt die Filter offen. Jetzt löst jeder neue PR dein vorher geschriebenes Review aus – ganz ohne jemand am Terminal. Die Routine verfolgt die Einheit des Gutscheins über die Dateien, hinterlässt einen Inline-Kommentar am Bug und postet ein Merge-Urteil. 

Jedes passende Event startet seine eigene Session – zwei PRs hintereinander ergeben zwei unabhängige Läufe.

Eine Routine über HTTP triggern

Mit dem API-Trigger können deine eigenen Tools eine Routine auslösen. Wähle unter dem Trigger-Selector API und klicke auf Token generieren. Das Token wird nur einmal angezeigt und kann später nicht erneut abgerufen werden – lege es sofort im Secret-Store deines Alerting-Tools ab.

Dann POSTe an den Fire-Endpoint der Routine mit dem Token und einem text-Body:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

Der text-Wert wird als String unverändert übergeben und nicht geparst – schreibe also Fließtext statt JSON. Strukturierte Eingaben kommen als Rohtext an, die Routine liest sie wortwörtlich. 

Der anthropic-beta-Header ist erforderlich, und die API ist experimentell – prüfe also die API-Referenz, bevor du sie in CI einbindest. Von dort kann ein Monitoring-Tool den Endpoint bei einem Alarm aufrufen und die Routine eigenständig einen Draft-Fix-PR eröffnen lassen.

Zugriff von Claude Code-Routinen gezielt beschränken

Eine Routine läuft allein. Bevor du sie auf ein echtes Repo loslässt, begrenze daher ihren Zugriff. Die Doku formuliert das als vier Stellschrauben:

• Wer die Routine ist – über deine GitHub-Identität und Connectors.
• Auf welche Branches sie pushen darf.
• Welche Connectors sie verwenden darf.
• Welche Hosts die Umgebung über das Netzwerk erreichen lässt.

Beschränke jeden Punkt auf das, was die Routine wirklich braucht.

Identität der Routine

Identität steht zuerst, denn sie fällt Kolleginnen und Kollegen im gemeinsamen Repo als Erstes auf. Alles, was eine Routine über deine GitHub-Identität oder Connectors tut, erscheint als du. 

Commits und Pull Requests tragen deinen GitHub-User, Slack-Nachrichten und Linear-Tickets deine verknüpften Accounts. Kolleginnen und Kollegen sehen deinen Namen – benenne Branches und Titel also so, dass klar ist, dass sie von einer Routine stammen.

Branches, auf die die Routine pushen darf

Branches kommen als Nächstes. Ein Lauf ist eine vollständige Cloud-Session ohne Berechtigungsabfragen – sie hält also nicht an, um vor Dateiänderungen oder PRs zu fragen. 

Das Geländer ist der Branch, auf den geschrieben werden darf. Standardmäßig pusht Claude nur auf Branches mit dem Präfix claude/ – damit bleibt es weg von geschützten oder langlebigen Branches wie main. 

Eine Repository-weite Einstellung, Unbeschränkte Branch-Pushes erlauben, hebt diese Begrenzung auf. Aktiviere sie bewusst – nur für Repos, die es benötigen.

Connectors, die die Routine nutzen darf

Connectors sind am riskantesten. Standardmäßig sind alle deine claude.ai-Connectors enthalten, und Claude kann jedes Tool eines enthaltenen Connectors nutzen – inklusive Schreibzugriff – ohne während des Laufs zu fragen. 

Stutze die Liste also auf das Nötige. Eine PR-Review-Routine braucht GitHub und wenig mehr. Ein verirrter E-Mail- oder Kalender-Connector ist unnötiger Zugriff, und eine Prompt Injection in einem PR könnte diesen Zugriff gegen dich wenden.

Netzwerkzugriff

Netzwerkzugriff ist die letzte Stellschraube. Die Default-Umgebung verwendet Trusted Network Access: Sie erreicht eine eingebaute Allowlist aus Paketregistern, Cloud-Provider-APIs, Container-Registern und gängigen Entwicklungsdomänen – den Rest blockt sie. 

Eine blockierte Anfrage schlägt mit 403 und x-deny-reason: host_not_allowed fehl. Weite den Zugriff nur, wenn die Routine wirklich deine eigenen Services erreichen muss. Andernfalls bleibt der Fehler unauffällig und zeigt sich nur im Transkript.

Ideen für weitere Claude Code-Routinen

Du kannst eine Routine bauen, auslösen und ihren Zugriff einschränken. Diese Beispiele aus der offiziellen Doku kombinieren je einen Job mit dem passenden Trigger:

• Individuelles Code-Review. GitHub-Trigger bei PR-Erstellung. Es wendet eure Review-Checkliste an, hinterlässt Inline-Kommentare zu Security, Performance und Stil und ergänzt eine Zusammenfassung. Das Demo – verallgemeinert auf eure Standards.
• Backlog-Pflege. Schedule-Trigger, jeden Werktagabend. Liest seit dem letzten Lauf erstellte Issues, vergibt Labels, weist Owner basierend auf dem betroffenen Codebereich zu und postet eine Zusammenfassung in Slack.
• Deploy-Verifikation. API-Trigger aus der CD-Pipeline nach jedem Prod-Deploy. Führt Smoke-Checks gegen den neuen Build aus, scannt Error-Logs auf Regressionen und postet ein Go/No-Go in den Release-Channel.
• Docs-Drift. Schedule-Trigger, wöchentlich. Scannt seit dem letzten Lauf gemergte PRs, markiert Docs, die geänderte APIs referenzieren, und eröffnet Update-PRs gegen das Docs-Repository.

Routinen eignen sich für unbeaufsichtigte, wiederholbare Arbeiten mit klarem Ergebnis. Wenn du die Erfolgskriterien in den Prompt schreiben kannst – wie beim PR-Review – ist die Aufgabe ein Kandidat. Arbeit, die Echtzeitentscheidungen braucht, eher nicht.

Fazit

Routinen verändern, wie du Zeit für wiederkehrende Aufgaben einsetzt. Statt jede Aufgabe am Terminal auszuführen, schreibst du sie einmal und prüfst, was bereits gelaufen ist. Das PR-Review, das du gebaut hast, läuft, während dein Laptop zu ist – und du liest das Urteil, wenn es dir passt.

Um mit Claude Code weiterzukommen, passen diese Tutorials gut dazu:

• Claude Code Best Practices – so holst du mehr aus jeder Session heraus.
• Eine CLAUDE.md schreiben, um Routinen und Sessions gemeinsamen Kontext zu geben.
• Spec-driven Development – für Aufgaben, die du vor der Automatisierung spezifizieren solltest.
• Auto Mode und Channels – um Claude Code mit weniger Aufsicht laufen zu lassen.