Codex Automations für Langläufer: geplante Trigger, Heartbeats und Arbeiten über Mitternacht

Wenn Sie wiederkehrende Checks, PR-Nachverfolgung, Post-Deploy-Kontrollen oder Arbeit über mehrere Tage hinweg an Codex übergeben, lautet die erste Frage nicht, ob sich das automatisieren lässt, sondern welche Art von Aufgabe wie automatisiert werden sollte. Automations machen Codex nicht zu einem permanenten Hintergrund-Agenten. Sie holen ihn zur richtigen Zeit in die richtige Begrenzung zurück, damit er genau eine klar umrissene Sache erledigt.

1. Erst prüfen, ob sich die Aufgabe überhaupt automatisieren lassen sollte

1.1 standalone/project automation: unabhängige Hintergrundjobs

Standalone-Automation und Project-Automation sind beide unabhängige Hintergrundjobs. Der Unterschied liegt im Umfang. Standalone ist nicht an ein bestimmtes Projekt gebunden; Project-Automation ist an einen Projektpfad gebunden und damit besser für wiederkehrende Arbeit rund um ein fixes Repository geeignet.

Jeder Trigger startet einen frischen Lauf. Wenn er fertig ist, landet das Ergebnis in Inbox oder Triage; wenn nichts gefunden wird, kann es automatisch archiviert werden. Typische Einsätze sind wöchentliche Dependency-Checks, tägliche Issue-Triage und planmäßige Kontrollen nach einem Deployment.

Die wichtigste Einschränkung ist die lokale Umgebung: Der Rechner mit der Codex-App muss eingeschaltet sein, die App muss laufen, und der Projektpfad muss weiter existieren. Wird der Rechner in den Ruhezustand versetzt, ausgeschaltet oder die App geschlossen, läuft nichts weiter. Für langfristiges unbeaufsichtigtes Hosting ist das nicht die richtige Ebene.

1.2 thread automation (heartbeat): periodisches Wecken im selben Thread

Thread-Automation ist ein Heartbeat-artiger periodischer Aufruf, der am aktuellen Gesprächs-Thread hängt. Der Kern ist Kontext-Erhalt: Beim Aufwachen wird das gleiche Gespräch fortgesetzt, statt ein neuer unabhängiger Lauf zu beginnen.

Das passt gut zu Post-Deploy-Logchecks, Cross-Day-Follow-up und kontinuierlicher Triage. Beispiel: Codex alle 10 Minuten die Deployment-Logs prüfen lassen, nur bei Fehlern oder Erfolgen melden und sonst still bleiben. Solche Aufgaben brauchen Kontextkontinuität, daher ist Standalone-Automation hier die schlechtere Wahl.

Heartbeat ist kein permanenter Daemon und keine Forever-Loop. Es ist ein Rhythmus aus Wecken -> Prüfen -> Melden -> Warten. Wenn die App pausiert oder geschlossen wird, endet der Heartbeat ebenfalls.

1.3 Vergleichstabelle

Dimension	standalone/project automation	thread automation (heartbeat)
Laufzeitort	Unabhängiger Hintergrund-Thread	Aktueller Gesprächs-Thread
Kontext	Bei jedem Lauf neu	Aktuelle Sitzung bleibt erhalten
Geeignete Fälle	Unabhängige Wiederholungsaufgaben, Issue-Triage, Dependency-Checks	Langläufer, kontinuierliche Triage, Deploy-Logchecks, Arbeit über mehrere Tage
Abhängigkeiten	Lokale App / Rechner / Projektpfad müssen vorhanden sein	Aktueller Thread muss gebunden bleiben
Ergebnisdarstellung	Inbox / Triage, bei nichts automatisches Archivieren	Aktuelles Gesprächsfenster
Stoppen	Automation ausschalten	App pausieren oder schließen

Die Entscheidung ist einfach: Braucht die Aufgabe Kontext? Dann Thread-Automation. Ist sie an ein bestimmtes Projekt gebunden? Dann Project-Automation; sonst Standalone-Automation.

2. Welche Aufgaben eignen sich für Automations?

Nicht jede Wiederholungsaufgabe gehört in Automations. Zuerst die Struktur der Aufgabe prüfen.

2.1 Merkmale geeigneter Aufgaben

Geeignete Aufgaben haben drei Merkmale: hohe Wiederholbarkeit, klare Regeln und verifizierbare Ergebnisse.

Hohe Wiederholbarkeit heißt: Die Aufgabe kommt regelmäßig vor und zielt jedes Mal auf ziemlich dasselbe Ergebnis. Wöchentliche Dependency-Checks, tägliche Issue-Triage und feste Kontrollen nach Deployments sind gute Beispiele. Umfang, Entscheidungskriterien und Ausgabeformat lassen sich vorher festlegen.

Regelbasierte Aufgaben lassen sich besonders gut als Prompt formulieren. Beispiel: „Prüfe die Versionen in package.json, liste Pakete mit neuen Versionen auf und gib eine Prioritätsempfehlung.“ Die Kriterien sind stabil, also muss man sie nicht jedes Mal neu sagen.

Verifizierbare Ergebnisse sind ebenfalls wichtig. Gute Automation landet in Inbox / Triage, archiviert sich bei keinem Befund automatisch und zeigt bei einem Befund klar den nächsten Schritt. So sparen Sie wirklich Zeit statt nur den Lärm zu verschieben.

2.2 Merkmale ungeeigneter Aufgaben

Ungeeignet sind Aufgaben mit vier Merkmalen: häufige menschliche Bewertung, schnell wechselnder externer Zustand, noch nicht stabiler Prompt oder Bedarf an langfristigem unbeaufsichtigtem Hosting.

Aufgaben mit häufiger menschlicher Bewertung haben oft unscharfe Grenzen. Architekturentscheidungen, komplexe Bug-Jagd und situative Abwägungen brauchen Kontext und Anpassung, daher passen sie schlecht in eine feste Automation.

Auch Aufgaben mit schnell wechselndem externem Zustand sind heikel. Echtzeit-Monitoring eines Produktionsdienstes ändert sich zu schnell und gehört eher in spezialisierte Monitoring-Tools als in Automations.

Ein noch ungetesteter Prompt sollte ebenfalls nicht sofort automatisiert werden. Erst ein paar manuelle Läufe, dann Regeln, Umfang und Ausgabe stabilisieren, und erst danach als Automation festhalten.

Langfristiges unbeaufsichtigtes Hosting ist nicht der Einsatzbereich von Project-scoped Automation. Es hängt von lokaler App, Rechner und Projektpfad ab. Wenn die Maschine weg ist, stoppt alles. Das ist keine Cloud-Hosting-Lösung.

2.3 Eignungstabelle

Aufgabentyp	Geeignet?	Begründung	Empfohlener Ansatz
Wöchentliche Dependency-Checks	Ja	Wiederkehrend, regelbasiert, verifizierbar	standalone automation oder project automation
Tägliche Issue-Triage	Ja	Kann in Inbox landen, automatisch archiviert werden, Prompt ist stabil	standalone automation oder thread heartbeat
Post-Deploy-Logchecks	Ja	Gleiches Thread-Kontext, Kontext bleibt wichtig	thread automation
Architekturentscheidungen	Nein	Häufige menschliche Bewertung nötig, Grenzen sind unscharf	manuelles Gespräch
Komplexe Bug-Jagd	Nein	Situative Anpassung nötig	manuelles Gespräch
Echtzeit-Monitoring	Nein	Externer Zustand ändert sich zu schnell	spezialisierte Monitoring-Tools
Langfristiges unbeaufsichtigtes Hosting	Nein	Project-scoped Automation hängt von lokaler Umgebung ab	CI- oder Cloud-Ansatz
Ungeprüfte Automationsflüsse	Nein	Prompt instabil, manuelle Läufe nicht konsistent	erst manuell stabilisieren

Der Ablauf ist simpel: zuerst prüfen, ob der Prompt stabil ist; dann entscheiden, ob Kontext erhalten bleiben muss; zuletzt prüfen, ob langfristiges Cloud-Hosting gebraucht wird.

3. Die erste standalone/project automation anlegen

3.1 Ablauf

1. Die Aufgabe zuerst sauber aufschreiben. Umfang, Input, Output, Erfolgskriterien und Stop-Bedingungen festlegen.
2. Die Automation-Art wählen. Unabhängige Wiederholungsarbeit bekommt Standalone-Automation; wiederholte Arbeit an einem festen Repository Project-Automation.
3. Den Laufzeitort wählen. In Git-Repos zuerst Worktree nutzen, damit der aktuelle Arbeitsbereich nicht gestört wird.
4. Die Frequenz festlegen. Minutenbasierte Jobs brauchen klare Stop-Bedingungen, sonst wecken sie endlos.
5. Zuerst ein paar Probeläufe machen. Wenn die Ausgabe stabil ist, auf die echte Frequenz hochgehen.

3.2 Worktree vs. Local Project

Laufzeitort	Isolation	Geeignet für	Risiko
worktree	Änderungen sind vom aktuellen Arbeitsverzeichnis getrennt	Aufgaben mit Dateiänderungen, Code-Schreiben oder PR-Vorschlägen	Fehler bleiben meist im Worktree und lassen sich leicht verwerfen
local project	Keine Isolation; läuft direkt im aktuellen Verzeichnis	Read-only-Checks, Report-Erzeugung, Triage	Kann Dateien beeinflussen, die Sie gerade bearbeiten

Für Git-Repos sollten Änderungsaufgaben standardmäßig in einem Worktree laufen. Local Project nur dann, wenn die Aufgabe ausdrücklich read-only, prüfend oder berichtend ist.

4. Thread-Automation (Heartbeat) anlegen

4.1 Ablauf

1. Zuerst sicherstellen, dass der aktuelle Thread بالفعل einen Langläufer bearbeitet.
2. Thread-Automation an diesen Thread binden.
3. Genau aufschreiben, was bei jedem Wakeup geprüft wird, wann gemeldet wird und wann geschwiegen werden soll.
4. Stop-Bedingungen definieren: Erfolg, Fehler, Timeout oder maximale Anzahl von Runden.
5. Erst mit niedriger Frequenz starten und prüfen, dass nichts gespammt wird, bevor die endgültige Kadenz kommt.

4.2 Beispiel für ein Heartbeat-Prompt

Prüfe die Deployment-Logs alle 10 Minuten und melde nur in diesen Fällen:

1. Ein Fehler-Signal erscheint (enthält "error", "failed" oder "exception")
2. Ein Erfolgs-Signal erscheint (enthält "deployed", "success" oder "completed")
3. Nach 30 Minuten ist der Vorgang noch nicht abgeschlossen

Meldeformat:
- Status: [in progress / success / failure]
- Wichtiger Log-Ausschnitt: [max. 3 Zeilen]
- Nächster Schritt: [falls vorhanden]

Wenn sich nichts geändert hat, schweigen.

Dieses Prompt macht Prüfbereich, Ausgabeboundary und Stop-Bedingungen eindeutig. Es muss nicht bei jedem Wakeup „Prüfung abgeschlossen“ wiederholen und sollte den No-Change-Zustand nicht in Lärm verwandeln.

5. Sicherheit: Sandbox, Approval Policy und Team-Governance

5.1 Sandbox und Approval Policy

Automations laufen standardmäßig in einer Sandbox. Die Sandbox bestimmt, welche Dateien berührt werden dürfen, ob Grenzen überschritten werden können und ob zusätzliche Freigaben nötig sind. Bei Hintergrundautomatisierung gilt: Je enger die Standardgrenze, desto besser.

sandbox-Modus	Rechtebereich	Geeignet für	Risiko
read-only	Nur lesen, kein Schreiben	Reine Inspektions- und Analyseaufgaben	Niedrig
workspace-write	Lesen/Schreiben im Workspace, externe Aktionen weiter genehmigungspflichtig	Tagesautomationen, Dateiedits, PR-Vorschläge	Mittel
danger-full-access	Unbeschränkter Systemzugriff	Isolierte Umgebungen oder sehr vertrauenswürdige Aufgaben	Hoch

Approval Policy steuert, ob bei riskanten Aktionen nach Freigabe gefragt wird.

approval policy	Verhalten	Einsatz
on-request	Bei Bedarf höhere Rechte anfragen	Etwas Autonomie, aber menschliche Kontrolle bleibt
never	Vollautomatisch ausführen, ohne nachzufragen	Automation-Skripte oder nicht interaktive Umgebungen

Die Standardempfehlung ist workspace-write + rules/allowlist, nicht full access + unattended. Letzteres ist schlicht zu weit gefasst.

5.2 Team-Governance

Teams können Sandbox und Approval über requirements.toml festziehen, damit niemand versehentlich zu viele Rechte gibt.

[agent]
approval_policy = "never"
sandbox = "workspace-write"

Die Idee ist nicht, alles zu blockieren. Die Idee ist, den Standard eng zu halten und nur bei Bedarf zu erweitern.

6. Drei direkt nutzbare Vorlagen

6.1 Wöchentlicher Dependency-Sweep

• Trigger-Frequenz: einmal pro Woche
• Laufzeitort: in Git-Repos Worktree bevorzugen
• Erfolgsoutput: upgradbare Dependencies und Prioritäten
• Stop-Bedingung: Wenn nichts upgradbar ist, mit einer kurzen Meldung beenden
• Rechtegrenze: read-only oder leichtes Reporting

6.2 Heartbeat-Follow-up nach Deploy

• Trigger-Frequenz: alle 10 Minuten, maximal 30 Minuten
• Laufzeitort: thread automation
• Erfolgsoutput: Erfolg, Fehler oder Timeout als Kurzbericht
• Stop-Bedingung: Erfolgsignal, Fehlersignal oder Timeout
• Rechtegrenze: nur Logs lesen, Produktion nicht anfassen

6.3 Tägliche Issue-/PR-Triage

• Trigger-Frequenz: einmal täglich
• Laufzeitort: standalone automation oder thread heartbeat
• Erfolgsoutput: alles, was menschliche Aufmerksamkeit braucht, in Inbox verschieben
• Stop-Bedingung: Bei nichts Neuem schweigen
• Rechtegrenze: standardmäßig workspace-write; full access vermeiden

7. Wenn die Automation scheitert, zuerst diese 6 Dinge prüfen

1. Läuft die Codex-App noch und ist der Rechner wach?
2. Existiert der Projektpfad noch, oder wurde der Worktree verschoben bzw. gelöscht?
3. Blockiert die Sandbox Schreibzugriffe oder Netzwerkoperationen?
4. Braucht die Thread-Automation wirklich Kontext-Erhalt?
5. Ist der Worktree zu voll und muss aufgeräumt werden?
6. Steht im Prompt klar, wann gestoppt und wann gemeldet werden soll?

8. FAQ-Checkliste

8.1 Ist Automations ein geplanter Job oder ein immer laufender Agent?

Eher ein geplanter oder periodisch geweckter Hintergrundjob. Bei jedem Wakeup wird geprüft, gearbeitet und berichtet, danach geht es zurück ins Warten. Keine Forever-Loop.

8.2 Was ist der Unterschied zwischen standalone/project und thread automation?

Standalone-/Project-Automation ist ein unabhängiger Hintergrundlauf, der jedes Mal neu startet und dessen Ergebnis in Inbox / Triage landet. Thread-Automation ist ein Heartbeat am selben Thread und behält den Kontext des aktuellen Gesprächs.

8.3 Welche Aufgaben passen zu Automations, welche nicht?

Geeignet sind Aufgaben, die wiederkehrend, regelbasiert und verifizierbar sind. Ungeeignet sind Aufgaben mit häufiger menschlicher Bewertung, schnell wechselndem externem Zustand oder instabilem Prompt.

8.4 Wie entscheide ich zwischen Worktree und Local Project?

Für alles, was Dateien ändern könnte, Worktree bevorzugen. Local Project nur für reine Lese- und Report-Aufgaben.

8.5 Läuft es weiter, wenn die App geschlossen wird oder der Rechner schläft?

Nein. Project-scoped Automation hängt von lokaler App, Rechner und Projektpfad ab. Wenn die App zu ist oder der Rechner schläft, stoppt es.

8.6 Wann sollte ich Computer Use einsetzen?

Nur wenn eine GUI direkt bedient werden muss und es keine API oder Web-Schnittstelle gibt. Wenn normaler Code reicht, lohnt sich Computer Use meist nicht.

8.7 Wie kontrolliere ich Kosten und Frequenz?

Frequenz nur so hoch wählen wie nötig, den Zustand mit /status prüfen, für jede Automation Stop-Bedingungen definieren und zu dichtes Polling vermeiden.

9. Fazit

Computer Use, der eingebaute Browser und Automations lösen verschiedene Ebenen desselben Problems. Automations sind dafür da, stabile, verifizierbare, wiederkehrende Arbeit im Hintergrund an Codex zu geben; Thread-Automation ist für die Nachverfolgung über mehrere Tage; Worktree und Sandbox halten das Risiko im Griff.

Die sicherste Reihenfolge ist immer dieselbe: zuerst prüfen, ob die Aufgabe überhaupt automatisiert werden sollte; dann Laufzeitort und Rechte wählen; erst danach die Frequenz feinjustieren. Erst den menschlichen Prozess zuverlässig machen, dann Codex ein Stück länger darauf laufen lassen.