Ein Codex-Task läuft bereits, ein Bugfix will übergeben werden, eine Testsuite braucht Coverage, und ein Refactoring schiebst du schon lange vor dir her. Alle vier sind unabhängig voneinander. Eigentlich spricht nichts dagegen, sie gleichzeitig laufen zu lassen – außer dem praktischen Problem: Richtest du zwei Codex-Sessions auf denselben Checkout, überschreiben sie gegenseitig ihre Änderungen. Aus der gewünschten Parallelität wird ein Merge, den du nie wolltest.
Mehrere Codex-Tasks gleichzeitig laufen zu lassen, ist weniger ein Feature, das du einfach einschaltest, als vielmehr ein Setup, das du vorbereitest. Es gibt drei Wege: Codex-Cloud-Tasks, mehrere lokale CLI-Sessions und Subagents innerhalb einer Session. Jeder bringt echte Nebenläufigkeit – und jeder hat genau einen Fehlermodus, der sich zeigt, sobald sich Schreibzugriffe überschneiden. Dieser Leitfaden führt durch alle drei Wege, mit den Befehlen und dem jeweils genannten Fehlerfall, und zeigt anschließend, wo ein Task-Board übernimmt.
Dieses Task-Board ist Sharkly. Codex hast du bereits. Sharkly setzt darüber an: Es führt Codex als Runtime aus und macht aus jedem parallelen Lauf einen Task mit eigenem isolierten Checkout, eigenem Log und eigenem Reviewer. Der Artikel behandelt zuerst das manuelle Setup, denn du solltest verstehen, was du automatisierst, bevor du es automatisierst.
TL;DR
Codex parallel agents bedeutet, mehrere Codex-Tasks gleichzeitig statt nacheinander auszuführen. Drei Wege führen dahin: Codex-Cloud-Tasks (laut OpenAI-Doku jeweils in einer isolierten Umgebung), mehrere lokale codex-CLI-Sessions oder Subagents innerhalb einer Session. Die Regel, die für alle gilt: eine Arbeitskopie pro Arbeitseinheit. Gib jedem Task sein eigenes Git-Worktree, damit gleichzeitige Änderungen nie dieselben Dateien berühren. Das skaliert problemlos bis zu einer Handvoll Tasks. Darüber hinaus wird das Nachverfolgen, welcher Agent was getan hat, und das separate Reviewen jedes einzelnen Ergebnisses zum Engpass – und genau diese Ebene ergänzt Sharkly.
Die drei Wege, Codex parallel auszuführen
Wähle den Weg danach, wo die Arbeit läuft und wie viel du sehen musst – nicht danach, welcher am mächtigsten klingt.
| Weg | Wie er läuft | Isolierung | Am besten geeignet für |
|---|---|---|---|
| Codex-Cloud-Tasks | Jeder Task in einer eigenen Cloud-Umgebung | Stark, pro Task | Delegierte, in sich geschlossene Tasks, die du später prüfst |
| Mehrere CLI-Sessions | Mehrere codex-Prozesse auf deinem Rechner |
Standardmäßig keine; geteilter Checkout | Lokale Arbeit, die du live verfolgen willst |
| Subagents in einer Session | Eine Session startet gespawnte Threads | Geteiltes Session-Verzeichnis | Leseintensive Arbeit: Exploration, Triage, Tests |
Nutze Codex-Cloud-Tasks, wenn die Arbeit klar abgegrenzt ist und du sie im Nachhinein prüfen kannst. Nutze lokale CLI-Sessions, wenn du jeden Lauf mitsteuern willst, während er läuft. Nutze Subagents, wenn die Aufgabe überwiegend aus Lesen besteht, denn gespawnte Agents teilen sich ein Arbeitsverzeichnis und – laut dem Verhalten der Codex-Subagents – wartet die Session auf alle und liefert eine einzige zusammengefasste Antwort. Diese letzte Form eignet sich nicht für paralleles Schreiben: Agents, die gleichzeitig Code bearbeiten, erzeugen Konflikte, und eine einzelne Zusammenfassung lässt sich nicht Stück für Stück prüfen.
Schritt für Schritt: mehrere Codex-Tasks lokal ohne Kollisionen ausführen
Der lokale Weg ist der, zu dem die meisten zuerst greifen – und der zuerst bricht. Hier ist das Setup, das hält.
Schritt 1. Gib jedem Task seinen eigenen Checkout. Ein Git-Worktree ist ein zweites Arbeitsverzeichnis, das auf demselben Repository basiert, aber auf einem eigenen Branch. Lege pro Task eines an:
git worktree add ../app-authfix -b fix/token-refresh
git worktree add ../app-tests -b test/checkout-coverage
git worktree add ../app-refactor -b refactor/api-client
Fehler, wenn du das überspringst: Zwei codex-Sessions im selben Ordner bearbeiten dieselben Dateien, der spätere Schreibvorgang gewinnt still und leise, und beide melden Erfolg. Den Verlust entdeckst du beim Review – oder in der Produktion.
Schritt 2. Starte eine Codex-Session pro Worktree. Öffne in jedem Verzeichnis ein Terminal und starte Codex dort:
cd ../app-authfix && codex
Fehler, wenn du das überspringst: Eine Session mit vier Zielen im Kontext driftet zwischen ihnen hin und her und verliert den Überblick darüber, welche Änderung zu welchem Task gehört.
Schritt 3. Skripte diejenigen, die keinen Menschen an der Tastatur brauchen. Bei einer in sich geschlossenen Aufgabe läuft der nicht-interaktive Modus ohne Rückfragen bis zum Ende durch:
cd ../app-tests && codex exec "add tests for the checkout flow until coverage passes"
Fehler, wenn du das überspringst: Du sitzt da und hütest Sessions, die dich nie gebraucht hätten – womit der Sinn der parallelen Ausführung dahin ist.
Schritt 4. Merge bewusst, einen Branch nach dem anderen. Jeder Worktree ist ein Branch, also prüfe und merge sie separat. Lass die Agents niemals die Arbeit der anderen mergen. Fehler, wenn du das überspringst: Drei Branches landen auf einmal, ein Konflikt taucht im Merge-Commit auf, und du kannst nicht mehr sagen, wessen Änderung ihn verursacht hat.
Wie du Worktrees danach sauber aufräumst, erfährst du unter Worktrees für Coding-Agents verwalten – ohne Aufräum-Schmerz. Dasselbe Worktree-Muster steckt hinter mehrere Claude-Code-Agents ausführen; es ist von Natur aus runtime-neutral.
Wo das DIY-Setup nicht mehr skaliert
Worktrees lösen Kollisionen. Sie lösen nicht alles, und die Wand kommt schneller näher, als es aussieht.
Bei drei oder vier Tasks hält das Setup. Bei acht ist das Terminal-Raster kein Arbeitsbereich mehr, sondern ein Gedächtnistest. Die Fehler sind nicht dramatisch; sie summieren sich:
- Du verlierst die Übersicht. Welches Fenster ist der Auth-Fix? Welches ist fertig? Welches ist vor zwanzig Minuten fehlgeschlagen und seitdem untätig? Der Zustand existiert nur in deinem Kopf und scrollt aus dem Bild.
- Beim Review gibt es keine Nahtstellen. Die Ausgabe jeder Session ist eine Wand aus Scrollback. Es gibt keinen Task-bezogenen Datensatz darüber, was berührt, was ausgeführt und wo gestoppt wurde – also kannst du nicht das eine Ergebnis annehmen und ein anderes sauber verwerfen.
- Nichts wird geteilt. Sobald ein Teammitglied den Fortschritt sehen will, kopierst du Diffs in einen Slack-Thread. Die Arbeit ist real, aber unsichtbar.
Das sind dieselben drei Probleme, auf die jeder Parallel-Agent-Workflow zuläuft, und sie sind der Grund, warum Teams zu speziellen Tools für die Verwaltung paralleler Coding-Agents greifen, sobald die Anzahl steigt. Isolation ist ein gelöstes Problem. Sichtbarkeit und Review sind es nicht – jedenfalls nicht mit einem Terminal-Raster.
Was ein Task-Board bringt
Hier verdient sich die Ebene über dem Agent ihren Platz. Ein Task ist in Sharkly der gemeinsame Datensatz einer Arbeitseinheit, und Codex-Tasks parallel auszuführen wird zum parallelen Ausführen von Tasks.
Jeder Task beansprucht automatisch ein isoliertes Git-Worktree, sodass parallele Agents in isolierten Worktrees nicht mehr etwas sind, das du skriptest, sondern der Standard. Zehn Tasks gegen ein Repository, null geteilter Zustand, kein git worktree add, das du per Hand tippst. Die Runtime, die die Bearbeitung vornimmt, ist weiterhin Codex; die Isolation wird drumherum bereitgestellt.
Die Arbeitsteilung ist der Punkt. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist. Deshalb behält jeder Lauf sein eigenes Ausführungslog mit dem Auslöser, den Tool-Aufrufen und dem Punkt, an dem er gestoppt hat, und sein Endergebnis kehrt zum Task zurück, statt im Terminal vorbeizuscrollen. Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review bleiben von der Anfrage bis zum Release sichtbar, und du prüfst jedes Ergebnis einzeln, statt eine Zusammenfassung von Zusammenfassungen zu lesen. Zur Reporting-Seite davon siehe wie du Arbeit nachverfolgst, die von KI-Coding-Agents erledigt wurde.
Sharkly ersetzt Codex nicht. Es ergänzt die Ebene für gemeinsame Tasks, Checkouts, Kontext und Review um den Agent herum, den du bereits betreibst. Wenn du immer nur eine Codex-Session gleichzeitig laufen lässt, brauchst du es nicht. Wenn du mehrere gegen eine Codebase laufen lässt und den Faden verlierst, ist genau das das Problem, für das es gebaut wurde. Du kannst das oben beschriebene Worktree-Setup von Hand aufbauen oder deine bestehenden Codex-Tasks über Sharkly laufen lassen und den Workflow den Zustand für dich halten lassen.
Eine Checkliste, die du heute umsetzen kannst
- Ein Git-Worktree pro Task, jeweils auf einem eigenen Branch. Keine zwei Tasks teilen sich einen Checkout.
- Eine Codex-Session pro Worktree oder
codex execfür Tasks, die dich nicht brauchen. - Nutze Subagents nur für leseintensive Arbeit; halte gleichzeitige Schreibvorgänge in getrennten Checkouts.
- Merge einen Branch nach dem anderen und prüfe jeden, bevor er landet.
- Führe an einer Stelle, die ein Teammitglied sehen kann, Buch darüber, welcher Task welcher ist, was jeder berührt hat und wie das Ergebnis aussieht.
- Wenn das Terminal-Raster nicht mehr in deinen Kopf passt, verlagere Tracking und Review auf ein Task-Board, damit jeder Lauf sein Ergebnis an einen gemeinsamen Ort zurückgibt.
FAQ
Kann Codex mehrere Tasks gleichzeitig ausführen? Ja. Codex Cloud führt Tasks laut OpenAI-Doku in isolierten Umgebungen aus, und lokal kannst du mehrere codex-Sessions gleichzeitig laufen lassen. Die Einschränkung ist der Checkout, nicht Codex: Gib jedem lokalen Task sein eigenes Git-Worktree, damit sich seine Änderungen nicht in die Quere kommen.
Wie viele parallele Codex-Agents kann ich laufen lassen? So viele, wie deine Maschine und dein Modell-Kontingent zulassen. Die praktische Obergrenze liegt niedriger: Es ist die Anzahl gleichzeitiger Ergebnisse, die eine Person tatsächlich prüfen kann. Ab einer Handvoll werden Tracking und Review zum Limit, nicht die Rechenleistung.
Brauche ich Worktrees, oder kann ich einfach mehr Terminals öffnen? Mehr Terminals im selben Verzeichnis bedeuten gleichzeitige Schreibvorgänge auf dieselben Dateien und stilles Überschreiben. Worktrees geben jeder Session ihr eigenes Verzeichnis und ihren eigenen Branch – genau das macht lokale Parallelität sicher. Siehe Git-Worktrees für KI-Coding-Agents.
Was ist der Unterschied zwischen Codex-Subagents und parallelen Tasks? Subagents laufen innerhalb einer Session, teilen sich deren Arbeitsverzeichnis und liefern eine einzige zusammengefasste Antwort – das eignet sich für Lesen und Triage. Parallele Tasks sind getrennte Läufe mit getrennten Checkouts, was du für gleichzeitiges Schreiben und unabhängiges Review willst.
