Was ist Worktrunk?
Worktrunk von Maximilian Roos ist ein Kommandozeilen-Tool (wt) zur Verwaltung von Git-Worktrees. Es ist selbst kein KI-Tool; es existiert, weil mehrere gleichzeitig laufende Coding-Agenten wie Claude Code oder Codex jeweils ein eigenes Arbeitsverzeichnis brauchen und die Worktree-Befehle von Git umständlich sind. Worktrees werden über den Branch-Namen angesprochen, und wt switch -c -x claude feat legt Branch und Worktree an und startet darin in einem Schritt einen Agenten.
Rund um die drei Kernbefehle (switch, list, remove) ergänzt es Hooks beim Anlegen und Mergen, von einem LLM geschriebene Commit-Nachrichten, Squash, Rebase und Merge mit einem Befehl, PR-Checkout, CI-Status in wt list und Copy-on-Write-Teilen von Build-Caches wie node_modules und target/ zwischen Worktrees.
Das Repo steht wahlweise unter MIT oder Apache-2.0, ist in Rust geschrieben und hat etwa 9.700 GitHub-Sterne. Version 0.81.0 erschien am 20. Oktober 2026, und das Crate hat etwa 41.000 Downloads auf crates.io.
Lohnt sich Worktrunk?
Worktrunk löst ein eng umrissenes Problem gut, und das Problem ist verbreitet geworden. Sobald ein Coding-Agent eine halbe Stunde unbeaufsichtigt arbeiten kann, liegt es nahe, fünf oder zehn gleichzeitig laufen zu lassen, und Git-Worktrees sind der übliche Weg, damit sie sich nicht gegenseitig überschreiben. Mit Git allein ist das mühsam: Einen Worktree und darin einen Agenten anzulegen heißt, den Branch-Namen dreimal zu tippen, verteilt auf git worktree add, cd und den Agentenbefehl, und das Aufräumen kostet drei weitere. Worktrunk macht daraus jeweils einen Befehl und berechnet die Pfade aus einer Vorlage, sodass sich Worktrees wie Branches verhalten.
Was es über einen Shell-Alias hinaushebt, ist die Schicht um den Kern. wt list zeigt jeden Worktree mit gestagten Änderungen, Commits vor main, nicht gepushter Arbeit und im Vollmodus CI-Status und einer KI-Zusammenfassung pro Branch. Hooks installieren Abhängigkeiten oder starten einen Dev-Server, wenn ein Worktree angelegt wird, und ein hash_port-Filter gibt jedem Worktree seinen eigenen Port. Auf APFS, btrfs und XFS teilt es node_modules und target/ per Copy-on-Write, zehn Worktrees bedeuten also nicht zehn kalte Builds, und genau diese Kosten unterschätzen die meisten. wt merge erledigt Squash, Rebase, Merge und das Entfernen des Worktrees in einem Zug.
Die entscheidende Designentscheidung ist, dass Worktrunk dem Agenten nicht im Weg steht. Anders als claude-squad oder orca hüllt es Agenten nicht in ein eigenes Terminal oder eine Desktop-Oberfläche; es verwaltet nur Verzeichnisse und Branches und funktioniert daher mit jedem Agenten und jedem Terminal-Multiplexer. Der Preis dafür ist, dass es nichts zur Koordination der Agenten selbst beiträgt: Merge-Konflikte zwischen parallelen Branches und die Review-Last von zehn Diffs bleiben bei dir.
Das Projekt ist jung und bewegt sich schnell, bei Version 0.81 nach etwa einem Jahr, mit 62 offenen Issues und einem Hauptmaintainer. Die Nummerierung vor 1.0 bedeutet, dass sich Flags und Konfiguration noch ändern können. Unter Windows kollidiert wt mit dem gleichnamigen Befehl von Windows Terminal, daher installiert winget es als git-wt. Nichts davon wiegt schwerer als das Wenige, das es verlangt: ein Binary, eine Zeile Shell-Integration und Git.
Wo es sich lohnt
Ein Solo-Entwickler mit drei Claude-Code-Sessions auf einem Rust-Repo
Jeden Agenten auf seinem eigenen Branch starten, ohne cd und Worktree-Boilerplate
wt switch -x claude -c feature-a -- 'Add user authentication', pro Aufgabe wiederholt; ein post-start-Hook führt Installationen aus, und target/ wird auf APFS per Copy-on-Write geteilt. Kostenlos; spart den kalten Build pro Worktree.
Eine Tech Lead in einem Webteam mit sechs Leuten, das parallele Agenten erprobt
Auf einen Blick sehen, welche Agenten-Branches voraus sind, Änderungen haben oder in der CI scheitern
wt list --full zeigt gestagte Änderungen, Commits vor main, nicht gepushte Arbeit und CI-Status pro Worktree; wt switch pr:123 springt zum PR eines Kollegen. Keine Lizenzkosten, nur die Review-Zeit, die die zusätzlichen Branches verursachen.
Ein Frontend-Entwickler, dessen Agenten jeweils einen laufenden Dev-Server brauchen
Mehrere Dev-Server nebeneinander ohne Portkonflikte betreiben
Nutze den Vorlagenfilter hash_port in einem Hook, damit jeder Worktree einen stabilen, eindeutigen Port bekommt; danach erledigt wt merge main Squash und Rebase und entfernt den Worktree, wenn die Aufgabe gemergt ist.
Bevor du dich festlegst
- Einrichtung
- brew install worktrunk oder cargo install worktrunk, dann wt config shell install, damit wt Verzeichnisse wechseln kann; auch über winget, pacman und conda-forge erhältlich. Ein erster Worktree dauert unter einer Minute.
- Integrationen
- Startet jeden Agenten über -x (die Integration mit Claude Code ist dokumentiert), liest PRs und CI-Status aus GitHub und GitLab und läuft in jedem Terminal oder Multiplexer wie Zellij oder tmux.
- Daten und Datenschutz
- Ein lokales Binary, das Git steuert; LLM-Commit-Nachrichten und Branch-Zusammenfassungen rufen den Modellbefehl auf, den du konfigurierst. Doppellizenz MIT oder Apache-2.0; keine Sicherheitshinweise veröffentlicht.
- Kosten im großen Maßstab
- Keine kostenpflichtige Edition. Die echten Kosten sind Speicherplatz für jeden Worktree, verringert durch Copy-on-Write-Cache-Teilen auf unterstützten Dateisystemen, und die Review-Zeit für die parallelen Branches.
- Grenzen
- 62 offene Issues und Versionierung vor 1.0; Copy-on-Write-Cache-Teilen braucht APFS, btrfs oder XFS; es verwaltet Verzeichnisse, nicht Agenten, und sieht daher nicht, was jeder Agent tut.
Was gut ist
- Ein Befehl legt einen Worktree an und startet darin einen Agenten
- Copy-on-Write-Teilen von node_modules und target/ zwischen Worktrees
- wt list zeigt Änderungen, Vorsprung und Rückstand sowie CI-Status pro Branch
- Funktioniert mit jedem Agenten; keine eigene Oberfläche oder Laufzeit
Was nicht
- Vor 1.0 mit schnellen Releases; Flags und Konfiguration können sich ändern
- Tut nichts gegen Konflikte zwischen parallelen Branches
- Namenskollision mit Windows Terminal; dort als git-wt installiert
- Cache-Teilen nur auf APFS, btrfs und XFS
Am besten für
Entwickler, die mehrere Coding-Agenten parallel auf einem Repo betreiben und Worktrees verwaltet haben wollen, ohne gleich ein ganzes Agenten-Dashboard einzuführen.
Alternativen zu Worktrunk
Worktrunk: häufige Fragen
- Lohnt sich Worktrunk?
- Ganz normale Git-Worktrees ohne die Reibung, und für alle, die Agenten parallel betreiben, war genau diese Reibung das ganze Problem. Wir bewerten es mit 4.4 von 5.
- Was kostet Worktrunk?
- Kostenlos und Open Source (MIT oder Apache-2.0).
- Welche Nachteile hat Worktrunk?
- Vor 1.0 mit schnellen Releases; Flags und Konfiguration können sich ändern; Tut nichts gegen Konflikte zwischen parallelen Branches; Namenskollision mit Windows Terminal; dort als git-wt installiert; Cache-Teilen nur auf APFS, btrfs und XFS.
- Für wen eignet sich Worktrunk?
- Entwickler, die mehrere Coding-Agenten parallel auf einem Repo betreiben und Worktrees verwaltet haben wollen, ohne gleich ein ganzes Agenten-Dashboard einzuführen.
- Was kostet Worktrunk für ein Team oder im Produktivbetrieb?
- Keine kostenpflichtige Edition. Die echten Kosten sind Speicherplatz für jeden Worktree, verringert durch Copy-on-Write-Cache-Teilen auf unterstützten Dateisystemen, und die Review-Zeit für die parallelen Branches.
- Ist Worktrunk sicher für Firmendaten?
- Ein lokales Binary, das Git steuert; LLM-Commit-Nachrichten und Branch-Zusammenfassungen rufen den Modellbefehl auf, den du konfigurierst. Doppellizenz MIT oder Apache-2.0; keine Sicherheitshinweise veröffentlicht.
- Was sind die besten Alternativen zu Worktrunk?
- Die nächsten Alternativen, die wir getestet haben, sind Claude Squad, Orca und Vibe Kanban.
Antworten geprüft am 31. Okt. 2026.