Claude Code und Codex parallel einsetzen: ein kleines Git-worktree-Experiment

Bevor Claude Code Texte überarbeitet und Codex gleichzeitig einen Exportfehler behebt, sollte jede Aufgabe ihr eigenes Arbeitsverzeichnis erhalten.

Zeigen beide Unterhaltungen auf dasselbe Verzeichnis, wird eine von einem Agenten geänderte Datei zur Eingabe des anderen. Bei „Tests bestanden“ ist dann womöglich nicht mehr klar, welche Änderungen dieses Ergebnis beschreibt.

Eine Einstellungsbeschreibung aktualisieren und den Export leerer Datumswerte reparieren: zwei Aufgaben, die parallel bearbeitet und getrennt geprüft werden können. Das reproduzierbare Experiment zeigt die Verzeichnisvorbereitung, Aufgabenverteilung und gemeinsame Abschlussprüfung. Ein Skript führt das Experiment aus; die Prompts dienen als anpassbare Beispiele.

Umfang und Abschlusskriterien zuerst festlegen

Das Beispielprojekt enthält eine Datei für Einstellungstexte und eine Funktion, die Zeitstempel in Exportdaten umwandelt.

Die Textaufgabe ändert nur settings.zh-CN.json: Die Beschreibung „管理设备“ wird durch „查看已登录设备，并撤销不再使用的设备访问“ ersetzt. Die Datumsaufgabe korrigiert nur fehlende Werte. Gültige Zeitstempel sollen weiterhin als UTC-Datum exportiert werden.

Die vereinfachten chinesischen Zeichenfolgen bleiben erhalten, damit das Experiment reproduzierbar ist. Die erste bedeutet „Geräte verwalten“, die neue Beschreibung „Angemeldete Geräte anzeigen und nicht mehr genutzten Geräten den Zugriff entziehen“.

Die ursprüngliche Datumsfunktion lautet:

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

Für null liefert sie 1970-01-01, bei einer leeren Zeichenfolge wirft sie eine Ausnahme. Beides widerspricht der Anforderung, ein fehlendes Datum leer zu lassen.

Führe zunächst alle vier Tests aus: Die zwei Fälle für fehlende Werte schlagen fehl, UTC-Zeitstempel und Zeitstempel mit Zeitzone bestehen. Diese Ausgangslage zeigt, was die Korrektur ändern und was sie erhalten muss.

Zwei Arbeitsverzeichnisse vom selben Commit erstellen

Bestätige in einem Repository mit vorhandenem main-Branch den Ausgangscommit. Neue Branchnamen und Zielverzeichnisse der folgenden Befehle dürfen noch nicht verwendet werden:

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

Jeder Worktree hat ein eigenes Checkout-Verzeichnis und einen eigenen Index, also einen Bereitstellungsbereich. Änderungen können so auf getrennten Branches bleiben; die Worktrees gehören weiterhin zum selben Git-Repository. Jedes neue Verzeichnis startet beim angegebenen Commit. Nicht eingecheckte Änderungen im ursprünglichen Verzeichnis werden nicht automatisch übernommen. Richte Abhängigkeiten und lokale Konfiguration nach den Projektanforderungen ein. Details stehen in der offiziellen Git-worktree-Dokumentation.

Danach sind Verzeichnisse und Branches so zugeordnet:

Ein Verzeichnis pro Aufgabe hält beide Arbeitskopien gleichzeitig verfügbar. Ein Branchwechsel in einem einzigen Verzeichnis schafft diese Trennung nicht.

In Tactic Remote das richtige Verzeichnis pro Unterhaltung wählen

Verbinde dich mit dem Entwicklungsrechner und öffne die Projektauswahl unter Neue Unterhaltung (New Conversation). Wähle bei Bedarf über Anderen Ordner auswählen (Choose another folder) den tatsächlichen Pfad des jeweiligen Worktrees aus. Danach wählst du den Agenten.

Existieren bereits Worktrees für das Repository, wähle deren Verzeichnisse direkt. Ein unabhängiger Arbeitsbereich (Independent Workspace) enthält nicht automatisch dieses Repository oder dessen Branchbeziehung.

Die erste Anfrage an Claude Code könnte lauten:

Ändere nur die Gerätebeschreibung in settings.zh-CN.json. Sie soll erklären, dass Nutzer angemeldete Geräte sehen und ihren Zugriff entziehen können. Bestätige zuerst Verzeichnis und Branch. Ändere die Datumsexportlogik nicht. Zeige zum Abschluss den Text-Diff und prüfe die JSON-Gültigkeit.

Die Anfrage an Codex könnte lauten:

Korrigiere export-date.mjs: null und eine leere Zeichenfolge sollen eine leere Zeichenfolge liefern; gültige Zeitstempel sollen weiterhin als UTC-Daten exportiert werden. Bestätige zuerst Verzeichnis und Branch, führe die vier vorhandenen Tests aus, reproduziere den Fehler und mache die kleinste nötige Änderung. Ändere keine Einstellungstexte. Berichte die Ergebnisse vor und nach der Korrektur.

Ein im Prompt begrenzter Dateiumfang erleichtert die Prüfung, ist aber keine Sicherheitssandbox. Welche Dateien ein Agent tatsächlich lesen und schreiben kann, bestimmen seine Berechtigungen auf dem Rechner.

Getrennt prüfen, was jedes Ergebnis belegt

Die kleinste Korrektur im Beispiel prüft fehlende Eingaben vor der Datumsumwandlung:

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

Der Code behandelt nur die vereinbarten fehlenden Werte. Für andere ungültige Datumszeichenfolgen braucht es eine eigene Definition. Gültige Zeitstempel werden weiterhin als UTC-Datum exportiert.

Führe in jedem Arbeitsverzeichnis Folgendes aus:

git status --short
git diff --name-only
git diff

Im Experiment änderte sich im Textverzeichnis nur settings.zh-CN.json, im Datumsverzeichnis nur export-date.mjs. Wir haben die Dateien auch direkt gelesen: Die ursprüngliche Datumsfunktion blieb im Textverzeichnis erhalten, der ursprüngliche Text im Datumsverzeichnis.

Die tatsächlichen Ergebnisse:

Der Textbranch bestand seine JSON-Prüfung, während die zwei bekannten Datumstestfehler bestehen blieben. Dokumentiere den Ausgangszustand und den Umfang jeder Prüfung, damit die Aussagekraft des Ergebnisses erkennbar bleibt.

Zum Schluss in einem klar benannten Branch integrieren

Nachdem beide Änderungen geprüft und als Commits gespeichert sind, erstellst du im ursprünglichen Verzeichnis des Beispielrepositorys einen Integrationsbranch:

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

Dies setzt voraus, dass im ursprünglichen Verzeichnis keine Änderungen ausstehen und beide Aufgabenbranches eingecheckt sind. Folge in einem echten Projekt weiterhin dem bestehenden PR- und Merge-Prozess. Bei einem Konflikt musst du beide Änderungen verstehen und anschließend die gemeinsame Prüfung ausführen.

Prüfe das zusammengeführte Ergebnis, denn Änderungen können sich gegenseitig beeinflussen, obwohl jede für sich die eigenen Tests besteht. Getrennte Verzeichnisse erfordern weiterhin Abstimmung über gemeinsame Konfiguration, Abhängigkeiten, Datenbanken und Serverports.

Sind die Änderungen erhalten, der Arbeitsbaum sauber und die Verzeichnisse nicht mehr in Gebrauch, entferne sie mit dem normalen git worktree remove. Lehnt Git das wegen Änderungen ab, kümmere dich zuerst um die gemeldeten, noch nicht eingecheckten Inhalte.

Auf dem Telefon zuerst Aufgabe und Prüfergebnis bestätigen

Prüfe für parallele Aufgaben zunächst Computer, Projekt und Unterhaltung. Lies danach das neueste Ergebnis und erkenne, wo eine Entscheidung nötig ist.

Beim Text musst du vielleicht nur einen Begriff bestätigen. Beim Datum kann eine Entscheidung zwischen UTC und Ortszeit nötig sein. Halte diese Entscheidung in der jeweiligen Unterhaltung fest, damit ihre Begründung später nachvollziehbar bleibt.

Der Ablauf funktioniert bereits mit zwei Aufgaben: je ein Verzeichnis, eine klare Anfrage und ein Prüfergebnis, danach ein Test des gemeinsamen Verhaltens. Mit mehr Aufgaben sollten Verzeichnisse, Anfragen und Ergebnisse genauso klar zuzuordnen bleiben.

Das Experiment lief in einem temporären lokalen Git-Repository ohne Agentenaufruf. Mit dem Reproduktionsskript und den Originalergebnissen kannst du jeden Schritt nachvollziehen.