OpenQodex prüft Agenten-Code vor dem Git-Push

Worum es geht

OpenQodex ist ein quelloffenes Werkzeug, das Codeänderungen vor dem Hochladen in ein Git-Repository prüft. Es richtet sich besonders an Teams, die Claude Code, Codex, Cursor oder Cline einsetzen und eine zweite Kontrollstufe zwischen einem Coding-Agenten und dem Git-Push benötigen.

Das Werkzeug läuft auf dem eigenen Rechner. Zuerst arbeiten klassische Scanner, anschließend bewertet ein getrennt gestarteter Claude-Code- oder Codex-Prozess die Änderung und die Scannerfunde. OpenQodex steht unter Apache 2.0 und befindet sich laut Projekt noch auf dem Weg zu Version 1.0.

Was OpenQodex tatsächlich macht

OpenQodex betrachtet nicht hochgeladene Commits und ungespeicherte Änderungen. Passend zu den betroffenen Dateien startet es Scanner für Geheimnisse, bekannte Schwachstellen, Abhängigkeiten, Lint-Regeln sowie Konfigurationen von GitHub Actions, Docker, Terraform, Kubernetes, CloudFormation und Datenbanken. Das Projekt nennt 22 eingebaute Scanner.

Danach startet es einen separaten Prüfer über eine vorhandene Anmeldung bei Claude Code oder Codex. Dieser muss jeden Scannerfund bestätigen oder mit Begründung verwerfen. OpenQodex kontrolliert, ob alle Funde und alle geänderten Zeilen berücksichtigt wurden. Die Ergebnisse erscheinen als HTML, Markdown, JSON und SARIF. Ein Git-Hook kann vor dem Push warnen; eine konfigurierbare Schweregrenze kann den Vorgang blockieren.

Warum das wichtig ist

Coding-Agenten können Änderungen schnell erzeugen, aber derselbe Agent übersieht bei der Selbstkontrolle möglicherweise dieselben falschen Annahmen. OpenQodex trennt deshalb Erzeugung und Prüfung, sofern ein zweiter Prozess verfügbar ist. Gleichzeitig liefern deterministische Scanner nachvollziehbare Signale, die nicht allein von einem Sprachmodell abhängen.

Für kleine Teams ist außerdem relevant, dass Berichte lokal entstehen und Scannerfunde auf geänderte Zeilen eingegrenzt werden. Der Modellprüfer sendet die Änderung jedoch an den Dienst des vorhandenen Claude-Code- oder Codex-Kontos. „Lokal“ bedeutet deshalb nicht automatisch, dass sämtlicher Code auf dem Gerät bleibt.

Einfach erklärt

OpenQodex funktioniert wie die Kontrolle eines Koffers vor einer Reise. Zuerst prüft eine Liste, ob Reisepass, Medikamente und verbotene Gegenstände auffallen. Danach schaut eine zweite Person in den Koffer und beurteilt die Hinweise. Trotzdem garantiert auch diese doppelte Prüfung nicht, dass nichts vergessen wurde.

Praktisches Beispiel

Ein Agent ändert in einem Webdienst 14 Dateien und ergänzt eine Datenbankmigration. Vor dem Push startet ein Entwickler openqodex review. Ein Geheimnis-Scanner meldet einen Testschlüssel, ein Abhängigkeits-Scanner findet eine bekannte Schwachstelle, und der getrennte Prüfer entdeckt zusätzlich eine fehlende Berechtigungsprüfung.

OpenQodex erzeugt einen Bericht mit Fundort, Schwere und Begründung. Der Entwickler lässt zwei Probleme beheben und verwirft den Testschlüssel-Fund nach Prüfung als absichtliche Attrappe. Erst nach einem neuen Lauf wird der Push freigegeben. Der Bericht dient dabei als nachvollziehbare Quittung, nicht als Sicherheitszertifikat.

Einordnung und Grenzen

• Für eine vollständige Prüfung müssen Claude Code oder Codex installiert und angemeldet sein. Cursor und Cline können den separaten Prüfer nicht selbst stellen.
• Im Codex-Sandboxbetrieb kann laut Projektdokumentation kein zweiter Codex-Prozess starten. Dann ist die vorgesehene Trennung eingeschränkt.
• Windows und WSL sind derzeit nicht durch die Projekt-CI abgedeckt; offiziell genannt werden macOS und Linux.
• Einige Scanner benötigen Netzwerkzugriff oder zusätzliche Laufzeiten. Der Offline-Modus überspringt mehrere Prüfungen, und der Modellprüfer kommuniziert weiterhin mit seinem Modelldienst.
• Kein Scanner und kein Sprachmodell findet jeden Fehler. Hooks lassen sich zudem mit Git-Optionen umgehen; organisatorische Regeln und Tests bleiben nötig.

Der sinnvolle Einstieg ist das mitgelieferte Demo-Repository mit absichtlich eingebauten Fehlern. Teams sollten danach einen nicht kritischen eigenen Pull Request prüfen, Laufzeit, Fehlalarme, Datenwege und Blockierregeln dokumentieren und erst dann einen verpflichtenden Push-Schutz erwägen.

SEO- und GEO-Schlüsselbegriffe

OpenQodex, Codeprüfung, Coding-Agenten, Codex CLI, Claude Code, lokale Scanner, SARIF, Git-Push, DevSecOps, Open Source