Wer mehrere Coding-Agenten parallel laufen lässt, etwa Claude Code und Codex in getrennten Terminals, verliert schnell den Überblick: Welcher Agent hat welche Aufgabe begonnen, wer sollte sie prüfen, und welcher Kontext gehört wozu? Nach einem Neustart ist dieser Zusammenhang oft weg. Hier setzt OpenRig an, ein Open-Source-Projekt auf GitHub, mit dem sich aus Claude Code, Codex und Pi ein eigenes Netzwerk von Agenten aufbauen lässt.
Der Autor von OpenRig formuliert den Unterschied in einem Satz: Ein Harness umschließt ein Modell, ein Rig umschließt deine Harnesses. Das beschreibt, worum es geht. Du startest nicht mehr einzelne Coding-Agenten, sondern eine Mannschaft, die als System funktioniert. Wer schon länger mit KI-Coding-Agenten arbeitet, kennt das Problem: Ein einzelner Agent ist mächtig, aber sobald mehrere parallel laufen, entsteht Chaos.
Was OpenRig von einem einzelnen Agenten unterscheidet
Ein KI-Coding-Agent wie Claude Code oder Codex ist ein Werkzeug, das Anweisungen versteht und Code verändert. Er arbeitet in einer Sitzung, in einem Verzeichnis, mit einem Kontext. Für eine einzelne Aufgabe reicht das. Sobald aber ein Agent implementiert, ein zweiter prüft und ein dritter die Infrastruktur anpasst, brauchst du eine übergeordnete Ebene, die weiß, wer was tut. Diese Ebene ist OpenRig.
Der Autor beschreibt sein System als Schicht über den Harnesses, nicht als Ersatz. Claude Code und Codex laufen weiter wie gewohnt, nur unter der Regie eines Daemons, der ihre Sitzungen kennt, ihre Rollen verwaltet und ihre Kommunikation weiterleitet. Statt loser Terminals entsteht ein beständiges Team, das einen Neustart übersteht und sich gegenseitig Nachrichten schicken kann.
Die Rollenverteilung ist schlicht. In der Einsteiger-Anleitung steht ein Zweier-Team im Mittelpunkt: ein „Owner“, der eine Aufgabe umsetzt, und ein „Checker“, der die Änderung überprüft. Du sprichst mit dem Owner, der Owner koordiniert den Checker, am Ende bekommst du ein Ergebnis samt Review. Ein nüchternes Modell für ein Feld, in dem sonst gern von autonomen Agentenschwärmen die Rede ist.
Das Agenten-Team in YAML definieren
Die Topologie eines Teams wird nicht im Terminal zusammengeklickt, sondern in einer Datei beschrieben. OpenRig nennt dieses Format RigSpec und baut darauf Konzepte wie Pods, Edges und Continuity-Policies auf. Pods sind Gruppen zusammengehöriger Plätze (im Projektjargon „Seats“), Edges beschreiben, wie diese Plätze miteinander verbunden sind und wer wem schreiben darf. Continuity-Policies legen fest, wie ein Team einen Neustart übersteht.
Wer schon CI-Pipelines oder Kubernetes-Manifeste geschrieben hat, erkennt das Muster: Zustand wird deklarativ beschrieben, das Werkzeug kümmert sich um die Ausführung. Ein Agententeam, das man per YAML definiert, lässt sich versionieren, teilen und reproduzieren. Das fehlt, solange jeder Agent als handgestartete Terminal-Sitzung existiert. Der Start läuft dann mit einem Befehl, rig up, der die nötigen tmux-Sitzungen, Harnesses und Startdateien anlegt und prüft, ob alles bereit ist.
Das ist nicht nur ein Startskript. OpenRig erkennt bestehende Claude-Code- und Codex-Sitzungen in tmux und übernimmt sie in ein verwaltetes Rig. Man muss also nicht bei null anfangen. Auch der umgekehrte Weg ist vorgesehen: rig down –snapshot friert die aktuelle Topologie ein, rig up <name> holt sie wieder hervor.
Die TUI als Kontrollzentrum
Ohne eine Übersicht wäre ein Team aus mehreren Agenten kaum zu überblicken. OpenRig liefert deshalb eine Terminal-Oberfläche, die dieselben Rigs einmal als Graph und einmal als Tabelle zeigt. In der Tabelle stehen die einzelnen Plätze mit Laufzeit, Modell, Kontext und Zustand. Wer will, öffnet einen bestimmten Platz und sieht im Detail, was gerade passiert. Unspektakulär, im Alltag aber entscheidend.
Zur Kommunikation zwischen den Agenten gibt es drei Befehle, die sich leicht merken lassen: rig send schickt eine Nachricht an einen bestimmten Platz, rig broadcast an mehrere, und rig chatroom öffnet einen gemeinsamen Raum. Wer selbst in einem Terminal tippt und nicht durch automatische Nachrichten unterbrochen werden will, kann mit rig seat set-typing-guard einen Platz schützen. Automatische Nachrichten werden dann zurückgehalten, statt mitten in die eigene Eingabe zu platzen.
Das Dashboard lässt sich geteilt oder unabhängig öffnen. Ein geteiltes Dashboard verschwindet nicht, wenn man das Fenster schließt. Ein Detail, das darüber entscheidet, ob man ein Werkzeug ständig neu startet oder im Hintergrund laufen lässt.
Was OpenRig auf deiner Maschine verändert
Die README enthält einen eigenen Abschnitt: „What OpenRig changes on your machine“. Den sollte man lesen, bevor man irgendetwas installiert. OpenRig schreibt Konfiguration in Vertrauensdateien, legt Hooks an und erweitert Dateien wie ~/.tmux.conf, ~/.claude.json und die Codex-Konfiguration unter ~/.codex/config.toml.
Konkret: Beim Start eines Rigs werden Workspace-Trust-Einstellungen gesetzt, Codex-Hooks aktiviert und Vertrauens-Hashes für bestimmte Befehle vorab eingetragen. Claude Code bekommt einen Statusline-Befehl und ausgewählte Activity-Hooks in die lokale Settings-Datei geschrieben. Die Aktivitäts-Relays senden Ereignistyp, Sitzungskennung und Zeitstempel an den eigenen Daemon, ausdrücklich ohne Prompt-Text und ohne Tool-Argumente. Wer Datenschutz ernst nimmt, sollte diese Liste lesen. Provider-Dateien und Instanz-Zustand sind getrennt, aber ein geänderter OPENRIG_HOME-Pfad isoliert die Provider-Konfiguration nicht automatisch.
Vor dem ersten Start sollte man die betreffenden Dateien sichern. Manche Schreibroutinen behandeln unlesbare Einstellungsdateien als leere Objekte, und eine Garantie zur Wiederherstellung gibt es nicht. Der Befehl rig setup –dry-run zeigt den geplanten Eingriff an, ohne ihn auszuführen, deckt aber nicht jeden späteren Starteffekt ab.
Berechtigungen: Der Punkt, an dem es ernst wird
Ein Multi-Agenten-System für Coding-Agenten darf Dateien ändern, Befehle ausführen und im Grunde alles tun, wozu ein Agent eben in der Lage ist. OpenRig löst das nicht dadurch, dass es pauschal alles erlaubt. Der Autor beschreibt mehrere Stufen: Die Standardeinstellung für Codex ist ein Sandbox-Modus mit Schreibzugriff auf den Workspace, Claude Code startet mit --permission-mode acceptEdits. Ein vollständiger Bypass ist möglich, aber ausdrücklich nicht die Voreinstellung.
Für einzelne Plätze lässt sich mit rig seat set-permissions ein auditiertes Modell wählen, das beim nächsten Start greift. Eine solche Auswahl verändert den laufenden Prozess nicht. Wer denkt, ein Befehl schalte sofort schärfere Rechte frei, täuscht sich. Gewünschte Einstellung und zuletzt verwendete Startargumente werden getrennt angezeigt, und keine der beiden Angaben beweist, dass die native Durchsetzung greift.
In einem Umfeld, in dem Agenten gern als magische Helfer dargestellt werden, sagt der Autor klar, was sein Werkzeug kontrolliert und was nicht. Ein Multi-Agenten-Harness ist kein Sicherheitskonzept. Es ist eine Verwaltungsschicht, die dir den Überblick erleichtert und dich zwingt, dich mit Berechtigungen auseinanderzusetzen.
Für wen sich der Einstieg lohnt
OpenRig läuft auf macOS und Linux, benötigt Node.js 22 oder 24 und tmux. Auf Apple-Silicon-Macs empfiehlt der Autor Node.js 22, nativer Windows-Support fehlt bislang, WSL2 ist ungetestet. Die Installation erfolgt global über npm mit @openrig/cli, alternativ mit Bun. Danach folgt der erwähnte Trockenlauf, bevor etwas verändert wird.
Wer nur gelegentlich einen einzelnen Coding-Agenten nutzt, braucht das nicht. Wer aber regelmäßig mehrere KI-Coding-Agenten parallel laufen lässt, kennt das Problem der auseinanderdriftenden Terminals. OpenRig macht aus verstreuten Sitzungen ein adressierbares Team, in dem du den Überblick behältst, in dem Aufgaben nachvollziehbar ankommen und in dem ein Neustart nicht bedeutet, alles neu aufzusetzen.
Der Autor beschreibt den Einstieg klein: ein Repository, eine nützliche Änderung, ein Owner, ein Checker, ein überprüftes Ergebnis. Die Vorstellung, man definiere heute ein Agenten-Team in YAML und morgen erledige es die halbe Codebasis, hält der Praxis selten stand. Ein Rig aufzusetzen heißt, sich Gedanken zu machen: Wer prüft wen, welche Rechte bekommt welcher Platz, was passiert beim nächsten Reboot. Diese Fragen sind wichtiger als jeder zusätzliche Agent.
Quelle: github.com
