KI-Coding-Agents mit Git Worktrees voneinander isolieren

Wer Worktree-Isolierung pro Agent wirklich braucht

Ein einzelner Agent allein in einem Repository hat nichts, womit er kollidieren könnte. Das Hauptarbeitsverzeichnis reicht, und die Isolierung bringt Ihnen nichts.

Sinnvoll wird sie, sobald Sie zwei oder mehr Agents gleichzeitig am selben Repository arbeiten lassen. Der Swarm Task Orchestrator von MXterm Pro bringt dafür zwei Presets mit. „Full Swarm Trio (Lead, QA, Docs)“ startet Claude Code, Codex und OpenCode gemeinsam. „Feature Duo (Dev + Tester)“ kombiniert Claude Code mit Codex. Beide schalten die Worktree-Isolierung standardmäßig ein, wenn Sie sie starten.

Ein Preset brauchen Sie nicht. Öffnen Sie einen neuen Tab, wählen Sie die Agents und haken Sie im Composer selbst „Features in git worktrees isolieren“ an. Das Kästchen ist standardmäßig aus und funktioniert nur in einem Git-Repository. Panes, die Sie danach abspalten, öffnen sich im Workspace-Ordner und nicht in einem eigenen Worktree.

Wie MXterm Pro für jedes Agent-Pane einen Worktree anlegt

Der Schalter erscheint an zwei Stellen, die dasselbe bewirken: im Bildschirm „Neuer Workspace“ („Features in git worktrees isolieren“) und im Dialog des Swarm Task Orchestrators („Features in git worktrees isolieren“), den Sie beim Starten eines Presets sehen. Dieselbe Einstellung beschreiben auch die Dokumentation zu Agents und Control Room (früher War Room).

Ist er an, bekommt jedes neue Agent-Pane einen eigenen Checkout im Verzeichnis .worktrees/ des Repositorys. Der Branch wird frisch erzeugt und heißt swarm/<adjective>-<noun>, zum Beispiel swarm/brave-otter. Ein einfaches Terminal-Pane ohne Agent öffnet sich weiterhin unberührt im Repository-Stammverzeichnis.

Der Name wird zufällig aus einem Pool von rund 17.000 Kombinationen gezogen, nicht nach einem nummerierten Schema. Zwei Läufe greifen deshalb nie zufällig auf einen veralteten Worktree zurück. Ist der Name schon vergeben, versucht MXterm es mit einem numerischen Suffix (swarm/brave-otter-2, dann -3 und so weiter). Insgesamt probiert es höchstens fünf Namen, bevor es für dieses Pane aufgibt.

MXterm trägt das Verzeichnis .worktrees/ beim ersten Anlegen automatisch in die .gitignore des Repositorys ein. Diese Wegwerf-Checkouts tauchen deshalb nie als nicht verfolgte Änderungen in Ihrem Haupt-Arbeitsverzeichnis auf.

Ist der Ordner, den Sie in MXterm öffnen, kein Git-Repository, wird die Isolierung übersprungen statt erzwungen. Bis 1.0.21 führte die App in solchen Ordnern git init, git add . und einen Commit aus. Dabei konnte eine .env oder ein privater Schlüssel in eine Historie geraten, die niemand wollte. Seit 1.0.22 führt sie dort kein git init mehr aus.

Das Eingabeformular des Workspace-Composers meldet jetzt „Dieser Ordner ist kein git-Repository, daher teilen sich die Agents ihn direkt (keine worktree-Isolierung)“. Die Panes öffnen sich ohne Isolierung im Ordner-Stammverzeichnis, und jedes zeigt einen schließbaren Hinweis mit dem Grund. Führen Sie git init aus und machen Sie selbst den ersten Commit, wenn Sie die Isolierung wollen.

Eine Ausnahme: In einem vorhandenen Repository ohne Commits legen der Composer von „Neuer Workspace“ und der Dialog des Swarm Task Orchestrators eine leere .gitkeep an und committen nur diese Datei als „Initial commit“, bevor sie Worktrees erzeugen (andere Dateien im Ordner werden nicht gestaged), denn ein Worktree braucht einen Commit, von dem er abzweigen kann.

Der Header jedes Panes zeigt den Branch-Namen seines Worktrees als kleines Badge. So sehen Sie, auf welchem Branch ein Agent steht, ohne das Git-Panel zu öffnen.

Das Anlegen läuft absichtlich nacheinander. Gleichzeitige git worktree add-Aufrufe in einem Repository streiten um die Lock-Datei von Git, und ein vorübergehender Fehler würde die Isolierung eines Panes kosten. Lässt sich ein Worktree nicht anlegen (Git-Lock-Fehler, voller Datenträger oder eine andere Ursache, auch nach den Wiederholungen bei Namenskonflikten), fällt genau dieses Pane auf das Repository-Stammverzeichnis zurück und protokolliert eine Warnung. Der Rest des Workspaces öffnet sich trotzdem.

Was Isolierung verhindert und was nicht

Nehmen wir den konkreten Fall: Sie starten „Feature Duo“, und Claude Code landet auf einem eigenen Branch und Worktree, Codex auf einem anderen.

Ohne Isolierung teilten sich beide Agents ein Arbeitsverzeichnis. Führt Codex mitten in der Aufgabe git checkout oder git stash aus, ändern sich die Dateien, an denen Claude Code gerade arbeitet, ohne dass Claude Code es merkt. Beim nächsten Tool-Aufruf weiß keiner der beiden Agents, warum die Datei, die er gerade geschrieben hat, nicht dem entspricht, was er zurückliest.

Mit getrennten Worktrees hat jeder Agent seine eigene Kopie jeder Datei, ausgecheckt auf seinem eigenen Branch. Das verringert die Wahrscheinlichkeit, dass der Checkout eines Agents die Dateien umschreibt, die ein anderer Agent geöffnet hat.

Isolierung beseitigt nicht jede Art von Konflikt. Zwei Agents, die dasselbe Feature aus verschiedenen Richtungen bearbeiten, können weiterhin Branches erzeugen, die später einen echten, von Menschen geprüften Merge brauchen, und diesen Teil automatisiert MXterm nicht. Was die Isolierung beseitigt, ist enger gefasst und rein mechanisch: den Kampf auf Dateisystemebene um ein gemeinsames Arbeitsverzeichnis.

Ein Worktree ist keine Sandbox. Das Pane ist weiterhin eine normale Shell, daher kann ein Agent seinen Ordner verlassen und jeden Befehl ausführen, den Ihr Benutzerkonto ausführen darf. Außerdem teilen sich alle Worktrees das eine .git hinter dem Repository. Die Isolierung hält die Dateien der Agents auseinander, sie begrenzt nicht, was die Agents tun können.

Worktrees mitten in der Sitzung hinzufügen, mergen und entfernen

Die Isolierung wird nicht nur beim Anlegen des Workspaces festgelegt. Ein Agent kann mitten in der Sitzung mit dem Tool worktree.spawn ein neues, isoliertes Worker-Pane für eine delegierte Teilaufgabe erzeugen. Das funktioniert nur in einem Workspace, der mit eingeschalteter Worktree-Isolierung angelegt wurde.

Das Mergen bleibt absichtlich manuell. Sobald der Branch eines Agents fertig ist, mergen Sie ihn auf dem üblichen Weg: git merge swarm/brave-otter im Haupt-Worktree, oder Sie pushen ihn und öffnen einen Pull Request, so wie Ihr Team es ohnehin macht. MXterm kümmert sich nur um das Anlegen und später das Aufräumen des Worktrees. Was mit dem Code darin geschieht, entscheidet es nicht.

Das Entfernen ist bewusst vorsichtig, und zwei Aufrufer nehmen zwei getrennte Wege. Ein Agent darf nur einen Worktree entfernen, der keine nicht committeten Änderungen enthält. Andernfalls verweigert das Tool die Aktion ohne jede Möglichkeit, das zu umgehen.

Über die Oberfläche läuft es anders. „worktrees aufräumen…“ steht neben der Worktree-Liste des Git-Panels. Es bereinigt veraltete Einträge (einen Worktree, dessen Verzeichnis fehlt) ohne Rückfrage und öffnet dann einen Dialog.

Im Dialog sind Worktrees mit nicht committeten Dateien nach Branch aufgelistet, mit der Anzahl der Dateien je Worktree. Sie sind standardmäßig nicht angehakt, Sie haken also jeden an, den Sie entfernen wollen. Worktrees ohne nicht committete Änderungen werden nur als Zahl zusammengefasst und beim Bestätigen entfernt.

Der Dialog zählt nur Commits, die dem Upstream eines Branches voraus sind, und die von MXterm angelegten Branches haben keinen Upstream, daher zählt er für sie keine. Prüfen Sie die Commits eines Branches selbst, bevor Sie bestätigen, denn das Entfernen löscht den Branch mit git branch -D.

Keiner der beiden Wege läuft automatisch. Das Schließen eines Panes, eines Workspaces oder der ganzen App löscht nie von selbst einen Worktree. Aufgeräumt wird nur, wenn Sie oder ein Agent innerhalb seiner strengen Grenzen es gezielt tun.

Eine Einschränkung vorab: Das Verzeichnis eines Worktrees wird nach dem Anlegen nie umbenannt, weil der Sitzungszustand eines Agents an diesen absoluten Pfad gebunden ist. Den Git-Branch darin dürfen Sie frei umbenennen, den Ordner nicht.

Free und Pro: Was tatsächlich begrenzt ist

Die Worktree-Isolierung ist kein Schalter nur für Pro. Sie funktioniert in beiden Tarifen gleich.

Begrenzt ist die Größe eines Control Room. Standardmäßig hat Free kein Pane-Limit, begrenzt aber jeden einzelnen Control Room (Agents, die für einen gemeinsamen Kontext zusammengefasst sind) auf 2 Mitglieder. Weitere Free-Limits, 5 gespeicherte SSH-Hosts und 1 gespeicherter Rechner, haben mit Worktrees nichts zu tun. Pro hebt diese Limits auf.

Das Preset „Feature Duo“ (2 Agents, 2 Worktrees) passt problemlos in das Limit von 2 Mitgliedern im Control Room von Free. „Full Swarm Trio“ hat drei Agents, ein Control Room mit allen dreien braucht also Pro.

Git Worktrees im Vergleich zu iTerm2, Warp, Termius und MobaXterm

Die kostenlose Alternative zur Automatisierung von MXterm ist keine andere App. Es ist ein von Hand eingerichteter Git Worktree für jeden KI-Agent, mit den einfachen Befehlen git worktree add und git worktree remove in dem Terminal, das Sie ohnehin nutzen. Für einen oder zwei Agents funktioniert das gut.

MXterm Pro nimmt Ihnen den Verwaltungsaufwand ab, der mit der Zahl der Agents wächst: einen eindeutigen Branch-Namen wählen, den Worktree anlegen, das Arbeitsverzeichnis des Panes darauf ausrichten und verhindern, dass versehentlich ein Worktree mit nicht committeter Arbeit gelöscht wird.

iTerm2 ist ein ausgezeichneter, stark skriptbarer Terminal-Emulator für macOS. Wie andere reine Terminals legt es keine Git Worktrees für Sie an. Wer diesen Ablauf dort fährt, tippt für jedes Pane git worktree add von Hand und muss später selbst daran denken, git worktree remove auszuführen und den Branch zu löschen.

Warp stellt ebenfalls einen KI-Agent in den Mittelpunkt des Terminals. Es kann mehrere Agents gleichzeitig in getrennten Tabs oder Panes ausführen, und seine eigene Multi-Agent-Anleitung empfiehlt einen Git Worktree pro Agent (siehe MXterm Pro vs Warp). Der Ansatz von MXterm Pro ist enger: Bei eingeschalteter Isolierung legt es Branch und Worktree für jedes Agent-Pane selbst an.