Einen einzelnen Codex-Agenten zu betreiben, ist einfach. Du öffnest ein Terminal, beschreibst eine Aufgabe und siehst ihm bei der Arbeit zu. Die Probleme fangen bei drei an. Ein Agent refaktoriert das Auth-Modul, ein zweiter behebt einen flaky Test, ein dritter entwirft eine Migration – und jeder lebt in seinem eigenen Terminal-Tab mit eigenem Scrollback. Zehn Minuten später weißt du nicht mehr, welcher Tab zu welcher Aufgabe gehört, ob die Migration fertig ist oder auf welchem Branch der Test-Fix gelandet ist. Den Agenten geht es gut. Was kaputtgegangen ist, ist deine Fähigkeit, sie im Blick zu behalten.
Das ist das eigentliche Problem hinter „mehrere Codex-Agenten verwalten“. Es ist nicht die Nebenläufigkeit; Codex läuft problemlos parallel in getrennten Arbeitsverzeichnissen. Das Problem ist, dass der Zustand dieser Arbeit – was jeder Agent gerade tut, was fertig ist, was fehlgeschlagen ist und was deine Prüfung braucht – über Terminal-Tabs, Worktree-Ordner und dein eigenes Gedächtnis verstreut landet. Verlierst du eines davon, verlierst du den Faden.
Sharkly gibt es genau für diese Lücke. Coding-Agenten hast du bereits; Sharkly macht daraus ein Team, indem jeder Agentenlauf einen gemeinsamen Eintrag bekommt. Dieser Artikel führt zuerst durch das manuelle Setup, denn du solltest verstehen, was du automatisierst, und zeigt dann, wo ein Task-Board seinen Platz verdient. Am Ende steht eine Checkliste, die du heute umsetzen kannst.
Was „den Überblick verlieren“ wirklich bedeutet
Den Überblick zu verlieren, ist nichts Vages. Es ist ein konkretes Versagen: Dein Arbeitszustand hat kein einziges Zuhause. Wenn du mehrere Codex-Sessions von Hand betreibst, ist die Wahrheit über jede Aufgabe gleichzeitig auf vier Orte verteilt. Die Anweisung lebt in dem Terminal, in das du sie getippt hast, die Änderungen leben in einem Git-Arbeitsverzeichnis, der Status lebt in deinem Kopf, und das Ergebnis lebt in einem Pull Request, den du noch nicht geöffnet hast. Nichts hält diese vier synchron. Schließ das Terminal, und die Anweisung ist weg. Wechsel die Tabs, und der Status ist eine Vermutung. Je mehr Agenten du hinzufügst, desto mehr Kopien von „was gerade passiert“ pflegst du, und du bist der einzige Integrationspunkt, der sie zusammenhält.
Das Ziel beim Verwalten mehrerer Codex-Agenten ist also eng umrissen und es lohnt sich, es klar zu benennen: Halte Aufgabe, Fortschritt, Änderungen und Review-Status jedes Agenten an einem Ort, statt sie über private Terminal-Sessions zu verteilen. Alles Folgende wird an genau diesem einen Maßstab gemessen.
Schritt 1: Jeden Agenten mit einem Worktree isolieren
Der erste Fehlerfall ist die Kollision. Richte zwei Codex-Agenten auf denselben Ordner und sie überschreiben gegenseitig ihre Änderungen, stagen gegenseitig ihre Dateien und erzeugen einen Diff, den niemand lesen kann. Git-Worktrees lösen das sauber, indem sie jedem Agenten einen eigenen Checkout desselben Repositories auf seinem eigenen Branch geben.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
Starte jetzt eine Codex-Session in jedem Verzeichnis. Jeder Agent sieht nur seine eigenen Dateien, committet auf seinen eigenen Branch und kann den anderen nicht in die Quere kommen.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
Fehlerfall, den man hier benennen muss: Worktrees lösen Dateikollisionen, nicht das Tracking. Du hast jetzt drei Ordner mit fast identischen Namen und keinen Vermerk darüber, welche Aufgabe in welchem steckt. Lege eine Namenskonvention fest, die die Aufgabe kodiert (agent/<task>), denn in einer Woche bedeuten repo-2 und repo-3 gar nichts mehr. Wenn du die tieferen Mechanismen willst, sieh dir Git-Worktrees für KI-Coding-Agenten und das übergreifende Muster in mehrere Codex-Aufgaben gleichzeitig ausführen an.
Schritt 2: Die Sessions im Blick behalten
Drei Agenten in drei Tabs heißt: Ein versehentliches Cmd+W trennt dich davon, eine laufende Aufgabe zu killen und ihren Scrollback zu verlieren. Ein Terminal-Multiplexer wie tmux hält jede Session in benannten Fenstern am Leben, von denen du dich lösen und später wieder verbinden kannst.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
Benannte Fenster (auth, flaky, migration) stellen das Label wieder her, das ein nackter Tab wegwirft. Mit Ctrl-b d löst du dich, klappst den Laptop zu, verbindest dich morgens wieder – und die Sessions sind noch da.
Fehlerfall, den man hier benennen muss: tmux hält Sessions am Laufen; es sagt dir nicht, welche dich brauchen. Ein Agent, der vor zwanzig Minuten fertig geworden ist, und ein Agent, der auf einen Fehler gestoßen ist, sehen von außen identisch aus: ein ruhiger Pane. Du musst trotzdem jedes Fenster besuchen und die letzten hundert Zeilen lesen, um seinen Status zu erfahren. Diese Polling-Kosten wachsen mit jedem Agenten, den du hinzufügst, und es ist die Steuer, die das manuelle Setup mit der Zeit immer schwerer wirken lässt.
Schritt 3: Status und Review an einem dauerhaften Ort festhalten
Der letzte manuelle Baustein ist der, den die Leute überspringen: aufschreiben, was jeder Agent produziert hat und ob du es akzeptiert hast. Scrollback ist kein Protokoll. Er verschwindet, ist nicht über Aufgaben hinweg durchsuchbar, und ein Teammitglied kann ihn nicht lesen. Die leichtgewichtige Variante ist eine einfache Checkliste, die du von Hand pflegst.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
Das ist die ganze Aufgabe im Kleinen: ein dauerhafter Ort, an dem Fortschritt, Blocker, Ergebnisse und menschliche Prüfung von der Anfrage bis zum Release sichtbar bleiben. Wenn du ihn gewissenhaft führst, kannst du mehrere Agenten lange Zeit von einem Terminal aus verwalten. Der Haken: Du bist die Sync-Engine und aktualisierst ihn jedes Mal von Hand, wenn sich etwas ändert. Mehr dazu, wie du die Ausgaben von Agenten prüfbar machst, findest du unter wie man Arbeit nachverfolgt, die KI-Coding-Agenten erledigt haben.
Wo das DIY-Setup nicht mehr skaliert
Sei ehrlich, wann der manuelle Ansatz ausreicht. Für ein oder zwei Codex-Agenten mit klar umrissenen Aufgaben sind Worktrees plus Namenskonvention plus handgeführte Statusdatei wirklich in Ordnung. Füge keine Tools hinzu, die du nicht brauchst; die beweglichen Teile sind nahe null und das Ganze passt in deinen Kopf.
Die Gleichung ändert sich an einem vorhersehbaren Punkt. Du spürst es, wenn:
- Du drei oder mehr Agenten laufen lässt und die Polling-Kosten (jeden Pane besuchen, das Ende lesen, den Status merken) mehr Zeit fressen, als die Agenten einsparen.
- Die Arbeit sich über mehr als ein Repository erstreckt, sodass Worktrees allein kein klares Gesamtbild mehr ergeben.
- Jemand anderes fragt „Was machen die Agenten gerade?“ und die einzige ehrliche Antwort steckt in deinem Terminal und deinem Gedächtnis.
Jeder dieser Punkte hat dieselbe Ursache wie am Anfang des Artikels: ein Arbeitszustand ohne gemeinsames Zuhause. Das manuelle Setup bewahrt ihn an dem einen Ort auf, der nicht skaliert – bei dir. Teams stoßen am schnellsten an diese Wand, weshalb die besten Tools zum Verwalten paralleler KI-Coding-Agenten alle auf denselben Schritt hinauslaufen: Gib der Arbeit ein Zuhause außerhalb des Terminals.
Was ein Task-Board bringt
Ein Task-Board ändert die Einheit der Verwaltung von „einer Terminal-Session“ zu „einem Task“. In Sharkly verbindest du den Computer, auf dem du Codex ohnehin laufen lässt, und weist dann einen Task einem Codex-Agenten zu, statt in einen Pane zu tippen. Der Agent läuft in seinem eigenen isolierten Worktree, und Ausführung, Fortschritt, Blocker und Ergebnisse fließen zurück in den Task. Du hörst auf zu pollen; das Board weiß bereits, was fertig ist und was fehlgeschlagen ist.
Die Arbeitsteilung ist bewusst gewählt, und es lohnt sich, sie als Grenze zu benennen: Sharkly ersetzt Codex nicht. Codex führt aus. Sharkly fügt den gemeinsamen Task, den Computer, den Kontext und die Review-Ebene darum herum hinzu. Agenten recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Die Automatisierung endet dort, wo dein Urteilsvermögen gefragt ist – an der Review-Schwelle, nicht am Code.
Genau das hat die manuelle Statusdatei angestrebt – jetzt dauerhaft und geteilt. Daraus ergeben sich drei Dinge, die dir das Terminal nicht bieten kann:
- Status ohne Polling. Jeder Task zeigt running, done, blocked oder needs-review, ohne dass du einen Pane besuchst.
- Ein Gesamtbild über Repositories hinweg. Tasks aus vielen Repos und von vielen Agenten liegen in einem Space, mehr Agenten bedeuten also nicht mehr Terminals, die du hüten musst. Aus demselben Grund betreiben Teams Claude Code und Codex zusammen von einem Ort aus.
- Ein Review-Schritt, der hält. Ergebnisse warten an einer Human-in-the-Loop-Schwelle, mit Änderungszusammenfassung und Belegen, sodass nichts gemergt wird, weil du vergessen hast, dass es noch aussteht.
Du kannst das alles mit Worktrees und Disziplin selbst bauen oder Sharkly nutzen, um den Workflow zu verwalten, wenn die Zahl der Agenten steigt. Codex bleibt genau wie es ist; die Verwaltung wandert von deinen Schultern weg. Wenn du bereits mehrere Codex-Agenten betreibst, ist das genau das Problem, um das Sharkly herum entworfen wurde.
Die Checkliste, die du heute umsetzen kannst
Ob du manuell bleibst oder auf ein Board umsteigst, das ist das Minimum, das dich davor bewahrt, den Überblick zu verlieren:
- [ ] Ein isolierter Worktree pro Agent, auf einem nach der Aufgabe benannten Branch, nie zwei Agenten in einem Ordner.
- [ ] Eine Namenskonvention, die die Aufgabe kodiert, sodass
agent/auth-refactorbesser ist alsrepo-3. - [ ] Langlebige Sessions (tmux oder ein Board), von denen du dich lösen und wieder verbinden kannst, ohne Arbeit abzubrechen.
- [ ] Ein dauerhafter Statusdatensatz außerhalb des Terminal-Scrollbacks: Task, Branch, Status, Review-Status.
- [ ] Eine ausdrückliche Review-Schwelle; kein Branch wird gemergt, bis ein Mensch ihn abnimmt.
- [ ] Eine Zählprüfung: Bei drei oder mehr Agenten oder zwei oder mehr Repos hol den Status aus deinem Kopf heraus.
Betreib die manuelle Variante, bis die Polling-Steuer wehtut. Wenn es so weit ist, lass deine bestehenden Coding-Agenten über Sharkly laufen, damit das Tracking die Aufgabe des Boards ist und nicht deine.
FAQ
Wie viele Codex-Agenten kann ich realistisch gleichzeitig betreiben? So viele, wie deine Maschine und deine Rate Limits zulassen; die Grenze, an die du zuerst stößt, ist meistens menschlich, nicht technisch. Beim manuellen Verfolgen von drei oder mehr verliert man am ehesten den Faden. Siehe Parallele Codex-Threads und Subagenten für die Limits auf der Ausführungsseite.
Ersetzt ein Task-Board Codex? Nein. Codex führt aus; das Board verwaltet Zuweisung, Isolation, Kontext und Review darum herum. Sie ergänzen sich gegenseitig.
