OpenRig: Claude Code und Codex mit YAML zu einem Agent-Team formen

Für wen es geeignet ist

OpenRig richtet sich an Entwickler, die mehrere Coding-Agents zu einem festen Team formen wollen: Ein rig umschließt Ihre Harnesses, das Agent-Team wird in YAML definiert und mit einem einzigen Befehl gestartet. Die auffälligste Fähigkeit ist, Claude Code und Codex im selben rig gleichzeitig laufen zu lassen und als ein System einheitlich zu verwalten. Der Wert liegt im „Team": Statt jeden Agent in separaten Terminalfenstern einzeln zu betreuen, tragen Sie die Mitglieder in ein und dieselbe YAML-Datei ein und überlassen die Verwaltung einem Befehl und einheitlichen Readiness-Checks.

Prüfen Sie vor dem Start die Umgebung und gehen Sie erst weiter, wenn alle vier Punkte erfüllt sind: Node.js 22 oder 24 (auf Apple Silicon 22), tmux, macOS oder Linux (Windows über WSL2) sowie ein angemeldetes Claude Code oder Codex. Beheben Sie fehlende Punkte zuerst – das allein erspart die meisten späteren Fehler. Wenn Sie nur andere Agents nutzen, bei nativem Windows bleiben oder eine andere Node-Version verwenden, macht die offizielle Dokumentation keine Angabe zur Unterstützung; betrachten Sie das als unbestätigt.

Umgekehrt gibt es drei Situationen, in denen Sie es noch nicht einsetzen sollten: Nutzer, die nur mit grafischen Oberflächen arbeiten und keine Konfiguration schreiben wollen; Nutzer, die direkt unter nativem Windows (nicht WSL2) laufen müssen; und Nutzer, die andere Clients als Claude Code und Codex einsetzen wollen – die offizielle Dokumentation deckt diese Verwendungen nicht ab. Anders gesagt: Wer ohnehin nur einen Client betreibt und keinen einheitlichen Start braucht, zieht aus der rig-Teamstruktur begrenzten Nutzen.

Der erste Versuch in 3 Minuten

Es gibt genau einen empfohlenen Hauptweg: Installieren Sie den rigs-Skill mit dem offiziellen Befehl in Claude Code, vorausgesetzt, die Umgebung aus dem vorigen Abschnitt steht. Führen Sie im Terminal aus:

npx skills add https://github.com/mvschwarz/openrig/tree/v0.7.0/skills/rigs --skill rigs --agent claude-code

Das v0.7.0 im Befehl ist der fixe Versionspfad von der offiziellen Seite – kopieren Sie ihn unverändert. Nach der Installation schreiben Sie Ihre Agent-Team-Definition in YAML; die Reihenfolge: Skill installieren, YAML schreiben, bei Bedarf initialisieren (rig setup), starten (rig up). Offiziell wird nur gesagt, dass das Team in YAML definiert und mit einem Befehl gestartet wird; Felder, Beispiele oder Dateispeicherorte fehlen. Maßgeblich für Konfigurationsdetails sind die Hinweise des Skills nach der Installation – schreiben Sie die Konfiguration nicht nach reinem Rätselraten.

Als Nächstes die Initialisierung. Bevor Sie rig setup ausführen, kennen Sie seine Nebenwirkungen: Es fügt ~/.tmux.conf einen OpenRig-Block hinzu; unter macOS kann es tmux über Homebrew installieren; und außer Sie übergeben --no-herdr, installiert es auch Herdr. Das ist der Bestätigungspunkt vor der Ausführung – wer Herdr nicht will, hängt --no-herdr an.

Zum Schluss der Start: Führen Sie rig up aus; es bringt die tmux-Sessions, jede Harness und die Startdateien hoch und führt die Readiness-Checks aus. Beobachtbare Erfolgssignale: In tmux erscheinen die Sessions Ihres Teams, jede Harness startet, und die Readiness-Checks liefern Punkt für Punkt Ergebnisse. Fehlen die Sessions oder meldet ein Check einen Fehler, gehen Sie zur Umgebungsliste zurück und prüfen Sie Node-Version und tmux. Ob rig up Dateien verändert oder aufs Netz zugreift, ist offiziell nicht beschrieben – unbestätigt. Bis hierher hat noch kein Mitglied echte Arbeit geleistet; prüfen Sie erst den sauberen Start, dann vertrauen Sie ihm echte Aufgaben an.

Anwendungsfälle

Fall 1: Claude Code und Codex im selben Team. Szenario: Sie nutzen beide Clients und wollen sie in einem einheitlich verwalteten System haben. Vorgehen: Nach der Installation des rigs-Skills definieren Sie beide Harnesses im Team-YAML und führen rig up aus. Erwartbares Ergebnis: Beide starten als ein System, in tmux erscheinen ihre jeweiligen Sessions, die Readiness-Checks berichten einzeln, und beide Mitglieder bleiben in tmux sichtbar – gut für den Vergleich.

Fall 2: Die tägliche Startvorbereitung auf einen Befehl verdichten. Szenario: Sie wollen nicht jedes Mal tmux von Hand öffnen und die Mitglieder einzeln hochfahren. Vorgehen: Sobald das Team-YAML steht, führen Sie rig up beim Tagesbeginn aus und überlassen ihm tmux-Sessions, Harnesses, Startdateien und Readiness-Checks. Erwartbares Ergebnis: Die wiederkehrende Vorbereitung schrumpft auf einen Befehl, und das Check-Ergebnis sagt Ihnen direkt, ob das Team bereit ist.

Beide Fälle lassen sich verketten: Bestätigen Sie zuerst mit Fall 1, dass die Formation überhaupt funktioniert, und machen Sie daraus den festen täglichen Einstieg wie in Fall 2. Beide Fälle enden dort, wo die offizielle Dokumentation endet: Wie sich Mitglieder nach dem Start die Arbeit teilen und welche Aufgaben sie ausführen, dafür gibt es keine offiziellen Beispiele – hier wird nichts erfunden.

Grenzen

• Umgebung und Clients: Offiziell gelistet sind nur Node.js 22 oder 24 (Apple Silicon: 22), tmux, macOS/Linux (WSL2) und ein angemeldetes Claude Code oder Codex; andere Clients, natives Windows und andere Node-Versionen sind sämtlich unbestätigt.
• Installationsweg und Version: Die Installation läuft über npx skills add, der offizielle Befehl ist ausdrücklich an --agent claude-code gebunden; ein Plugin-Marketplace oder gleichwertige Wege für andere Clients sind nicht dokumentiert – raten Sie nicht selbst. Der Installationspfad ist auf v0.7.0 fixiert, ein Upgrade-Weg wird nicht genannt.
• Nebenwirkungen und Bestätigungspunkt: rig setup fügt ~/.tmux.conf einen OpenRig-Block hinzu, kann tmux über Homebrew installieren und installiert Herdr, außer Sie übergeben --no-herdr; stellen Sie vor der Ausführung sicher, dass Sie diese Änderungen akzeptieren.
• Teamdefinition: Konkrete YAML-Felder, Beispiele und Dateispeicherorte stehen nicht in der offiziellen Dokumentation; schreiben Sie die Konfiguration nicht nach Rätselraten.
• Readiness-Checks: rig up führt sie aus, welche Punkte geprüft werden und was bei Fehlern passiert, ist offiziell offen; verlassen Sie sich auf die Befehlsausgabe und unterstellen Sie weder automatische Wiederholungen noch ein Rollback.
• Aufgabenverhalten: OpenRig orchestriert Teams; Textumformung oder Änderungen an Nutzerdateien behandelt die offizielle Dokumentation nicht. Datei-, Befehls- und Netzverhalten der Mitglieds-Agents zur Laufzeit hängen vom gewählten Client ab – hier wird kein zusätzliches Sicherheitsurteil gefällt.
• Unbestätigt: Lizenz und Preisgestaltung, Deinstallation, Exit- und Aufräumverhalten von rig up sowie die Obergrenze der Mitglieder pro rig – allesamt in der offiziellen Dokumentation nicht gefunden.