# Przegląd zmian Codex przed commitem URL: https://developertoolkit.ai/pl/codex/quick-start/review-workflow/ Description: Sprawdź pracę Codex bez czytania każdej linii: uruchom bramki, /review lub codex review, oceń uwagi P0–P3, zostaw dobre hunki w Git i commituj. 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](/pl/codex/quick-start/first-task/) 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** ```text 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** ```bash 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 ' 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** ```bash 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](/pl/codex/ship/ci-cd/). **Prompt do skopiowania: ukierunkowany przegląd** ```text 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](/pl/ecosystem/models/). ## 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. ```markdown ## 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](/pl/codex/quick-start/github-integration/). Cały plik opisuje [konfiguracja AGENTS.md](/pl/codex/quick-start/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** ```text 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** ```text 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. ```bash 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** ```text 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. ```bash 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](/pl/codex/automate/cloud-environments/). `codex app` i polecenie `/app` (macOS i Windows) przenoszą bieżącą sesję do aplikacji desktopowej; co pokazuje aplikacja, opisuje [praca w aplikacji desktopowej Codex](/pl/codex/build/app-mastery/). 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](/pl/workflows/ship/agent-pr-review/), a o tym, jak zablokować Codex edycję testów, które go oceniają, przeczytasz w [ochronie wyroczni](/pl/workflows/test/protect-the-oracle/). ## 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](/pl/codex/quick-start/error-recovery/). ## Dokąd dalej z przeglądami w Codex - [Skonfiguruj serwery MCP w Codex](/pl/codex/quick-start/mcp-setup/) — Daj Codex dostęp na żywo do trackera zadań, dokumentacji i baz danych. - [Odzyskiwanie, gdy Codex zbłądzi](/pl/codex/quick-start/error-recovery/) — Błędy sandboksa, edycje w złą stronę, pętle i punkty kontrolne Git. - [Code review z Codex na wszystkich powierzchniach](/pl/codex/ship/code-review/) — Przegląd każdej zmiany: CLI, aplikacja desktopowa i GitHub, ze wspólnymi regułami. - [Strategie przeglądu, które nie blokują zespołu](/pl/codex/ship/review-strategies/) — Wielopoziomowy przegląd i tryby zatwierdzania wyników Codex w skali zespołu.