OpenQodex: Open-Source-KI-Code-Review vor dem Push für Claude Code und Codex

KI-Coding-Agenten haben das Tempo erhöht, in dem Code entsteht, aber nicht das Tempo, in dem er geprüft wird. Diffs werden größer, die menschliche Aufmerksamkeit nutzt sich ab, und die wenigen Zeilen, auf die es wirklich ankommt, verschwinden in einem Haufen plausibel wirkender Änderungen. OpenQodex antwortet darauf schlicht: Die Prüfung rückt vor den Push und wird zur letzten Schranke, bevor eine Änderung Ihren Rechner verlässt. Das Werkzeug zielt auf Claude Code und Codex und läuft auch direkt im Terminal. Der Kern ist ein einziger Befehl, openqodex review. Er klärt zuerst, was Sie tatsächlich geändert haben: die noch nicht gepushten Commits plus alles, was noch nicht committet ist. Dann startet er die Scanner, die zu den geänderten Dateien passen, und behält nur Befunde auf Zeilen, die Sie angefasst haben. Die Altlasten im alten Code lenken Sie so nicht ab.

Die Scanner-Ausgabe ist nur Rohmaterial. Als Nächstes startet OpenQodex einen eigenen Prüfer, einen getrennten Claude-Code- oder Codex-Prozess, der eine eingefrorene Kopie der Änderung liest. Dieser Prüfer muss jeden Scanner-Befund kontrollieren, und er bekommt jede geänderte Zeile vorgelegt. Seine Antwort wird nicht auf Treu und Glauben übernommen: OpenQodex prüft sie mit Skripten und setzt dann einen einzigen Bericht zusammen. Der Kern dieses Entwurfs ist die Arbeitsteilung. Regelbasierte Scanner finden Muster stabil und wiederholbar, erzeugen aber viele Fehlalarme und verstehen keinen Kontext. Sprachmodelle verstehen Absicht und Kontext, können aber Dinge übersehen oder erfinden. Lässt man das Modell über jeden Scanner-Befund urteilen und prüfen deterministische Skripte dann die Schlüsse des Modells, entstehen drei Ebenen, die sich gegenseitig in Schach halten. Das ist glaubwürdiger, als sich auf eine einzelne Ebene zu stützen.

Der Grad der Isolation um den Prüfer ist der Teil des Projekts, der die genaueste Lektüre verdient. Laut README startet Claude Code als Prüfer nur mit Lese-, Such- und Listenwerkzeugen, innerhalb der Kopie der Änderung und ohne Ihre Einstellungen, Hooks, Plugins, Ihr Gedächtnis oder Ihre Anweisungsdateien. Sein Ereignisstrom zeigt jeden Lesezugriff, sodass der Bericht die gelesenen Dateien auflisten kann. Bei Codex liegt es etwas anders. Es startet in einer schreibgeschützten Sandbox, die Lesezugriffe auf die Kopie der Änderung und die Systemordner beschränkt, ohne Netzwerk für seine Befehle und ohne Ihre Konfiguration, Plugins, Hooks oder die Anweisungsdateien des Repositorys. Die Dokumentation nennt zwei Grenzen offen: Codex lädt weiterhin die globale Datei ~/.codex/AGENTS.md, und sein Ereignisstrom zeigt nicht jeden Befehl, weshalb der Bericht festhält, dass seine Lesezugriffe nicht aufgezeichnet wurden. Solche Grenzen in die Dokumentation zu schreiben, beruhigt mehr als ein Versprechen absoluter Sicherheit, und es lädt jeden ein, sie am eigenen Bedrohungsmodell zu messen.

Vollständigkeit ist hier präzise definiert. Eine Prüfung ist nur dann vollständig, wenn drei Dinge zutreffen: Jede Stufe lief, jeder Scanner-Befund wurde aufgegriffen oder mit Begründung verworfen, und jede geänderte Zeile lag dem Prüfer vor. Das kann im Briefing geschehen, in einer späteren Nachricht von OpenQodex oder, bei Claude Code, in einer Datei, die er gelesen hat. Fehlt eine Bedingung, gibt das Werkzeug «Review incomplete» aus statt eines glatten Urteils. Abdeckung wird so vom Schlagwort zur prüfbaren Bedingung. Für Teams, die vage Freigaben gewohnt sind, ist das eine Praxis, die man übernehmen kann. Auch die Ausgabe ist zurückhaltend. Am Ende druckt das Terminal einen kurzen Beleg: das Urteil, die Zusammenfassung des Prüfers, eine Zeile je Befund (Nummer, Schweregrad, Kategorie, Titel, Datei und Zeile) und die absoluten Pfade von report.html und report.md. Der vollständige Bericht wird zusätzlich als HTML, Markdown, JSON und SARIF auf die Platte geschrieben, wobei SARIF die Anbindung an vorhandene Sicherheitswerkzeuge erleichtert. Die Datei report.html ist eine einzelne Datei auf Ihrer Platte. Sie zeigt jede geänderte Datei als Diff, jeden Befund unter seiner Zeile und danach Abdeckung, Scanner und Auswirkungsradius. Laut README führt sie kein Skript aus, lädt nichts von außen, maskiert jede Zeichenkette und schwärzt die von den Scannern gefundenen Geheimnisse. Die Entscheidung zum Beheben bleibt beim Menschen. Der mitgelieferte Skill weist den Agenten an, Ihnen den Beleg zu zeigen, «Fix all, or tell me which?» zu fragen und nur die von Ihnen genannten Befunde zu beheben. Der Befehl openqodex findings 1,3 gibt die benannten Befunde vollständig aus.

Die Einstiegshürde ist niedrig. Der Befehl npx openqodex init sucht auf Ihrem Rechner nach Claude Code, Cursor, Codex CLI und Cline, listet alle Dateien auf, die er schreiben wird, und fragt nur einmal. Danach nennt er den gefundenen Prüfer oder das, was Sie beheben müssen. Nötig sind Node 22 oder neuer und git; das Werkzeug läuft unter macOS und Linux, unter Windows nutzt man WSL. Außer einem angemeldeten Claude Code oder Codex braucht es weder Schlüssel noch Konto noch Server. Neben der lokalen Standardänderung deckt review --all das ganze Repository ab, und review mit einem Branch-Namen oder einer Pull-Request-Nummer wie '#42' prüft Arbeit, die nicht Ihr aktueller Stand ist: OpenQodex holt sie, checkt sie in einem temporären Ordner aus und prüft, was seit der Abzweigung von der Basis hinzukam. Die aktuelle Version ist 0.12.0 unter der Apache-2.0-Lizenz. Im Alltag verändert das die Form des Arbeitsablaufs. Die meisten Code-Reviews finden statt, nachdem ein Pull Request geöffnet wurde, wenn der Prüfer vor einer fertigen Commit-Historie steht und der Kontext des Autors schon zerstreut ist. Rückt die Prüfung vor den Push, tauchen Probleme im günstigsten Moment auf: Die Änderung ist noch lokal, der Autor erinnert sich an seine Überlegungen, und die Korrektur unterbricht keinen Kollegen. Weil jedes Scanner-Ergebnis auf geänderte Zeilen beschränkt ist, betrifft jeder Befund im Bericht das, was Sie gerade tun, und Sie müssen nicht in geerbten Problemen wühlen. Für Teams, in denen Agenten Code in großer Menge erzeugen, entsteht so zwischen Commit und Teilen eine billige, verlässliche Schranke. Menschliche Prüfer können ihre Aufmerksamkeit für Architektur und fachliche Urteile aufsparen, die Maschinen noch schlecht beherrschen.

Aus Sicht der Branche steht OpenQodex für ein Muster, das Gestalt annimmt: Die Prüfung ist nicht mehr ein Schritt nach dem Merge, sondern ein lokaler, prüfbarer Schritt im Agenten-Workflow. Nüchternheit ist angebracht. Ein Modell derselben Familie, das Code eines ähnlichen Modells prüft, kann dieselben blinden Flecken teilen. Der Codex-Pfad ist deutlich schlechter nachprüfbar als der Claude-Code-Pfad. Und die Versionsnummer 0.12.0 zeigt ein junges Projekt an. Diese Analyse stützt sich auf einen öffentlichen README-Auszug, und über nicht abgedeckte Teile treffen wir keine Aussagen. Dennoch verankert das Projekt drei Ideen im Skelett des Produkts: Belege, Abdeckung und einen Menschen, der entscheidet. Jedes Team, das Agenten an die tägliche Entwicklung anschließt, sollte diese drei Ideen ernst nehmen.