Code review z Codex: jeden standard w CLI, aplikacji desktopowej i GitHubie

Code review w Codex to jeden recenzent uruchamiany na kilka sposobów: lokalnie przez /review i codex review, w skryptach przez codex exec review, a na pull requestach GitHuba przez @codex review lub automatycznie. Wszystkimi steruje sekcja ## Review guidelines w AGENTS.md. Recenzentowi można ufać, gdy test na zasianych błędach pokaże, że wyłapuje klasy defektów ważne dla zespołu.

Ta strona jest dla developerów i tech leadów, którzy dostają już od Codex przeglądy pojedynczych zmian, a teraz chcą z nich zrobić bramkę dla całego zespołu. Zespół otwiera więcej pull requestów, niż jest w stanie przeczytać, a połowę z nich piszą agenci. Przegląd Codex u jednej osoby zgłasza wszystko, u drugiej nic, i nikt nie wie, czy czysty przegląd oznacza czystą zmianę. Poniższy workflow zamienia review w Codex w warstwową, mierzoną bramkę z wyraźną granicą, od której decyduje człowiek.

Jeśli nie uruchamiałeś jeszcze przeglądu w Codex, zacznij od strony przegląd zmian Codex przed commitem, która omawia /review, priorytety P0–P3 i triaż. Konfiguracja repozytorium pod @codex review jest w podłączeniu Codex do GitHuba.

Co zyskasz, wdrażając review z Codex w całym zespole

• Mapę tego, która powierzchnia przeglądu Codex pasuje do którego etapu potoku i co każda z nich może zablokować.
• Hook pre-push, który uruchamia codex exec review i blokuje push przy znaleziskach P0 lub P1.
• Kolejność wdrażania @codex review, @codex security review i automatycznych przeglądów, która trzyma szum w ryzach.
• Sposób na reguły review w AGENTS.md pisane na podstawie historii własnych pull requestów, a nie z ogólnej listy.
• Test na zasianych błędach, który pokazuje, co recenzent wyłapuje, zanim ktokolwiek zacznie na nim polegać.
• Listę eskalacji: zmiany, które zawsze zatwierdza człowiek, niezależnie od tego, co mówi Codex.

Która powierzchnia przeglądu Codex pasuje do którego etapu potoku?

Wszystkimi powierzchniami sterują te same reguły przeglądu z AGENTS.md. Różnią się tym, kto je uruchamia, jaki zakres widzą i czy mogą zatrzymać zmianę.

Powierzchnia	Kto uruchamia	Zakres	Czy może zablokować zmianę?
/review w TUI	Autor, w trakcie sesji	Niezacommitowane zmiany, gałąź bazowa, jeden commit lub własne instrukcje	Nie, informuje autora
codex review (powłoka)	Autor, z terminala	--uncommitted, --base BRANCH lub --commit SHA	Nie
codex exec review (skrypt)	Hook Gita lub zadanie CI	Te same flagi oraz -o, --json i pozostałe opcje exec	Tak, gdy skrypt czyta jego wynik
Aplikacja desktopowa Codex (codex app lub /app z TUI; macOS i Windows)	Autor, wizualnie	Zmiany z sesji	Nie
@codex review na pull requeście	Każdy, kto doda komentarz	Zmiany z pull requesta	Tylko jeśli reguły merge’a wymagają rozwiązania jego komentarzy
Automatyczne przeglądy	Każdy nowy pull request	Zmiany z pull requesta	Jak wyżej
@codex security review	Każdy, kto doda komentarz	Pull request, z naciskiem na bezpieczeństwo	Jak wyżej

Kolejność jest ważniejsza niż sam wybór. Tanie, prywatne kontrole idą pierwsze, więc publiczny przegląd pull requesta widzi mniej defektów, a jego komentarze nadal warto czytać:

1. Przed commitem: autor uruchamia /review lub codex review --uncommitted i poprawia znaleziska P0 i P1.
2. Przed pushem: hook pre-push uruchamia codex exec review --base origin/main i blokuje push przy P0 lub P1.
3. Na pull requeście: @codex review, a później automatyczne przeglądy publikują znaleziska tam, gdzie widzi je każdy recenzent.
4. Na ryzykownych ścieżkach: @codex security review dla uwierzytelniania, obsługi wejścia i sekretów oraz imiennie wskazana osoba odpowiedzialna.
5. Przed merge’em: decydują bramki CI (testy, typy, lint) i lista eskalacji. Przegląd Codex to dane wejściowe, nie zatwierdzenie.

Pisz reguły review na podstawie historii własnych pull requestów

Codex czyta sekcję ## Review guidelines w AGENTS.md. Lokalny prompt przeglądu w Codex CLI 0.157.1 każe też recenzentowi przeczytać AGENTS.override.md i AGENTS.md dla zmienionych plików oraz cytować regułę stojącą za znaleziskiem. Ten cytat to twoje pierwsze narzędzie weryfikacji: znalezisko, które wskazuje regułę, pokazuje, że reguła działa.

Ogólne reguły („sprawdzaj obsługę błędów”) powtarzają to, co recenzent robi i tak. Warto pisać reguły wyprowadzone z defektów, które zespół już wypuścił albo złapał za późno. Niech Codex zrobi szkic na podstawie historii, a ty tnij bez litości.

Prompt do skopiowania: szkic reguł review z 50 ostatnich zmergowanych pull requestów

Read the last 50 commits on main's first-parent history (git log --first-parent -50 main,
plus the diffs), and every
commit whose message starts with "fix" or "revert" in the last six months. Find defect
patterns that a reviewer could have caught from the diff: the file path, the wrong
pattern and the right one. Propose at most 10 rules for a "## Review guidelines" section
in AGENTS.md. Each rule must name a path or file pattern, a condition someone can check
from the diff, and a severity (P0 or P1). Do not propose rules about formatting, naming
or anything our linters already enforce. Do not edit any file; print the rules and, for
each one, the commit that motivated it.

Zestaw reguł, który przejdzie przez to sito, wygląda tak:

## Review guidelines

- P0: any change under migrations/ that drops or renames a column without a matching
  backfill step in the same pull request.
- P1: an HTTP handler under src/api/ that reads req.body without a zod schema.
- P1: money handled as a float anywhere under src/billing/; amounts are integer cents.
- P1: a test under tests/ that is deleted, skipped (.skip, xit) or loses its assertions.
- Do not comment on formatting, import order or naming; dprint and oxlint run in CI.

Ostatnia linia utrzymuje przegląd w czytelnej formie. Każdy komentarz o czymś, co już egzekwuje linter, uczy zespół pomijać komentarze Codex. Reguły, które mają obowiązywać zawsze, trzymaj w głównym AGENTS.md. Źródła sprawdzone 26.09.2026 nie mówią, jak przegląd w GitHubie dla pull requesta obejmującego kilka pakietów uwzględnia zagnieżdżone pliki AGENTS.md, więc reguła na poziomie pakietu to bonus, a nie gwarancja. Cały plik omawia strona AGENTS.md w Codex.

Zablokuj push przy znaleziskach P0 i P1 za pomocą codex exec review

Przegląd, który autor może pominąć, to tylko rada. Hook pre-push zamienia prywatny przegląd w bramkę i kosztuje jedno uruchomienie Codex na push, a nie na commit.

#!/usr/bin/env bash
# .githooks/pre-push: block the push when Codex reports a P0 or P1 finding
set -euo pipefail

git fetch --quiet origin main
codex exec review --base origin/main --ephemeral -o .codex-review.md

if grep -qE '\[P[01]\]' .codex-review.md; then
  echo "Codex review found P0/P1 findings. Read .codex-review.md, fix or disprove them."
  exit 1
fi

Włącz go raz w każdym klonie poleceniami git config core.hooksPath .githooks i chmod +x .githooks/pre-push, a .codex-review.md dopisz do .gitignore. Flagi są zgodne z codex exec review --help w wersji 0.157.1: --base wybiera zakres, --ephemeral nie zapisuje przebiegu w historii sesji, a -o zapisuje końcową wiadomość przeglądu do pliku.

Wbudowany prompt przeglądu każe recenzentowi zaczynać tytuł każdego znaleziska od znacznika priorytetu, na przykład [P1]. Zanim zaufasz grep, uruchom hook raz na gałęzi ze znanym błędem i sprawdź, czy plik zawiera znacznik. Ten sam przebieg to pierwszy pomiar w teście na zasianych błędach opisanym niżej.

Dwa ograniczenia wersji 0.157.1 wpływają na kształt hooka. Flaga zakresu i własny prompt się nie łączą (--base main "focus on auth" kończy się błędem), dlatego hook opiera ukierunkowanie przeglądu na AGENTS.md, a nie na prompcie. Poza tym przegląd w tej samej sesji używa tego samego modelu co autor: żeby dostać drugą opinię innego modelu, ustaw review_model w ~/.codex/config.toml na inny model z listy /model, wybrany według przeglądu modeli.

Tę samą bramkę w CI uruchomisz przez konfigurację openai/codex-action opisaną w CI/CD z GitHub Action dla Codex. Nie dawaj dostępu do klucza API zadaniu, które przegląda pull requesty z forków: to przeglądana gałąź dostarcza AGENTS.md, który steruje przebiegiem.

Przeglądaj pull requesty przez @codex review, potem włącz automatyczne przeglądy

Na pull requeście w podłączonym repozytorium przegląd uruchamia komentarz. Codex publikuje znaleziska z powrotem na pull requeście jako komentarze review.

@codex review

Gdy pull request niesie konkretne ryzyko, dopisz po komendzie, na czym przegląd ma się skupić. Niech będzie krótki i sprawdzalny; reguły z AGENTS.md nadal obowiązują pod spodem.

Prompt do skopiowania: przegląd pull requesta pod kątem kompatybilności API

@codex review for backward compatibility of the public HTTP API. Compare every changed
route under src/api/ with main: flag removed or renamed endpoints, removed or newly
required request fields, changed response field types, and changed status codes. Tag
each finding P0 if an existing client would break and P1 if it needs a migration note.
Ignore internal refactors that keep the wire format identical.

Przy zmianach dotykających uwierzytelniania, parsowania wejścia, dostępu do plików lub sekretów poproś o osobny przegląd bezpieczeństwa, który OpenAI dokumentuje dla GitHuba (zweryfikowane w przewodniku OpenAI po integracji z GitHubem 28.08.2026):

@codex security review

Jego znaleziska przypisz wskazanemu właścicielowi bezpieczeństwa, a nie autorowi pull requesta; sam skaner omawia strona Codex Security. Merge requesty w GitLabie także przyjmują @codex review (przewodnik OpenAI po integracji z GitLabem, sprawdzony 28.08.2026).

Automatyczne przeglądy sprawiają, że Codex przegląda każdy nowy pull request bez komentarza. Włącz je w tych samych ustawieniach code review w Codex, w których włączyłeś repozytorium, i dopiero po dostrojeniu reguł. Kolejność, która trzyma szum w ryzach:

1. Tydzień pierwszy i drugi: tylko @codex review na żądanie, na pull requestach wybranych przez zespół. Każde znalezisko oznaczaj jako przydatne albo szum.
2. Strojenie: każde znalezisko uznane za szum staje się linią „Do not flag” w AGENTS.md; każdy błąd, który złapał dopiero człowiek, staje się regułą.
3. Test na zasianych błędach: przeprowadź test z następnej sekcji i zapisz odsetek wykrytych błędów jako punkt odniesienia.
4. Włącz automatyczne przeglądy dla repozytorium. W publicznych repozytoriach z zewnętrznymi kontrybutorami zostań przy przeglądach na żądanie.
5. Co miesiąc: powtórz test na zasianych błędach i usuń reguły, które nigdy nie zadziałały.

Automatyczne przeglądy nie zastępują wymaganej akceptacji człowieka

Czysty przegląd Codex znaczy tyle, że recenzent nie znalazł niczego z tego, czego szukał. Zachowaj w ochronie gałęzi wymaganą akceptację człowieka dla ścieżek z listy eskalacji poniżej i wymagaj zielonego CI przed merge’em.

Aplikacja desktopowa Codex także pokazuje zmiany z sesji, a /app przenosi tam sesję z TUI na macOS i Windows. README OpenAI nadal nazywa ją Codex App; od 9.07.2026 jest dostarczana jako tryb Codex aplikacji desktopowej ChatGPT (źródło wtórne: Neowin, 9.07.2026). Praca w aplikacji jest opisana na stronie aplikacja desktopowa Codex w praktyce.

Skąd wiesz, że recenzent Codex łapie prawdziwe błędy?

Recenzent, który nic nie znajduje, wygląda dokładnie tak samo jak recenzent ślepy. Mierz go tak, jak mierzysz zestaw testów: podłóż defekty i policz, co znajdzie.

Prompt do skopiowania: gałąź z zasianymi błędami do testu recenzenta

Create a branch named refactor/tidy-handlers from main. On it, make exactly five small,
realistic defects, one per file, each matching a rule in the "## Review guidelines"
section of AGENTS.md or a common defect class: an off-by-one in a loop bound, a
swallowed exception, a missing auth check on one route, a float used for a money amount,
and a skipped test. Keep the code compiling and the other tests passing. Commit them as
one commit titled "refactor: tidy handlers and billing helpers". Do not write an answer key into the
repository, because the reviewer would read it. Instead, end your reply with the answer
key: each defect's file, line and the rule or defect class it violates.

Nazwa gałęzi i tytuł commita są celowo neutralne: recenzent widzi jedno i drugie, a nazwa zdradzająca podłożone defekty zawyża wskaźnik wykrycia. Następnie uruchom codex exec review --base main -o seeded-review.md na tej gałęzi i porównaj znaleziska z kluczem odpowiedzi zapisanym z odpowiedzi agenta. Przy każdym przebiegu zapisz trzy liczby: ile zasianych defektów wykryto, ile znalezisk było szumem i ile znalezisk cytowało regułę. Powtarzaj test po każdej zmianie reguł i co najmniej raz w miesiącu.

Dowód	Co dowodzi	Kto za to odpowiada
Odsetek wykrytych zasianych błędów, śledzony per przebieg	Recenzent znajduje klasy defektów, na których ci zależy	Tech lead
Znaleziska zamknięte testem, który najpierw nie przechodzi, a potem przechodzi, albo wycofane	Znalezisko było prawdziwe, a nie zbyte argumentem	Autor pull requesta
Odsetek szumu na prawdziwych pull requestach (znaleziska oznaczone jako „nieprzydatne”)	Przegląd nadal warto czytać	Zespół, omawiane na retro
Zielone bramki CI: testy, typy, lint	Dotychczasowe zachowanie nadal działa	CI
Akceptacja człowieka na ścieżkach eskalacji	Człowiek przyjął ryzyko tam, gdzie pomyłka jest droga	Wskazany właściciel kodu

Lista eskalacji jest krótka i jawna: migracje bazy danych, uwierzytelnianie i autoryzacja, przepływ pieniędzy, kryptografia, publiczne kontrakty API oraz każda zmiana, która edytuje testy lub konfigurację CI. Wpisz ją do CODEOWNERS, żeby egzekwowała ją ochrona gałęzi. Wszystko inne może trafić do main na zielonych bramkach i czystym przeglądzie Codex, i właśnie tak czytanie przenosi się z diffu na dowody. Wersję tego triażu dla pull requestów opisuje strona code review PR-a agenta bez czytania każdej linii, a manifest, który powinien dołączać pull request agenta, to pakiet dowodów.

Co się psuje, gdy Codex przegląda każdą zmianę?

Zespół przestaje czytać komentarze Codex. Reguły dają za dużo znalezisk P2 i P3. Dodaj do AGENTS.md „Report only P0 and P1 findings on pull requests” i po jednej linii „Do not flag” na każdą powracającą kategorię szumu, a potem powtórz test na zasianych błędach, żeby potwierdzić, że wykrywalność nie spadła.

@codex review nie odpowiada. Code review nie jest włączone dla tego repozytorium albo połączenie Codex z GitHubem go nie widzi przez uprawnienia organizacji. Sprawdź oba punkty w krokach konfiguracji na stronie podłączenie Codex do GitHuba.

Hook pre-push przepuszcza zmianę z błędem P1. grep nie znalazł znacznika [P1], bo format wyniku w twojej wersji jest inny, albo zakres był zły. Otwórz .codex-review.md, sprawdź, jak zapisane są znaleziska, i popraw wzorzec. Po każdej aktualizacji Codex uruchom hook na gałęzi z zasianymi błędami.

codex exec review odrzuca polecenie. W 0.157.1 flag --base, --uncommitted i --commit nie można łączyć z własnym promptem („cannot be used with ‘[PROMPT]’”). Usuń prompt i przenieś ukierunkowanie przeglądu do AGENTS.md albo usuń flagę i opisz zakres w samym prompcie.

Komentarze trafiają w złe linie. Ktoś zrobił push w trakcie przeglądu. Poproś ponownie o @codex review po ostatnim pushu i ustal w zespole, że autor pushuje raz, a nie serią drobnych commitów.

Recenzent zgadza się z kodem, który sam napisał. Ten sam model przejrzał własny wynik w tej samej sesji. Ustaw review_model na inny model, uruchom przegląd w nowym procesie i opieraj się na testach, a nie na opiniach.

Codex za każdym razem pomija regułę domenową. Nie ma jej w AGENTS.md albo jest tylko w zagnieżdżonym pliku, którego przegląd pull requesta nie uwzględnił. Przenieś ją do głównego pliku, sformułuj jako sprawdzalny warunek na ścieżce i dodaj dla niej zasiany defekt.

Dokąd dalej w code review z Codex

Strategie przeglądu wyników Codex Głębokość przeglądu dopasowana do ryzyka i tryby zatwierdzania, które nie blokują zespołu.

Automatyzacja pull requestów z Codex Pull request od worktree do merge'a, z przeglądem i poprawkami CI po drodze.

Kolejka code review, gdy pull requesty otwierają agenci Limity WIP, budżety rozmiaru pull requestów i kierowanie według ryzyka.

Porównanie botów do code review Przegląd Codex obok Claude Code Review, Bugbota i botów zewnętrznych.

Korzystasz też z innego agenta? Ten sam potok dla Claude Code opisuje automatyzacja review w Claude Code, a dla Cursora code review w Cursorze.