Claude Code Routines nächtliche Checks ohne Orderrechte.
Claude Code Routines sind gespeicherte Claude-Code-Aufträge, die in Anthropics Cloud nach Zeitplan, per API-Aufruf oder bei GitHub-Ereignissen starten, auch wenn Ihr Rechner ausgeschaltet ist. Für private Trader, Quant-Entwickler und Trading-Teams eignen sie sich für Research-Arbeit wie nächtliche Datenprüfungen oder Backtest-Berichte als Pull Request (Änderungsvorschlag auf GitHub), nicht für die Orderausführung. Stand Oktober 2026 sind Routines eine Research Preview (Vorschauphase) für die Pläne Pro, Max, Team und Enterprise. Entscheidend ist die Sicherheitslogik: Eine Routine fragt bis auf wenige Artifact-Aktionen nicht nach Freigabe, nutzt standardmäßig alle verbundenen Connectors samt Schreibrechten und handelt unter Ihrem Namen. Dieser Leitfaden zeigt, welche Aufgaben sich lohnen, wie ein typischer Nachtlauf aussieht und wie Sie die Umgebung so zuschneiden, dass eine Routine weder Geld bewegen noch Ihren Hauptzweig verändern kann.
Was sind Claude Code Routines und wer kann sie nutzen?
Eine Routine bündelt einen Prompt, ein oder mehrere GitHub-Repositories, eine Cloud-Umgebung, ausgewählte Connectors (Anbindungen an Dienste wie Slack oder Google Drive) und einen oder mehrere Auslöser. Jeder Lauf ist eine vollwertige Claude-Code-Sitzung auf Anthropics Infrastruktur oder, wenn ein Unternehmen das eingerichtet hat, in einer selbst gehosteten Umgebung. Den Verlauf jeder Sitzung können Sie anschließend öffnen, Änderungen prüfen und das Gespräch fortsetzen.
Verfügbar sind Routines laut Dokumentation in den Plänen Pro, Max, Team und Enterprise. Angelegt werden sie unter claude.ai/code/routines, in der Desktop-App (Bereich Code, „Routines“, Variante „Cloud“) oder im Terminal mit /schedule. Der CLI-Befehl setzt eine Anmeldung mit claude.ai-Abo voraus; mit einem Console-API-Schlüssel oder über Cloud-Anbieter wie Amazon Bedrock erscheint er nicht. Owner in Team- und Enterprise-Organisationen können Routines für alle Mitglieder abschalten. Routines gehören immer zum persönlichen Konto, lassen sich nicht mit Kollegen teilen und verbrauchen dasselbe Nutzungskontingent wie Ihre interaktiven Sitzungen.
Anthropic bietet drei Wege, Claude Code zeitgesteuert laufen zu lassen. Die Unterschiede sind für Trading-Projekte wichtig, weil sie bestimmen, welche Daten und Werkzeuge erreichbar sind:
| Routine (Cloud) | Desktop-Aufgabe (lokal) | /loop | |
|---|---|---|---|
| Läuft auf | Anthropic-Cloud | Ihrem Rechner | Ihrem Rechner |
| Rechner muss laufen | nein | ja | ja, mit offener Sitzung |
| Lokale Dateien | nein, frischer Klon des Repos | ja | ja |
| Freigabe-Rückfragen | keine, läuft autonom | je Aufgabe einstellbar | wie die Sitzung |
| Kürzestes Intervall | 1 Stunde | 1 Minute | 1 Minute |
Für Trader folgt daraus: Eine Routine sieht weder Ihr lokales Terminal noch Dateien, die nur auf Ihrem Rechner liegen. Was sie prüfen soll, muss im Repository stehen oder über eine freigegebene Domain abrufbar sein. Wer Claude Code lokal mit Hooks und Sandbox für Strategie-Code einsetzt, findet den Arbeitsablauf dafür im Artikel Claude Code für Trader; hier geht es um den unbeaufsichtigten Betrieb.
Zeitplan, API oder GitHub: welcher Auslöser für welche Research-Aufgabe?
Eine Routine kann mehrere Auslöser kombinieren. Für Research-Aufgaben im Trading bieten sich drei Muster an, die sich direkt auf die Auslöser abbilden lassen:
| Auslöser | Typische Research-Aufgabe | Zu beachten |
|---|---|---|
| Zeitplan | Nächtliche Datenqualitätsprüfung im Daten-Repository, wöchentlicher Abgleich von Strategie-Dokumentation und Parametern im Code | Voreinstellungen stündlich, täglich, werktags, wöchentlich oder einmalig; Zeiten in Ihrer lokalen Zeitzone; eigene Cron-Ausdrücke (Zeitplan-Syntax aus der Unix-Welt) über /schedule update, aber nie öfter als stündlich |
| GitHub | Backtest-Neuberechnung nach jedem Merge in den Hauptzweig, Ergebnis als Bericht im Pull Request | Ereignisse Pull Request und Release, filterbar etwa nach Zielzweig oder „is merged“; die Claude-GitHub-App muss installiert sein; Ereignisse über dem Stundenlimit werden verworfen |
| API | Ihre Datenpipeline meldet „Download abgeschlossen“ und stößt die Prüfung an | POST an einen eigenen /fire-Endpunkt mit Bearer-Token; Token wird nur einmal angezeigt; API-Auslöser lassen sich nur im Web anlegen |
Ein Detail aus der Dokumentation: Läufe genau zur vollen Stunde können einige Minuten später starten. Wer einen Bericht zu Handelsbeginn braucht, plant besser 5:07 Uhr statt 5:00 Uhr. Einmalige Termine deaktivieren sich nach dem Lauf selbst.
Für die Backtest-Neuberechnung gilt dieselbe Disziplin wie lokal: fester Daten-Snapshot, feste Zufalls-Seeds, Kosten- und Slippage-Annahmen im Code statt im Prompt. Sonst lässt sich eine Abweichung im Bericht nach dem Merge nicht mehr eindeutig der Code-Änderung zuordnen. Der Bericht sollte Kennzahlen alt gegen neu nebeneinanderstellen, nicht bewerten, ob die Strategie „besser“ geworden ist.
Beispiel: nächtliche Datenprüfung mit Bericht als Pull Request.
Typisches Beispiel: Ein Daten-Repository enthält Tagesdaten als Parquet-Dateien (ein spaltenorientiertes Datenformat) und ein Prüfskript, das Lücken im Handelskalender, doppelte Zeitstempel, verletzte OHLC-Logik (Hoch unter Schlusskurs, Tief über Eröffnung), Nullvolumen und auffällige Kurssprünge findet, wie sie unbereinigte Splits erzeugen. Die Logik der Prüfungen steckt im Skript, nicht im Prompt. Claude soll das Skript ausführen, das Ergebnis lesbar zusammenfassen und den Bericht zur Prüfung vorlegen. Der Prompt einer solchen Routine kann so aussehen:
Aufgabe: Nächtliche Datenprüfung im Repository marktdaten. 1. Führe python checks/run_checks.py --since 7d aus. Ändere keine Dateien unter data/. 2. Schreibe das Ergebnis nach reports/datacheck/<Datum>.md: geprüfte Symbole, Lücken, Duplikate, OHLC-Verstöße, Sprünge über der Schwelle aus checks/config.yaml. 3. Erste Zeile des Berichts: STATUS: OK, STATUS: AUFFÄLLIG oder STATUS: FEHLGESCHLAGEN (Skript lief nicht durch). 4. Committe nur den Bericht auf claude/datacheck-<Datum> und öffne einen Draft-Pull-Request, Status im Titel. 5. Rufe keine Broker- oder Handelsschnittstellen auf. Fehlende Daten nur melden, nie ersetzen oder schätzen.
Dazu passende Einstellungen: Auslöser werktags 5:07 Uhr, nur das Daten-Repository, eine eigene Umgebung mit Netzwerkzugriff „Custom“, in der nur die Paketregistries (für Bibliotheken wie pandas) und, falls nötig, die Domain Ihres Datenanbieters freigegeben sind, und keine Connectors. „None“ funktioniert nur, wenn das Skript ohne nachzuinstallierende Pakete auskommt, denn ohne Netzwerk scheitern laut Dokumentation auch Installationen im Setup-Skript. Das Modell wählen Sie fest im Prompt-Feld; es gilt für jeden Lauf.
Der Pull Request statt eines direkten Commits ist Absicht: Der Bericht läuft so durch dieselbe Prüfung wie jede andere Änderung. Sie sehen morgens einen Draft mit „STATUS: AUFFÄLLIG“ im Titel, lesen den Bericht und entscheiden selbst, ob ein Datenproblem vorliegt. Die Routine korrigiert nichts. Gerade bei Marktdaten ist das wichtig: Ein Sprachmodell, das eine Lücke „sinnvoll“ auffüllt, erzeugt genau die stille Verzerrung, die Backtests später wertlos macht.
Warum Routines ohne Rückfrage handeln: Connectors, Konto, Umgebungsvariablen.
Routines laufen als vollständige Cloud-Sitzungen ohne Auswahl eines Berechtigungsmodus. Claude führt Shell-Befehle aus, nutzt Skills aus dem geklonten Repository und ruft eingeschlossene Connectors auf, ohne anzuhalten. Ausnahmen gibt es laut Dokumentation nur für bestimmte Artifact-Aktionen. Seit Claude Code 2.1.213 behandelt Claude den gespeicherten Prompt als zugewiesene Aufgabe; er gilt aber ausdrücklich nicht als Zustimmung zu Aktionen während des Laufs. Daraus ergeben sich vier Punkte, die Sie kennen sollten:
- Connectors sind standardmäßig alle dabei. Beim Anlegen werden sämtliche verbundenen Connectors eingeschlossen, und Claude darf jedes ihrer Werkzeuge nutzen, auch schreibende. Connector-Verkehr läuft über Anthropics Server und wird von der Netzwerk-Allowlist (der Liste freigegebener Domains) der Umgebung nicht erfasst.
- Alles geschieht unter Ihrem Namen. Commits und Pull Requests tragen Ihren GitHub-Nutzer, Slack-Nachrichten oder Tickets erscheinen über Ihre verknüpften Konten.
- Umgebungsvariablen sind nicht geheim. Variablen und Setup-Skript einer Umgebung kann jeder lesen, der diese Umgebung nutzt; in organisationsweit geteilten Umgebungen sind das alle Mitglieder.
- Network Secrets verbergen, begrenzen aber nicht. Auf Pro und Max lassen sich API-Schlüssel als Network Secret hinterlegen. Ein Proxy hängt sie an Anfragen an die eingetragenen Hosts an; Claude sieht den Schlüssel nie. In Team und Enterprise gibt es das laut Dokumentation noch nicht.
Beim letzten Punkt liegt das eigentliche Risiko. Ein Network Secret schützt den Schlüssel vor dem Auslesen, nicht vor seiner Verwendung. Die Sitzung kann die eingetragenen Hosts sogar dann erreichen, wenn die Netzwerkstufe sie sonst sperren würde. Läge dort ein Broker-Schlüssel mit Handelsrechten, könnte eine fehlgeleitete Sitzung damit Orders senden. Das ist die logische Folge der dokumentierten Funktionsweise, kein Fehler des Produkts.
Absicherung: keine Handelsrechte, enge Allowlist, Branch-Schutz.
Aus dieser Logik ergibt sich eine einfache Grundregel: Die Routine bekommt nur, was sie für den Bericht braucht, und nichts, womit sie Geld bewegen oder den Hauptzweig verändern kann. Konkret:
- Keine Handelsrechte in der Umgebung. Weder als Umgebungsvariable noch als Network Secret. Braucht der Bericht Kontodaten, exportiert Ihr eigenes System sie vorab in das Repository oder nutzt einen reinen Lesezugang. Orderlogik und Notaus bleiben in Ihrem separat abgesicherten Handelssystem; wie ein solcher Notaus aussieht, beschreibt der Artikel Kill-Switch für Trading-Bots.
- Connectors entfernen. Für eine Datenprüfung braucht es in der Regel keinen einzigen. Wenn doch, dann nur lesende Dienste und bewusst einzeln hinzugefügt.
- Eigene Umgebung mit enger Allowlist. Die Standardumgebung erlaubt mit „Trusted“ eine Liste von Paketregistries, Cloud- und Container-Diensten, GitHub und gängigen Entwicklerdomains. Legen Sie eine eigene Umgebung mit „Custom“ (oder „None“, wenn nichts nachinstalliert wird) an und tragen Sie nur die Domains ein, die das Skript braucht. GitHub bleibt über einen eigenen Proxy auf jeder Stufe erreichbar. „Full“ ist für Trading-Repositories selten zu rechtfertigen. Gesperrte Anfragen scheitern mit HTTP 403 und tauchen im Sitzungsverlauf auf.
- Branch-Schutz ohne Hintertür. Claude pusht standardmäßig auf Zweige mit dem Präfix
claude/, der Prompt kann das aber ändern. Schutzregeln greifen laut Dokumentation gegenüber Ihrem verbundenen GitHub-Zugang; eine Regel, die Ihr Konto umgehen darf, hält also auch die Routine nicht auf. Bei klassischen Branch-Schutzregeln gelten die Einschränkungen laut GitHub standardmäßig nicht für Repository-Admins, also meist auch nicht für Ihr eigenes Konto. Aktivieren Sie deshalb „Do not allow bypassing the above settings“ oder nutzen Sie ein Ruleset ohne Ausnahmeliste, damit Änderungen am Hauptzweig nur per Pull Request möglich sind. - Research und Live-Betrieb trennen. Die Routine bekommt das Daten- oder Research-Repository, nicht das Repository mit Live-Konfiguration und Deployment.
- API-Payload als fremde Eingabe behandeln. Text, der per API oder „Run now“ mitgegeben wird, kommt in einem als untrusted markierten Block an. Claude befolgt Anweisungen darin nur, wenn Ihr Prompt das ausdrücklich vorsieht. Übergeben Sie dort höchstens Daten wie ein Datum oder einen Dateinamen, keine Arbeitsanweisungen, und verwahren Sie das Token in einem Secret-Store. Bei Verdacht auf ein Leck lässt es sich neu erzeugen oder widerrufen.
Zusätzlich gelten Hooks und Berechtigungsregeln aus der .claude/settings.json des Repositories, sofern die Sitzung nur ein Repository nutzt. Ablehnungsregeln für bestimmte Befehle sind damit ein brauchbares zweites Sicherheitsnetz, ersetzen aber nicht die Begrenzung von Netzwerk, Connectors und Zugangsdaten.
Grenzen und Risiken: Research Preview, Stundenlimits, grüner Status.
Research Preview. Verhalten, Limits und die API können sich ändern. Der /fire-Endpunkt läuft hinter einem datierten Beta-Header; bei Änderungen bleiben laut Anthropic die zwei vorherigen Header-Versionen noch nutzbar. Wer Routines in eine Pipeline einbindet, sollte die Release Notes im Blick behalten.
Stundenlimits ohne Overage. Je Konto sind 100 geplante Läufe pro Stunde möglich; darüber warten Läufe. „Run now“ und API-Aufrufe teilen sich je Routine 30 Auslösungen pro Stunde, je Konto gelten zusätzlich eigene Obergrenzen. Unabhängig davon zählt jeder Lauf auf Ihr Abo-Kontingent. Ist es erschöpft, werden weitere Läufe abgelehnt, sofern keine Nutzungs-Credits aktiviert sind. Ein pausiertes Abo setzt alle Routines aus.
Kein Werkzeug für den Handelstag. Das Mindestintervall von einer Stunde, die Abhängigkeit von einer fremden Cloud und das Fehlen lokaler Dateien machen Routines ungeeignet für Überwachung im laufenden Handel. Fällt die GitHub-Verbindung aus, überspringt die Routine Läufe bis zu 72 Stunden und schaltet sich danach ab. Für zeitkritische Alarme brauchen Sie ein eigenes, unabhängiges Monitoring.
Grüner Status ist kein Erfolg. Anthropic stellt klar, dass ein grüner Status nur bedeutet: Die Sitzung lief ohne Infrastrukturfehler. Gesperrte Netzwerkanfragen, fehlende Connector-Werkzeuge oder eine Prüfung, die gar nicht stattfand, sehen Sie nur im Sitzungsverlauf. Deshalb gehört die Statuszeile in den Bericht, und deshalb sollte ein ausbleibender Pull Request selbst ein Alarmsignal sein. Ab Claude Code 2.1.227 können Sie im Terminal auch nachfragen, etwa warum ein Nachtlauf nichts erzeugt hat; Claude liest dann den Verlauf aus.
Modellfehler bleiben möglich. Claude kann ein Skript-Ergebnis falsch zusammenfassen oder eine Anweisung großzügig auslegen. Die Zahlen im Bericht sollten deshalb aus dem Skript stammen, nicht aus Claudes Formulierung, und ein Mensch prüft, bevor etwas gemergt wird.
Checkliste für Ihre erste Routine.
Existiert das Prüfskript schon, ist die erste Routine schnell eingerichtet. Eine sinnvolle Reihenfolge:
- Ein Prüfskript schreiben, das lokal läuft und einen eindeutigen Exit-Code liefert. Die Routine kommt erst danach.
- Eine eigene Cloud-Umgebung anlegen: Netzwerk „Custom“ mit nur den nötigen Domains (oder „None“, wenn nichts installiert werden muss), keine Schlüssel mit Schreib- oder Handelsrechten in Variablen.
- Die Routine nur mit dem Daten- oder Research-Repository verbinden und alle Connectors entfernen.
- Im Prompt Ausgabepfad, Statuszeile, Zweigname und Verbote festlegen, wie im Beispiel oben.
- Den Hauptzweig auf GitHub so schützen, dass auch Ihr eigenes Konto nur per Pull Request ändern kann (Admin-Ausnahme abschalten).
- Mit „Run now“ einen Probelauf starten und den Sitzungsverlauf vollständig lesen, nicht nur den Status.
- Erst dann den Zeitplan aktivieren und in der ersten Woche jeden Bericht gegen das Skript-Ergebnis prüfen.
- Monatlich kontrollieren, welche Connectors, Domains und Tokens die Routine noch hat, und Überflüssiges entfernen.
Grundsätzlich gilt für private Trader wie für Unternehmen: Research-Automatisierung und Orderausführung gehören in getrennte Umgebungen mit getrennten Zugangsdaten. Routines passen gut auf die Research-Seite. Wer Datenprüfung, Backtest-Berichte und den Weg in den Live-Betrieb sauber aufsetzen will, findet dazu mehr unter Trading-Automatisierung.
Häufige Fragen.
Kann eine Claude Code Routine automatisch Trades ausführen?
Technisch kann eine Routine jeden Dienst aufrufen, für den in ihrer Umgebung Zugangsdaten und Netzwerkzugang vorhanden sind, und sie fragt dabei nicht nach. Genau deshalb sollten Sie es nicht vorsehen: Broker-Schlüssel mit Handelsrechten gehören weder in Umgebungsvariablen noch in Network Secrets. Routines eignen sich für Datenprüfungen, Backtest-Berichte und Dokumentationsabgleiche; die Orderausführung bleibt in einem separat abgesicherten System mit eigenem Notaus.
Welche Claude-Pläne unterstützen Routines?
Stand Oktober 2026 sind Routines eine Research Preview in den Plänen Pro, Max, Team und Enterprise. Sie werden unter claude.ai/code/routines, in der Desktop-App oder mit /schedule im Terminal angelegt; dafür ist eine Anmeldung mit claude.ai-Abo nötig. In Team- und Enterprise-Organisationen können Owner Routines für alle Mitglieder abschalten. Läufe zählen auf das normale Nutzungskontingent des Abos.
Wie oft darf eine Claude Code Routine laufen?
Zeitpläne laufen höchstens stündlich; kürzere Cron-Intervalle werden abgelehnt. Je Konto sind 100 geplante Läufe pro Stunde möglich, manuelle Starts und API-Aufrufe sind auf 30 pro Routine und Stunde begrenzt. Für diese Grenzen gibt es keine Überziehung gegen Aufpreis. Zusätzlich verbraucht jeder Lauf Ihr Abo-Kontingent. Für Überwachung im laufenden Handel ist das zu grob.
Was ist der Unterschied zwischen Routines und Desktop-Aufgaben in Claude Code?
Routines laufen in der Cloud auf einem frischen Klon Ihres GitHub-Repositorys, auch wenn Ihr Rechner aus ist, und fragen bis auf einzelne Artifact-Aktionen nicht nach Freigabe. Desktop-Aufgaben laufen auf Ihrem Rechner, haben Zugriff auf lokale Dateien und einen pro Aufgabe einstellbaren Berechtigungsmodus, starten aber nur, wenn die App offen und der Rechner wach ist. Routines können zusätzlich per API oder GitHub-Ereignis starten.
Sind API-Schlüssel in einer Claude Code Routine sicher?
Umgebungsvariablen kann jeder lesen, der die Umgebung nutzt. Auf Pro und Max gibt es Network Secrets, die Claude nie zu sehen bekommt, weil ein Proxy sie erst beim Verlassen der Sitzung anhängt. Die Sitzung kann den Schlüssel aber für Anfragen an die eingetragenen Hosts verwenden. Hinterlegen Sie daher nur Schlüssel mit minimalen Rechten, idealerweise reine Lesezugänge.
Quellen und Stand.
- Automate work with routines — Anthropic (Claude Code Docs)
- Configure cloud environments — Anthropic (Claude Code Docs)
- Schedule recurring tasks in Claude Code Desktop — Anthropic (Claude Code Docs)
- About protected branches — GitHub Docs
- About rulesets — GitHub Docs
Stand: 7. Oktober 2026. Produkte, Funktionen und Preise ändern sich schnell; maßgeblich sind die Angaben der Anbieter und Behörden.
Sie wollen Datenprüfungen und Backtest-Berichte automatisieren, ohne Ihrem Werkzeug Orderrechte zu geben? Unverbindlich anfragen — wir klären Repository-Aufbau, Prüfregeln und die saubere Trennung zwischen Research und Live-Handel. Mehr zu meinem Angebot: Trading-Systeme entwickeln lassen.