Herdr vs. tmux: Was Detach und Server-Neustart wirklich überlebt

Was ist Herdr?

Herdr ist eine in Rust entwickelte, terminalbasierte Laufzeit für mehrere Coding-Agenten. Das Open-Source-Projekt steht laut Repository unter Apache-2.0-Lizenz. Der letzte stabile Release war zum Recherchezeitpunkt v0.9.1 vom 16. September 2026. Herdr stellt selbst kein Sprachmodell bereit, sondern organisiert externe Coding-CLIs wie Claude Code, Codex oder Hermes Agent.

Die Architektur trennt einen Hintergrundserver von den TUI- und CLI-Clients. Der Server besitzt die Pseudoterminals (PTYs) und hält die darin gestarteten Prozesse am Leben. Schließt du einen Client oder trennst eine SSH-Verbindung, bleibt der Server aktiv. Ein späterer Client kann sich wieder mit demselben Zustand verbinden.

Herdr arbeitet laut Dokumentation zur Agentenautomatisierung mit drei Ebenen:

Ebene	Aufgabe
Layout	Organisiert Workspaces, Tabs und Panes
Pane	Führt Shells, Tests, Server und andere Terminalprozesse aus
Agent	Ordnet einen erkannten Coding-Agenten einem Pane zu und verfolgt seinen Zustand

Das klingt zunächst nach tmux mit zusätzlicher Oberfläche. Der Unterschied liegt jedoch nicht im Detach selbst, sondern in den Agenten-Primitiven: Herdr kann Agenten benennen, Status auswerten, Prompts senden, auf Zustände warten und Terminalausgaben über CLI oder Socket lesen.

Was unterscheidet Herdr von tmux und Zellij?

tmux löst seit Jahren das grundlegende Problem: Prozesse laufen in einer Server-Session weiter, wenn sich ein Client trennt. Die offizielle tmux-Dokumentation beschreibt Detach und Reattach als Kernfunktion. Herdr erfindet diese Persistenz nicht neu.

Der zusätzliche Nutzen entsteht, wenn mehrere Coding-Agenten parallel laufen und eine Automatisierung wissen muss, ob ein Agent arbeitet, auf eine Freigabe wartet oder wieder Eingaben annehmen kann. tmux liefert diese Semantik nicht im Kern. Du kannst sie mit Skripten, Hooks und eigenen Statusdateien nachbauen, musst dann aber auch Erkennung, Fehlerfälle und Schnittstellen selbst pflegen.

Zellij bietet ebenfalls persistente Terminal-Sessions. Nach einem Crash kann es laut Dokumentation zur Session Resurrection Layouts und erkannte Befehle serialisieren. Diese Befehle werden standardmäßig erst nach manueller Bestätigung erneut ausgeführt. Das ist Rekonstruktion, keine Fortsetzung desselben Prozesses.

Kriterium	Herdr v0.9.1	tmux	Zellij
Detach und Reattach	Ja	Ja	Ja
Prozesse bei getrenntem Client weiter aktiv	Ja, solange der Herdr-Server läuft	Ja, solange der tmux-Server läuft	Ja, solange die Session läuft
Eingebaute Agentenzustände	Ja, mit Einschränkungen	Nein	Kein gleichwertiger Status durch die vorliegenden Quellen belegt
Agentenspezifisches Warten und Prompten	Ja, per CLI und Socket	Nur per eigener Logik	Nicht als gleichwertige Kernfunktion belegt
Zustand nach Server-Crash	Layout und Arbeitsverzeichnisse; Prozesse normalerweise weg	`kill-server` beendet Sessions	Layout und erkannte Befehle rekonstruierbar
Beliebige Prozesse nach Host-Reboot fortsetzen	Nein	Nein	Nein
Prozessisolation	Nein	Nein	Nicht Gegenstand dieses Vergleichs

Die nüchterne Einordnung lautet daher: Herdr ist ein Agent-Multiplexer, tmux ein allgemeiner Terminal-Multiplexer. Für normale Shell-Arbeit reicht tmux oft. Herdr wird interessant, wenn Agentenstatus und maschinenlesbare Steuerung Teil deines Workflows sind.

Was überlebt Detach, SSH-Abbruch und Server-Neustart?

Der Begriff „persistente Session“ ist zu ungenau. Entscheidend ist, welcher Prozess verschwindet: nur der Client, der Herdr-Server oder der ganze Host.

Ereignis	PTY und laufender Prozess	Layout und Arbeitsverzeichnis	Agentenkonversation
TUI-Client wird geschlossen	Bleiben aktiv	Bleiben aktiv	Läuft weiter
Normales Detach	Bleiben aktiv	Bleiben aktiv	Läuft weiter
SSH-Verbindung bricht ab	Bleiben aktiv, wenn der Herdr-Server auf dem Host weiterläuft	Bleiben aktiv	Läuft weiter
Herdr-Server wird normal neu gestartet	Werden normalerweise beendet	Werden aus einem Snapshot rekonstruiert	Bei gültiger unterstützter Integration und Session-Referenz in einem neuen Agentenprozess fortsetzbar
Herdr-Server crasht oder erhält `SIGKILL`	Werden beendet	Snapshot kann die Struktur wiederherstellen	Native Wiederaufnahme kann bei gültiger Integration und Session-Referenz möglich sein, ist aber kein Prozess-Checkpoint
Host-Reboot	Werden beendet	Snapshot kann die Struktur wiederherstellen	Erst nach erneutem Start von Herdr und Agent gegebenenfalls in einem neuen Prozess fortsetzbar
Experimentelles Live-Handoff	Best-Effort-Übergabe an einen neuen Herdr-Server	Bleibt erhalten	Kann ohne normalen Neustart weiterlaufen

Die Herdr-Dokumentation zu Session State und Restore trennt diese Mechanismen ausdrücklich. Beim Live-Betrieb gehören die PTYs dem laufenden Herdr-Server. Beim Snapshot Restore entstehen dagegen neue Shells in den gespeicherten Arbeitsverzeichnissen. Laufende Tests, Entwicklungsserver und beliebige Hintergrundprozesse werden nicht wiederbelebt.

Ein unabhängiger Test mit Herdr v0.7.4 bestätigte diese Grenze per `kill -9`: Das Layout kam zurück, die Prozesse und der vorherige Agentenstatus nicht. Das ist ein nützlicher Gegencheck, aber kein aktueller Test von v0.9.1. Die heutige Dokumentation beschreibt weiterhin dieselbe grundsätzliche Trennung.

Native Session-Wiederaufnahme ist kein Prozess-Checkpoint

Unterstützte Agenten können ihre eigene Konversation anhand einer Session-ID fortsetzen. Herdr speichert diese Referenz über die jeweilige offizielle Integration und startet nach einem Server-Neustart einen neuen Agentenprozess mit dessen Resume-Funktion. Dafür müssen die Integration und die gespeicherte Session-Referenz weiterhin gültig sein. Nach einem Host-Reboot müssen außerdem Herdr und der Agent erneut gestartet werden. Ist die Referenz ungültig oder veraltet, bleibt nur eine normale neue Shell.

Gesprächskontext kann dadurch zurückkehren, der alte Prozesszustand jedoch nicht. Das schützt weder einen laufenden Testprozess noch einen nicht gespeicherten Editorzustand. Auch ein Tool, das seinen eigenen Zustand nicht sauber persistiert, wird durch Herdr nicht plötzlich checkpoint-fähig.

Live-Handoff ist eine enge Ausnahme

Das experimentelle Live-Handoff versucht bei einem unterstützten Servertausch, bestehende PTYs und Prozesse an den neuen Server zu übergeben. Laut Session-State-Dokumentation ist das ein Best-Effort-Mechanismus und kein allgemeiner Schutz vor Crash oder Reboot. Unter Windows steht diese Funktion laut Windows-Support-Dokumentation nicht zur Verfügung.

Daraus folgt eine klare Regel: Plane einen Host-Reboot oder `SIGKILL` immer so, als würden alle laufenden Prozesse enden. Das Handoff ist kein Ersatz für Commits, persistente Checkpoints oder einen Prozessmanager.

Wie erkennt Herdr arbeitende und blockierte Agenten?

Herdr zeigt Zustände wie `idle`, `working`, `blocked`, `done` und `unknown`. Diese Werte sehen eindeutig aus, sind aber nicht bei jedem Agenten gleich belastbar.

Die Agenten-Dokumentation unterscheidet vollständige Lifecycle-Integrationen von Screen Manifests. Vollständige Integrationen können Zustandswechsel direkt melden. Bei Claude Code, Codex und Hermes Agent dienen die offiziellen Integrationen primär dazu, die Session-ID für eine spätere Wiederaufnahme zu liefern. Den Live-Zustand erkennt Herdr bei diesen drei Tools überwiegend anhand des sichtbaren Terminalinhalts.

Dafür liest Herdr einen Snapshot des unteren Bildschirmbereichs und gleicht ihn mit bekannten Mustern ab. Eine erkannte Freigabeabfrage kann zu `blocked` führen. Eine neue oder veränderte Approval-Oberfläche kann dagegen durch das Raster fallen und als `idle` erscheinen.

Status	Praktische Bedeutung	Grenze
`working`	Herdr erkennt laufende Aktivität	Erkennung hängt vom Agenten und Manifest ab
`blocked`	Bekanntes Frage- oder Freigabemuster wurde erkannt	Unbekannte Oberfläche kann übersehen werden
`idle`	Agent scheint Eingaben annehmen zu können	Kann bei fehlendem Muster ein Fallback sein
`done`	Fertiger, noch nicht als gesehen markierter Zustand	Kein fachlicher Qualitätsnachweis
`unknown`	Agent vorhanden, Zustand nicht sicher klassifizierbar	Bedeutet ausdrücklich nicht „erfolgreich abgeschlossen“

Der Status ist damit ein Orchestrierungssignal, kein Beweis für korrekten Code. Ein Agent kann `done` melden und trotzdem einen fehlerhaften Patch erzeugt haben. Tests, Diff-Prüfung und Review bleiben separate Schritte. Wie stark die Laufzeitumgebung das Verhalten eines Modells prägt, habe ich auch im Artikel über den Einfluss des Agent Harness eingeordnet.

Wie lässt sich Herdr kontrolliert automatisieren?

Herdr trennt allgemeine Pane-Befehle von agentenspezifischen Befehlen. Für Shells, Testläufe oder Entwicklungsserver nutzt du Pane-Primitiven. Für erkannte Coding-Agenten stehen Befehle zum Starten, Prompten, Lesen und Warten bereit.

Das folgende Rezept basiert auf der offiziellen Automatisierungsdokumentation und wurde für diesen Artikel nicht selbst ausgeführt. Es setzt `jq` und eine installierte Codex-CLI voraus. `–timeout 120000` entspricht 120.000 Millisekunden beziehungsweise zwei Minuten.

created=$(herdr workspace create --cwd "$HOME/project" --label api --no-focus)
pane_id=$(printf '%s\n' "$created" | jq -r '.result.root_pane.pane_id')

herdr agent start reviewer --kind codex --pane "$pane_id"
herdr agent prompt reviewer "Prüfe den aktuellen Diff." --wait --timeout 120000
herdr agent read reviewer --source recent-unwrapped --lines 80

`agent prompt –wait` verfolgt keinen individuellen Turn mit einer eindeutigen Transaktions-ID. Wenn ein Agent bereits arbeitet, kann das Ende dieses aktiven Turns die Wartebedingung erfüllen. Ein Timeout oder `agent_prompt_stalled` beweist außerdem nicht, dass der Prompt nicht gesendet wurde.

Deshalb ist eine sichere Reihenfolge wichtiger als ein blindes Retry:

1. Agentenstatus prüfen.
2. Prompt einmal senden.
3. Auf exakt definierte Zustände warten.
4. Bei Timeout oder `agent_prompt_stalled` zuerst die Ausgabe mit `agent read` lesen.
5. Erst danach entscheiden, ob ein erneuter Prompt notwendig ist.

Ohne diesen Leseschritt riskierst du doppelte Eingaben. `unknown` darfst du nur akzeptieren, wenn dein Workflow diesen Zustand ausdrücklich behandeln kann. Für autonome Abläufe brauchst du zusätzlich einen fachlichen Prüfpfad, etwa Tests und eine Diff-Auswertung.

Getrennte Worktrees statt paralleler Schreibzugriffe

Ein Multiplexer verhindert keine Git-Konflikte. Wenn mehrere Agenten denselben Checkout bearbeiten, können sie Dateien überschreiben oder einen inkonsistenten Zwischenstand erzeugen. Nutze pro schreibendem Agenten einen eigenen Git-Worktree und definiere einen klaren Scope.

Ein belastbares Muster sieht so aus:

• ein Worktree pro Agent oder Aufgabe
• getrennte Branches
• explizite Zuständigkeit für Dateien und Verzeichnisse
• automatisierte Tests vor dem Zusammenführen
• Review des finalen Diffs durch einen separaten Agenten oder Menschen

Herdr koordiniert Prozesse. Die Integrationsstrategie deines Repositories musst du selbst festlegen.

Welche Sicherheits- und Plattformgrenzen hat Herdr?

Herdr ist keine Sandbox. Agenten, Shells und Plugins handeln grundsätzlich mit den Rechten des Benutzerkontos, unter dem sie laufen. Getrennte Worktrees schützen nur Arbeitskopien, nicht Zugangsdaten, Netzwerkzugriff oder das restliche Dateisystem.

Besonders kritisch sind Community-Plugins. Laut Plugin-Dokumentation validiert Herdr das Manifest, führt aber weder eine Codeprüfung noch eine Sandbox aus. Plugins können Umgebungsvariablen erben und auf Herdr-CLI beziehungsweise Socket zugreifen. Ein Eintrag im Plugin-Index ist deshalb kein Security-Review.

Weitere Grenzen:

• Pane-History kann Prompts, Tokens oder andere Geheimnisse enthalten. Sie ist laut Session-State-Dokumentation standardmäßig deaktiviert.
• Die Windows-Unterstützung nutzt ConPTY, enthält aber dokumentierte Lücken. Unter anderem fehlen `herdr terminal attach` und Live-Handoff (Windows Support).
• Bei Windows als SSH-Ziel widersprechen sich die offiziellen Seiten: Die Windows-Support-Seite listet es als nicht unterstützt, die Connecting-Machines-Dokumentation und die v0.9.1-Release-Notes nennen Windows-x86_64-Hosts. Ohne eigenen Test lässt sich dieser Dokumentationskonflikt nicht auflösen.
• Remote-Maschinen besitzen jeweils einen eigenen Herdr-Server. Agentennamen und IDs sind nicht automatisch global.
• Ein gemeinsamer Unix-Nutzer für mehrere weitreichend berechtigte Agenten ist keine Isolation. Für riskante Werkzeuge brauchst du getrennte Nutzer, Container oder virtuelle Maschinen.

Wenn du Coding-Agenten vom Smartphone aus steuerst, löst die Transportebene ebenfalls keine Sicherheitsfrage. Mein Artikel zu Claude Code über Telegram und Discord zeigt einen anderen Zugriffsweg, aber auch dort bleiben Berechtigungen und Freigaben entscheidend.

Für wen lohnt sich Herdr?

Profil	Empfehlung
Ein Coding-Agent und wenige Shells	tmux oder Zellij reicht meistens
Mehrere unterschiedliche Coding-CLIs parallel	Herdr kann Status und Bedienung vereinheitlichen
Skriptgesteuerte Agenten-Pipeline	Herdr ist wegen CLI und Socket interessant, benötigt aber defensive Statuslogik
Prozessfortsetzung nach Host-Reboot	Herdr löst das nicht
Stark isolierte oder untrusted Agenten	Zusätzliche Container-, VM- oder Nutzerisolation erforderlich
Reiner Remote-Zugriff auf lange Prozesse	tmux bleibt die einfachere, etablierte Lösung

Herdr lohnt sich nicht durch die Anzahl sichtbarer Panes, sondern durch die Frage, ob du Agentenzustände programmatisch auswerten willst. Wer Status, Prompting und Remote-Steuerung selbst um tmux gebaut hat, erhält mit Herdr eine integrierte Alternative. Wer diese Ebene nicht braucht, tauscht ein simples Werkzeug gegen zusätzliche Komplexität.

Für größere Agentensysteme bleibt außerdem die Architektur entscheidend. Mehr parallele Agenten sind nicht automatisch besser. Der Artikel über Graph Engineering für KI-Agenten erklärt, warum Zuständigkeiten, Übergaben und Kontrollpunkte wichtiger sind als bloße Parallelität.

FAQ: Häufig gestellte Fragen zu Herdr

Läuft ein Coding-Agent nach dem Schließen des Herdr-Clients weiter?

Ja. Solange der Herdr-Server auf dem Host weiterläuft, bleiben PTY und Agentenprozess bei normalem Detach oder geschlossenem Client aktiv. Ein SSH-Abbruch ändert daran grundsätzlich nichts.

Überlebt ein Prozess einen Herdr-Server-Neustart?

Normalerweise nein. Herdr rekonstruiert Layout und Arbeitsverzeichnisse, startet aber für normale Panes neue Shells. Das experimentelle Live-Handoff ist eine enge Best-Effort-Ausnahme für unterstützte Serverwechsel.

Überlebt Herdr einen Host-Reboot?

Die gespeicherte Session-Struktur kann zurückkehren, laufende Prozesse aber nicht. Unterstützte Agentenkonversationen lassen sich bei gültiger Integration und Session-Referenz gegebenenfalls in einem neuen Prozess fortsetzen, nachdem Herdr und der Agent wieder gestartet wurden.

Ist Native Session Restore dasselbe wie Prozesspersistenz?

Nein. Herdr startet einen neuen Agentenprozess und übergibt ihm eine gespeicherte Session-Referenz. Speicherzustand, laufende Unterprozesse und beliebige Terminalprogramme werden dadurch nicht fortgesetzt.

Erkennt Herdr den Zustand von Claude Code und Codex über Hooks?

Die offiziellen Integrationen liefern bei Claude Code, Codex und Hermes Agent vor allem die Session-ID. Für `idle`, `working` und `blocked` verwendet Herdr bei diesen Tools Screen Manifests. Dadurch sind Fehlklassifikationen möglich.

Bedeutet `unknown`, dass ein Agent fertig ist?

Nein. `unknown` bedeutet nur, dass Herdr den Zustand nicht sicher klassifizieren kann. Der Status ist weder ein Erfolgsnachweis noch ein Ersatz für Tests.

Sind Herdr-Plugins geprüft oder isoliert?

Nein. Die Manifestprüfung ist kein Code-Review, und Plugins laufen nicht in einer Herdr-Sandbox. Prüfe Quellcode und Herausgeber, bevor du ein Community-Plugin installierst.

Brauche ich neben Herdr noch tmux?

Nicht zwingend. Beide Werkzeuge können persistente Terminal-Sessions bereitstellen. tmux bleibt sinnvoll, wenn du einen allgemeinen Multiplexer ohne agentenspezifische Steuerung brauchst; eine Verschachtelung kann Herdrs Agentenerkennung erschweren.

Fazit

Herdrs Mehrwert gegenüber tmux ist nicht das Detach, sondern die integrierte Agentensemantik mit Status, CLI und Session-Resume. Die Grenze bleibt hart: Ein Client-Abbruch ist harmlos, ein Server- oder Host-Neustart beendet normale Prozesse. Für regelmäßig parallele Coding-Agenten ist Herdr einen Blick wert; als Reboot-sicherer Prozess-Checkpoint ist es das falsche Werkzeug.

Verwandte Themen: Warum der Agent Harness oft wichtiger als das Modell ist, Graph Engineering für koordinierte KI-Agenten und Claude Code Channels für den mobilen Zugriff.

Quellen

Primärquellen

• Herdr Repository auf GitHub, abgerufen am 28. September 2026
• Herdr v0.9.1 Release, veröffentlicht am 16. September 2026
• Herdr: Session state and restore, abgerufen am 28. September 2026
• Herdr: Agents, abgerufen am 28. September 2026
• Herdr: Integrations, abgerufen am 28. September 2026
• Herdr: Agent automation, abgerufen am 28. September 2026
• Herdr: CLI reference, abgerufen am 28. September 2026
• Herdr: Plugins, abgerufen am 28. September 2026
• Herdr: Windows support, abgerufen am 28. September 2026
• Herdr: Connecting machines, abgerufen am 28. September 2026
• tmux: Getting Started, abgerufen am 28. September 2026
• Zellij: Session Resurrection, abgerufen am 28. September 2026

Externer Praxistest und Diskussion

• Engr Mejba Ahmed: Herdr Terminal Multiplexer Tested, Test von v0.7.4; für aktuelle Funktionen nur eingeschränkt übertragbar
• Hacker News: Diskussion zu Herdr, subjektive Praxisberichte, kein Benchmark

*Recherche- und Dokumentationsstand: 28. September 2026. Der Artikel basiert auf Herstellerdokumentation und einem externen Test von v0.7.4. Es wurde kein eigener Herdr-Installationstest durchgeführt.*