Blog

Codex Worktree: Arbeitskopie für eine zweite Aufgabe

Markdown

Arbeitskopie von Codex CLI 0.155.1: experimentelles Worktree-Flag, HEAD des Quellprojekts, Überprüfung des neuen Ordners, Sicherung des Ergebnisses und sicheres Entfernen.

Vollständigen Artikel lesen

Das Wichtigste

In Codex CLI Version 0.155.1 erstellst du mit codex --enable worktrees --worktree eine separate Arbeitskopie für eine zweite Aufgabe. Die Funktion ist experimentell und standardmäßig deaktiviert: Wenn du sie nicht bereits aktiviert hast, verweigert Codex den Start mit --worktree ohne --enable worktrees. Die Kopie wird aus dem neuesten Commit des ursprünglichen Projekts (HEAD) erstellt, ohne nicht committete Änderungen, und befindet sich in einem Detached-HEAD-Zustand – ihr ist kein benannter Branch zugeordnet.

Zum Beispiel verwendest du Codex CLI, um ein Modul zu refaktorieren, als eine zweite Aufgabe hinzukommt: Tests für ein anderes Modul zu schreiben. Eine zweite Sitzung im selben Ordner zu öffnen, ist riskant: Änderungen aus der ersten und der zweiten Aufgabe können leicht durcheinandergeraten. Das Flag --worktree erstellt für die zweite Aufgabe einen separaten Ordner desselben Projekts und lässt den ersten unangetastet.

Praktische Ressourcen zur parallelen Arbeit mit Agenten: Ailoot-Dokumentation.

Was erstellt Codex mit --worktree?

In der Git-Terminologie ist ein Worktree ein zusätzlicher Arbeitsordner, der mit demselben Repository verknüpft ist: Er teilt die Commit-Historie, hat aber einen eigenen Dateibestand auf der Festplatte. In Codex CLI 0.155.1 nutzt das Flag --worktree diesen Git-Mechanismus, um eine neue Agentensitzung in einem separaten Ordner zu starten und den Ordner, in dem die erste Aufgabe bereits läuft, unangetastet zu lassen.

Die neue Arbeitskopie enthält die Dateien aus dem Commit, auf den HEAD des ursprünglichen Projekts beim Start zeigt – dem neuesten Commit und nicht dem Zeitpunkt, zu dem du zuletzt eine Datei in deinem Editor gespeichert hast. Dieser Befehl überträgt weder nicht committete Änderungen noch neue Dateien. Im Editor zu speichern ist nicht dasselbe wie in Git zu committen. Wenn der erste Ordner beim Start der zweiten Aufgabe noch nicht committete Änderungen enthält, bleiben diese nur in diesem Ordner.

Das ist weder ein Backup des gesamten Repositorys noch eine Isolation des gesamten Computers. Es ist ein zweiter Arbeitsordner desselben Projekts mit Zugriff auf denselben Branch und dieselbe Commit-Historie. Einen ähnlichen Mechanismus in einem anderen Tool findest du unter Claude Code und git worktree: parallele Aufgaben.

Vorbereitung: Version, Projektvertrauen und ein Commit

Überprüfe vor dem Start drei Dinge. Führe die Befehle im Ordner des ursprünglichen Projekts aus.

Prüfe zuerst die Version von Codex CLI. Diese Anleitung gilt für Version 0.155.1; bei anderen Versionen solltest du das Verhalten der Flags separat prüfen:

codex --version

Zweitens brauchst du ein lokales Git-Projekt, dessen HEAD auf einen vorhandenen Commit zeigt – anders gesagt: Das Repository muss mindestens einen Commit enthalten. Andernfalls gibt es keine Grundlage, aus der die Kopie erstellt werden kann.

Drittens muss die Quelle vertrauenswürdig sein: Wenn das Projekt ausdrücklich als nicht vertrauenswürdig markiert ist, schlägt der Start mit --worktree fehl, bevor die Kopie erstellt wird. Wenn du Codex CLI gerade erst einrichtest, findest du die grundlegende Vorbereitung unter Codex (OpenAI): Was es ist und wie du loslegst.

Überprüfe vorab die Liste der vorhandenen Arbeitskopien dieses Repositorys. Du kannst sie nach dem Start zum Vergleich heranziehen:

git worktree list

Separate Ordner helfen dabei, Aufgaben auseinanderzuhalten. Einen allgemeinen Ansatz für die Arbeit mit einem Agenten findest du in den praktischen Ressourcen der Ailoot-Dokumentation.

Schritte: Eine separate Kopie für eine zweite Aufgabe starten

  1. Experimentelle Funktion aktivieren und eine Sitzung mit einer separaten Kopie starten

    Führe den Befehl im Ordner des ursprünglichen Projekts aus, in dem du bereits an der ersten Aufgabe arbeitest.

    codex --enable worktrees --worktree
    

    Erwartetes Ergebnis: Codex erstellt aus dem aktuellen HEAD eine neue Arbeitskopie des Projekts und öffnet dort eine Agentensitzung. Die Kopie befindet sich in einem Detached-HEAD-Zustand, ihr ist kein benannter Branch zugeordnet. So funktioniert das Flag in Version 0.155.1.

  2. Arbeitskopien erneut in einem anderen Terminal im ursprünglichen Projekt auflisten

    git worktree list
    

    Erwartetes Ergebnis: Die Ausgabe enthält eine zusätzliche Zeile mit dem Pfad der neuen Kopie und einer Markierung für Detached HEAD (oder einem Branch, falls einer vorhanden ist). Diese Liste zeigt, dass Git die Kopie registriert hat, bestätigt aber nicht, dass der Agent die Aufgabe abgeschlossen hat. Um sicherzugehen, dass die Dateien vorhanden sind, öffne den Ordner unter dem aufgeführten Pfad und überprüfe seinen Inhalt.

Ergebnis überprüfen und Arbeit sichern

Wenn die zweite Aufgabe in der neuen Kopie abgeschlossen ist, musst du das Ergebnis separat sichern und übertragen. Der Befehl --worktree führt Änderungen nicht in den Haupt-Branch zusammen und überträgt das Ergebnis auch nicht automatisch. Die Kopie bleibt in einem Detached-HEAD-Zustand, deshalb erstellt ein Commit darin allein noch keinen neuen Branch. Wenn du diese Commits sichern musst, ordne sie einem Branch zu oder übertrage sie in das Hauptprojekt, bevor du den Ordner der Kopie löschst.

Lösche den Ordner der Kopie erst, nachdem du das Ergebnis gesichert hast. Zu überprüfen, ob das Arbeitsverzeichnis sauber ist, ersetzt nicht das Sichern der benötigten Commits: Ihnen ist möglicherweise noch kein Branch zugeordnet.

Wenn du gleichzeitig an Aufgaben in verschiedenen Tools arbeitest, plane im Voraus, wie du Störungen zwischen ihnen vermeidest. Die gemeinsame Arbeit mit zwei Agenten wird unter Claude Code und Codex zusammen behandelt.

Wenn der Start unterbrochen wurde: Wo du die Kopie findest

Der Start mit --worktree kann aus mehreren Gründen fehlschlagen:

  • Die Funktion wurde nicht vorher aktiviert und der Startbefehl enthält --enable worktrees nicht: Codex verweigert den Start mit dem Flag --worktree;
  • du befindest dich im falschen Ordner oder es gibt keinen Commit: Wenn der aktuelle Ordner kein Git-Repository ist oder noch keine Commits enthält, gibt es keine Grundlage, aus der die Kopie erstellt werden kann;
  • das Projekt ist ausdrücklich als nicht vertrauenswürdige Quelle markiert: Codex verweigert den Start einer Sitzung mit --worktree. Vergewissere dich zuerst, dass du das richtige Projekt geöffnet hast. Ändere dessen Vertrauensstatus nicht automatisch.

Wenn die Sitzung nicht mit der neu erstellten Kopie verbunden werden konnte – zum Beispiel, weil der Prozess unterbrochen wurde –, wird der Arbeitsordner nicht automatisch gelöscht. Überprüfe zunächst die Liste der Arbeitskopien und stelle vor dem Löschen sicher, dass keine Codex-CLI-Sitzung diese Kopie noch verwendet:

git worktree list

Öffne den Ordner und sichere alle Änderungen, die du benötigst, bevor du ihn löschst. Die Kopie kann bestehen bleiben, auch wenn die Agentensitzung nicht vollständig gestartet wurde. Wenn die Kopie existiert, nicht mehr benötigt wird und mit Sicherheit von keiner Sitzung verwendet wird, entferne sie manuell mit git worktree remove aus dem ursprünglichen Repository und gib dabei den Pfad des Ordners an. Füge --force nicht hinzu: Wenn die Kopie nicht committete oder nicht verfolgte Dateien enthält, verweigert der Befehl das Löschen. Wenn er das Löschen verweigert, überprüfe den Inhalt des Ordners, ohne die Schutzmaßnahme zu deaktivieren.

Wenn du Codex CLI aktualisierst, prüfe erneut codex --version und wiederhole die Überprüfung mit git worktree list: Experimentelle Flags können sich zwischen Versionen unterschiedlich verhalten.

Weitere Ressourcen und Tools: Ailoot.

Weitere Details

Fragen und Antworten

Enthält der zweite Worktree ungespeicherte oder nicht committete Änderungen?

Nein. In der beschriebenen CLI-Version startet er vom HEAD-Commit des Ausgangsrepositorys. Nicht committete Änderungen und neue Dateien bleiben im ursprünglichen Ordner. Speichern im Editor genügt deshalb nicht für die Übertragung.

Kann ich einen sauberen Detached-Worktree gefahrlos löschen?

Auch ein sauberer Ordner kann Commits ohne benannten Branch enthalten. Sichere oder übertrage diese zuerst und prüfe, dass keine Sitzung den Worktree nutzt. Entferne ihn danach regulär mit Git, ohne Schutzprüfungen gewaltsam zu umgehen.

Alle Artikel