Przegląd zmian Codex przed commitem

Workflow przeglądu w Codex to pętla między komunikatem „Codex skończył” a commitem: uruchomienie testów i sprawdzania typów projektu, osobny przegląd tylko do odczytu przez /review lub codex review, naprawienie albo podważenie każdej uwagi z priorytetem, zachowanie dobrych hunków w Git i odrzucenie reszty. O commicie decydują dowody, nie podsumowanie agenta.

Ta strona jest dla programistów, którzy mają za sobą pierwsze zadanie w Codex i patrzą teraz na wynik. Codex pisze „Gotowe, wszystkie testy przechodzą”, diff obejmuje dziewięć plików, a za 20 minut masz spotkanie. Czytanie każdej linii trwa za długo, a commit na wiarę to prosta droga, żeby połknięty wyjątek trafił na produkcję. Poniższa pętla zajmuje mniej więcej tyle, co przygotowanie do spotkania, i zostawia cię z dowodem zamiast przeczucia.

Co daje ci pętla przeglądu w Codex

• Stałą kolejność sprawdzania zmiany z Codex: dowody, bramki, przegląd, ocena uwag, częściowa akceptacja, commit.
• Dokładne formy /review, codex review i codex exec review dla Codex CLI 0.157.1, łącznie z kombinacją flag, która nie działa.
• Blok ## Code Review Rules do AGENTS.md, na który recenzent powołuje się w uwagach.
• Polecenia Git, które zostawiają część hunków, a resztę odrzucają bez utraty pracy.
• Pięć promptów do skopiowania: prośba o dowody, ukierunkowany przegląd, naprawa uwag, udowodnienie albo wycofanie uwagi i ponowne przygotowanie zmian w cofniętym pliku.

W jakiej kolejności sprawdzać zmianę z Codex?

Najpierw tanie, obiektywne kontrole, a na końcu twoja uwaga, skierowana tylko tam, gdzie wskazują kontrole.

1. Poproś o dowody. Lista zmienionych plików, polecenia, które Codex uruchomił, z kodami wyjścia, oraz każdy test dodany, zmieniony, pominięty lub usunięty.
2. Sam uruchom bramki. Testy, sprawdzanie typów i linter w twoim terminalu, a nie w podsumowaniu Codex.
3. Uruchom przegląd. /review w TUI albo codex review z powłoki. Przegląd działa jako osobny przebieg, z instrukcją szukania defektów, a nie bronienia kodu.
4. Oceń uwagi. Napraw P0 i P1, wątpliwe uwagi zamień w padające testy, P2 i P3 zanotuj.
5. Zostaw to, co dobre. Dodaj dobre hunki do stage, przywróć złe i odeślij Codex do wąskiej poprawki.
6. Powtórz bramki i przegląd na tym, co zostało, potem commituj. Drugi przebieg na mniejszym diffie idzie szybko.

Prompt do skopiowania: poproś Codex o dowody przed przeglądem

Before I review, list every file you changed and one line on why. Then list the exact
commands you ran to verify the change, with their exit codes, and every test you added,
changed, skipped or deleted. Do not change any code in this turn.

Test, który Codex pominął albo usunął, to najważniejsza linia tej odpowiedzi. Pominięcie albo usunięcie testu to najtańszy sposób, w jaki agent zamienia czerwony zestaw testów w zielony, i nigdy nie pojawia się w podsumowaniu „testy przechodzą”.

Uruchom przegląd przez /review lub codex review

Codex CLI 0.157.1 ma trzy wejścia do tego samego przeglądu. Różnią się miejscem uruchomienia, a nie tym, co sprawdzają.

TUI: /review

Wpisz /review bez argumentów, żeby otworzyć wybór presetu:

• Review against a base branch: cały branch, jak pull request.
• Review uncommitted changes: pliki w stage, poza stage i nieśledzone.
• Commit: wybierasz jeden z listy z wyszukiwarką o tytule „Select a commit to review”.
• Custom review instructions: twój własny tekst.

Wpisz /review z tekstem, żeby pominąć wybór i uruchomić przegląd z tym tekstem jako instrukcją. Codex nie uruchomi /review, dopóki trwa tura, więc najpierw poczekaj na koniec zadania. /diff pokazuje surowy git diff, także z plikami nieśledzonymi, bez wychodzenia z sesji.

Powłoka: codex review

codex review --uncommitted        # staged, unstaged and untracked changes
codex review --base main          # everything the branch adds on top of main
codex review --commit HEAD        # the last commit only
codex review "Review the uncommitted changes. Focus on error handling in src/api/."

--uncommitted, --base i --commit wykluczają się wzajemnie i żadnej z nich nie połączysz z własnym promptem: codex review --base main "focus on auth" kończy się błędem the argument '--base <BRANCH>' cannot be used with '[PROMPT]' (sprawdzone w 0.157.1). Wybierz preset albo opisz zakres w prompcie. Polecenie wymaga repozytorium Git lub zaufanego katalogu.

Skrypt: codex exec review

codex exec review --base main -o review.txt       # final review text to a file
codex exec review --uncommitted --json            # JSONL events for a script to parse

codex exec review przyjmuje te same flagi zakresu oraz zwykłe opcje exec, na przykład --model, --output-schema, --ephemeral i --skip-git-repo-check. Użyj go w hooku pre-push albo w zadaniu CI; pełna konfiguracja CI jest w CI/CD z Codex GitHub Action.

Prompt do skopiowania: ukierunkowany przegląd

Review the uncommitted changes in this repository against origin/main. Report only
defects you can tie to a specific line: wrong behaviour, missing or swallowed error
handling, unhandled edge cases (empty input, null, concurrency, time zones), security
issues, and tests that were weakened, skipped or no longer assert anything. Ignore
formatting and naming. Tag each finding P0 to P3 and end with an overall verdict.

Wklej go po /review w TUI albo podaj jako jedyny argument codex review.

Co mówi ci wynik przeglądu

Prompt przeglądu wbudowany w Codex CLI 0.157.1 każe zgłaszać uwagi, które autor faktycznie by naprawił, po jednej na problem, każdą na krótkim zakresie linii i z priorytetem od P0 (rzuć wszystko) do P3 (niski). Każe pomijać styl, formatowanie i literówki, a na końcu wydać ogólny werdykt: „patch is correct” albo „patch is incorrect”. Pusta lista uwag to prawidłowy wynik, a nie błąd.

Gdy uruchamiasz przegląd w TUI w tej samej sesji, która napisała kod, recenzent korzysta z tego samego modelu. Żeby dostać drugą opinię od innego modelu, ustaw review_model w ~/.codex/config.toml na inny model z listy /model. Aktualny zestaw modeli jest w przeglądzie modeli.

Zapisz reguły, na które recenzent się powoła

Ogólne uwagi o poprawności daje każdy recenzent. To reguły twojego repozytorium sprawiają, że przegląd jest wart uruchomienia. Ten sam prompt każe recenzentowi czytać AGENTS.override.md i AGENTS.md dla zmienionych plików (wygrywa plik bardziej szczegółowy) i przy każdej uwadze wynikającej z reguły cytować plik i linię tej reguły.

## Code Review Rules

- Money is integer cents. Flag any floating-point arithmetic on an amount as P1.
- Every new route in src/api/ validates its input with zod. Flag a missing schema as P1.
- tests/contract/ is owned by the platform team. Flag any edit there as P0.
- Do not flag formatting: dprint runs in CI.

Umieść ten blok w głównym AGENTS.md albo w zagnieżdżonym pliku jednego pakietu. Ten sam nagłówek steruje też @codex review w pull requestach na GitHub, co konfigurujesz w połączeniu Codex z GitHub. Cały plik opisuje konfiguracja AGENTS.md.

Oceń uwagi: napraw, udowodnij albo zanotuj

Traktuj każdą uwagę jak tezę, która wymaga takich samych dowodów jak kod.

Uwaga	Co robisz	Dowód, który ją zamyka
P0 lub P1, z którą się zgadzasz	Odsyłasz ją do Codex promptem naprawczym poniżej	Nowy test, który pada przed poprawką i przechodzi po niej
P0 lub P1, w którą wątpisz	Prosisz Codex o dowód	Padający test albo wycofanie uwagi przez Codex
P2 lub P3	Notujesz w opisie pull requesta albo w issue	Na razie nic; nie powiększaj tego diffa
Uwaga powołuje się na regułę z AGENTS.md	Naprawiasz kod albo zmieniasz regułę, jeśli jest błędna	Reguła i kod są zgodne

Prompt do skopiowania: napraw blokujące uwagi

Fix the P0 and P1 findings from the review above, one at a time. For each fix, add or
update a test that fails without the fix and passes with it. Do not touch code that no
finding points at. Leave P2 and P3 findings alone and list them at the end. Run the full
test suite and the type check, and paste their summary lines.

Prompt do skopiowania: udowodnij uwagę albo ją wycofaj

For the finding "[P1] Retry loop never gives up on 429" show me a concrete input or call
sequence that triggers it, and write that as a test in the existing test file for this
module. Run the test. If you cannot make it fail against the current code, say so and
withdraw the finding instead of changing the code.

Drugi prompt pozwala sprawdzić przegląd bez czytania kodu, którego dotyczy: uwaga, która daje padający test, jest prawdziwa, a taka, która go nie daje, to szum, który możesz spokojnie odrzucić.

Zostaw dobre hunki, a resztę odrzuć w Git

Codex edytuje twoje drzewo robocze, więc każde narzędzie Git, którego już używasz, działa na jego wyniku. Najwięcej czasu oszczędza częściowa akceptacja: zostawiasz dobre pliki, przywracasz złe i odsyłasz Codex do wąskiej poprawki.

git diff > ../codex-task.patch       # safety copy of tracked changes before you discard any
git add -p src/api/orders.ts         # stage hunk by hunk: y keeps a hunk, n skips it
git add src/api/schemas.ts           # stage a whole file you trust
git restore -p src/lib/cache.ts      # discard selected unstaged hunks
git restore src/billing/invoice.ts   # discard a whole file's unstaged changes
git clean -n src/                    # list new untracked files Codex created
git diff --staged                    # exactly what the commit will contain

git restore odrzuca zmiany bezpowrotnie i nigdy nie usuwa plików utworzonych przez Codex: są nieśledzone, więc wylistuj je przez git clean -n, zanim cokolwiek usuniesz przez git clean -f <ścieżka>.

Prompt do skopiowania: przerób cofnięty plik od nowa

I reverted your changes to src/billing/invoice.ts with git restore. Re-implement only the
rounding fix in that file. Keep every exported function signature unchanged and pass the
tax-rate lookup in as a parameter instead of importing it. Do not edit any other file.
Run the invoice tests and paste the result.

Gdy poprawka wróci, uruchom ponownie bramki i codex review --uncommitted na tym, co zostało. Potem commituj zawartość stage z komunikatem, który nazywa zadanie, a nie narzędzie.

Przegląd pracy z Codex cloud i aplikacji desktopowej

Zadania w chmurze działają poza twoją maszyną, ale ich diff nadal możesz przejrzeć, zanim stanie się pull requestem. W 0.157.1 codex cloud jest oznaczone jako eksperymentalne.

codex cloud list                      # recent cloud tasks and their ids
codex cloud diff TASK_ID              # the task's unified diff, printed locally
codex cloud apply TASK_ID --attempt 2 # apply attempt 2 of a best-of-N task to your tree
codex review --uncommitted            # then review it like local work

TASK_ID to identyfikator wypisany przez codex cloud list. Nałożenie zmian lokalnie pozwala puścić na pracy z chmury te same bramki i ten sam przegląd. Konfigurację środowisk i próby best-of-N opisują środowiska Codex cloud.

codex app i polecenie /app (macOS i Windows) przenoszą bieżącą sesję do aplikacji desktopowej; co pokazuje aplikacja, opisuje praca w aplikacji desktopowej Codex. README OpenAI nadal nazywa ją Codex App; od 2026-07-09 jest dostarczana jako tryb Codex w aplikacji desktopowej ChatGPT (źródło wtórne: Neowin, 2026-07-09).

Skąd wiesz, że zmiana jest dobra, bez czytania każdej linii?

Przegląd to jeden sygnał, a nie zatwierdzenie. Z góry ustal, który dowód co potwierdza, i czytaj tylko te linie, których dowody nie pokrywają.

Dowód	Kto go wytwarza	Co potwierdza
Testy, sprawdzanie typów i linter uruchomione przez ciebie	Twoje narzędzia	Zmiana się buduje, a dotychczasowe zachowanie działa
Nowe testy przypisane do kryteriów akceptacji zadania	Codex, na prośbę	Każde kryterium ma test, który bez zmiany pada
Brak pominiętych, usuniętych lub osłabionych testów	Prompt o dowody plus git diff --stat tests/	Codex nie kupił zielonych testów ich osłabieniem
Uwagi z przeglądu zamknięte testami lub wycofane	/review albo codex review	Znane defekty są naprawione, a nie zbyte dyskusją
Twoja lektura ryzykownych ścieżek	Ty	Uwierzytelnianie, pieniądze, migracje i współbieżność widział człowiek

Ostateczna akceptacja nadal należy do ciebie. Zmienia się to, gdzie idzie twoja lektura: do diffa testów i do kilku ścieżek, na których błąd jest drogi. Wersję tej procedury dla pull requestów opisuje code review PR-a agenta bez czytania każdej linii, a o tym, jak zablokować Codex edycję testów, które go oceniają, przeczytasz w ochronie wyroczni.

Co psuje się w pętli przeglądu Codex?

codex review odrzuca twój prompt. Komunikat to „cannot be used with ‘[PROMPT]’”. W 0.157.1 flaga zakresu i własne instrukcje się nie łączą. Usuń flagę i opisz zakres w prompcie („Review the changes on this branch against main…”).

„Not inside a trusted directory and —skip-git-repo-check was not specified.” codex review wymaga repozytorium Git lub zaufanego katalogu. Uruchom git init i zrób commit bazowy, żeby przegląd miał względem czego porównywać. codex exec review przyjmuje też --skip-git-repo-check.

Przegląd nic nie znajduje, choć diff jest duży. Sprawdź zakres. --uncommitted pomija pracę, którą Codex już zacommitował; użyj --base main albo --commit HEAD. Czysty werdykt na złym zakresie to najbardziej przekonujący fałszywy negatyw, jaki istnieje.

Recenzent zgadza się z autorem. Przegląd w tej samej sesji dzieli z autorem model i kontekst. Ustaw review_model na inny model, uruchom codex review w świeżym terminalu i opieraj się na testach, a nie na drugiej opinii.

Testy przechodzą, bo Codex je zmienił. Zanim zaufasz zielonym testom, uruchom git diff --stat na katalogach z testami. Dodaj do AGENTS.md regułę „flag any edit to tests/contract/ as P0” i niech CI trzyma kontrole, których Codex nie może dotknąć.

git restore nie usunął pliku. Nowe pliki są nieśledzone. Wylistuj je przez git clean -n <ścieżka> i usuń przez git clean -f <ścieżka>.

Patch z chmury się nie nakłada. Twój branch przesunął się od startu zadania. Zacommituj albo schowaj lokalną pracę, zrób pull i nałóż ponownie albo spróbuj innej próby (--attempt). Jeśli konflikt zostaje, zleć nowe zadanie w chmurze na bieżącym branchu. Więcej wzorców naprawy znajdziesz w odzyskiwaniu po błędach Codex.

Dokąd dalej z przeglądami w Codex

Skonfiguruj serwery MCP w Codex Daj Codex dostęp na żywo do trackera zadań, dokumentacji i baz danych.

Odzyskiwanie, gdy Codex zbłądzi Błędy sandboksa, edycje w złą stronę, pętle i punkty kontrolne Git.

Code review z Codex na wszystkich powierzchniach Przegląd każdej zmiany: CLI, aplikacja desktopowa i GitHub, ze wspólnymi regułami.

Strategie przeglądu, które nie blokują zespołu Wielopoziomowy przegląd i tryby zatwierdzania wyników Codex w skali zespołu.