Mehrere KI-Agents parallel in geteilten Terminal-Panes betreiben

Warum zwei Agents im selben Repository meistens schiefgehen

Der Fehler ist fast immer derselbe. Sie öffnen Claude Code in einem Terminal-Tab und Codex in einem anderen, richten beide auf dieselbe Arbeitskopie und geben ihnen verschiedene Aufgaben. Ein Agent führt git checkout -b feature-a aus, während der andere mitten in einer Änderung auf main steckt. Jetzt haben Sie uncommittete Änderungen auf dem falschen Branch oder ein git status, das keiner der beiden Agents erwartet.

Selbst auf einem einzigen Branch erzeugen zwei Agents, die gleichzeitig überlappende Dateien bearbeiten, Merge-Konflikte, die Sie von Hand auflösen müssen.

Wenn Sie die Agents nacheinander laufen lassen, vermeiden Sie die Kollision, aber Sie warten doppelt so lange. Sie betreuen einen Agent, während der andere untätig bleibt. Die Lösung ist nicht sorgfältigeres Abwechseln. Geben Sie jedem Agent eine eigene Arbeitskopie auf der Festplatte, dann kann ein git checkout in einem Pane die Dateien des anderen nicht berühren.

Schritt für Schritt: geteilte Panes mit Agent-Isolierung einrichten

1. Öffnen Sie einen neuen Workspace für Ihr Repository. Wählen Sie im Willkommens- bzw. „Neuer Workspace“-Bildschirm von MXterm Pro den Projektordner. Unter macOS können Sie stattdessen die Finder-Schnellaktion „New MXterm Pro Tab Here“ verwenden, falls sie in Ihrem Dienste-Menü erscheint, oder den Ordner auf das Dock-Symbol ziehen.

2. Aktivieren Sie „Features in git worktrees isolieren“. Die Beschreibung unter dem Kontrollkästchen sagt, was die Option bewirkt: „Jeder Agent-Bereich startet in einem eigenen worktree und Branch.“ Standardmäßig ist sie ausgeschaltet.

Das hilft nur innerhalb eines Git-Repositorys. Ist der Ordner keines, führt MXterm Pro nicht mehr selbst git init aus (geändert in 1.0.22). Die App sagt das gleich zu Beginn: „Dieser Ordner ist kein git-Repository, daher teilen sich die Agents ihn direkt (keine worktree-Isolierung)“. Danach öffnet sie normale, nicht isolierte Panes, jedes mit einem Hinweis, den Sie schließen können. Führen Sie zuerst selbst git init aus, wenn Sie Isolierung wollen.

3. Fügen Sie geteilte Panes hinzu. Verwenden Sie Cmd+D (rechts teilen) oder Shift+Cmd+D (unten teilen), oder legen Sie die Anzahl der Panes im Composer fest, bevor Sie den Workspace erstellen. Mehr zum Teilen steht in den Pane-Docs.

Um Panes später anders anzuordnen, ziehen Sie die Kopfzeile eines Panes an den Rand eines anderen Panes. Die Einblendung zeigt „Links einfügen (50 %)“, „Rechts einfügen (50 %)“, „Oberhalb einfügen (50 %)“ bzw. „Unterhalb einfügen (50 %)“, und das Pane landet daneben im Verhältnis 50/50. Auch die Größenänderung rastet ein: Lassen Sie einen Teiler innerhalb von etwa 3,5 % der Mitte los, dann springt er auf 50/50. Ein Doppelklick auf einen Teiler setzt ihn jederzeit auf 50/50 zurück.

4. Starten Sie pro Pane einen Agent. Weil die Worktree-Isolierung aktiv war, liegt jedes Agent-Pane, das Sie im Composer gewählt haben (Claude Code in einem, Codex im anderen), bereits auf einem eigenen Branch mit einem Namen wie swarm/brave-otter.

Die App erzeugt ein kurzes Adjektiv-Nomen-Paar, das auf Kollisionen geprüft wird, und verwendet nicht die Namen der Agents. Ist der Name doch schon vergeben, versucht sie es erneut mit dem Suffix -2. Ein normales Terminal-Pane oder ein Pane, das Sie später per Teilen hinzufügen, bleibt im Stammverzeichnis des Repositorys.

5. Geben Sie jedem Agent eine eigene Aufgabe, nach Möglichkeit auf Dateien beschränkt, die sich nicht überschneiden. Zum Beispiel „Auth-Middleware refaktorieren“ im ersten Pane und „Einstellungs-UI aktualisieren“ im zweiten. Die Isolierung verringert die Wahrscheinlichkeit von Branch-Kollisionen. Sie hindert zwei Agents nicht daran, unabhängig voneinander dieselbe gemeinsame Datei zu ändern. Teilen Sie die Arbeit deshalb entlang echter Nahtstellen im Code auf.

6. Prüfen und mergen Sie vom Stammverzeichnis des Repositorys aus. Wenn ein Agent fertig ist, wechseln Sie per cd in seinen Worktree (<repo>/.worktrees/<slug>) oder wählen ihn in der Worktrees-Liste im Git-Panel. Mergen Sie den Branch dann auf dem üblichen Weg zurück: git merge, den Diff prüfen oder einen PR öffnen. MXterm Pro mergt nicht für Sie. Es hält nur die beiden Arbeitskopien auseinander, solange die Agents laufen.

Einen Prompt an alle Panes senden

Drücken Sie unter macOS Cmd+Shift+B, um Broadcast-Modus umzuschalten, wenn dieselbe Anweisung gleichzeitig an alle Agents gehen soll, etwa „Testsuite ausführen“ oder „neuesten Stand holen und rebasen“. Die Tastenbelegung sieht unter Windows Ctrl+Shift+B vor.

Solange die Funktion an ist, werden Ihre Tastenanschläge im aktiven Pane in Echtzeit in jedes andere Pane der Broadcast-Gruppe gespiegelt. Ein einziges npm test oder ein einziger Prompt erreicht alle Panes, ohne dass Sie ihn pro Tab neu tippen.

Broadcast ist bewusst grob gehalten. Es führt keine Ausgaben zusammen und wartet nicht, bis ein Agent fertig ist, bevor der nächste Befehl ankommt. Es verteilt einfach dieselben Tastenanschläge. Schalten Sie es aus (erneut Cmd+Shift+B), bevor Sie etwas eingeben, das nur für ein Pane gilt, etwa die Antwort auf die Rückfrage eines Agents. Sonst geht diese Antwort an jedes Pane der Gruppe.

Der Multi-Agent Control Room und wo er sich von einfachen geteilten Panes unterscheidet

Der Control Room (früher War Room) ist eine eigene Ebene über geteilten Panes mit Worktree-Isolierung, die verhindert, dass zwei Agents sich auf der Festplatte in die Quere kommen. Er sitzt im rechten Zusatzpanel. Alt+Cmd+B schaltet das Panel unter macOS um, danach wählen Sie den Tab Control Room. Unter Windows sieht die Tastenbelegung Ctrl+Alt+B vor.

Sie verbinden Terminal-Panes über die Schaltfläche Control Room des jeweiligen Panes mit einem gemeinsamen Raum. Der Raum führt ein fortlaufendes Protokoll über Beitritte, Austritte, Umbenennungen und die Nachrichten, die der Moderator und die Agents einander schicken.

Wenn Sie in einem Pane tippen, wird die Zustellung von Prompts aus dem Control Room an diesen Agent zurückgehalten, bis Sie aufhören zu tippen oder auf „Jetzt zustellen“ klicken. So wird keine wartende Anweisung mitten in Ihre Eingabe geschoben. Der Leitfaden zum Control Room behandelt den Rest, die Docs zu Agents und Control Room die Seite der App.

Free-Konten bekommen standardmäßig bis zu 2 Mitglieder pro Control Room. Pro hebt diese Grenze auf. Eine Begrenzung der Zahl der Räume gab es nie. Claude Code und Codex nebeneinander zu betreiben, worum es in diesem Leitfaden geht, passt in den kostenlosen Raum mit 2 Mitgliedern. Die Grenze erreichen Sie erst, wenn Sie demselben Raum ein drittes oder viertes Mitglied hinzufügen.

Token-Verbrauch pro Agent (Token Meter)

Der Token Meter von MXterm Pro deckt Claude Code und Codex ab. Klicken Sie auf den Chip in der Titelleiste, dann erhält jeder Agent eine Zeile. Sie lässt sich zu einer Sparkline pro Stunde und einer Aufschlüsselung über 7 Tage aufklappen. Der Token Meter liest die eigenen Transkripte jedes Agents auf Ihrem Rechner und braucht weder API-Schlüssel noch Konto. Es wird nichts irgendwohin gesendet, solange Sie nicht die optionalen Live-Abfragen der Limits des Tarifs einschalten. Wie der Token-Verbrauch gezählt wird nennt die Einzelheiten.

Vergleich mit iTerm2, Warp und tmux

iTerm2 ist ein ausgereiftes, skriptbares macOS-Terminal mit hervorragenden geteilten Panes und einem riesigen Plugin-Ökosystem. Es eignet sich gut, um Claude Code und Codex manuell in zwei Panes laufen zu lassen. Die Dokumentation beschreibt Benachrichtigungen bei Aktivität, Stille und abgeschlossenen Jobs, ein optionales KI-Plugin und eine Claude-Code-Integration. Eine Worktree-Einrichtung führt sie nicht auf, die Branch-Isolierung verwalten Sie also selbst mit git worktree add.

Warp ist über einen einzelnen Chat-Assistenten hinausgewachsen. Auf der Website steht, man könne einen eigenen Agent wie Claude Code oder Codex mitbringen und Flotten von Agents über Web, Mobilgerät, Terminal und IDE hinweg von einer zentralen Steuerung aus koordinieren. MXterm Pro ist enger gefasst: ein lokales Desktop-Terminal mit einem Worktree pro Agent-Pane. Den ganzen Vergleich finden Sie unter MXterm Pro vs. Warp.

tmux liefert die Panes und das Muskelgedächtnis, das viele Entwickler schon haben, und kommt dem Split-Pane-Modell von MXterm Pro am nächsten. Es ist aber ein Terminal-Multiplexer und kennt Git nicht.

Tasten an mehrere Panes zu senden (:setw synchronize-panes on) ist ein alter tmux-Trick, und der Broadcast-Modus von MXterm Pro bildet ihn nach. Worktree-Einrichtung, Statusverfolgung der Agents und das Protokoll des Control Room bildet eine tmux-Konfiguration nicht ohne echten Skriptaufwand nach.

Keine dieser Optionen ist falsch. iTerm2, Warp und tmux sind alle leistungsfähige Terminals. Die Lücke, die MXterm Pro für diesen Ablauf füllt, ist die Kombination: Worktree-Isolierung beim Anlegen des Workspace, Statuserkennung der Agents und Broadcast in einer nativen App, statt drei einzelner Skripte und einer .tmux.conf, die Sie von Hand zusammenkleben.

Free- und Pro-Limits für diesen Ablauf

Der Kern dieses Leitfadens funktioniert im Free-Tarif: Aufteilung in zwei Panes, Worktree-Isolierung, Broadcast-Modus und ein Control Room mit 2 Mitgliedern. Die Zahlen spielen erst eine Rolle, wenn Sie über ein Paar von Agents hinauswachsen.

Standardmäßig hat Free kein Limit für Terminal-Panes. Es erlaubt 5 gespeicherte SSH-Hosts, 2 Mitglieder pro Control Room und 1 gespeicherten Rechner. Pro hebt die Grenzen für SSH-Hosts und die Mitglieder im Control Room auf.

Der Free-Tarif ist also keine abgespeckte Demo dieses Ablaufs. Die Grenzen zeigen sich erst, wenn Sie größere Gruppen von Agents betreiben oder neben Ihren Agents eine ganze Flotte von SSH-Hosts verwalten.

Wenn es nicht klappt: typische Stolperstellen

Die Panes wurden ohne Worktrees geöffnet. Der Ordner war kein Git-Repository. MXterm Pro führt seit 1.0.22 nicht mehr selbst git init aus. Das geschah früher automatisch und konnte eine .env oder einen Schlüssel in eine brandneue Historie ziehen, die niemand angefordert hatte. Deshalb fällt die App auf normale, gemeinsam genutzte Panes zurück und nennt Ihnen den Grund.

Führen Sie selbst git init aus und erstellen Sie den Workspace dann erneut. Hat das Repository noch keine Commits, legt MXterm Pro einen „Initial commit“ an, der nur eine leere Datei .gitkeep enthält, damit die Worktrees angelegt werden können. Sonst wird nichts aus dem Ordner committet.

Beide Agents landen immer wieder in denselben Dateien. Die Worktree-Isolierung verringert Kollisionen bei Branches und beim ausgecheckten Stand. Aber zwei Agents können trotzdem beide beschließen, aus ihrer eigenen Kopie zum Beispiel eine gemeinsame Konfigurationsdatei anzufassen. Das ist ein Problem der Aufgabenaufteilung, das die Isolierung nicht löst. Teilen Sie die Arbeit entlang echter Modulgrenzen auf.

Broadcast hat eine Antwort an das falsche Pane geschickt. Das ist der häufigste Fehler mit Broadcast. Der Modus bleibt an, bis Sie ihn ausschalten. Eine Antwort, die für die Rückfrage eines Agents gedacht war, geht deshalb an alle. Schalten Sie Cmd+Shift+B aus, bevor Sie etwas eingeben, das nur für ein Pane gilt.

Den Worktree-Branch zurückzumergen fühlt sich nach zusätzlichen Schritten an. Es ist absichtlich ein zusätzlicher Schritt. Die Isolierung hält die Arbeitskopien während des Laufs auseinander, aber MXterm Pro mergt nicht automatisch. Behandeln Sie jeden Worktree-Branch wie einen normalen Feature-Branch: Prüfen Sie den Diff, mergen Sie dann oder öffnen Sie einen PR, wie Sie es sonst auch tun.