Claude · Loops und autonome Runs: /loop, Iteration und Scheduling

Manche Arbeit ist dieselbe Aufgabe in Wiederholung, bis eine Bedingung erfüllt ist:

• „Behebe weiter Bugs, bis alle Tests bestehen.“
• „Prüfe das Deploy alle paar Minuten, bis es live ist, und sag mir dann Bescheid.“
• „Fasse jeden Morgen um 8 Uhr zusammen, was sich über Nacht im Repo geändert hat.“

Nichts davon ist eine einzelne Aktion. Jede ist ein Loop mit einer Abbruchbedingung. Claude Code geht damit auf mehrere Arten um, je nachdem, ob die Wiederholung innerhalb eines Runs stattfindet, per Timer in Ihrer Session oder über viele geplante Runs hinweg.

Diese Lektion behandelt drei Dinge: iterieren, bis ein Ziel erreicht ist, mit /loop einen Prompt in einem Intervall erneut ausführen und einen Agent nach festem Rhythmus starten lassen. Außerdem geht es um die Guardrails, die verhindern, dass ein unbeaufsichtigter Run Ihr Token-Budget oder Ihre Codebase verbrennt.

Wann ein Loop das richtige Werkzeug ist

Ein Loop lohnt sich, wenn drei Dinge zutreffen:

• Die Aufgabe wiederholt sich. Sie führen dieselbe Operation mehr als einmal aus (Polling, Retry, Iteration).
• Es gibt eine messbare Abbruchbedingung. Tests bestehen, ein Build ist grün, eine Datei existiert oder ein Wert überschreitet einen Schwellenwert. Wenn Sie „fertig“ nicht präzise beschreiben kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, können Sie nicht sicher loopen.
• Jeder Durchlauf verbessert das Ergebnis, oder Sie warten auf eine externe Änderung. Tests zu fixen verbessert mit jedem Durchlauf etwas. Einen Build zu pollen heißt, auf etwas außerhalb Ihrer Kontrolle zu warten.

Trifft das nicht zu, ist ein einzelner Aufruf sauberer und günstiger. „Refaktoriere diese Funktion“ ist ein Aufruf. „Refaktoriere jede Funktion, bis der Linter still ist“ ist ein Loop.

Drei Wege zu iterieren in Claude Code

Claude Code läuft in Ihrem Terminal mit Zugriff auf Ihre Dateien, Ihre Shell und Ihre Git-Historie. Wiederholung erreichen Sie auf drei Wegen.

Innerhalb eines einzelnen Runs. Sie schreiben die Aufgabe, die Abbruchbedingung und ein hartes Limit in Ihren Prompt. Claude erledigt die Arbeit, prüft das eigene Ergebnis gegen die Bedingung und wiederholt, bis die Bedingung erfüllt oder das Limit erreicht ist. Das ist das Muster „mach weiter, bis X“.

Mit `/loop`. Dieser Befehl führt einen Prompt (oder einen anderen Slash-Befehl) in einem festen Intervall erneut aus, solange Ihre Session offen bleibt. Zum Beispiel /loop 5m check whether the deploy is live and tell me when it is. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → eignet sich für leichtes Polling und Aufpass-Aufgaben, die neben Ihrer normalen Arbeit laufen sollen. Diese Loops sind an die Session gebunden. Schließen Sie Claude Code, stoppen sie, und wiederkehrende Loops laufen außerdem nach einer festgelegten Zeit automatisch ab, sie laufen also nicht ewig. Die aktuelle Intervall-Syntax und die Limits finden Sie in der Claude Code documentation.

Mit einer Shell-Schleife um den Headless-Modus. Sie rufen claude -p "..." (ein Prompt, der läuft und sich dann beendet) aus einer Bash-Schleife oder einem Skript auf. Ihr Skript verantwortet die Wiederholung, die Verzögerung und die Exit-Logik. Das funktioniert, wenn Sie exakte Kontrolle oder gar keine interaktive Session brauchen.

Hier das Muster innerhalb der Session:

claude
> Run the full test suite with pytest. If any tests fail,
  read the failure output, fix the SOURCE code (not the tests),
  and run the suite again. Repeat until all tests pass or you
  have made 10 attempts. If you hit 10 attempts, stop and tell me
  what is still failing.

Der Prompt hat drei Teile. Die Aufgabe ist explizit (pytest ausführen, Code fixen). Die Abbruchbedingung ist eindeutig (alle Tests bestehen). Das harte Limit (10 Versuche) verhindert, dass sich ein hartnäckiger Bug endlos im Kreis dreht.

Hier derselbe Polling-Job auf zwei Arten. Mit /loop, innerhalb einer Session:

/loop 2m curl https://myapp.example.com/health. If it returns 200,
post a one-line 'shipped' note and stop looping.

Mit einem Shell-Skript, bei dem Sie alles kontrollieren:

# Deploy alle 30 s pollen, bis zu 20 Mal, bis 200 zurückkommt
for i in $(seq 1 20); do
  if curl -sf -o /dev/null https://myapp.example.com/health; then
    claude -p "The deploy is live. Post a one-line 'shipped' note."
    break
  fi
  sleep 30
done

/loop ist schneller eingerichtet. Das Skript ist strenger, weil Limit und Verzögerung im Code stehen und Claude nur läuft, wenn es etwas zu tun gibt.

Warum die Abbruchbedingung maschinell prüfbar sein muss

„Fixe den Code, bis er gut aussieht“ ist keine Loop-Bedingung. Claude hat kein objektives Signal zum Prüfen, also stoppt es entweder an einem beliebigen Punkt oder poliert ewig weiter. „Fixe den Code, bis pytest mit 0 endet“ ist prüfbar, weil ein Exit-Code ein Fakt ist.

Gute Loop-Bedingungen sind Dinge, die ein Befehl beantworten kann:

• Exit-Code von pytest ist 0
• npm run build ist erfolgreich
• git status zeigt keine uncommitteten Änderungen
• ein bestimmter String erscheint in einer Logdatei
• ein HTTP-Endpoint liefert 200

Wenn Sie „fertig“ als Befehl ausdrücken können, der Erfolg oder Misserfolg zurückgibt, haben Sie einen Loop, dem Sie zutrauen können, von selbst zu stoppen.

Praxisbeispiel: weiterfixen, bis die Suite grün ist

Sie haben nach einem chaotischen Merge eine Test-Suite mit einer Handvoll Fehlschlägen. Claude soll die Tests ausführen, lesen, was kaputt ist, den Quellcode patchen und erneut laufen lassen, bis die ganze Suite grün ist.

claude
> Goal: make the entire test suite pass.
  1. Run: pytest -x --tb=short
  2. If exit code is 0, the goal is met. Stop and summarize what changed.
  3. If tests failed, read the traceback, fix the SOURCE code only.
     Never edit or delete tests to make them pass.
  4. Commit each fix with a clear message, then repeat from step 1.
  Budget: stop after 8 attempts and report if not green by then.

Schritt 3 blockiert die häufigste Abkürzung, die ein autonomer Agent nimmt: den fehlschlagenden Test zu löschen. Wird ein Modell ohne Einschränkung gebeten, „die Tests bestehen zu lassen“, kann es entscheiden, dass das Entfernen des Tests der schnellste Weg ist. „Fix the SOURCE code only“ schließt das aus.

Die Anweisung, jeden Fix einzeln zu committen, gibt Ihnen eine saubere Git-Historie und einen einfachen Revert, falls ein Fix falsch war. Wenn der Run endet, prüfen Sie den Diff, nicht den Prozess.

Ein einmaliges Fixen und Stoppen würde eine Runde Fehlschläge beseitigen und wahrscheinlich eine zweite Runde zutage fördern, die es nie angefasst hat. Iteration arbeitet alles ab, während Sie etwas anderes tun.

GuardrailsGuardrailsRegeln und Kontrollen, die ein KI-System in sicheren, rechtskonformen und markengerechten Grenzen halten und unerwünschte Ausgaben blockieren.Vollständige Definition ansehen → für unbeaufsichtigte Runs

Sobald ein Run läuft, ohne dass Sie jeden Schritt beobachten, kann er in Maschinengeschwindigkeit Schaden anrichten oder Geld verschwenden. Drei Guardrails sind nicht verhandelbar.

1. Ein hartes Budget

Jeder Loop braucht eine Obergrenze, die nicht vom Urteil des Modells abhängt. Eine Anzahl an Versuchen im Prompt ist das Einfachste. In einem Skript begrenzen Sie die Iterationen im Code (for i in $(seq 1 20)). Bei /loop wählen Sie ein Intervall, das dazu passt, wie schnell sich das Beobachtete ändert. Jeder Tick ist ein Modellaufruf, ein 1-Minuten-Loop, der den ganzen Nachmittag läuft, summiert sich also. Brechen Sie den Loop ab, sobald er seine Aufgabe erledigt hat. Das Budget ist die Absicherung für den Fall, dass die Abbruchbedingung nie greift.

2. Eine klare Abbruchbedingung

Das ist der primäre Sicherheitsmechanismus, das Budget ist nur die Absicherung. Ein Run mit Budget, aber ohne echte Abbruchbedingung läuft jedes Mal bis zum Limit durch. Bei /loop schreiben Sie die Stopp-Anweisung direkt in den Prompt („wenn 200 zurückkommt, melden und stoppen“).

3. Ein menschliches Review-Gate

Für alles, was Zustand verändert (Code schreiben, Commits pushen, Nachrichten senden, eine kostenpflichtige APIAPIApplication Programming Interface: eine standardisierte Schnittstelle, über die Anwendungen kommunizieren und Daten austauschen, ohne die interne Funktionsweise der jeweils anderen zu kennen.Vollständige Definition ansehen → aufrufen), legen Sie vorab fest, wo ein Mensch freigibt. Es gibt zwei gängige Muster:

• Review am Ende. Der Run ist vollständig autonom, erzeugt aber nur einen Branch und einen Diff. Sie prüfen vor dem Merge.
• Review pro Aktion. Die Permission-Prompts von Claude Code verlangen Ihre Zustimmung für riskante Operationen wie Shell-Befehle, Schreibzugriffe außerhalb eines Verzeichnisses oder Netzwerkaufrufe. Das ist langsamer, aber angemessen, wenn der Blast Radius groß ist.

Nutzen Sie die Permission-Einstellungen von Claude Code, um einzuschränken, welche Tools der Agent verwenden und welche Verzeichnisse er anfassen darf, bevor er unbeaufsichtigt läuft. Die Claude Code documentation behandelt die Permission-Modi im Detail.

Eine nützliche Regel: Je autonomer der Run, desto enger die Sandbox. Ein Run, den Sie beobachten, darf weitreichende Berechtigungen haben. Einer, der um 3 Uhr nachts startet, sollte fast nichts anfassen können außer der einen Sache, für die er da ist.

Scheduling: Runs nach festem Rhythmus

Iteration beantwortet „wiederholen, bis fertig“. Scheduling beantwortet „später erneut laufen, in einem Rhythmus“. Beispiele sind ein täglicher Digest, ein nächtlicher Dependency-Check oder ein wöchentlicher Report.

/loop deckt kurzlebige Wiederholung ab, solange Ihre Session offen ist. Einen zugeklappten Laptop überlebt es nicht. Für dauerhafte Schedules nutzen Sie den Scheduler Ihres Betriebssystems (cron unter Linux und macOS, Task Scheduler unter Windows) oder einen CI-Runner wie GitHub Actions.

Hier ein werktäglicher Repo-Digest als Cron-Eintrag im Headless-Modus:

# Jeden Werktag um 8:00 Uhr die nächtliche Git-Aktivität zusammenfassen
0 8 * * 1-5 cd /home/me/project && \
  claude -p "Summarize commits from the last 24 hours grouped by \
  author. Flag anything touching auth/ or billing/. Output markdown." \
  >> ~/digests/daily-$(date +\%F).md 2>&1

Das Flag -p führt einen Prompt aus und beendet sich, genau das braucht ein geplanter Job. Es gibt keine interaktive Session, Start und Ende sind sauber, und die Ausgabe landet in einer Datei. Fügen Sie einen MCPMCPEin offener Standard, mit dem KI-Assistenten einheitlich und kontrolliert an die Werkzeuge und Daten des Unternehmens angebunden werden, statt jede Integration einzeln zu bauen.Vollständige Definition ansehen →-Server hinzu, kann derselbe Run den Digest in Slack posten oder ein GitHub-Issue eröffnen. Wie Sie diese Verbindungen einrichten, steht in den Model Context Protocol docs.

Für Schedules, die mit Ihrem Repo leben statt auf einer einzelnen Maschine, nutzen Sie die Claude Code GitHub Action von Anthropic. Sie führt Claude nach Zeitplan oder bei Repo-Events aus, etwa bei einem neuen PR oder einem Issue mit einem bestimmten Label. Ein wöchentlicher on: schedule-Workflow, der Dependencies prüft und einen PR eröffnet, ist ein sauberer, reviewbarer autonomer Run.

Geplante Runs brauchen dieselben Guardrails, sogar noch mehr

Niemand schaut zu, wenn ein geplanter Job startet. Geben Sie ihm ein Budget und eine Abbruchbedingung, auch bei einem einmaligen Digest, damit ein hängender externer Aufruf ihn nicht endlos laufen lässt. Leiten Sie alles, was Zustand verändert, über ein Review-Gate. Ein geplanter Run, der einen PR eröffnet, ist sicher. Einer, der auf main pusht, ist ein Eigentor, das nur auf eine schlechte Nacht wartet.

Die richtige Form wählen

• Einzelner Aufruf: eine Aufgabe, keine Wiederholung, Sie sind dabei. „Refaktoriere dieses Modul.“
• Iteration in der Session: Aufgabe, prüfbare Abbruchbedingung und Versuchslimit in einem Prompt. „Fixe, bis die Tests bestehen, maximal 8 Versuche.“
• /loop: einen Prompt in einem Intervall erneut ausführen, solange Ihre Session offen ist. „Prüfe alle 5 Minuten das CI meines PR und sag mir, wenn es grün ist.“
• Shell-Schleife um claude -p: Ihr Skript verantwortet Wiederholung, Verzögerung und Limit. Nutzen Sie das, wenn Sie exakte Kontrolle brauchen.
• Geplanter Run: cron oder GitHub Actions führen claude -p aus, meist jedes Mal mit einer neuen Aufgabe. „Erstelle jeden Morgen einen Digest des Repos.“

Diese Formen lassen sich gut kombinieren. Ein nächtlicher GitHub-Actions-Workflow kann Claude innerhalb des Runs iterieren lassen, bis die Dependency-Upgrades das CI bestehen. Der Schedule gibt den Rhythmus vor, die Iteration findet in jedem einzelnen Run statt.

Das Wichtigste in Kürze

• Loopen Sie nur, wenn sich die Aufgabe wiederholt und „fertig“ maschinell prüfbar ist. Lässt sich die Abbruchbedingung nicht als Befehl formulieren, der Erfolg oder Misserfolg zurückgibt, haben Sie noch keinen sicheren Loop.
• /loop führt einen Prompt in einem Intervall innerhalb Ihrer Session erneut aus. Das ist gut für Polling und Aufpass-Aufgaben, stoppt aber mit dem Ende der Session, und Loops laufen von selbst ab.
• Für Iteration auf ein Ziel hin gehören Aufgabe, Abbruchbedingung und Versuchslimit in einen Prompt. Für strikte Kontrolle packen Sie claude -p in ein Skript, das den Loop verantwortet.
• Jeder unbeaufsichtigte Run braucht ein hartes Budget, eine klare Abbruchbedingung und ein menschliches Review-Gate für alles, was Zustand verändert.
• Versperren Sie die naheliegende Abkürzung. „Lass die Tests bestehen“ lädt dazu ein, Tests zu löschen, also sagen Sie „nur Quellcode fixen, niemals Tests bearbeiten“ und committen Sie jeden Fix einzeln.
• Für dauerhafte Schedules nutzen Sie cron, Task Scheduler oder GitHub Actions mit claude -p. Je autonomer der Run, desto enger die Sandbox.