Emdash: mehrere Coding-Agents parallel in getrennten Git-Worktrees

Welches Problem Emdash adressiert

Wer heute mit Coding-Agents arbeitet, kennt das Muster: ein Terminal pro Agent, ein Branch pro Versuch, und irgendwann verliert man den Überblick darüber, welcher Agent welche Datei angefasst hat. Emdash setzt genau dort an. Die Desktop-Anwendung startet mehrere Agents gleichzeitig und legt für jede Aufgabe einen eigenen Git-Worktree an, sodass sich parallele Fixes und Features unabhängig voneinander entwickeln lassen. Der Worktree ist dabei kein Nebeneffekt, sondern die eigentliche Isolationsgrenze: Änderungen des einen Laufs sind im Arbeitsverzeichnis des anderen nicht sichtbar, bis sie zusammengeführt werden. Die Zielgruppe sind Entwicklerinnen und Entwickler, die bereits eine oder mehrere Agent-CLIs installiert haben und diese nicht mehr einzeln in Terminals betreuen wollen. Das README nennt als unterstützte Agents unter anderem Claude Code, Codex, Cursor, OpenCode, Amp, Devin, Qwen Code, Droid und GitHub Copilot. Emdash ersetzt diese Werkzeuge nicht, es orchestriert sie.

Git-Worktrees als Isolationsschicht

Das Modell ist einfach: eine Aufgabe, ein Worktree, ein Branch. Das README beschreibt den Ablauf als parallele Erkundung mehrerer Wege, bei der am Ende zusammengeführt wird, was funktioniert. Technisch greift Emdash damit auf ein Git-Feature zurück, das seit Jahren existiert, aber selten bequem zu bedienen war. Ein Worktree teilt sich das Repository-Objektverzeichnis mit dem Haupt-Checkout, hat aber ein eigenes Arbeitsverzeichnis und einen eigenen HEAD. Genau das macht parallele Agenten erst sinnvoll: zwei Agents können gleichzeitig in derselben Codebasis arbeiten, ohne sich gegenseitig die Dateien zu überschreiben. Der Preis dafür ist bekannt und wird im README nicht ausgeführt: mehrere Worktrees bedeuten mehrere vollständige Arbeitskopien auf der Platte, und jede Abhängigkeitsinstallation, jeder Build und jeder Testlauf fällt pro Worktree an. Ein Projekt mit großem node_modules oder langen Kompilierzeiten multipliziert diesen Aufwand mit der Zahl der parallel laufenden Agents.

Wie Emdash die Agents anbindet

Emdash erkennt installierte Provider-CLIs automatisch, statt eigene Modelle mitzubringen. Der relevante Mechanismus steht im README: Für Agents mit Unterstützung für Lifecycle-Hooks installiert Emdash marker-tagged Einträge in der Benutzerkonfiguration des jeweiligen Agents. Diese Hooks melden Statusänderungen zurück, ermöglichen Benachrichtigungen und erlauben wiederaufnehmbare Sitzungen. Wichtig ist der Zusatz, dass die Hooks stillschweigend nichts tun, wenn der Agent außerhalb einer Emdash-Sitzung läuft. Das ist ein sauberer Entwurf, weil er den Agent auch außerhalb der Anwendung benutzbar lässt. Es bedeutet aber auch, dass Emdash in die Konfiguration eines fremden Werkzeugs schreibt. Wer seine Agent-Konfiguration versioniert oder über ein Dotfiles-Repository verteilt, sollte vorher prüfen, welche Einträge hinzukommen. Die Dokumentation verweist für die vollständige Liste und das providerspezifische Verhalten auf eine eigene Seite, die im vorliegenden Material nicht enthalten ist.

Installation und Betrieb

Emdash wird als Desktop-Build ausgeliefert, nicht als npm-Paket. Auf macOS lautet der Befehl aus dem README brew install --cask emdash, alternativ stehen DMGs für Apple Silicon und Intel bereit. Für Windows gibt es einen Installer und eine portable EXE, für Linux x64 und ARM64 jeweils AppImage, DEB und RPM. Ein headless Modus, ein Docker-Image oder eine CLI zum Starten von Emdash selbst taucht im README nicht auf, obwohl das Repository-Thema containerization enthält. Diese Lücke ist relevant: Wer Agents in einer Pipeline oder auf einem Build-Server betreiben will, findet hier keinen dokumentierten Einstieg. Die Anwendung ist ausdrücklich lokal-first. Der Zustand liegt in einer lokalen SQLite-Datenbank, und laut README sendet Emdash weder Code noch Chats an eigene Server. Telemetrie ist optional und lässt sich in den Einstellungen oder beim Start über TELEMETRY_ENABLED=false abschalten. Der Hinweis auf die Provider ist korrekt und wichtig: Die Agent-CLIs selbst können Code, Prompts und Kontext an ihre Anbieter übertragen, und dieses Verhalten hängt allein vom gewählten Provider ab.

Tickets, Diffs und Remote-Maschinen

Neben der reinen Orchestrierung verbindet Emdash Ticketsysteme mit den Agenten. Das README nennt Linear, GitHub, Jira, GitLab, Asana, Featurebase, Monday.com, Forgejo und Plain als Quellen, aus denen sich Issues an einen Agenten schicken lassen. Ebenso lassen sich Diffs prüfen, Pull Requests erstellen, CI-Checks ansehen und Merges auslösen, ohne die Anwendung zu verlassen. Das ist der Teil, der den größten praktischen Unterschied macht, weil er den Kontextwechsel zwischen Browser, Terminal und Git-Client reduziert. Für Remote-Arbeit unterstützt Emdash SSH und SFTP, mit Authentifizierung per SSH-Agent, Schlüssel oder Passwort, wobei die Zugangsdaten laut README in der Schlüsselbundverwaltung des Betriebssystems liegen. Die Details stehen auf einer separaten Dokumentationsseite. Wer auf entfernten Maschinen arbeitet, sollte beachten, dass dort dieselben Provider-CLIs vorhanden sein müssen, denn Emdash bringt sie nicht mit.

Grenzen und Fälle, in denen Emdash das falsche Werkzeug ist

Die deutlichste Einschränkung ist die Form der Auslieferung. Emdash ist eine Desktop-Anwendung. Es gibt keinen dokumentierten Weg, sie ohne grafische Oberfläche zu betreiben, und damit auch keinen, sie in eine CI-Umgebung oder einen Container einzubinden. Teams, die Agents reproduzierbar auf einem Server ausführen wollen, brauchen etwas anderes. Ein zweiter Punkt betrifft die Kosten: Jeder Worktree ist eine eigene Arbeitskopie, und bei vielen parallelen Agents wächst der Ressourcenbedarf entsprechend. Das README geht darauf nicht ein. Drittens hängt der Komfort an den Hooks. Ohne Hook-Unterstützung im jeweiligen Agent fehlen Statusverfolgung, Benachrichtigungen und wiederaufnehmbare Sitzungen, und die Anwendung fällt auf das zurück, was der Agent von sich aus meldet. Viertens ist der Umfang der Anbieterintegrationen nicht belegt. Das README listet neun Ticketsysteme, aber nicht, welche davon nur Lesen erlauben und welche Statusänderungen zurückschreiben. Wer Jira oder Linear als führendes System nutzt, sollte das vor der Einführung klären.

Alternative und der eigentliche Unterschied

Die naheliegende Alternative ist der manuelle Weg: mehrere Terminalfenster, für jeden Agent ein eigener Aufruf von git worktree add, dazu ein Git-Client und ein Browser für Tickets und Pull Requests. Dieser Ansatz kostet keine zusätzliche Abhängigkeit und funktioniert auf jedem Rechner, auf dem Git und die Agent-CLI installiert sind. Er skaliert nur nicht über drei oder vier parallele Läufe hinaus, weil die Zuordnung von Fenster zu Worktree zu Branch zu Ticket im Kopf stattfindet. Genau diese Zuordnung ist das, was Emdash übernimmt, und zwar in einer Oberfläche, die den Status der Agents, die Diffs und die CI-Checks an einer Stelle zeigt. Der Unterschied liegt also nicht in der Fähigkeit, mehrere Agents zu starten, sondern darin, den Überblick darüber zu behalten. Wer diesen Überblick bereits über Skripte und tmux herstellt und damit zufrieden ist, gewinnt durch Emdash wenig hinzu.

Wartung, Versionen und Lizenz

Das Repository zeigt eine hohe Release-Frequenz. Neben stabilen Versionen wie v1.2.4 vom 7. September 2026 erscheinen canary-Builds im Abstand von Stunden, im vorliegenden Ausschnitt v1.2.4-canary.92 und v1.2.4-canary.91. Daraus lässt sich ableiten, dass das Projekt aktiv entwickelt wird, aber nicht, wie stabil die stabilen Builds sind. Für die Update-Kosten heißt das: Wer Emdash einsetzt, muss mit häufigen Aktualisierungen rechnen, und bei einer Desktop-Anwendung mit Hooks in fremden Konfigurationsdateien lohnt es sich, vor jedem Sprung auf eine neue Version zu prüfen, ob die Hooks noch zur installierten Agent-Version passen. Emdash steht unter der Apache-2.0-Lizenz. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, verlangt aber die Beibehaltung der Lizenzhinweise und der Datei, die auf Änderungen hinweist. Wer die Anwendung forkt und intern verteilt, sollte diese Pflichten mit der eigenen Rechtsabteilung klären; eine Rechtsberatung ist an dieser Stelle nicht möglich und nicht beabsichtigt. Die Lizenz betrifft ausdrücklich nur Emdash selbst, nicht die Agent-CLIs und nicht die Anbieter, an die diese Daten senden.

Redaktionelles Fazit

Wer mehrere Coding-Agents nebeneinander laufen lässt und dabei nicht den Überblick über Branches und Diffs verlieren will, findet in Emdash eine lokale Desktop-Oberfläche, die auf bestehenden Provider-CLIs aufsetzt statt sie zu ersetzen. Wer Agents in CI-Pipelines, in Containern oder auf Servern ohne Bildschirm ausführen muss, ist hier falsch, weil das Projekt nur als Desktop-App für macOS, Windows und Linux ausgeliefert wird. Vor dem Einsatz sollte man klären, welche Provider-CLI in welcher Version installiert ist und ob die Hooks in der Benutzerkonfiguration des Agents akzeptiert werden, denn davon hängen Status, Benachrichtigungen und wiederaufnehmbare Sitzungen ab.

Offizielle Quellen

1. generalaction/emdash on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases