/goal: Der sechsstündige Codex-Run, der eine fünfstündige Pause überlebt hat
TL;DR
/goalist in Codex CLI v0.128.0 am 30. April 2026 als benanntes Headline-Feature erschienen.- Es führt persistierte Ziele ein: ein Zielzustand, der Terminal-Neustarts, Laptop-Schlaf und mehrstündige Pausen überlebt, ohne dass neu geprompt werden muss.
- Runtime continuation bedeutet, dass Codex beim Fortsetzen eine Developer Message injiziert, statt zu warten, bis du etwas tippst.
- Ich habe eine echte Session auf einem TypeScript-Monorepo durchgeführt. Wanduhrzeit: etwa 6 Std. 44 Min. Tatsächliches Modell-Compute: etwa 41 Minuten. Abschlussstatus:
TASK_COMPLETE. - Die Session hat rund 6,8M kumulative Input-Tokens verbraucht, bei einer Cache-Trefferquote von ~94 %. Auto-Context-Compaction hat einmal ausgelöst, konfigurierbar über
model_auto_compact_token_limit.
Ich hatte nicht vor, Codex über Nacht laufen zu lassen. Ich habe eine Session um 21:19 Uhr Berliner Zeit am 30. April gestartet, einen Turn 57 Sekunden lang beobachtet, dann den Laptop zugeklappt und bin ins Bett gegangen. Als ich fünfeinhalb Stunden später zurückkam, lief /goal bereits wieder. Es hatte genau dort weitergemacht, wo es aufgehört hatte. Ich hatte nichts neu geprompt.
Das ist das, was an /goal nicht aus einem Changelog-Eintrag hervorgeht. Es ist nicht einfach ein neuer Befehl. Es ist ein anderer Vertrag zwischen dir und dem Agenten.
Was am 30. April ausgeliefert wurde
Codex CLI v0.128.0 (getaggt rust-v0.128.0) ist am 30. April 2026 erschienen. Die Überschrift aus den Release Notes: “Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls for create, pause, resume, and clear.”
Dieser eine Satz steckt viel drin, also zerlege ich ihn.
Persistierte Ziele sind die Kernidee. Frühere Codex-Sessions waren flüchtig. Terminal schließen, Thread verloren. /goal speichert das aktive Ziel im App-Server-Zustand, sodass es den Prozess überlebt.
App-Server-APIs ist die Mechanik hinter dieser Persistenz. Codex spricht jetzt mit einer lokalen Server-Schicht, die den Zielzustand verfolgt.
Model tools bedeutet, dass das Modell selbst Werkzeuge bekommt, um mit dem Ziel-Lebenszyklus zu interagieren. Es kann den Abschluss signalisieren, eine Fortsetzung anfordern und den Zielzustand als Teil seines Denkens inspizieren.
Runtime continuation ist das Verhalten, das ich in jener Nacht beobachtet habe. Wenn du fortsetzt (oder wenn Codex erkennt, dass die Session wieder aktiv ist), injiziert es eine Developer Message, die das Modell auffordert, weiterzuarbeiten. Du musst nichts tippen.
TUI-Controls runden die Oberfläche ab. Das Terminal-UI bekommt explizite Create-, Pause-, Resume- und Clear-Aktionen für die Zielverwaltung. Du kannst ein laufendes Ziel absichtlich pausieren, nicht nur durch Zuklappen des Deckels.
Der Rest von v0.128.0 ist eine kurze Erwähnung wert. Scrollback Reflow funktioniert jetzt beim Terminal-Resize, statt dass der Text durcheinander gerät. Ein neuer codex update-Befehl übernimmt CLI-Self-Updates. Der Composer zeigt Plan-Mode-Hinweise, wenn ein Task ein guter Kandidat für Planung erscheint. TUI-Keymaps sind jetzt konfigurierbar. Permission Profiles sind erweitert. Das --full-auto-Flag ist zugunsten expliziter Approval Profiles deprecated. Die Desktop-App hat in derselben Woche ebenfalls Verbesserungen bekommen, aber der Fokus dieses Posts liegt auf der CLI. Plan Mode selbst erschien früher, in v0.122.0 am 20. April 2026. /goal baut auf diesem Fundament auf.
Was /goal tatsächlich macht
Die grundlegende Mechanik ist unkompliziert. Du tippst /goal gefolgt von deinem Prompt. Codex speichert das Ziel und beginnt zu arbeiten. Wenn die Session unterbrochen wird (Netzwerkausfall, zugeklappter Laptop, bewusste Pause), bleibt das Ziel bestehen. Wenn die Session zurückkehrt, setzt Codex automatisch über Runtime continuation fort.
Das Modell signalisiert den Abschluss mit TASK_COMPLETE oder dem task_complete-Tool. Bis das passiert, bleibt das Ziel aktiv.
Was das wirklich von einer langen --continue-Session unterscheidet, ist die Persistenz-Schicht. Vor /goal bedeutete ein geschlossenes Terminal eine tote Session. Du konntest Kontinuität annäherungsweise herstellen, indem du sorgfältig Context-Dateien verwaltet und Prompts neu injiziert hast. Das ist im Grunde das, was der Ralph Wiggum Loop auf improvisierte Weise macht. /goal macht Kontinuität zu einem First-Class-Feature.
Ein paar Konfigurationsschalter sind hier relevant. In ~/.codex/config.toml setzt der Schlüssel model_auto_compact_token_limit den Schwellenwert für automatische Context-Compaction. Der [features]-Block ist, wo Feature-Flags leben. Der Schlüssel model_reasoning_effort setzt den Reasoning Effort für die Session. Wenn du hands-off autonome Runs willst, musst du außerdem approval_policy und sandbox_mode korrekt konfigurieren. Dazu komme ich noch.
Das TUI ändert sich ebenfalls. Du bekommst sichtbaren Zielzustand. Du kannst ein laufendes Ziel absichtlich pausieren, ohne den Prozess zu beenden. Resume nimmt es mit Runtime continuation wieder auf.
Ein echter sechsstündiger Run
So sah eine echte Session tatsächlich aus.
Das Projekt war ein TypeScript-Monorepo, an dem ich arbeite. Ein Voice-Interview-System mit mehreren End-to-End-Szenarien, die unter einem definierten Satz von Bedingungen korrekt funktionieren müssen.
Ich führe Codex mit approval_policy = "never" und sandbox_mode = "danger-full-access" für autonome /goal-Sessions aus. Diese beiden Einstellungen sind die Voraussetzung für hands-off lange Runs: Das Modell hält nicht an, um nach Erlaubnis zu fragen, und hat vollen Filesystem-Zugriff für seine Arbeit. Das ist nur vernünftig in einem vertrauenswürdigen Projektverzeichnis mit sauberem Git-Stand zu Beginn.
Der /goal-Prompt war rund 600 Wörter lang. Ich habe ihn mit einem strukturierten Ansatz geschrieben: XML-artige Blöcke, die das Ziel organisieren, eine explizite Leseliste von zehn oder mehr Dateien, die das Modell zuerst konsultieren soll, Arbeitsregeln (Git-Status vor Bearbeitungen prüfen, rg gegenüber grep bevorzugen, apply_patch verwenden), einen done_when-Vertrag mit vier konkreten Erfolgskriterien und explizite Anti-Pattern-Fences. Eine davon: “Keine String-Matching-Patches hinzufügen, um ein Transcript zu bestehen.” Wer an Voice-Systemen gearbeitet hat, weiß, warum dieser Fence existieren muss.
Einen solchen Prompt zu schreiben ist selbst eine Aufgabe. Wenn du sehen willst, wie ich Prompt-Design für diese Art von Arbeit angehe, beschreibt The Interview Method den Workflow.
Modell: gpt-5.5. Reasoning Effort: high.
Session-Timeline:
- 21:19 Uhr -
/goaleingereicht. - 21:20 Uhr - Erster Turn läuft. Ich habe 57 Sekunden zugeschaut, dann unterbrochen (
turn_aborted). - 5,5 Stunden - Laptop zugeklappt. Kein Re-Prompting.
- ~2:50 Uhr - Als ich zurückkam, hatte
/goalbereits eine Developer Message injiziert (“Continue working toward the active thread goal”) und lief. Autonom. - Context Compaction hat einmal ausgelöst, bei ungefähr 6,7M kumulativen Input-Tokens.
- Kumulative Tokens: ~6,8M Input, ~10K Output, ~2,6K Reasoning-Tokens. Cache-Trefferquote: ~94 %.
- Wanduhrzeit: 6 Std. 44 Min. Tatsächliches Modell-Compute: ~41 Minuten über alle Turns.
- Abschlussstatus:
TASK_COMPLETE. Alle vier Ziel-End-to-End-Voice-Szenarien haben die Verifikation bestanden.
Manuelles Transcript-Review fand keine Prompt-Loops, keine Liveness-Spiralen, keine vorzeitigen Abschlüsse. Das Modell hat sich methodisch durch die Szenarien gearbeitet und es für erledigt erklärt, als die Kriterien erfüllt waren.
Eine praxisrelevante Grenze ist es wert, erwähnt zu werden. Ein TTS-First-Byte-Timing-Feld, das ich erfasst haben wollte, konnte nicht gemessen werden, weil die Upstream-Bibliothek das relevante Runtime-Event nicht auslöst. Das Modell hat das ehrlich dokumentiert. Explizite Nullwerte im Artefakt, mit einer Notiz, die erklärt, warum das Feld fehlte. Es hat die Lücke nicht übertüncht. /goal kann dir einen autonomen Run geben, aber es kann nicht umgehen, was die externe Umgebung tatsächlich bereitstellt.
Die ~94 % Cache-Trefferquote ist die Zahl, die die Ökonomie zum Funktionieren bringt. 6,8M Input-Tokens klingen alarmierend, bis man erkennt, dass die tatsächlichen inkrementellen Kosten bei dieser Cache-Rate nur ein Bruchteil der Nominalzahl sind.
/goal vs. der Ralph Wiggum Loop
Ich habe vor einer Weile über den Ralph Wiggum Loop geschrieben. Geoffrey Huntley hat ihn geprägt, und sein Originalpost ist noch immer die kanonische Referenz: Die Technik ist im Wesentlichen while :; do cat PROMPT.md | claude-code; done mit Git-History als Speicher. Er löst dasselbe Kernproblem, das /goal löst: Wie hältst du einen KI-Agenten länger an etwas arbeiten als ein einzelnes Context Window erlaubt?
Die Ansätze unterscheiden sich im Charakter.
| Dimension | Ralph Wiggum Loop | /goal |
|---|---|---|
| Setup | Shell-Skript oder Plugin, externe Orchestrierung | In Codex CLI eingebaut |
| Zustandspersistenz | Git-History, Dateien auf Disk | App-Server-APIs, nativer Zielzustand |
| Resume-Verhalten | Manuelles Re-Aufrufen | Automatische Runtime continuation |
| Context-Verwaltung | Frischer Context pro Iteration (by Design) | Compaction innerhalb der Session |
| Reasoning-Kontinuität | Zustandslos zwischen Iterationen | Kontinuierlich innerhalb der Session |
| Modell | Claude Code | Codex mit gpt-5.5 |
| Gut für | Tasks, die von frischen Augen pro Durchlauf profitieren | Langfristige Tasks mit akkumulierendem Context |
Der Ralph Wiggum Loop ist genuinely nützlich. Die zustandslose Eigenschaft ist manchmal ein Vorteil: Jede Iteration geht das Problem an, ohne falsche Zwischenschlüsse weiterzutragen. Wenn das Modell verwirrt ist, startet die nächste Iteration sauber.
/goal setzt stattdessen auf Kontinuität. Das Modell baut sich über Turns hinweg ein Bild der Codebase auf und muss nicht bei jedem Durchlauf alles neu lesen. Für Tasks, bei denen Reasoning akkumuliert (Debugging einer subtilen Interaktion, Navigation durch eine komplexe State Machine), gewinnt Kontinuität. Für Tasks, die von Natur aus iterativ und konvergent sind (Tests hinzufügen, Lint fixen), funktioniert Ralphs Fresh-Context-Modell oft genauso gut.
Keines ist der richtige Default. Es sind Werkzeuge für unterschiedliche Problemformen.
Wann /goal die falsche Wahl ist
Ein paar Situationen, in denen ich nicht zu /goal greifen würde.
Undefinierte Erfolgskriterien. Der done_when-Vertrag ist nicht optional. Wenn du keine vier konkreten Erfolgskriterien schreiben kannst, bevor du startest, hat das Modell keine Möglichkeit zu wissen, wann es fertig ist. Es wird entweder TASK_COMPLETE verfrüht erklären oder unbegrenzt loopen. Schreib den Vertrag zuerst.
Explorative Arbeit. Frühe “Herausfinden, was diese Codebase macht”-Arbeit profitiert von Human-in-the-Loop. Du lernst Dinge, während das Modell sie aufdeckt. /goal ist für Ausführung, nicht für Exploration.
Sicherheitskritische Pfade. Ich laufe mit approval_policy = "never" und sandbox_mode = "danger-full-access". Diese Konfiguration ist nur in Projektverzeichnissen angemessen, denen ich vollständig vertraue. Authentifizierungssysteme, Payment-Flows, alles, was sensible Daten berührt: Approval im Loop behalten.
Unklare externe Abhängigkeiten. Wenn dein Task von einem externen System abhängt, über das du dir nicht sicher bist, finde es zuerst heraus. Das TTS-Timing-Feld, das ich oben erwähnt habe, ist die milde Version. Die teurere Version ist ein sechsstündiger Run, der in Stunde fünf gegen eine Wand läuft, weil die externe API nicht unterstützt, was du angenommen hast.
Kurze Tasks. /goal hat Overhead. Ein Task, den du in zehn Minuten interaktivem Codex abschließen kannst, wird nicht besser, wenn du ihn in ein persistiertes Ziel einwickelst. Die Komplexität lohnt sich unterhalb einer bestimmten Schwelle nicht. Meine grobe Heuristik: Wenn der Task nicht bequem zwei oder mehr separate Sessions im alten Modell umspannen würde, braucht er wahrscheinlich kein /goal.
Der Mindset Shift
Alt: Autonome KI-Runs sind Sessions, die du überwachst und bereit bist einzugreifen, wenn etwas schief läuft. Neu: Autonome KI-Runs sind Verträge, die du im Voraus schreibst, und dann aus dem Weg gehst.
Der Shift geht vom Supervisor zum Architekten. Die Qualität der /goal-Session wird fast vollständig bestimmt, bevor der erste Turn läuft. Die Prompt-Qualität, die Erfolgskriterien, die Anti-Pattern-Fences, die Leseliste. Sobald es startet, ist deine Arbeit größtenteils getan. Wenn du den Vertrag gut geschrieben hast, führt das Modell aus. Wenn nicht, rettet kein Monitoring es.
Das ist eine andere Fähigkeit als interaktives Prompting. Es ist näher daran, eine Spec zu schreiben, als ein Gespräch zu führen.
Fazit
/goal ist das Bedeutendste, was Codex seit Plan Mode ausgeliefert hat. Die Persistenz-Schicht und Runtime continuation sind das, was es in der Praxis von einer langen --continue-Session unterscheidet. Sechs Stunden und 44 Minuten Wanduhrzeit bei 41 Minuten tatsächlichem Compute sind nur möglich, weil das Modell seinen Context behalten hat, der Cache gehalten hat und das Ziel eine fünfstündige Lücke überlebt hat, ohne dass ich irgendetwas angefasst habe.
Die Ökonomie funktioniert wegen der Cache-Trefferquoten. Die Qualität funktioniert wegen Prompt-Disziplin im Vorfeld. Keines davon ist automatisch.
Das ist der erste Post in einer zweiteiligen Serie. Der begleitende Post deckt die Workflow-Seite ab: wie ich Specs und Prompts vorbereite, bevor sie /goal erreichen. Von SPEC.md zu /goal: Mein Codex + GPT-5.5 Workflow.
Quellen
