Claude Code Harness: Plan-Arbeit-Review-Zyklus für Agenten

Harness v5.13.1: Verfahren statt Modellintelligenz

Claude Code Harness adressiert ein bekanntes Problem der Agentenprogrammierung: Pläne leben im Chat und verschwinden, Tests werden unter Termindruck optional, Review findet erst nach dem Merge statt, Release-Nachweise werden hinterher aus dem Gedächtnis rekonstruiert. Das Rahmensystem ersetzt das laut README durch einen wiederholbaren Pfad: Spezifikation schreiben, nur den freigegebenen Ausschnitt implementieren, verifizieren, unabhängig prüfen, Nachweise verpacken. Es macht das Modell nicht schlauer, sondern repariert das Verfahren und die Grenzen um das Modell herum, deshalb bleibt es wirksam, wenn das Modell wechselt. Eine bemerkenswerte Disziplin gilt dem eigenen Text: Die Behauptungen der README werden maschinell durch CI-Gates geprüft, die nachweisen, dass beschriebene Komponenten tatsächlich verdrahtet sind, dass das Aufgaben-Ledger konsistent bleibt und dass ausgelieferte Binärdateien aus dem Quellcode neu bauen. Die Metadaten zeigen Shell als Sprache, MIT als Lizenz und 3.072 Sterne bei 302 Forks.

Fünf Verb-Skills von /harness-plan bis /harness-release

Die Oberfläche bleibt absichtlich klein: plan, work, review, sync und release, dazu läuft /harness-setup einmalig bei der Installation. /harness-plan verwandelt eine Absicht in spec.md und Plans.md mit Umfang, Akzeptanzkriterien, Abhängigkeiten, Unbekannten und Stoppbedingungen; die Aufgabe des Nutzers ist es laut README, diesen Vertrag freizugeben oder zu korrigieren, nicht ihn zu schreiben. /harness-work implementiert eine freigegebene Aufgabe, /harness-work all den ganzen Plan, jeweils mit TDD-Pflicht, wenn die Aufgabe Tests verlangt. /harness-review prüft das Ergebnis getrennt von der Implementierung, schwerwiegende Befunde blockieren den Abschluss, PR-fertig ist nicht release-fertig. /harness-sync meldet Abweichungen zwischen Plan und Umsetzung, /harness-release verpackt nur verifizierte Nachweise in CHANGELOG, Tag und Release und verlangt ein bestandenes Preflight. Daten, die der Agent nicht gesehen hat, bleiben als unknown markiert, statt erfunden zu werden. Drei Einseiten-HTML-Ansichten, Plan Brief, Progress und Acceptance, erlauben zudem einem fachlichen Sponsor, ohne Codelesung zu urteilen.

Runtime-Floor und Guardrails R01 bis R15 in der Go-Engine

Der Sicherheitsansatz unterscheidet Harness von einem Prompt-Templat: Jeder Tool-Aufruf wird von einer Go-Engine entschieden, bevor er läuft, nicht nachträglich geprüft, denn ein Datei-Diff sieht eine Netzwerkübertragung oder eine Löschung nicht. Die Struktur ist zweistufig und bewusst ungleich stark. Der Runtime-Floor umfasst fünf Kategorien und lehnt kategorisch ab, ohne dass Konfiguration, Umgebungsvariable oder Berechtigungsmodus ihn umgehen können: Abrechnung, Netzwerk-Ausgang, Lesen von Geheimnissen, Produktionsbereitstellungen und Zerstörung außerhalb des Aufgaben-Worktrees. Diese Ebene sitzt auf einem isolierten Codepfad ohne Abschalter, ein autonomer Lauf kann sich also nicht daran vorbeireden. Darüber liegen die Guardrails R01 bis R15 mit den Urteilen deny, confirm und warn, teils pro Projekt konfigurierbar, etwa für direkte Pushes auf main, Schreibzugriffe auf geschützte Pfade, Force-Pushes und History-Rewrites.

Bestätigungen zur Planzeit und JSONL-Protokoll mit Hash

Statt einen Lauf mitten im Fluss zu unterbrechen, sammelt Harness die riskanten Operationen, die ein Plan benötigen wird, und fragt einmal im Voraus. Jede Genehmigung trägt eine Ablaufzeit, einen Aufgabenbereich und ein Nutzungslimit, eine einmal erteilte Freigabe wird also nie zu einem dauerhaften Loch. Jeder Stopp wird protokolliert: Regel-ID, Kategorie und Urteil landen in einem JSONL-Log. Der Befehlstext selbst wird nie geschrieben, nur ein Hash und eine Länge, und bei Geheimnislesen und Abrechnung nicht einmal das. Damit lässt sich zählen, was tatsächlich blockiert hat, statt es zu erraten, ohne dass das Log selbst zu einer Ansammlung sensibler Inhalte wird. Diese Kombination aus Vorabfreigabe und verhaltenen Protokolldaten ist der pragmatischste Teil des Designs.

Sitzungs-Roster und bin/harness inbox send zwischen Worktrees

Mehrere Agenten auf demselben Repository arbeiten normalerweise blind nebeneinander. Harness hält ein Roster und einen Nachrichtenpfad zwischen lokalen Sitzungen. bin/harness session list zeigt jede live Sitzung auf der Maschine, einschließlich Sitzungen in anderen Worktrees, weil der Speicher aus git --git-common-dir aufgelöst wird; jede Zeile trägt team und agent, die ein Absender braucht. Gesendet wird mit bin/harness inbox send --team <t> --from <a> --to <b> --subject <s> "<body>" oder über den session-send-Skill. Empfangen wird an der Sprechturngrenze der Zielsitzung, eingebettet als Daten mit einer ausdrücklichen Nicht-Anweisungs-Hülle, eine Peer-Nachricht ist ein Bericht zur Verifikation, nie ein Befehl. Das Ganze ist nur lokal und hängt nicht von harness-mem ab; wenn harness-mem parallel installiert ist, bleiben dessen Roster-Einträge unangetastet.

CooperBench-Befund: falsche Annahmen über fremde Änderungen

Für die Motivation dieser Sitzungs-kommunikation zieht die README einen Befund aus CooperBench heran: Zwei Agenten, die dieselbe Datei bearbeiten, schaffen es etwa halb so oft wie ein Agent allein, und 63 Prozent dieser Ausfälle gehen auf eine falsche Annahme darüber zurück, was der andere geändert hat. Darauf basiert auch die optionale Verifikationsstufe für Nachrichten: Mit [livemsg] verification = "on" prüft ein Gate die faktischen Behauptungen einer Nachricht, ob erwähnte Dateien existieren, ob erwähnte Commits auflösen und ob eine Behauptung wie sauberer Worktree mit git status übereinstimmt, und gibt den Ablehnungsgrund an den Absender zurück, statt eine falsche Nachricht zuzustellen. Steht der Schalter auf off, wird das Gate im Sendepfad gar nicht aufgerufen, das Senden selbst ist standardmäßig ungefiltert.

Installationsrouten für Claude Code, Codex CLI, Cursor und Grok

Der schnellste Weg läuft über Claude Code: /plugin marketplace add Chachamaru127/claude-code-harness, dann /plugin install claude-code-harness@claude-code-harness-marketplace, dann /harness-setup. Für andere Werkzeuge existieren eigene Routen, und die README insistiert darauf, dass vier Routen keine vier identischen Garantien sind: Ein Setup-Skript bedeutet einen Einstiegspfad, kein gemeinsames Produktversprechen. Codex CLI richtet scripts/setup-codex.sh --user ein, das nach jedem Harness-Update erneut auszuführen ist, danach startet Codex neu; Cursor nutzt scripts/setup-cursor.sh, Grok scripts/setup-grok.sh. Weitere Tools sind in niedrigeren Stufen klassifiziert und steigen erst auf, wenn sie ihre eigenen Prüfungen bestehen. Die Release-Folge ist eng: v5.12.0 erschien am 24. August 2026, v5.13.0 am 25. August, v5.13.1 am selben Tag, der main-Zweig weist 9 offene Issues auf.

Redaktionelles Fazit

Harness passt für Teams, die Agenten-Codierung wie Claude Code, Codex CLI oder Cursor produktiv nutzen und eine erzwungene Plan-, Prüf- und Freigabestruktur mit nachvollziehbaren Stopps wollen. Unpassend ist es für Nutzer, die sich freie Agentenläufe ohne Eingriffswünsche erhalten wollen, denn der Runtime-Floor lässt sich absichtlich nicht abschalten. Vor der Einführung lohnt ein kleiner Realtest: das Plugin installieren, /harness-plan für eine Miniaturaufgabe ausführen und prüfen, ob die erzeugte spec.md samt Akzeptanzkriterien zur eigenen Arbeitsweise passt.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes