Codex für Code-Review: So lassen Sie KI PRs prüfen, ohne dass sie wahllos Code ändert

Ein PR mit 800 Zeilen landet im Repository. Der Titel lautet nur fix, und in der Beschreibung steht ein einziger Satz: „ein paar Dinge repariert“. Sie starren auf den Diff, wissen nicht, wo die eigentlichen Risiken liegen, und möchten nicht jede geänderte Datei Zeile für Zeile lesen. Jemand schreibt im PR-Kommentar @codex review for auth bypass and PII logging. Ein paar Minuten später erscheint ein Inline-Kommentar direkt bei logger.info(user.email).

Jetzt müssen Sie entscheiden: Soll Codex automatisch fixen, ändern Sie die Stelle selbst, oder fragen Sie zuerst beim Fachteam nach, ob dieses Logging überhaupt erlaubt ist? Dieser Artikel erklärt die Auslösebedingungen, Review guidelines, die Bedeutung von P0/P1, den Umgang mit Findings und die Grenze, an der Menschen bestätigen müssen.

@codex review ist kein Zauberspruch

@codex review ist kein Schalter, der KI automatisch Code ändern lässt. Der Kommentar bittet Codex nur, den PR-Diff zu lesen und Review-Kommentare nach Ihren Regeln zu veröffentlichen. Ob das Review startet, was geprüft wird und wie Sie mit den Ergebnissen umgehen, hängt von Setup und menschlichem Urteil ab.

GitHub Cloud: Trigger und Einstellungen

Die Voraussetzung für Codex als Code-Review-Hilfe: Das Repository ist für Codex Cloud eingerichtet, und Sie haben Zugriff auf die Code-Review-Einstellungen. Es gibt zwei Auslösewege: Sie schreiben @codex review in einen PR-Kommentar, oder Sie aktivieren Automatic reviews in den Einstellungen, damit Codex bei einem neuen PR im Zustand opened for review automatisch ein Review veröffentlicht.

Nach dem Start liest Codex den PR-Diff, folgt der Repository guidance, meist den Review guidelines in AGENTS.md, und veröffentlicht Inline-Kommentare als normales GitHub Code-Review. @codex review ist keine Approval. Automatic reviews bedeuten ebenfalls keine automatische Freigabe. Sensible Änderungen an auth, payment oder data migration brauchen weiterhin menschliche Bestätigung.

Sie können PR-Trigger und CI-Workflows mit Branch Protection Rules kombinieren, damit AI review nur eine von mehreren Prüfungen bleibt. Zur Konfiguration von PR-Triggern passt der frühere Artikel GitHub Actions PR-Trigger Grundlagen.

Auf P0/P1 fokussieren, nicht alles kommentieren

Codex markiert standardmäßig nur Probleme mit P0/P1-Priorität. P0 meint blockierende Probleme wie security regressions, auth bypass oder data loss. P1 meint Probleme, die behoben werden sollten, etwa performance, concurrency oder logging sensitive data.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Dieser Fokus verhindert, dass Review-Kommentare explodieren, hält das Signal hoch und reduziert niedrigwertiges Rauschen. In AGENTS.md können Sie im Abschnitt Review guidelines die Standardregeln überschreiben. Zum Beispiel: Nur auth bypass, PII logging und concurrency prüfen, code style an Prettier übergeben und minor performance nur auf Hot Paths betrachten. Der nächste Abschnitt zeigt, wie solche Review guidelines aussehen können.

Review guidelines gehören in AGENTS.md, nicht in jeden PR-Kommentar

Review guidelines bestimmen, worauf Codex review achten soll und wie Findings priorisiert werden. Sie gehören in die AGENTS.md-Datei des Repositorys, nicht als Wiederholung in jeden einzelnen PR-Kommentar.

AGENTS.md-Hierarchie und Review guidelines

Codex liest AGENTS.md vor dem Start. Die Suche läuft vom Git root bis zum aktuellen Arbeitsverzeichnis, und näher liegende Anweisungen sind spezifischer. Eine AGENTS.md unter auth/ kann also Projektregeln überschreiben und nur auth-relevante Risiken fokussieren.

Ein typischer Abschnitt Review guidelines:

## Review guidelines

Nur auf folgende Risiken achten:
1. Security regressions(auth bypass、path traversal)
2. PII logging(user.email、phone number)
3. Concurrency issues(race condition、deadlock)

Nicht prüfen:
- Code style(durch Prettier automatisiert)
- Minor performance(nicht auf Hot Paths)

Der Vorteil: Alle PRs teilen dieselben Regeln, Sie müssen sie nicht jedes Mal im Kommentar wiederholen, und eine AGENTS.md nahe an den geänderten Dateien kann konkreter sein.

Beachten Sie, dass Instruktionsdateien durch project_doc_max_bytes begrenzt sind. Der Standardwert liegt bei 32 KiB; zu lange Dateien können abgeschnitten werden. Die vollständige AGENTS.md-Struktur mit Project rules, Review guidelines und Coding style gehört in einen eigenen Codex-Praxisartikel. Hier geht es nur um Struktur und Priorisierung der Review guidelines.

Im Codex app review pane erst den Diff sehen, dann entscheiden

Das review pane in der Codex app zeigt nicht nur Änderungsvorschläge der KI. Es bildet den Zustand des Git-Repositorys ab. Standardmäßig liegt der Fokus auf uncommitted changes, Sie können aber auch all branch changes oder last turn changes ansehen.

Inline-Kommentare und PR-Kontext

Inline-Kommentare im review pane hängen direkt an Diff-Zeilen. Diese präzisen Hinweise können Sie nutzen, um zu entscheiden: Codex fixen lassen, selbst ändern oder als False Positive markieren. Nach /review erscheinen die Ergebnisse als Inline-Kommentare im review pane.

Wenn Codex GitHub access hat und das Projekt auf einem PR-Branch liegt, kann die app PR context anzeigen: reviewer feedback, changed files und PR description. Voraussetzung ist eine installierte und authentifizierte GitHub CLI mit gh auth login. Fehlt das, erscheinen PR details möglicherweise nicht, und Sie sehen nur den lokalen Diff.

Granularität steuern: nach File oder Hunk stagen und reverten

Das review pane kann auf Ebene des entire diff, einzelner files oder einzelner hunks stage, unstage und revert ausführen. Revertieren Sie nicht sofort den ganzen Commit, nur weil ein Finding auftaucht, besonders bei Änderungen über mehrere Dateien. Hunk-Granularität erlaubt es, sichere Änderungen zu behalten und nur riskante Teile zurückzunehmen.

Review-Findings bearbeiten: Nach @codex fix trotzdem Diff, CI und Tests prüfen

Wenn Codex ein P0/P1 findet, sollten Sie nicht sofort alles an @codex fix übergeben. Zuerst müssen Sie prüfen, ob das Finding stimmt, ob der Fix vernünftig wäre und ob die Änderung eine sensible Grenze berührt, die das Team bestätigen muss.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Review findings triage 判断表

Ein ausführbarer Ablauf für Findings

Prüfen, ob das Finding stimmt: Schauen Sie sich die Diff-Zeile an, auf die der Inline-Kommentar zeigt, und bestätigen Sie, dass das Problem tatsächlich existiert.

Fix-Grenze bestimmen: auth, payment und data migration sind sensible Änderungen und brauchen menschliche Bestätigung. style und minor perf können oft ignoriert oder der Toolchain überlassen werden.

Umgang wählen:

• Codex fixen lassen: Schreiben Sie im PR-Kommentar @codex fix the P1 issue; Codex startet aus dem PR context eine cloud task
• Selbst ändern: Code manuell bearbeiten, lokal testen und danach pushen
• Tests verlangen: Ein follow-up issue öffnen oder im Kommentar erklären
• False Positive markieren: Im Kommentar begründen, damit dieselbe Meldung nicht wiederholt auftaucht

Diff und CI ansehen: Selbst wenn @codex fix in den PR branch pushen darf, müssen Sie Diff, CI-Ergebnis und Testabdeckung prüfen. Ein Codex-Fix ist kein automatischer Merge, kein CI-Pass und keine menschliche Reviewer-Approval.

Sensible Änderungen menschlich bestätigen: auth bypass, payment flow und data migration betreffen Sicherheitsgrenzen. Ein Team-Reviewer muss das bestätigen. Überspringen Sie diese Prüfung nicht.

Dinge, die Sie nicht tun sollten

• Nicht automatisch pushen oder mergen: @codex fix bittet KI um eine Codeänderung, ist aber keine Merge-Erlaubnis
• CI nicht überspringen: Auch nach einem Codex-Fix muss CI laufen und zeigen, dass keine anderen Tests brechen
• Menschliches Reviewer-Feedback nicht ignorieren: AI review ist eine zweite Prüfung, kein Ersatz für Team-Reviewer
• Codex keine zu großen Rechte geben: main branch push, force push und write access auf sensible Verzeichnisse sollten eingeschränkt bleiben

Sicherheitsgrenzen und Rechteverwaltung für sensible Änderungen gehören in einen späteren Codex-Praxisartikel zu Berechtigungen und Secrets. Für CI-Best-Practices siehe den früheren Artikel zur GitHub Actions CI-Pipeline.

Commit Message und PR description: KI darf Text entwerfen, aber keine Norm erfinden

Mit @codex generate commit message oder @codex generate PR description kann Codex aus Diff und PR context Text entwerfen. Prüfen Sie das Ergebnis, bevor Sie es verwenden, und committen Sie es nicht blind. Commit Messages sollten Conventional Commits folgen, statt spontan ein eigenes Format zu erfinden.

Conventional Commits und eine Commit-Message-Vorlage

Das Conventional-Commits-Format lautet <type>[optional scope]: <description>. Häufige Typen sind fix für PATCH-Versionen, feat für MINOR-Versionen und ein BREAKING CHANGE footer oder ! für Breaking Changes.

Beispiel:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

fix(auth): prevent bypass in login flow

- Add session validation before auth redirect
- Reject expired tokens within 5 minutes

Refs: #123

Conventional Commits sind sinnvoll, weil sie ein breit genutzter Standard sind. Toolchains wie semantic-release, auto-changelog und commitlint nutzen dieses Format, um Changelogs zu erzeugen und Versionssprünge abzuleiten. Ein selbst erfundenes Format kann diese Automatisierung brechen und die Zusammenarbeit im Team teurer machen.

PR-description-Vorlage

Eine PR description sollte mindestens fünf Teile enthalten:

1. Hintergrund: Warum diese Änderung nötig ist, etwa Nutzerfeedback, Performance-Problem oder Sicherheitsrisiko
2. Änderungsumfang: Welche Module betroffen sind, etwa auth, payment oder logging
3. Tests: Geprüfte Szenarien, etwa lokale Tests, CI-Abdeckung oder manuelle Prüfung
4. Risiko: Bekannte Randbedingungen, etwa Nebenläufigkeit oder Verhalten unter hoher Last
5. Rollback: Wie schnell zurückgerollt werden kann, etwa revert commit, feature flag oder config toggle

Nach der Generierung prüfen Sie, ob alle fünf Teile vollständig sind, ob die Beschreibung stimmt und ob Risiken oder Rollback fehlen. Committen Sie generierten Text nicht direkt, besonders bei sensiblen Änderungen.

Für Commit Message und PR description können Sie im PR-Kommentar konkrete Anweisungen geben, zum Beispiel @codex generate commit message following Conventional Commits. So folgt die KI dem Standardformat.

Zusammenfassung

Codex review ist eine zweite, signalstarke Prüfung, keine Merge-Erlaubnis. @codex review bittet die KI, den Diff zu lesen und Inline-Kommentare zu veröffentlichen. Automatic reviews automatisieren nur den Auslöser, nicht Approval oder Merge.

Kernablauf:

1. In den AGENTS.md Review guidelines auf 1 bis 2 Risiken fokussieren, etwa auth bypass, PII logging oder concurrency. Nicht versuchen, alles abzudecken
2. P0/P1 ist der Standardfokus, damit Review-Kommentare nicht explodieren. P0 muss behoben werden, P1 braucht eine Entscheidung zum Umgang
3. Nach einem Finding die Diff-Zeile prüfen, auf die der Inline-Kommentar zeigt, und bestätigen, ob das Problem stimmt. Sensible Änderungen an auth, payment oder data migration brauchen menschliche Bestätigung
4. Nach @codex fix weiterhin Diff, CI-Ergebnis, Testabdeckung und menschliches Review prüfen. Nicht automatisch pushen oder mergen, CI nicht überspringen und Team-Reviewer nicht ignorieren
5. Commit Messages im Conventional-Commits-Format schreiben. Kein eigenes Format erfinden, weil die Toolchain den Standard für Changelog und Versionierung nutzt

Nächste Schritte:

• Fügen Sie Ihrem Repository AGENTS.md hinzu und schreiben Sie kurze Review guidelines, die nur 1 bis 2 Risiken fokussieren
• Probieren Sie im nächsten PR @codex review aus und prüfen Sie, ob die Inline-Kommentare zu Ihren Regeln passen
• Bei sensiblen Änderungen lesen Sie zuerst die späteren Codex-Praxisartikel zu Berechtigungen, Secrets und Fehleranalyse, bevor Sie @codex fix einsetzen

Verwandte Artikel

• GitHub Actions PR-Trigger Grundlagen: PR-Trigger und Branch Protection Rules konfigurieren
• GitHub Actions CI-Pipeline Best Practices: Checks im CI-Ablauf und Aufgaben menschlicher Reviewer
• AI-Coding-Assistant-Vergleich: Claude Code vs Cursor vs Copilot: Auswahl von AI-Coding-Tools