codeArbiter Leitfaden für Entscheidung und ersten Einsatz: Gate-basierte Code-Governance für Claude Code, Codex CLI und Pi

Für wen geeignet

• Für Entwickler und Teams, die in Claude Code, Codex CLI oder Pi arbeiten und wollen, dass Änderungen vor dem Eintritt in die Codebasis eine erzwungene Prüfung durchlaufen: codeArbiter ist eine Governance-Schicht (governance layer) für genau diese drei Hosts. Die Titelzeile des offiziellen Repositorys nennt die Motivation: „When you can't trust yourself with your code base, trust Arbiter." (Wenn du deinem eigenen Code nicht vertrauen kannst, vertraue Arbiter.)
• Nach der Aktivierung wird jede Absicht, die du dem Agenten äußerst, an einen gated skill oder reviewer agent geroutet; nichts wird committet, bevor alle Gates grün sind; Entscheidungen laufen über SMARTS; der Audit-Trail ist append-only. Es wirkt auf Repository-Ebene: Das Opt-in gilt für ein einzelnes Repository. Wer verpflichtende Gates vor dem Commit und nachvollziehbare Entscheidungsprotokolle braucht, findet genau das hier. Append-only bedeutet: Audit-Einträge können nur ergänzt, nie gelöscht oder umgeschrieben werden.
• Für vorsichtige Nutzer, die erst prüfen und dann handeln: Laut offizieller Dokumentation bleibt das Plugin nach der Installation standardmäßig inaktiv und tut für ein Repository nichts, bis du dieses Repository ausdrücklich per Opt-in anmeldest. Im Original heißt es „That silence is intentional." (Diese Stille ist beabsichtigt.) Die Installation allein ändert das bestehende Verhalten des Repositorys nicht sofort.
• Wann es nicht passt: wenn du keinen Gate-basierten Prozess willst, nur eine einmalige Code-Analyse oder -Umschreibung brauchst, oder wenn deine Umgebung die Anforderungen des nächsten Abschnitts nicht erfüllt. Für welche Programmiersprachen und Projekttypen es geeignet ist, sagt die offizielle Dokumentation nicht – das ist unbekannt und beeinflusst direkt, ob du es wählen solltest.
• Ob andere Agent-Hosts neben Claude Code, Codex CLI und Pi unterstützt werden, geht aus den Belegen nicht hervor – unbekannt.

Erster Versuch in 3 Minuten

• Voraussetzungen: Windows, macOS oder Linux; offiziell gefordert sind Pi 0.80.10, Node.js 22.19 oder neuer, Python 3 und Git, kein Konto und keine Beispieldaten nötig. Fehlt eines davon, richte zuerst die Umgebung ein und installiere dann.
• Installationsort: Der offiziell dokumentierte Installationsweg ist der Plugin-Marketplace von Claude Code. Führe in Claude Code die folgenden zwei Befehle der Reihe nach aus – der erste fügt arbiterForge/codeArbiter als Marketplace-Quelle hinzu, der zweite installiert das Plugin namens ca aus dieser Quelle:

/plugin marketplace add arbiterForge/codeArbiter
/plugin install ca@codearbiter

• Erfolgssignal nach der Installation: Hooks, Commands, Agents und Statusline-Verdrahtung werden automatisch geladen, und alle Befehle werden unter dem /ca:-Namespace aufgelöst. Das heißt: Nach der Installation ist kein manuelles Verdrahten nötig, und Befehle mit dem Präfix /ca: sollten erkannt werden. Das Plugin ruht zu diesem Zeitpunkt noch – das ist erwartetes Verhalten und kein Zeichen einer fehlgeschlagenen Installation.
• Wichtigster Kontrollpunkt: Ein Repository gelangt erst in den Governance-Prozess, wenn es ausdrücklich per Opt-in angemeldet wurde. Eine abgeschlossene Installation bedeutet nicht, dass das Tool arbeitet. Der konkrete Opt-in-Befehl erscheint nicht in der offiziellen Dokumentation; wie dieser Schritt auszuführen ist, ist unbekannt. Halte dich an die Angaben im offiziellen Repository und rate Befehle nicht selbst.
• Erste Aufgabe: Nach dem Opt-in äußere eine ganz normale Absicht zur Code-Analyse oder -Änderung gegenüber dem Agenten und beobachte zwei Dinge: Wird die Absicht an einen gated skill oder reviewer agent geroutet? Bleibt alles uncommittet, bis alle Gates grün sind? Wird die Absicht nicht geroutet oder wird committet, obwohl Gates noch rot sind, läuft der Governance-Prozess nicht wie offiziell beschrieben. Welche konkreten Befehle es unter /ca: gibt, ist in den Belegen nicht aufgeführt und lässt sich nicht wörtlich angeben.

Anwendungsfälle

• Fall 1: Gate-basierte Commits für ein privates Repository aktivieren. Szenario: Jede Änderung soll vor dem Commit automatisch geprüft werden. Vorgehen: Führe die beiden Installationsbefehle oben in Claude Code aus, um das Plugin ca zu installieren; prüfe, dass Hooks, Commands, Agents und Statusline-Verdrahtung automatisch geladen wurden und /ca:-Befehle aufgelöst werden; melde dann das Repository per Opt-in an und äußere schließlich eine Änderungsabsicht gegenüber dem Agenten. Zu erwarten: Die Absicht wird an einen gated skill oder reviewer agent geroutet, nichts wird committet, bevor alle Gates grün sind, Entscheidungen laufen über SMARTS, und Audit-Einträge können nur ergänzt werden. Weil das Plugin nach der Installation ruht, beginnen alle Nebenwirkungen dieses Falls erst mit dem Opt-in; die Installationsbefehle selbst lösen keine Governance-Aktionen aus. Wer nur sehen will, wie es nach der Installation aussieht, kann nach „automatisch geladen, /ca: wird aufgelöst" innehalten und beobachten – das Opt-in muss nicht überstürzt erfolgen.
• Fall 2: Änderungsentscheidungen im Team nachvollziehbar machen. Szenario: In der Zusammenarbeit mehrerer Personen soll jede Änderungsentscheidung dokumentiert sein und die Historie darf nicht umgeschrieben werden. Vorgehen: Äußere gegenüber dem Agenten eine Änderungsabsicht für ein bereits angemeldetes Repository und durchlaufe denselben Gate-Workflow. Zu erwarten: Entscheidungen werden über SMARTS aufgezeichnet, der Audit-Trail ist append-only, und bereits geschriebene Einträge werden durch spätere Aktionen nicht überschrieben. Wie die Interaktion mit SMARTS konkret abläuft und in welcher Oberfläche man die Einträge sieht, ist in den Belegen nicht beschrieben; die bestätigte Reichweite endet hier.

Nutzungsgrenzen

• Nebenwirkungen und Kontrollpunkte: Bei der Installation werden Hooks, Commands, Agents und Statusline-Verdrahtung automatisch geladen – das ist laut offizieller Dokumentation ein Verhalten, das mit der Installation eintritt. Der Ausgangszustand ist inaktiv; bis ein Repository ausdrücklich per Opt-in angemeldet ist, tut das Plugin für es nichts. Ohne Opt-in lässt sich die Governance-Wirkung daher nicht prüfen. Ob sich ein Opt-in rückgängig machen lässt und wie, ist in den Belegen nicht beschrieben – unbekannt. Wer die Kosten eines Rückgängigmachens scheut, sollte diesen Punkt vor dem Opt-in klären.
• Dateien, Befehle und Netzwerk: Ob es deine Dateien liest oder schreibt, welche Befehle es ausführt und ob es aufs Netzwerk zugreift, sagt die offizielle Dokumentation nicht – unbekannt. Aus dieser Stille lässt sich nicht ableiten, dass solche Verhaltensweisen nicht existieren. Bevor du es an ein wichtiges Repository bindest, teste das Opt-in am besten in einer Wegwerf-Umgebung.
• Plattform- und Client-Unterschiede: Der einzige wörtlich genannte Installationsweg ist der Plugin-Marketplace von Claude Code. Codex CLI und Pi werden zwar als Hosts der Governance-Schicht genannt, doch ihre Installationswege fehlen in der offiziellen Dokumentation – unbekannt.
• Noch unbestätigte Kernpunkte: der konkrete Opt-in-Befehl, die vollständige Befehlsliste unter dem /ca:-Namespace, wie die Interaktion mit SMARTS abläuft, unterstützte Programmiersprachen und Projekttypen, Unterstützung über Windows, macOS und Linux hinaus sowie Deinstallation und vorübergehendes Deaktivieren – nichts davon erscheint in den Belegen. Prüfe jeden Punkt vor der Einführung direkt im offiziellen Repository.