Codex CLI Worktrees: Parallele Sessions ohne Checkout-Chaos

Codex CLI Worktrees: die kürzeste funktionierende Einrichtung

Erforderlich sind Codex CLI 0.154.0, ein lokales Git-Repository und das aktivierte experimentelle Feature worktrees. Prüfen Sie zuerst die Version – ältere Binärdateien kennen das neue Flag nicht.

codex --version
npm install -g @openai/codex@0.154.0
codex features enable worktrees
codex features list

Der dauerhafte Befehl schreibt die Feature-Auswahl in die Codex-Konfiguration. Für einen einmaligen Test kann die Konfiguration unverändert bleiben; ergänzen Sie dann beim jeweiligen Aufruf --enable worktrees.

Anschließend lässt sich wahlweise eine neue isolierte Sitzung, eine Headless-Aufgabe oder ein Fork einer bestehenden Unterhaltung starten:

codex --enable worktrees --worktree "Upgrade the test runner and run its suite"
codex exec --enable worktrees --worktree "Find the flaky test and propose the smallest fix"
codex fork --enable worktrees --worktree <session-id> "Try the lower-risk implementation"

Für den interaktiven Fork ist <session-id> die Chat-ID, die /status anzeigt. Version 0.154.0 verlangt an dieser Stelle eine explizite ID. codex fork --worktree --last wird nicht akzeptiert.

Der gleiche Ablauf steht in der Terminaloberfläche zur Verfügung. Nach der Eingabe von /worktree kann die aktuelle Unterhaltung in einem neuen Checkout fortgesetzt, dort eine neue Unterhaltung begonnen oder durch die bereits von Codex verwalteten Worktrees dieses Repositorys navigiert werden.

Was Codex im Hintergrund anlegt

Ein verwalteter Worktree ist ein zweiter Checkout, der mit demselben Git-Repository verbunden ist. Das Repository lässt sich wie ein Bibliothekskatalog verstehen, den zwei Lesesäle gemeinsam nutzen: In jedem Raum können andere Seiten ausliegen, beide greifen jedoch auf dieselben Commits und Branches zurück.

Codex erstellt den neuen Checkout am committeten HEAD des Ausgangs-Repositorys, versetzt ihn in den Detached-HEAD-Zustand und bindet ihn anschließend an die neue Sitzung. Detached HEAD bedeutet, dass der Checkout direkt auf einen Commit zeigt, statt einen benannten Branch weiterzubewegen. Der ursprüngliche Checkout bleibt unverändert.

Dieser saubere Ausgangspunkt hat eine wichtige Konsequenz: Nicht committete Änderungen aus dem ursprünglichen Checkout werden nicht in die Sitzung übernommen. Dasselbe gilt für ignorierte Dateien wie eine typische .env-Datei oder das Verzeichnis node_modules. OpenAI dokumentiert das Kopieren per .worktreeinclude für lokal in der Desktop-App verwaltete Worktrees, schließt über die Kommandozeile erstellte Worktrees davon jedoch ausdrücklich aus. Beim CLI-Weg muss die für die Aufgabe benötigte Umgebung daher separat eingerichtet werden.

Wird Codex aus einem Unterverzeichnis des Repositorys gestartet, behält der verwaltete Checkout diese relative Position bei. Ein Start in apps/web führt die Sitzung beispielsweise in das entsprechende Verzeichnis apps/web des neuen Worktrees – vorausgesetzt, dieses Verzeichnis ist im committeten Stand vorhanden.

Der praxistaugliche Ablauf: vom Start bis zur Übernahme

Ein sicherer Ablauf besteht aus fünf Teilen: sauber starten, den Zielort prüfen, die Aufgabe erledigen, die Belege kontrollieren und das Ergebnis anschließend bewusst übernehmen oder verwerfen.

1. Vom tatsächlich gewünschten Commit starten

--worktree ist ein boolescher Schalter, kein Branch- oder Basis-Selektor. Ausgangspunkt ist das HEAD des angegebenen Repositorys. Wechseln Sie vor dem Start auf den vorgesehenen Basis-Branch und committen Sie alle Änderungen aus dem ursprünglichen Checkout, die für die Aufgabe erforderlich sind. Mit -C <repo-path> lässt sich Codex auf einen bestimmten lokalen Checkout ausrichten.

Eine neue Sitzung passt zu einer eigenständigen Aufgabe. Ein Fork ist sinnvoll, wenn der neue Versuch die Entscheidungen und Rahmenbedingungen der ursprünglichen Unterhaltung benötigt. Dabei bleibt das Transkript in einem neuen Chat erhalten, während die weitere Arbeit in einen isolierten Checkout wandert. So kann der erste Versuch unverändert mit dem zweiten verglichen werden.

2. Vor dem Bearbeiten den Checkout kontrollieren

Lassen Sie Codex zu Beginn pwd, git status --short und git rev-parse --short HEAD ausführen. Das Arbeitsverzeichnis sollte auf den verwalteten Pfad zeigen, der Status sauber sein und der Commit dem vorgesehenen HEAD des Ausgangs-Checkout entsprechen.

Diese kurze Kontrolle verhindert einen ebenso banalen wie teuren Fehler: hervorragende Arbeit auf der falschen Basis.

3. Nur die für diese Arbeitsspur nötige Umgebung installieren

Ein Worktree isoliert die ausgecheckten Dateien. Er erstellt keinen Container, reserviert keinen Port, klont keine Datenbank und installiert keine Abhängigkeiten. Führen Sie den üblichen Einrichtungsbefehl des Repositorys im verwalteten Checkout aus. Parallele Sitzungen benötigen getrennte Ports, temporäre Datenbanken, Cache-Verzeichnisse und Testkonten, sobald diese Ressourcen miteinander kollidieren können.

Genau hier liegt die entscheidende Grenze. Zwei saubere Git-Diffs können sich trotzdem gegenseitig stören, wenn beide Sitzungen dieselbe Entwicklungsdatenbank migrieren oder denselben Port belegen.

4. Den Diff prüfen und die richtige Unterhaltung fortsetzen

Innerhalb der Worktree-Sitzung kann /review die noch nicht committeten Änderungen prüfen. In einem anderen Terminal öffnen Sie zunächst /worktree, wählen Browse worktrees, anschließend den Checkout und dann Copy working directory. Danach folgen git -C "<worktree-path>" status --short, git -C "<worktree-path>" diff --stat und git -C "<worktree-path>" diff.

Führen Sie nicht codex review --worktree aus. Version 0.154.0 weist diese Flag-Kombination zurück. Prüfen Sie den aktiven Worktree aus seiner Sitzung heraus oder richten Sie reguläre Review-Werkzeuge auf den kopierten Pfad.

Für eine spätere Fortsetzung geben Sie /worktree ein, wählen Browse worktrees, den verwalteten Checkout und danach Resume owner thread. Ergänzen Sie codex resume nicht um --worktree: Beim Fortsetzen soll Codex in den bereits an die Sitzung gebundenen Checkout zurückkehren, statt einen weiteren anzulegen.

5. Änderungen sichern, bevor der Checkout entfernt wird

Wenn eine Änderung erhalten bleiben soll, führen Sie im Worktree die relevanten Tests aus, committen sie und kopieren die Commit-SHA. Im ursprünglichen Checkout übernimmt git cherry-pick <sha> diesen Commit auf den aktuellen Branch. Der Cherry-Pick sollte vor dem Entfernen des Worktrees erfolgen, damit der Detached Commit ein dauerhaftes Ziel erhält.

Soll die Arbeit als eigener Review-Branch weiterlaufen, führen Sie im Worktree git switch -c codex/<task> aus, erstellen einen Commit, pushen den Branch und eröffnen einen Pull Request. Git erlaubt nicht, denselben Branch gleichzeitig auch im ursprünglichen Checkout auszuchecken. Pushen Sie ihn daher aus dem Worktree oder entfernen Sie den Worktree, bevor der Branch an anderer Stelle ausgecheckt wird.

Über die CLI erstellte Worktrees werden nicht automatisch aufgeräumt. Sobald die Änderung sicher committet oder bewusst verworfen wurde, prüfen Sie, ob der Checkout sauber ist, und führen im Ausgangs-Repository git worktree remove <worktree-path> aus. Verzichten Sie auf --force. Mit git worktree prune lassen sich später verwaiste Git-Registrierungen entfernen; der Befehl ersetzt jedoch nicht die Prüfung, ob eine Sitzung den Checkout noch verwendet.

Wie sich das auf das Budget auswirkt

Das native Feature beseitigt eine kleine, aber ständig wiederkehrende Schicht aus Shell-Hilfskonstruktionen. Vor 0.154.0 mussten CLI-Nutzer einen Pfad und einen Branch anlegen oder abkoppeln, Codex in diesem Verzeichnis starten, die Zuordnung zwischen Chat und Checkout im Blick behalten und später sowohl Git- als auch Sitzungsstatus bereinigen. Das neue Flag erstellt und bindet den Checkout mit einem Aufruf; /worktree ergänzt einen repositorybezogenen Browser samt Weg zur Fortsetzung.

Für bestehende Codex-Abonnenten verursacht der Checkout keine separat ausgewiesenen Kosten. Codex Plus kostet $20 pro Monat. Der kommerzielle Agenten-Arbeitsbereich Unstoppable, der parallele Worktrees organisiert, bietet seinen kostenpflichtigen Pro-Tarif ab $19 pro Monat an; Business kostet $29 pro Nutzer und Enterprise $49 pro Nutzer. Innerhalb des bereits genutzten Abonnements deckt natives Codex damit nun die eng umrissene Aufgabe ab, Checkouts anzulegen und Sitzungen fortzusetzen.

Die übrige Kategorie kostenpflichtiger Arbeitsbereiche ersetzt das Feature nicht. Agentenübergreifende Dashboards, Port-Zuweisung, gemeinsame Umgebungseinrichtung, Testaggregation, Pull-Request-Verfolgung, Teamrichtlinien und Kostenberichte liegen weiterhin oberhalb des reinen Checkout-Mechanismus. Parallele Sitzungen greifen außerdem auf dasselbe Codex-Nutzungskontingent zu. Die treffende finanzielle Einordnung lautet daher nicht „kostenlose Parallelentwicklung“, sondern „ein Orchestrierungstool weniger, sofern Dateisolation der einzige Kaufgrund war“.

Einen breiteren Blick auf das Produkt rund um dieses Feature bietet der Codex-Test zum lokalen CLI- und Agenten-Workflow. Der frühere Überblick zu Codex CLI 0.152.0 zeigt, weshalb versionsspezifische Grenzen bei der Automatisierung im Terminal entscheidend sind.

Sieben Worktree-Aufgaben nach praktischem Nutzen

1. Riskante Abhängigkeits-Upgrades

Ein Maintainer kann ein Framework-, Paketmanager- oder Testrunner-Upgrade in einem Worktree starten, Codex Sperrdateien und Konfiguration bearbeiten lassen und die komplette Testsuite ausführen, ohne die offene Feature-Arbeit im Haupt-Checkout zu verschmutzen. Der Nutzen: eine prüfbare Upgrade-Spur, die sich ohne Stash und ohne Rollback sachfremder Änderungen verwerfen lässt.

2. Konkurrierende Umsetzungen desselben Features

Ein Tech Lead kann dieselbe Planungsunterhaltung in zwei verwaltete Worktrees forken, eine Sitzung mit dem kleinstmöglichen Patch und die andere mit einem stärker strukturellen Ansatz beauftragen. Anschließend lassen sich Diff-Größe, Tests und Migrationsrisiko vergleichen. So entsteht eine evidenzbasierte Entscheidung, ohne dass der zweite Versuch den ersten überschreibt.

3. Fehleranalyse parallel zur laufenden Produktarbeit

Wer mitten in der Entwicklung eines Features steckt, kann von einem committeten HEAD einen sauberen Worktree starten, um einen Produktionsfehler zu reproduzieren. Codex instrumentiert, testet und behebt den Fehler in dieser Spur, während das unfertige Feature unangetastet bleibt. Das Ergebnis sind weniger Notfall-Stashes und ein saubererer Hotfix-Diff.

4. Umfangreiche Codemods und Refactorings

Ein Plattformteam kann eine weitreichende Umbenennung oder API-Migration in einen eigenen Checkout verlagern, dort Formatter und Tests ausführen und die betroffenen Dateien prüfen, bevor die Änderung den Haupt-Branch erreicht. Der Vorteil ist die klare Begrenzung: generierter Änderungsballast bleibt getrennt, bis er einen Commit verdient.

5. Eine eigene Spur für Review-Korrekturen

Der Autor eines Pull Requests kann die Review-Basis committen, von diesem Stand eine isolierte Codex-Sitzung starten und Kommentare aus dem Review abarbeiten, ohne einen anderen lokal ausgecheckten Branch zu stören. Daraus entsteht eine fokussierte Korrekturserie, die bei Bedarf direkt aus dem Worktree gepusht werden kann.

6. Reproduzierbare Wartungsläufe

Ein Build Engineer kann codex exec --worktree für eine klar umrissene Aufgabe einsetzen, etwa um generierte Dateien zu aktualisieren oder einen unzuverlässigen Test zu untersuchen. Der Headless-Lauf erhält einen sauberen Checkout der getrackten Dateien und eine persistente Sitzung, die sich später inspizieren lässt. Dadurch sinkt das Risiko einer unbeabsichtigten Verunreinigung durch alles, was gerade im primären Arbeitsbaum geöffnet ist. Allerdings muss die Automatisierung Einrichtung und Bereinigung der Abhängigkeiten selbst übernehmen.

7. Sichere Orientierung im Repository

Ein neues Teammitglied kann Codex eine unbekannte Codebasis kartieren und eine kleine Dokumentations- oder Teständerung in einem verwalteten Worktree ausprobieren lassen, bevor der reguläre Checkout berührt wird. Der Gewinn ist nicht nur technischer, sondern auch psychologischer Natur: Die Erkundung hat eine sichtbare Grenze und einen einfachen Weg zum Verwerfen.

Drei Produktideen für die verbleibende Lücke

1. Die stärkste Wette: eine Worktree-Readiness-Schicht

Ein kleines lokales Tool könnte aus einem frischen verwalteten Checkout eine lauffähige, kollisionsfreie Arbeitsspur machen. Es würde den Projekt-Stack erkennen, die freigegebene Abhängigkeitsinstallation ausführen, einen Port zuweisen, eine temporäre Datenbank oder ein Schema anlegen, nur ausgewählte Secrets verfügbar machen, einen Healthcheck durchführen und den dazugehörigen Bereinigungsplan ausgeben.

Die Nachfrage ist breit: git worktree kommt auf ungefähr 9,900 US-Google-Suchen pro Monat, what is a git worktree auf weitere 590. Das native Codex-Feature übernimmt das Anlegen des Checkout, lässt die Herstellung der Laufzeitbereitschaft aber offen. Deshalb ist dies die stärkste Gelegenheit.

Die kleinste marktfähige Version benötigt ein Repository-Manifest, Befehle für Einrichtung und Abbau, Port-Reservierung, Vorlagen für Umgebungsdateien und eine Statusprüfung. Der ehrliche Haken ist die Sicherheit. Ein Tool, das Secrets kopiert oder zwei Agenten auf dieselbe Datenbank richtet, kann mehr Risiken schaffen als beseitigen. Zudem könnte OpenAI eigene Lebenszyklus-Hooks ergänzen und die Lücke verkleinern.

2. Ein agentenübergreifendes Spur-Dashboard

Ein Desktop- oder Terminal-Dashboard könnte Worktrees über Repositorys und Tools hinweg finden und pro Spur die verantwortliche Sitzung, Branch- oder Detached-Status, geänderte Dateien, Testergebnis, Codex-Nutzung, Pull Request, Speicherbedarf sowie eine sichere Aktion zum Fortsetzen oder Bereinigen anzeigen.

git worktree claude code erreicht ungefähr 480 US-Suchen pro Monat, die exakte Phrase parallel coding agents kommt auf 10. Die zweite Suchanfrage ist klein, bezahltes Verhalten ist aber sichtbar: Unstoppable verlangt für ein Produkt mit parallelen Agenten-Worktrees ab $19 pro Monat. Käufer sind Entwickler, die bereits Codex, Claude Code und gewöhnliche Terminals parallel handhaben.

Ein MVP kann vollständig schreibgeschützt bleiben: Git-Worktrees erfassen, bekannte Sitzungsmetadaten zuordnen, Status- und Testbefehle bei Bedarf ausführen und Deep-Links zu den jeweiligen Agenten anbieten. Der Haken ist die native Konkurrenz. Codex 0.154.0 kann seine eigenen verwalteten Worktrees bereits durchsuchen; ein solches Produkt muss daher mit agentenübergreifender Übersicht, Laufzeitstatus und Teamberichten überzeugen.

3. Eine Integrations- und Bereinigungsschranke

Eine Schutzschicht zwischen einer abgeschlossenen Agentenspur und dem Haupt-Branch könnte einen sauberen Status bestätigen, die vorgeschriebenen Tests ausführen, von anderen aktiven Worktrees geänderte Dateien erkennen, eine Cherry-Pick-Reihenfolge empfehlen und eine destruktive Bereinigung verweigern, solange noch nicht integrierte Commits vorhanden sind.

Die dazugehörigen Fragen zeigen sich bereits in der Suchnachfrage: git remove worktree erreicht ungefähr 390 US-Suchen pro Monat, git worktree vs branch 320 und git worktree prune 140. Diese Anfragen bündeln sich genau an dem Punkt, an dem isolierte Arbeit in gemeinsame Arbeit überführt werden muss.

Das MVP besteht aus einem lokalen Git-Befehl und einer kleinen Richtliniendatei. Es kann nützlich sein, ohne automatisch auch nur eine Zeile zu verändern. Der Haken liegt im Vertrieb: Git-Clients und CI-Anbieter können dieselben Prüfungen ergänzen. Ein eigenständiges Tool braucht deshalb herausragende Unterstützung für mehrere Coding-Agenten und unaufgeräumte reale Repositorys.

Grenzen, die die Entscheidung beeinflussen sollten

Native Worktrees sind die richtige Wahl, wenn Dateien isoliert werden müssen. Sie ersetzen keine vollständige Umgebungsisolation.

In dieser Version gibt es außerdem kein CLI-Pendant zur Handoff-Schaltfläche der Desktop-App. Code zurückzuführen bleibt eine Git-Entscheidung: committen und per Cherry-Pick übernehmen, einen Branch pushen oder die Arbeit verwerfen und den Worktree entfernen. Dieser explizite Schritt ist sinnvoll. Isolation ist gerade deshalb nützlich, weil nichts versehentlich in den Haupt-Checkout gelangen sollte.

Der nächste Schritt für Montag: Wählen Sie ein unkritisches Abhängigkeits-Update, führen Sie es mit codex --enable worktrees --worktree aus, vergleichen Sie Diff und Tests über den kopierten Checkout-Pfad, übernehmen Sie nur den akzeptierten Commit per Cherry-Pick und entfernen Sie anschließend den Worktree. Wenn rund um Ihre Repositorys ein zuverlässiger Workflow für isolierte Agenten entstehen soll, unterstütze ich Sie gern beim Entwurf des produktionsreifen Systems.