Helmor: lokale Workbench für parallele Coding-Agenten mit Git-Worktrees
Dieses Projekt rundet „Open-source local workbench for multi-agent software development.“ zu einer praxistauglichen Open-Source-Lösung zusammen, mit wiederverwendbarer Tooling- und Integrationsunterstützung für reale Anwendungsfälle.
Auf einen Blick
- Was ist das?
- Helmor von dohooo orchestriert Coding-Agenten wie Claude Code, Codex, Cursor, OpenCode und Kimi Code lokal unter ~/helmor/, jede Aufgabe in einem isolierten Git-Worktree. Der Text ordnet Arbeitsweise, Benutzeroberfläche, CLI, MCP-Server und den experimentalen Mobile-Begleiter ein.
- Für wen ist es gedacht?
- Helmor passt für Entwickler, die mehrere Coding-Agenten parallel auf einem eigenen Rechner führen wollen und dabei Diffs, Tests und PR-Erstellung in einem Fenster behalten möchten, ohne Cloud-Zwischenschicht. Vorausgesetzt werden macOS auf Apple Silicon oder Intel beziehungsweise Windows x64 und ein Konto bei GitHub oder GitLab für den ersten Start.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 25 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Die Lücke, die Helmor schließen will
Das README von Helmor beginnt mit einer Diagnose: KI hat das Schreiben von Code beschleunigt, und genau dort setzt das Projekt an, um den Rest der Schleife zu schließen, also Orchestrierung, Review, Testen, Mergen und das tatsächliche Ausliefern. Helmor versteht sich als local-first Workbench für Coding-Agenten: Alles läuft auf dem eigenen Rechner, die Daten liegen unter ~/helmor/, und es gibt keine serverseitige Vermittlungsinstanz zwischen Entwickler und Agent.
Konkret heißt das: Viele Agenten laufen parallel, jeder in seinem eigenen isolierten Git-Arbeitsbereich mit eigener Konversation, eigenen Diffs, Editor und Terminals. Mit 1.295 Sternen und Apache-2.0-Lizenz in TypeScript ist das Projekt aus dem Haus dohooo noch jung, die Release-Historie mit v0.45.1, v0.45.2 und v0.46.0 innerhalb einer Woche im Juli 2026 zeigt eine schnelle Iterationsphase. Der Vorschau-Screenshot wird für dunkle und helle Systemdesign getrennt ausgeliefert, was zur Desktop-Anwendung als Zielplattform passt.
Isolierte Workspaces über Git-Worktrees
Die zentrale Idee der Arbeitsorganisation ist der Workspace: pro Aufgabe ein Git-Worktree und ein eigener Branch unter ~/helmor/workspaces/. Der Vorteil liegt in der Parallelschaltung, denn Agenten können sich so gegenseitig nicht in die Quere kommen, weil jeder in seiner eigenen Kopie des Repositories arbeitet. Das Grundmuster lautet im README in vier Schritten: Repository hinzufügen als lokalen Klon oder per URL, Workspace anlegen, den Agenten mit einer Beschreibung starten, dann Review und Versand über Diff, Tests und PR.
Diese Struktur nutzt eine bewährte Git-Fähigkeit, statt ein eigenes Sandbox-Konzept zu erfinden, und macht den Zustand einer Aufgabe für jedes andere Git-Werkzeug lesbar. Wer einen Workspace verlässt, hinterlässt einen Branch, der sich wie jeder andere weiterbehandeln lässt. Der Ablauf ist als Schleife gedacht, der Mermaid-Fluss im README zeichnet die Rückführung von Review und Versand zum nächsten Workspace als Wiederholung in Parallelität.
Agenten mitbringen: eigene Logins, Schlüssel und Provider
Helmor bündelt die Agent-CLIs selbst, im ersten Start ist nichts nachzuinstallieren; man verbindet GitHub oder GitLab und meldet sich beim ersten Agenten an. Unterstützt werden laut README Claude Code, Codex, Cursor, OpenCode und Kimi Code, und zwar mit den eigenen Anmeldungen, API-Schlüsseln und benutzerdefinierten Providern. Das Werkzeug ersetzt damit die Konten nicht, es stellt die Arbeitsumgebung darum herum.
Für den Alltag ist die Schnittstelle in ein Fenster gelegt: Diffs, der Monaco-Editor und Terminals stehen neben der Agentenkonversation, der Review bleibt also im selben Kontext wie der Auftragslauf. Der Terminal Mode ergänzt dies, indem er Prompts in der nativen Textoberfläche des Agenten laufen lässt oder eine GUI-Konversation im Terminal fortsetzt. Als Verschnitt zwischen beiden Welten dient die Schnellpaneel-Taste Umschalt-Alt-Leertaste, die ein schwebendes Fenster zum Start eines Workspace aus jedem Programm heraus öffnet.
Versand über eine Schaltfläche: PR, Merge und CI-Reparatur
Die Auslieferungssseite ist als Ein-Knopf-Weg beschrieben: PR oder MR anlegen, mergen, CI-Fehler beheben, Konflikte auflösen, gestapelte PRs, beides für GitHub und GitLab. Damit zieht Helmor den Teil der Arbeit in die Workbench, der nach dem Agentenlauf üblicherweise zwischen Terminal, Browser und PR-Benutzeroberfläche pendelt. Ein Beispiel im README zeigt den vorgesehenen Fluss eines Agenten, der eine Korrektur selbst ausliefert.
Die UI-Komponente Skills wird über die Einführung oder unter Settings, Helmor Components installiert und im Composer über die Taste / durchsucht. Als experimentell markiert ist der Mobile-Begleiter: über einen Cloudflare-Tunnel zur Desktop-Maschine lassen sich Aufgaben aus dem Telefonbrowser starten. Als kommende Erweiterungen nennt das README Slack- und GitHub-Kontext, einen Plan-Modus und agentengetriebene Orchestrierung; diese Punkte sind angekündigt, aber noch nicht Teil des Funktionsumfangs.
Die helmor-CLI und der MCP-Server
Für die Skriptebene gibt es zwei Wege. Der erste ist die CLI, installiert über Settings, Experimental, Command Line Tool. Sie arbeitet gegen dieselbe lokale Datenbank wie die Anwendung, sogar während sie läuft. Die Befehlsfolge aus dem README: helmor repo add /path/to/repo meldet ein Repository an, helmor workspace new --repo myapp erzeugt einen Workspace, helmor workspace list zeigt den Bestand, helmor send --workspace myapp/feature-x "Add a test for the parser edge case." verschickt einen Auftrag, helmor workspace status meldet den Zustand, und helmor workspace run-action stößt die Versandaktionen an. Über helmor mcp startet sich ein MCP-Server über stdio.
Workspaces werden in der Kurzform repo-name/directory-name angesprochen, jeder Befehl unterstützt --json, und helmor --help listet die vollständige Referenz. Der zweite Weg ist genau dieser MCP-Server, mit dem ein anderes Werkzeug oder ein anderer Agent Helmor steuern kann. Damit ist die Workbench nicht nur ein Ort für Menschen, sondern auch ein Ansatzpunkt für übergeordnete Automatisierung, die selbst Agenten startet.
Beitragen und die Entwicklung mit Bun
Für Beitragende verweist das README auf die Datei AGENTS.md, in der Architektur, Befehle und Testanordnung dokumentiert sind. Der lokale Start läuft mit bun install && bun run dev, das Projekt ist also auf Bun als Laufzeit und Werkzeugkette ausgerichtet. Ungewöhnlich ist der selbstreferenzielle Beitragsweg: Wer fragt, wie man zu Helmor beitragen kann, soll es in Helmor selbst importieren und den Agenten fragen, das README zitiert diese Anweisung als That's the guide.
Die Gemeinschaftswege sind Discord für Fragen und Release-Gespräche, GitHub Issues für Fehler und Funktionswünsche sowie der Feedback-Knopf am unteren Rand der Seitenleiste. Lizenz ist Apache 2.0 über die LICENSE-Datei im Repository. Insgesamt präsentiert sich das Projekt als schnell rotierendes Werkzeug in der v0.x-Phase, bei dem die Dokumentation in README und AGENTS.md samt docs.helmor.ai der verlässlichste Referenzpunkt bleibt.
Redaktionelles Fazit
Helmor passt für Entwickler, die mehrere Coding-Agenten parallel auf einem eigenen Rechner führen wollen und dabei Diffs, Tests und PR-Erstellung in einem Fenster behalten möchten, ohne Cloud-Zwischenschicht. Vorausgesetzt werden macOS auf Apple Silicon oder Intel beziehungsweise Windows x64 und ein Konto bei GitHub oder GitLab für den ersten Start. Wer das Werkzeug übernehmen will, sollte zuerst die CLI nach Settings, Experimental, Command Line Tool installieren und mit helmor repo add und helmor workspace new einen Probelauf gegen ein Nebencode-Repository fahren, bevor ein Hauptprojekt darauf wandert.
Community-Notizen