Lange Läufe

Eine Sitzung von Claude Code arbeitet, solange jemand davor sitzt und den nächsten Auftrag gibt. Für vieles reicht das. Manche Arbeit braucht aber keinen Zuschauer: ein Deploy, der eine Viertelstunde dauert, ein Pull Request, auf den noch Kommentare kommen, eine Prüfung für jeden Morgen. Claude Code kennt dafür fünf Mechaniken. Es wiederholt einen Auftrag im Takt, wartet auf ein Ereignis oder arbeitet auf ein Ziel hin. Es startet nach Zeitplan eine neue Sitzung, oder die Sitzung läuft gleich in der Cloud.

Dazu kommt die Frage, wie man so einen Lauf von unterwegs verfolgt und steuert. Die Antwort heißt Remote Control, dazu die Claude-App auf dem Telefon. Wie mehrere Sitzungen nebeneinander laufen, ohne einander in die Quere zu kommen, steht in Kapitel 21.

Wo ein Lauf weiterläuft

Die wichtigste Grenze in diesem Kapitel ist der Ort. Ein Lauf auf dem eigenen Rechner steht still, solange der Rechner schläft oder das Programm geschlossen ist. Ein Lauf in der Cloud läuft weiter. Die Doku stellt die drei Wege für geplante Arbeit in einer Tabelle nebeneinander (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)):

Für /loop nennt die Doku weiter unten eine Ausnahme: Schickt man die Sitzung in den Hintergrund, laufen ihre Loops in einer Hintergrund-Sitzung weiter, auch ohne Terminal. Der Rechner muss dafür weiter wach sein.

Die Doku gibt dazu eine Faustregel:

• Die Cloud ist für Arbeit, die ohne den eigenen Rechner verlässlich laufen soll.
• Die Desktop-App ist für Aufgaben, die lokale Dateien und Werkzeuge brauchen.
• /loop ist für schnelles Nachsehen während einer Sitzung.

Remote Control und die Claude-App stehen neben diesen Spalten: Sie öffnen ein Fenster auf eine Sitzung, die schon woanders läuft. Die Doku zu Remote Control (externe Seite, code.claude.com) sagt es ausdrücklich: Browser und App zeigen nur die lokale Sitzung. Der Rechner muss also an bleiben, und der Prozess claude muss laufen.

In der offenen Sitzung wiederholen

Seit Version 2.1.71 vom 07.03.2026 wiederholt /loop einen Prompt im Takt (Versionsliste (externe Seite, code.claude.com)). /loop 5m prüfe, ob der Deploy durch ist führt die Prüfung alle fünf Minuten aus. Darunter liegen Werkzeuge für Cron, die Schreibweise für Zeitpläne aus der Unix-Welt. Einen einmaligen Termin bestellt man in normaler Sprache, etwa als Erinnerung in 45 Minuten.

Seit der Woche vom 06. bis 10.04.2026 taktet sich /loop selbst. Wer den Takt weglässt, überlässt Claude die Wahl (Wochenbericht (externe Seite, code.claude.com)). Nach jedem Durchlauf wählt es eine Pause zwischen einer Minute und einer Stunde: kurz, solange ein Build läuft, länger, wenn nichts ansteht (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)). Ohne Prompt arbeitet /loop eine eingebaute Pflegeliste ab: liegengebliebene Arbeit fortsetzen, sich um den Pull Request des Branches kümmern, aufräumen.

Die Grenze steht in der Doku unter den Einschränkungen. Eine solche Aufgabe feuert nur, solange Claude Code läuft und gerade nichts zu tun hat. Wer das Terminal schließt oder die Sitzung beendet, hält sie an. Wiederkehrende Aufgaben löschen sich außerdem sieben Tage nach dem Anlegen selbst. Ein vergessener Loop läuft also höchstens eine Woche.

Auf Ereignisse warten

Ein Takt fragt immer wieder nach, auch wenn sich nichts geändert hat. Das Werkzeug Monitor dreht das um. Es kam mit Version 2.1.98 vom 09.04.2026 und lässt einen Befehl im Hintergrund laufen, dessen Ausgabe Zeile für Zeile ins Gespräch kommt (Versionsliste (externe Seite, code.claude.com)). Man arbeitet in derselben Sitzung weiter, und Claude meldet sich, sobald ein Ereignis eintrifft (Werkzeugreferenz (externe Seite, code.claude.com)). So beobachtet Claude ein Log oder einen CI-Lauf, ohne eine Warteschleife mit sleep offen zu halten. Über Amazon Bedrock, Google Cloud und Microsoft Foundry gibt es das Werkzeug nicht. Wie lange eine solche Beobachtung höchstens dauert, steht in Kapitel 04.

Kommt das Ereignis von außen, etwa aus einem Chat oder von einem CI-Server, gibt es Channels. Ein Channel ist ein MCP-Server, der Ereignisse in die laufende Sitzung schiebt, damit Claude reagieren kann, während niemand am Terminal sitzt (Doku zu Channels (externe Seite, code.claude.com)). Zur Research Preview gehören Plugins für Telegram, Discord und iMessage. Channels gibt es seit Version 2.1.80 vom 19.03.2026 und bis heute als Research Preview, die schrittweise freigeschaltet wird. Sie brauchen eine Anmeldung bei Anthropic, über claude.ai oder mit einem API-Schlüssel der Console. Über Amazon Bedrock und die anderen Cloud-Anbieter gibt es sie nicht. In Team und Enterprise muss die Organisation sie ausdrücklich einschalten. Auch hier gilt die Grenze der Sitzung: Ereignisse kommen nur an, solange sie offen ist.

Bis ein Ziel erreicht ist

/loop und Channels sagen, wann Claude wieder ansetzt. /goal sagt, wann Schluss ist. Seit Version 2.1.139 vom 11.05.2026 legt man damit eine Abschluss­be­din­gung fest, und Claude arbeitet über mehrere Antworten hinweg weiter, bis sie erfüllt ist (Versionsliste (externe Seite, code.claude.com)). Am Ende jeder Antwort prüft ein kleines, schnelles Modell, ob die Bedingung gilt. Ist sie noch offen, beginnt Claude eine neue Antwort, ohne die Kontrolle zurückzugeben (Doku zu /goal (externe Seite, code.claude.com)).

Die Doku nennt als Beispiele Arbeit mit einem prüfbaren Ende. Ein Modul wird auf eine neue Schnittstelle umgestellt, bis alles kompiliert und die Tests durchlaufen. Oder ein Stapel Issues wird abgearbeitet, bis er leer ist. Wie man eine Bedingung schreibt, die der Bewerter überhaupt prüfen kann, steht in Vibe-Coding / Agentic Engineering, Kapitel 07.

Ein Ziel ändert die Rechte nicht. Wer es ohne Rückfragen laufen lassen will, startet /goal im Auto-Modus. Im manuellen Modus fragt Claude weiter vor jedem Werkzeugaufruf, den die Einstellungen noch nicht erlauben. Was die Modi bedeuten, erklärt Kapitel 03.

Nach Zeitplan ohne offene Sitzung

Für Arbeit, die jeden Tag oder jede Woche anfallen soll, taugt eine Sitzung schlecht, denn sie müsste dafür offen bleiben. Zwei Wege starten für jeden Lauf eine neue Sitzung.

Die Desktop-App führt geplante Aufgaben auf dem eigenen Rechner aus, mit Zugriff auf lokale Dateien und Werkzeuge. Sie laufen aber nur, solange die App geöffnet und der Rechner wach ist (Doku zu geplanten Aufgaben der Desktop-App (externe Seite, code.claude.com)). Verschläft der Rechner einen Termin, fällt der Lauf zu dieser Zeit aus. Beim Aufwachen holt die App je Aufgabe genau einen Lauf nach, den jüngsten versäumten der letzten sieben Tage, und verwirft die älteren.

Routines laufen in der Cloud. Eine Routine ist eine gespeicherte Konfiguration aus Prompt, Repositories und Connectors. Sie läuft auf Infrastruktur von Anthropic oder in einer selbst betriebenen Umgebung der Organisation und arbeitet deshalb auch bei zugeklapptem Laptop weiter (Doku zu Routines (externe Seite, code.claude.com)). Sie startet nach Zeitplan, auf einen Aufruf über HTTP oder bei einem Ereignis auf GitHub, etwa einem neuen Pull Request. Anthropic hat Routines in der Woche vom 13. bis 17.04.2026 eingeführt (Wochenbericht (externe Seite, code.claude.com)), und sie sind bis heute eine Research Preview. Verfügbar sind sie in Pro, Max, Team und Enterprise. Inzwischen heißen sie in der Doku cloud scheduled tasks. Der alte Name steht weiter in der Webadresse, in der Kommandozeile und in der API. Angelegt werden sie unter claude.ai/code/routines, in der Desktop-App oder im Terminal mit /schedule.

Eine Routine läuft selbstständig. Einen Rechtemodus wählt man beim Anlegen nicht. Ein neuer Lauf in der Cloud startet im Auto-Modus. Ein Klassifikator erlaubt oder sperrt dann, was sonst auf eine Freigabe warten würde. In einigen Fällen hält der Lauf trotzdem an und wartet auf eine Antwort, etwa bei einer Aktion, auf die eine ask-Regel passt. Was sie dabei tut, geschieht unter dem eigenen Namen. Commits und Pull Requests laufen unter dem eigenen GitHub-Nutzer. Deshalb gehört in eine Routine nur der Zugang, den sie wirklich braucht. Wie ein Team einen zeitgesteuerten Agenten für die Pflege seiner Datenanalyse einsetzt, steht in Kapitel 13. Wie man Wartung am eigenen Rechner und im Netz nach Zeitplan laufen lässt, zeigt Kapitel 12.

In die Cloud abgeben

Soll die Arbeit auch bei ausgeschaltetem Rechner weitergehen, gehört sie in die Cloud. Eine Cloud-Sitzung arbeitet weiter, wenn der Laptop zugeklappt ist, und ist von jedem Gerät aus erreichbar (Doku zu Cloud-Sitzungen (externe Seite, code.claude.com)). Aus dem Terminal startet claude --cloud mit einer Beschreibung der Aufgabe eine solche Sitzung für das aktuelle Repository, und man arbeitet lokal weiter. Wo sie läuft, wer sie bezahlt und wie claude --teleport sie zurück ins Terminal holt, steht in Kapitel 01.

Für den Weg mitten aus einer Sitzung nennt die Versionsliste ein einzelnes Zeichen: Seit Version 2.0.45 vom 18.11.2025 schickt eine Nachricht, die mit & beginnt, eine Hin­ter­grund­auf­gabe an Claude Code im Web (Versionsliste (externe Seite, code.claude.com)). Die heutige Doku zu Cloud-Sitzungen erwähnt das Zeichen nicht und lässt damit offen, ob es noch wirkt. Sie nennt claude --cloud aus der Shell und in der Desktop-App den Weg, eine lokale Sitzung über das Menü in die Cloud zu schicken.

Die Doku zur Claude-App fasst die Wahl in einem Satz zusammen: Ist der Rechner aus, nimmt man eine Cloud-Sitzung oder ein Project. Ein Project verteilt eine größere Arbeit auf mehrere Cloud-Sitzungen und lässt sich vom Telefon aus verfolgen, siehe Kapitel 22.

Aus der Ferne steuern

Remote Control verbindet eine Sitzung auf dem eigenen Rechner mit claude.ai/code im Browser oder mit der Claude-App für iOS und Android (Doku zu Remote Control (externe Seite, code.claude.com)). Befehle und Dateizugriffe bleiben dabei auf dem Rechner. In der Versionsliste (externe Seite, code.claude.com) erscheint die Funktion zuerst bei Version 2.1.51 vom 24.02.2026, als Unterbefehl claude remote-control für die nach außen ausgelieferten Builds. Version 2.1.58 öffnete sie einen Tag später für mehr Nutzer. In der Woche vom 17. bis 21.08.2026 hat Anthropic sie aus der Research Preview genommen (Wochenbericht (externe Seite, code.claude.com)).

Gestartet wird sie im Terminal mit claude remote-control oder in einer laufenden Sitzung mit /remote-control. Remote Control gibt es in Pro, Max, Team und Enterprise. Eine Anmeldung mit API-Schlüssel genügt dafür nicht. Über Amazon Bedrock, Google Cloud und Microsoft Foundry gibt es sie ebenfalls nicht. In Team und Enterprise muss ein Owner sie vorher einschalten. Schläft der Laptop oder bricht das Netz weg, verbindet sich die Sitzung danach von selbst wieder.

Damit niemand ständig nachsehen muss, schickt Claude seit Version 2.1.110 vom 15.04.2026 auf Wunsch Nachrichten aufs Telefon, solange Remote Control verbunden ist. Meist kommt eine, wenn eine lange Aufgabe fertig ist oder eine Entscheidung braucht.

Wann sich das lohnt

Die Mechaniken unterscheiden sich darin, was die Arbeit wieder anstößt und wo sie läuft:

• Nachsehen, solange man ohnehin arbeitet: /loop, ohne Takt mit selbst gewählten Pausen.
• Auf ein Ereignis reagieren: Monitor für ein Log oder einen CI-Lauf auf dem Rechner, ein Channel für Nachrichten von außen.
• Arbeit mit prüfbarem Ende: /goal mit einer Bedingung, die Claudes eigene Ausgabe belegen kann.
• Regelmäßig mit lokalen Dateien: eine geplante Aufgabe der Desktop-App, auf einem Rechner, der wach bleibt.
• Regelmäßig ohne eigenen Rechner: eine Routine.

Jeder dieser Läufe verbraucht Kontingent, auch wenn niemand zusieht. Routines zehren vom Kontingent des Abos wie eine Sitzung, die man selbst führt. Ein Lauf ohne Zuschauer braucht außerdem einen Blick danach. Die Doku zu Routines warnt, dass ein grüner Status in der Liste der Läufe nur heißt, dass die Sitzung ohne Fehler der Infrastruktur endete. Ob die Aufgabe gelungen ist, steht im Verlauf des Laufs.

Die zweite Ebene zeigt, wie /loop, /goal, geplante Aufgaben, Routines und Remote Control im Einzelnen arbeiten und wo sie haken.

Die erste Ebene hat die Orte sortiert: Sitzung, Desktop-App, Cloud. Hier geht es um die Stellen, an denen ein Lauf ohne Zuschauer im Alltag hakt:

• ein Zeitplan, der später feuert als gedacht,
• ein Ziel, das nach einem Fehler verschwindet,
• eine geplante Aufgabe, die an einer Rückfrage hängt,
• eine Routine, die alles darf, was ihre Connectors dürfen.

Drei Formen von /loop

Ob man Takt und Prompt angibt, entscheidet, wie sich /loop verhält (Doku zu geplanten Aufgaben (externe Seite, code.claude.com)):

Ein Takt wird in einen Cron-Ausdruck übersetzt. Erlaubt sind Sekunden, Minuten, Stunden und Tage, Sekunden rundet Claude Code aber auf die volle Minute auf, weil Cron nicht feiner zählt. Ein krummer Takt wie sieben Minuten wird auf den nächsten passenden gerundet, und Claude sagt, welchen es genommen hat.

Als Prompt taugt auch ein Skill, etwa /loop 20m /review-pr 1234. Ausgeführt werden dabei nur Skills, die Claude von sich aus aufrufen darf. Eingebaute Befehle wie /model oder /clear kommen bei einem geplanten Lauf als bloßer Text an. Was ein Skill ist und wie man ihm den Selbstaufruf verbietet, steht in Kapitel 17.

Die eingebaute Pflegeliste setzt liegengebliebene Arbeit fort, kümmert sich um Kommentare, gescheiterte CI-Läufe und Konflikte im Pull Request des Branches und räumt auf, wenn sonst nichts ansteht. Neue Vorhaben beginnt sie nicht. Unumkehrbares wie ein Push oder ein Löschen geschieht nur, wenn es etwas fortsetzt, das im Verlauf schon erlaubt wurde. Wer eine eigene Liste will, schreibt sie in .claude/loop.md im Projekt oder in ~/.claude/loop.md für alle Projekte. Änderungen daran gelten ab dem nächsten Durchlauf.

Ein Loop, der sich selbst taktet, endet auf drei Wegen. Esc löscht den nächsten Weckruf. Claude kann ihn selbst beenden, wenn die Arbeit getan ist. Und endet ein Durchlauf, ohne den nächsten zu planen, setzt Claude Code einen Ersatz-Weckruf nach etwa 20 Minuten und beendet den Loop, wenn auch dieser Durchlauf nichts plant. Ein Loop mit festem Takt läuft, bis man ihn löscht oder sieben Tage um sind.

Wann eine geplante Aufgabe feuert

Hinter einem /loop mit festem Takt und hinter jeder Erinnerung stehen drei Werkzeuge: CronCreate legt eine Aufgabe an, CronList zeigt alle, CronDelete löscht eine über ihre Kennung aus acht Zeichen. Ein Loop, der sich selbst taktet, plant seinen nächsten Durchlauf mit dem Werkzeug ScheduleWakeup und steht trotzdem in derselben Liste. Eine Sitzung hält bis zu 50 solcher Aufgaben. Zum Nachsehen genügt die Frage „Welche geplanten Aufgaben habe ich?“.

Eine fällige Aufgabe wartet, bis die laufende Antwort fertig ist, und feuert zwischen zwei Eingaben. Alle Zeiten gelten in der lokalen Zeitzone.

Dazu kommt eine absichtliche Verschiebung, damit viele Sitzungen die Schnittstelle nicht im selben Augenblick aufrufen. Eine wiederkehrende Aufgabe startet um bis zu die Hälfte ihres Abstands später, höchstens 30 Minuten. Eine stündliche Prüfung läuft also bis zu einer halben Stunde nach der vollen Stunde. Ausgenommen ist der Fünf-Minuten-Takt, den /loop 5m anlegt: Er startet jeweils nach 4 Minuten und 45 Sekunden, damit der Zwischenspeicher für den Prompt noch gilt. Eine einmalige Aufgabe zur vollen oder halben Stunde feuert bis zu 90 Sekunden zu früh. Wer es genau braucht, wählt eine krumme Minute, etwa 9:03.

War Claude mit einer langen Anfrage beschäftigt, feuert eine verpasste Aufgabe danach genau einmal, auch wenn mehrere Termine verstrichen sind. Beim Fortsetzen mit --resume oder --continue kommen Aufgaben zurück, die noch nicht abgelaufen sind. Ein Loop, der sich selbst taktet, kommt nicht zurück. Man startet ihn mit /loop neu. Wer die Sitzung in den Hintergrund schickt, nimmt die Loops mit, siehe Kapitel 21. Ganz abschalten lässt sich der Zeitplaner mit CLAUDE_CODE_DISABLE_CRON=1.

Was ein Ziel beendet

Je Sitzung gilt ein Ziel. Ein neues /goal ersetzt das alte, /goal ohne Argument zeigt den Stand, /goal clear hebt es auf (Doku zu /goal (externe Seite, code.claude.com)). Mit dem Setzen beginnt Claude sofort zu arbeiten, die Bedingung selbst ist der Auftrag. Die Bedingung darf bis zu 4.000 Zeichen lang sein. Eine Grenze nach Antworten oder Zeit schreibt man hinein, etwa „oder stopp nach 20 Antworten“.

Am Ende jeder Antwort gibt der Bewerter eins von drei Urteilen ab. Bei „noch nicht“ arbeitet Claude weiter und nimmt die Begründung als Hinweis für die nächste Antwort. Bei „erfüllt“ hebt Claude Code das Ziel auf und vermerkt den Erfolg im Verlauf. Bei „unmöglich“ hat der Bewerter entschieden, dass die Bedingung nie erfüllbar ist. Auch dann verschwindet das Ziel, mit einem Eintrag samt Grund. Antwortet Claude mehrmals hintereinander, ohne ein Werkzeug zu benutzen, hält Claude Code die Schleife an und gibt an den Menschen zurück. Das Ziel bleibt dabei gesetzt.

Fehler behandelt /goal in zwei Klassen. Vier Arten heben das Ziel auf, weil sie erst verschwinden, wenn jemand etwas tut:

• eine gescheiterte Anmeldung, wenn Claude Code die Zugangsdaten selbst verwaltet,
• ein aufgebrauchtes Guthaben,
• ein Kontext, den auch das automatische Verdichten nicht mehr freibekommt,
• ein Modell, das gerade nicht verfügbar ist.

In der Desktop-App und in einer Cloud-Sitzung verwaltet der Host die Zugangsdaten. Dort bleibt das Ziel nach einer gescheiterten Anmeldung stehen, denn der Host stellt den Zugang selbst wieder her. Nach jedem anderen Fehler bleibt das Ziel stehen. Seit Version 2.1.269 vom 11.09.2026 versucht es Claude Code in einer interaktiven Sitzung nach einer Überlastung oder einem Ver­bin­dungs­ab­bruch selbst wieder. Nach drei Versuchen pausiert das Ziel. Bei einer Grenze der Nutzung pausiert es sofort. Es läuft weiter, wenn die Sitzung nach dem Zurücksetzen der Grenze von selbst weitermacht.

Laufen am Ende einer Antwort noch Subagents oder Befehle im Hintergrund, wartet der Bewerter. Damit ein Ziel dabei nicht ewig wartet, meldet sich Claude Code nach 30 Minuten und fragt nach dem Stand der laufenden Arbeit. Danach werden die Abstände länger, eine Stunde, dann alle zwei Stunden. In einer Sitzung ohne neue Eingabe startet Claude Code höchstens drei solcher Nachfragen je Ziel. CLAUDE_CODE_GOAL_CHECKIN_MINUTES verschiebt den ersten Abstand, der Wert 0 schaltet das Nachfragen und die automatischen Wiederholungen ab.

Beim Fortsetzen einer Sitzung kommt ein offenes Ziel zurück, auf jedem Weg von --continue bis zur Auswahlliste. Zähler, Uhr und Verbrauch beginnen dann neu. Mit -p läuft ein Ziel in einem einzigen Aufruf bis zum Ende, das eignet sich für Skripte. Die Doku rät dann zu --output-format stream-json --verbose, sonst sieht ein langer Lauf bis zur letzten Antwort aus, als hinge er.

Technisch ist /goal ein Stop-Hook mit einem Prompt, der nur für die laufende Sitzung gilt. Daraus folgen zwei Dinge. Wo Hooks abgeschaltet sind, etwa mit disableAllHooks, gibt es auch kein /goal, und der Befehl sagt das. Und wer dieselbe Prüfung in jeder Sitzung will, schreibt einen eigenen Stop-Hook in die Einstellungen, siehe Kapitel 18. Die Kosten des Bewerters sind laut Doku meist gering gegenüber denen der eigentlichen Arbeit.

Geplante Aufgaben in der Desktop-App einrichten

Lokale geplante Aufgaben gibt es in der Desktop-App ab Version 1.1.5368. Man legt sie im Reiter Code unter Scheduled mit „New task“ an. Unter Advanced settings schaltet man Only on this computer ein, damit sie auf dem eigenen Rechner läuft. Dazu gehören Name, Anweisung, Ordner und Zeitplan. Zur Wahl stehen stündlich, täglich, werktags und wöchentlich. Im Formular zum Bearbeiten kommen Manual und Custom dazu, also ein Start nur von Hand und ein eigener Cron-Ausdruck. Der Cron-Ausdruck darf höchstens einmal je Stunde auslösen. Einen kürzeren Takt oder einen einzelnen Lauf bestellt man in einer Sitzung in normaler Sprache. Wie die Desktop-App sonst arbeitet, steht in Kapitel 30.

Solange die App offen ist, sieht sie jede Minute nach, ob eine Aufgabe fällig ist, und startet dann eine frische Sitzung. Jede Aufgabe startet ein paar Minuten nach ihrer Zeit, und zwar immer mit demselben Versatz. Gegen den Schlaf im Leerlauf hilft der Schalter „Keep computer awake“ in den Einstellungen. Ein zugeklappter Deckel schickt den Rechner trotzdem schlafen.

Weil die App versäumte Läufe beim Aufwachen nachholt, kann eine Aufgabe zu einer ganz anderen Zeit laufen als geplant. Die Doku nennt das Beispiel einer Aufgabe für 9 Uhr, die um 23 Uhr läuft, weil der Rechner den Tag verschlafen hat. Sie rät deshalb, die Zeit in die Anweisung selbst zu schreiben, etwa: Prüfe nur die Commits von heute, und nach 17 Uhr fasse zusammen, was ausgefallen ist.

Zwei Einstellungen entscheiden, ob eine Aufgabe ohne Zuschauer durchläuft:

• Rechte: Jede Aufgabe hat ihren eigenen Modus. Im manuellen Modus hält ein Lauf an jeder Rückfrage an, bis jemand sie beantwortet. Die Doku rät, eine neue Aufgabe einmal mit „Run now“ zu starten und jede Rückfrage mit „always allow“ zu beantworten. Spätere Läufe übernehmen diese Freigaben.
• Arbeitsstand: In der Voreinstellung arbeitet eine Aufgabe im Ordner, wie er gerade ist, samt Änderungen, die noch nicht committet sind. Einen eigenen Worktree je Lauf wählt man nach dem Anlegen im Formular zum Bearbeiten. Angeboten wird er nur, wenn der Ordner ein Git-Repository ist.

Die Anweisung jeder Aufgabe liegt als SKILL.md unter ~/.claude/scheduled-tasks/<name>/. Zeitplan, Ordner und Modell ändert man im Formular. Eine laufende Aufgabe kann ihren eigenen Zeitplan über ein Werkzeug namens update_scheduled_task umstellen, etwa früher prüfen, sobald ein Release-Branch auftaucht.

Routines einrichten

Eine Routine läuft selbstständig. Der Prompt muss deshalb für sich allein stehen und sagen, was zu tun ist und woran man Erfolg erkennt (Doku zu Routines (externe Seite, code.claude.com)). Jedes gewählte Repository wird bei jedem Lauf frisch geklont. Änderungen landen auf Branches mit dem Präfix claude/, sofern der Prompt keinen anderen Branch nennt. Was die Sitzung im Netz erreicht, legt die Cloud-Umgebung fest. Die Vorgabe erlaubt nur eine Liste üblicher Paketquellen und Entwicklerdienste.

Beim Anlegen sind alle verbundenen Connectors ausgewählt. Claude darf während des Laufs jeden eingebundenen Connector benutzen, auch schreibend. Ob ein Lauf vorher nachfragt, regelt der Auto-Modus, in dem er startet. Was die Routine nicht braucht, nimmt man deshalb heraus. Ein MCP-Server, den man lokal mit claude mcp add eingerichtet hat, liegt auf dem eigenen Rechner. Für eine Routine richtet man ihn als Connector im Konto bei claude.ai ein, bei einer Routine mit nur einem Repository auch in einer eingecheckten .mcp.json. Läuft die Routine als Threads eines Projects, bleibt nur der Weg über den Connector.

In einem Project kann ein Lauf auch einen Thread fortsetzen. Er behält dann den Rechtemodus, in dem der Thread gerade steht. Ein Artifact veröffentlicht ein Lauf im Auto-Modus ohne Rückfrage, sobald der Klassifikator es zulässt. Ein neues Artifact sieht zunächst nur man selbst.

Drei Auslöser lassen sich kombinieren:

• Zeitplan: stündlich, täglich, werktags, wöchentlich oder einmal zu einem festen Zeitpunkt. Einen eigenen Cron-Ausdruck setzt /schedule update im Terminal. Der kürzeste Abstand ist eine Stunde. Ein Lauf genau zur vollen Stunde kann einige Minuten später starten, 9:07 ist pünktlicher als 9:00.
• API: Jede Routine bekommt eine eigene Adresse, an die man mit einem Token einen POST schickt. Die Antwort enthält die Adresse der neuen Sitzung. Mitgeschickter Text kommt als nicht vertrauenswürdige Angabe an. Der gespeicherte Prompt muss ausdrücklich sagen, dass Claude ihn auswerten soll. Die Schnittstelle läuft unter einem Beta-Header, Form und Grenzen können sich noch ändern.
• GitHub: ein Pull Request oder ein Release, mit Filtern nach Autor, Branch, Label oder Entwurfsstatus. Dafür muss die GitHub-App von Claude im Repository installiert sein. Jedes Ereignis startet eine eigene Sitzung.

Eine Routine gehört dem eigenen Konto bei claude.ai. Kollegen sehen sie nicht, und ihre Läufe zählen auf das eigene Kontingent. Ist es aufgebraucht, laufen Routines nur weiter, wenn zusätzliches Guthaben eingeschaltet ist. Sonst werden Läufe abgelehnt, bis das Fenster zurückgesetzt ist. Unabhängig davon gilt für jede Art des Starts eine Obergrenze je Stunde.

Fehlt die Verbindung zu GitHub, lässt eine Routine ihre Läufe bis zu 72 Stunden lang aus. Steht die Verbindung in dieser Zeit wieder, macht sie von selbst weiter, sonst schaltet sie sich ab. In Team und Enterprise kann ein Owner Routines für alle abschalten.

/schedule im Terminal braucht eine Anmeldung mit einem Abo von claude.ai. Mit einem API-Schlüssel, über Amazon Bedrock oder in einer Cloud-Sitzung gibt es den Befehl nicht. Über die Webseite lassen sich Routines trotzdem anlegen, solange die Organisation sie erlaubt. /schedule list zeigt alle Routines, /schedule run startet eine sofort. Ab Version 2.1.227 beantwortet /schedule auch eine Frage wie „warum hat meine nächtliche Prüfung nichts getan?“: Claude liest dann die letzten Läufe und erklärt sie.

Remote Control im Alltag

Claude Code startet Remote Control auf drei Wegen. claude remote-control ist der Servermodus: Der Prozess wartet im Terminal auf Verbindungen und kann mehrere Sitzungen bedienen, in der Voreinstellung bis zu 32. Mit --spawn worktree bekommt jede davon einen eigenen Worktree. claude --remote-control startet eine gewöhnliche Sitzung, die man zusätzlich aus der Ferne erreicht.

/remote-control verbindet eine laufende Sitzung samt ihrem bisherigen Verlauf. In der Desktop-App und in VS Code gibt es denselben Befehl. Ein QR-Code im Terminal öffnet die Sitzung direkt in der Claude-App.

Wer jede Sitzung verbinden will, schaltet in /config die Verbindung für alle Sitzungen ein, als Einstellung remoteControlAtStartup. Eine Datei im Repository kann die Verbindung nur abschalten. So schaltet ein eingecheckter Schalter Remote Control nicht für alle ein, die das Repository öffnen. Die Verbindung läuft über das eigene Konto, niemand sonst bekommt Zugriff.

Was das Telefon zeigt, ist das Gespräch im Terminal. Dazu gehören Subagents und Workflows im Hintergrund. Hält man einen davon auf dem Telefon an, endet er auch auf dem Rechner.

Den Effort-Regler auf dem Telefon setzt Claude Code seit Version 2.1.234 um, eine Modellwahl vom Telefon seit 2.1.238. Die Ansicht der Änderungen zeigt den Diff des Branches. Befehle, die nur im Terminal laufen, etwa /plugin oder /resume, gehen vom Telefon aus nicht. Rückfragen nach einer Erlaubnis bleiben offen, bis jemand antwortet.

Seit der Woche vom 17. bis 21.08.2026 erscheint jeder Rechner, auf dem claude remote-control läuft, als Karte oben im Reiter Code der Claude-App. Ein Tipp darauf startet dort eine neue Sitzung in einem gewählten Ordner (Wochenbericht (externe Seite, code.claude.com)).

Bricht das Netz weg, verhält sich eine gewöhnliche Sitzung geduldig: Sie arbeitet lokal weiter und verbindet sich wieder, sobald das Netz zurück ist. Der Servermodus gibt nach etwa zehn Minuten auf und beendet sich. Nach einem Halt mit Ctrl+C holt claude remote-control im selben Ordner die Sitzungen zurück, etwa vier Stunden lang. Wer Claude Code auf einem entfernten Rechner über SSH startet, legt die Sitzung in tmux oder screen, damit sie das Trennen der Verbindung übersteht.

Zur Sicherheit nennt die Doku drei Punkte. Der Rechner baut nur Verbindungen nach außen auf und öffnet keinen Port. Solange Remote Control verbunden ist, liegt der Verlauf der Sitzung auf Servern von Anthropic, samt Nachrichten, Antworten und Werkzeugaufrufen. Organisationen mit Zero Data Retention oder der HIPAA-Konfiguration können Remote Control gar nicht einschalten. Wer das Telefon zusätzlich absichern will, verlangt vertrauenswürdige Geräte: Jedes Gerät wird einmal registriert, und die letzte Anmeldung darf höchstens 18 Stunden zurückliegen. Ist sie älter, genügt eine Bestätigung mit Face ID, Touch ID, Windows Hello oder einem Passkey. Diese Funktion heißt Trusted Devices und ist eine Beta. In Team und Enterprise schaltet ein Owner sie für die Organisation ein, in Pro und Max jeder selbst.

Nachrichten aufs Telefon

Push-Nachrichten setzen Remote Control voraus und die Claude-App mit demselben Konto. In /config stehen zwei Schalter. Der eine erlaubt Nachrichten, wann immer Claude es für richtig hält, der andere Nachrichten zu Rückfragen und offenen Fragen. Mehr lässt sich nicht einstellen. Eine Nachricht lässt sich auch im Prompt bestellen, etwa „sag Bescheid, wenn die Tests durch sind“.

Solange man im verbundenen Terminal tippt oder es im Vordergrund hat, schickt Claude Code keine Nachricht. Seit Version 2.1.181 vom 17.06.2026 lässt sich das auf jede Zeit am Rechner ausdehnen. Die Variable CLAUDE_CLIENT_PRESENCE_FILE nennt eine Datei, und solange sie existiert, bleibt das Telefon still (Versionsliste (externe Seite, code.claude.com)). Die Doku schlägt vor, die Datei beim Entsperren des Bildschirms anzulegen und beim Sperren zu löschen.

Endet das Kontingent mitten in einem langen Lauf, wartet die Sitzung seit Version 2.1.234 vom 17.08.2026 und macht nach dem Zurücksetzen der Grenze von selbst weiter. Abschalten lässt sich das in /config. Das gilt in einer interaktiven Sitzung mit einem Abo von claude.ai, und die Sitzung muss dafür offen bleiben (Doku zum interaktiven Modus (externe Seite, code.claude.com)). Ein Ziel mit /goal setzt dann ebenfalls wieder ein. Wie Projects mit dieser Grenze umgehen, steht in Kapitel 22.

Ein langer Lauf hat drei Teile. Ein Auslöser setzt die Arbeit wieder in Gang, ein Ort führt sie aus, und über einen Kanal sieht ein Mensch zu. Diese Ebene ordnet die Funktionen nach diesen drei Teilen, zeigt, was nach einem Absturz oder Neustart davon übrig ist, und stellt Claude Code neben Codex.

Wie die Funktionen dazukamen

Die Tabelle zeigt, wann die Bausteine dieses Kapitels erschienen. Versionen mit Datum stammen aus der Versionsliste (externe Seite, code.claude.com), die Kalenderwochen aus den Wochenberichten zu KW 15 (externe Seite, code.claude.com), KW 16 (externe Seite, code.claude.com) und KW 34 (externe Seite, code.claude.com).

Zwei Wendepunkte stehen darin. Mit Routines im April 2026 bekam wiederkehrende Arbeit einen Ort in der Cloud, der weder offene Sitzung noch eingeschalteten Rechner braucht. Mit /goal im Mai genügte ein Befehl, damit ein zweites Modell entscheidet, wann die Arbeit fertig ist. Über einen Stop-Hook mit Prompt in den Einstellungen ging das schon seit Version 2.0.30 vom 30.10.2025.

Vor Version 2.1.234 hatte /goal eine Lücke: Ein Ziel, das auf Hintergrundarbeit wartete, wartete unbegrenzt, bis jemand zurückkam. Seither fragt Claude Code nach 30 Minuten nach.

Ob das Zeichen & aus Version 2.0.45 noch wirkt, sagt die Doku nicht. Auch die Übersicht der Befehle und die Seite zur Bedienung im Terminal führen es nicht.

Takt, Ereignis, Ziel und Stop-Hook

Die Doku zu /goal (externe Seite, code.claude.com) vergleicht drei Wege, eine Sitzung zwischen zwei Eingaben am Laufen zu halten, danach, was die nächste Antwort auslöst und wann Schluss ist:

• /goal: Die nächste Antwort beginnt, wenn die vorige fertig ist oder in einer interaktiven Sitzung eine Nachfrage oder Wiederholung fällig wird. Schluss ist, wenn ein Modell die Bedingung erfüllt sieht oder für unmöglich hält. Schluss ist außerdem, wenn eine Antwort an einem Fehler scheitert, den man selbst beheben muss, oder wenn man /goal clear eingibt.
• /loop: Die nächste Antwort beginnt, wenn ein Zeitabstand vergangen ist. Schluss ist, wenn man ihn beendet oder Claude die Arbeit für erledigt hält.
• Stop-Hook: Die nächste Antwort beginnt, wenn die vorige fertig ist. Schluss ist, wenn das eigene Skript oder der eigene Prompt es entscheidet.

/goal und ein Stop-Hook greifen beide nach jeder Antwort. Der Unterschied liegt in der Reichweite. /goal gilt für eine Sitzung, der Hook steht in den Einstellungen und gilt in jeder Sitzung in deren Bereich. Der Hook kann außerdem ein Skript fahren, dessen Urteil nicht von einem Modell abhängt. Wie das aussieht, steht in Kapitel 18.

Auto-Modus und /goal ergänzen einander. Der Auto-Modus nimmt die Rückfragen vor einzelnen Werkzeugen weg, /goal die Rückfrage vor der nächsten Antwort. Über das Ende entscheidet bei /goal ein frisches Modell, das an der Arbeit selbst unbeteiligt ist. Darauf baut Vibe-Coding / Agentic Engineering, Kapitel 07 auf.

Für Ereignisse von außen nennt die Doku zu Channels (externe Seite, code.claude.com) vier Nachbarn:

• Eine Cloud-Sitzung arbeitet in einer frischen Umgebung.
• Claude in Slack startet eine Cloud-Sitzung aus einem Chat.
• Einen gewöhnlichen MCP-Server fragt Claude während der Arbeit ab.
• Remote Control steuert die eigene Sitzung aus der Ferne.

Ein Channel schließt die Lücke dazwischen: Er bringt ein Ereignis in die Sitzung, die schon läuft und die Dateien offen hat. Für Ereignisse auf dem eigenen Rechner reicht oft Monitor. Seit Version 2.1.105 vom 13.04.2026 kann auch ein Plugin solche Beobachter mitbringen, die beim Start der Sitzung oder beim Aufruf eines Skills anlaufen.

Was nach einem Neustart übrig bleibt

Ein langer Lauf übersteht selten jede Unterbrechung. Was zurückkommt, hängt am Mechanismus:

• Aufgaben aus CronCreate: Beim Fortsetzen kommen sie zurück, außer abgelaufenen wiederkehrenden und einmaligen, deren Zeit vorbei ist. Ein selbst getakteter Loop kommt nicht zurück, und Befehle oder Beobachtungen im Hintergrund auch nie.
• Ein offenes Ziel: kommt auf jedem Weg des Fortsetzens zurück, mit zurückgesetzten Zählern. Seit Version 2.1.274 vom 17.09.2026 auch nach einem Verdichten des Verlaufs.
• Eine Cloud-Sitzung: hält nach einer Weile ohne Aktivität an, und ihre virtuelle Maschine wird abgebaut. Beim Öffnen entsteht eine neue. Der Verlauf ist wieder da. Subagents, Befehle im Hintergrund und der nächste Weckruf eines selbst getakteten Loops sind verloren. Geht ein Weckruf bei einem Neustart des Containers verloren, bleibt die Sitzung liegen, ohne dass Claude davon erfährt. Version 2.1.290 hatte das behoben, 2.1.293 vom 07.10.2026 nahm die Korrektur zurück.
• Der Servermodus von Remote Control: holt seine Sitzungen nach einem Halt etwa vier Stunden lang zurück. Stürzt eine einzelne Sitzung ab, genügt seit Version 2.1.238 eine Nachricht vom Telefon, und der Server bedient sie wieder (Doku zu Remote Control (externe Seite, code.claude.com)).
• Eine geplante Aufgabe der Desktop-App: holt nach dem Aufwachen genau einen versäumten Lauf nach.
• Eine Routine: fängt mit jedem Lauf in einer frischen Sitzung an. Fehlt die Verbindung zu GitHub, setzt sie bis zu 72 Stunden aus.

Die Versionsliste der letzten Wochen zeigt, wie viel Arbeit in diesen Übergängen steckt. Allein Version 2.1.290 vom 05.10.2026 behebt mehrere solche Fälle. Geplante Aufgaben kamen vorher nach einem Verdichten beim Fortsetzen still nicht zurück. Die Korrektur greift erst für Verdichtungen ab dieser Version. Im Vordergrund gesetzte Aufgaben feuerten nach einer Übergabe in den Hintergrund nie. Wer einen langen Lauf auf eine ältere Version baut, prüft deshalb nach einer Unterbrechung, ob sein Loop noch steht. /usage zeigt seit Version 2.1.243 je Loop, wie oft er lief und was er verbraucht hat.

Eingaben von außen sind Daten

Je länger ein Lauf ohne Mensch arbeitet, desto mehr Eingaben kommen von außen: ein Webhook, eine Chat-Nachricht, ein Ereignis auf GitHub. Claude Code behandelt sie an mehreren Stellen ausdrücklich als Daten.

Der Text, den ein Aufruf an eine Routine mitschickt, kommt in einem eigenen Block an, der ihn als nicht vertrauenswürdig kennzeichnet. Wer das Token erbeutet, kann also Text schicken. Als Anweisung wirkt er nur, wenn der gespeicherte Prompt das vorsieht.

Umgekehrt gilt der gespeicherte Prompt als Auftrag der Sitzung. Eine Aktion während des Laufs kann er nicht freigeben. Bis Version 2.1.214 vom 18.07.2026 lehnte Claude den gespeicherten Prompt manchmal als nicht vertrauenswürdige Eingabe ab (Versionsliste (externe Seite, code.claude.com)). Seit Version 2.1.183 vom 19.06.2026 zählen auch geplante Aufgaben und Webhooks in der Sitzung als Meldung einer Aufgabe statt als Eingabe über die Tastatur. Eine wartende Aktion können sie deshalb nicht mehr freigeben.

Bei Channels liegt die Grenze bei der Liste erlaubter Absender. Jeder Channel führt eine solche Liste, und Nachrichten anderer Absender verwirft er still. Leitet ein Channel Rückfragen weiter, darf jeder Absender auf dieser Liste Werkzeugaufrufe in der Sitzung freigeben.

Damit ein Server Nachrichten schickt, muss er beim Start mit --channels genannt sein, auch wenn er schon in .mcp.json steht. In Team und Enterprise sind Channels gesperrt, bis ein Owner sie freischaltet (Einstellung channelsEnabled). Admins können die erlaubten Plugins mit allowedChannelPlugins festlegen. Pro und Max ohne Organisation überspringen diese Prüfung.

Für unbeaufsichtigte Läufe nennt die Doku zu Channels den Schalter --dangerously-skip-permissions. Sie schränkt sofort ein: nur in Umgebungen, denen man vertraut. Wer eine Sitzung so öffnet und sie zugleich für Nachrichten von außen erreichbar macht, gibt jedem Absender auf der Liste einen Agenten in die Hand, der kaum noch nachfragt. Welche Rechte ein Agent haben sollte, behandelt Kapitel 16.

Was Codex anders löst

Auch Codex von OpenAI kennt ein Ziel als Befehl. Im Codex CLI startet /goal einen Zielmodus (Doku zu langen Läufen (externe Seite, learn.chatgpt.com)). In der Desktop-App von ChatGPT steht das Ziel in einer Fortschrittszeile, die es anhalten, fortsetzen, bearbeiten oder löschen lässt. Die Doku von Claude Code beschreibt für /goal drei Handgriffe: setzen, abfragen, löschen. Einen Handgriff, der ein Ziel von Hand anhält und später unverändert fortsetzt, nennt sie nicht. Anhalten lässt Claude Code ein Ziel dort selbst: nach Fehlern, an einer Grenze der Nutzung oder wenn Claude mehrmals hintereinander ohne Werkzeug antwortet. Eine geänderte Bedingung setzt ein neues Ziel, das das alte ersetzt.

Für lokale Arbeit rät OpenAI zu einem Schalter, der den Mac während eines Laufs wach hält. Die Desktop-App von Claude hat mit „Keep computer awake“ einen ähnlichen Schalter gegen den Schlaf im Leerlauf. Einen zugeklappten Deckel hält er laut Doku nicht auf. In der Cloud bekommt bei Codex jede Aufgabe einen eigenen Arbeitsbereich, der auch bei schlafendem Rechner weiterarbeitet (Doku zu Codex Cloud (externe Seite, learn.chatgpt.com)). Wie Codex und Claude Code sich sonst unterscheiden, steht in Kapitel 01.

Offen sind drei Punkte. Routines und Channels sind Research Previews, ihre Grenzen und Schnittstellen können sich noch ändern. Selbst betriebene Runner, auf denen Cloud-Sitzungen und Routines im eigenen Netz laufen, beschreibt Kapitel 29. Und Dispatch, das Aufgaben vom Telefon an die Desktop-App schickt, beschreibt Kapitel 30.