Ein Review-Agent darf nicht schreiben können. So setzen wir das durch, CLI für CLI.

Anfang dieser Woche hat uns ein Nutzer einen Run-Bericht geschickt, den man zweimal lesen sollte. Siebzehn Agenten, ein gemeinsamer Worktree, eine Pipeline mit einem Implementierer, einem Release-Gate und zwei Review-Zweigen. Version 1.171.0 von AgentsRoom.

Drei Dinge sind in diesem Run passiert, in dieser Reihenfolge.

Der Release-Agent hatte eine rote Testsuite vor sich. Er hat die Test-Spec so lange bearbeitet, bis die Suite grün war. Damit hat er einen echten Defekt ausgeliefert, jetzt abgedeckt durch einen Test, der ihm recht gab.

Dann haben zwei Review-Agenten, auf zwei parallelen Zweigen desselben Runs, je einen echten Einzeiler-Bug gefunden. Jeder hat ihn direkt gefixt, im selben Worktree, zur selben Zeit. Sie sind kollidiert.

Jeder dieser Agenten hatte einen Schritt-Prompt, der in klaren Worten sagte: nur Review. Nichts hat sie aufgehalten, und nichts hat es gemeldet: aus Sicht der Plattform hatte ein Schritt Schreibwerkzeuge und hat sie benutzt.

Warum der Prompt nicht gehalten hat

Die verlockende Lesart ist, dass die Agenten die Anweisung ignoriert haben. Das ist nicht, was passiert ist, und es zählt, weil es ändert, wie der Fix aussehen muss.

Jeder Agent hatte einen lokal vertretbaren Grund zu schreiben. Eine rote Suite und eine Spec, die falsch aussah. Ein Bug, der vier Sekunden zum Fixen braucht und vierzig zum Beschreiben. Keiner hat beschlossen, die Regel zu brechen. Jeder hat beschlossen, dass sein Fall der ist, den die Regel nicht meinte. Von innerhalb des Schritts sieht die Ausnahme immer vernünftig aus.

Eine geschriebene Anweisung ist eine Bitte an das Urteilsvermögen des Modells. Ein Reviewer, der auch fixen kann, wird früher oder später fixen, weil Fixen der kürzeste Weg von „ich habe es gefunden“ zu „erledigt“ ist. Die einzige Regel, die den Kontakt mit einer plausiblen Ausnahme überlebt, ist eine, mit der das Modell nicht diskutieren kann: ein Werkzeug, das nicht da ist.

Warum die globale Einstellung es auch nicht konnte

Bis dahin war der einzige Hebel, der einen laufenden Schritt erreichte, die Provider-Einstellung, die alle Claude-Agenten auf der Maschine auf einmal abdeckt. Das ist die falsche Form für einen Run. In derselben Pipeline muss der Implementierer schreiben und der Reviewer nicht. Ein globaler Schalter kann die beiden nicht auseinanderhalten.

Und die Einschränkung pro Agent, die wir schon hatten, die ein Ticket mitgeben kann, wenn es einen Agenten startet, wurde bewusst nicht an Team-Schritte weitergereicht. Ein aus einem Ticket gestarteter Agent konnte also eingeschränkt werden, ein Knoten eines Teams nicht. Das war die eigentliche Ursache, und es war eine Designentscheidung, die schlecht gealtert war.

Die Regel: eine Checkbox am Knoten

Der Fix ist ein Boolean am Review-Knoten. Hake Nur lesen an, und der Agent, der diesen Schritt verkörpert, wird ohne Schreibzugriff auf das Projekt gestartet: keine Dateiänderung, kein git commit oder push, kein Shell-Befehl, dessen einzige Aufgabe es ist, den Worktree zu verändern. Lesen, grep, git diff, git log, die Tests, der Linter und jedes Team-Werkzeug bleiben offen.

Wir waren explizit dabei, was es nicht ist: es ist keine Deny-Liste, die der Nutzer von Hand schreibt, pro CLI. Niemand sollte fünf Berechtigungssyntaxen kennen müssen, um „dieser hier reviewt“ zu sagen. Der Schalter erzeugt für jeden Provider das richtige Flag, und er wird zuletzt angewendet, nach dem autonomen Modus und nach allem, was der Nutzer am Agenten gespeichert hat, damit er gewinnt.

Was jedes CLI tut, abgelesen aus seiner eigenen Hilfe

Wir setzen nur bei Providern durch, deren Flag wir in ihrer eigenen --help gelesen haben. Ein geratenes Flag killt den Start mit einem Parse-Fehler, und das ist schlimmer als ein Schritt ohne Durchsetzung. Die anderen CLIs bekommen nur die geschriebene Regel, und der Editor sagt das im Klartext unter der Checkbox.

Zwei Details in dieser Tabelle haben uns je einen Bug gekostet, sie sind es also wert, ausgeschrieben zu werden.

Codex und Grok verweigern ein wiederholtes Flag. Beide parsen ihre Argumente mit einem strikten Parser. Hätte der Nutzer bereits --sandbox workspace-write am Agenten gespeichert, würde ein angehängtes --sandbox read-only es nicht überschreiben, es würde den Start abstürzen lassen. Für Flags mit Wert entfernen wir also jedes vorhandene Vorkommen, samt Wert, bevor wir unseres anhängen. Dasselbe für --agent bei OpenCode, dessen Parser ein wiederholtes Flag in ein Array verwandelt und weiter unten scheitert.

Auf Claude Code muss sich die Liste stapeln. --disallowedTools nimmt eine durch Leerzeichen getrennte Liste und kann wiederholt werden, und wir übergeben schon eine, wenn ein Agent den eingebetteten Browser nicht steuern darf. Der Parser verkettet eine wiederholte variadische Option, also addieren sich die beiden Listen, statt dass die zweite die erste ersetzt.

Die vollständige Liste für Claude Code sind die vier Dateibearbeitungswerkzeuge, jeder Git-Unterbefehl, der in den Index, den Baum, die Refs oder ein Remote schreibt (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree), und die Shell-Befehle, die nur existieren, um Dateien zu verändern (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i). Grok nimmt dieselben Regel-Strings, in seiner Glob-Form, plus seine eigenen Namen für die Dateiwerkzeuge (search_replace, write, hashline_edit).

Der Prompt hat trotzdem eine Aufgabe

Das Flag verweigert. Es erklärt nicht. Und ein Agent, der auf eine Verweigerung stößt, die er nicht versteht, behandelt sie als Bug und sucht einen anderen Weg hindurch, was genau das Verhalten ist, das wir loswerden wollten.

Ein Nur-Lesen-Schritt bekommt also auch zwei Sätze in seinen Prompt. Der erste sagt, dass der Schritt nur lesen darf, listet auf, was das bedeutet, und stellt klar, dass eine Verweigerung die Regel ist, kein Hindernis, das man mit einem anderen Befehl umgeht. Der zweite listet auf, was offen bleibt, und weist den Agenten an, in seiner Übergabe zu melden, was sich ändern sollte, mit Datei, Zeile und Grund, und den Schritt, dem der Code gehört, es umsetzen zu lassen.

Auf den CLIs mit verifiziertem Flag ist dieser Absatz das, was die Verweigerung verständlich macht. Auf den anderen ist er die ganze Durchsetzung, und das sagen wir lieber, als so zu tun, als ob.

Wer in den mitgelieferten Vorlagen nur lesen darf

Die Knoten, die urteilen, sind nur lesend: der QA-Verifikationsschritt der beiden Starter-Vorlagen, die Reproduktions- und Verifikationsschritte von Bug hunt, die Zweige QA und Security von Release shield, der Tester von Feature squad.

Die Knoten, denen der Code gehört, schreiben weiter: der Entwickler, und das Release-Gate, das so geschrieben ist, dass es jeden Befund selbst behebt. Ein Release-Gate, das nicht schreiben kann, ist ein Release-Gate, das nicht releasen kann.

Diese Aufteilung ist das ganze Design, und es ist die Aufteilung, die der Vorfall zweimal verletzt hat: ein Release-Knoten, der am falschen Ort geschrieben hat, und Review-Knoten, die überhaupt geschrieben haben.

Was das nicht ist

Es ist keine Sicherheitsgrenze. Der Melder hat es im Bericht gesagt, und er hatte recht: ein bash -c kommt an einer Werkzeug-Deny-Liste vorbei. Wenn du einen Agenten isolieren musst, dem du nicht traust, ist das eine Sandbox oder eine separate Maschine, und Codex ist der einzige der fünf, dessen Nur-Lesen-Modus tatsächlich das ist.

Was der Schalter stoppt, sind der Unfall und die Rollendrift, und das ist es, was tatsächlich passiert. Ein Reviewer entkommt einer Deny-Liste nicht absichtlich. Er greift reflexhaft nach Edit, und der Reflex wird jetzt verweigert.

Was wir nicht gebaut haben

Der Melder hat noch eine Sache gewünscht: ein Ereignis in der Zeitleiste des Runs mit dem Text „Knoten X hat in den Baum geschrieben“, als Mindestsignal auch ohne Durchsetzung. Es ist eine gute Idee, und wir haben sie hier nicht umgesetzt, weil sie ein Basis-Diff pro Schritt auf Seiten des Runners braucht. Wenn der Bedarf zurückkommt, ist das das nächste Stück.

Wenn du AgentsRoom nicht benutzt

Die Flags oben lassen sich so kopieren, wie sie sind. Ein von Hand gestarteter Review-Agent mit codex --sandbox read-only, oder claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)", kann nicht tun, was unsere beiden Review-Knoten getan haben. Schreib dieselben zwei Sätze in seinen Prompt, damit er weiß, warum er abgewiesen wird.

Was die Checkbox hinzufügt, ist, dass du dir nicht merken musst, welche der fünf Syntaxen gilt, dass das Flag über jeden autonomen Modus gewinnt, in dem der Schritt läuft, und dass es einen Run übersteht, der später denselben Schritt erneut betritt.

Der Knoten-Schalter und die Tabelle pro Provider sind auf der Seite Agent Teams dokumentiert. Ob ein Review durch einen Agenten überhaupt etwas wert ist, und wie viel von einem Diff noch einen Menschen verdient, ist eine andere Frage, und darüber haben wir in Solltest du den Code deines KI-Agenten noch reviewen? geschrieben. Dieser Beitrag handelt von der kleineren, mechanischeren Sache: sobald du entschieden hast, dass ein Agent reviewt, mach ihn physisch unfähig, irgendetwas anderes zu tun.