Jak przeglądać pracę Codex i nie zostać wąskim gardłem

Strategia przeglądu pracy Codex rozstrzyga, ile ludzkiej uwagi dostanie zmiana, zanim Codex zacznie pracę, a nie po fakcie. Każde zadanie dostaje klasę ryzyka (niska, średnia, wysoka lub krytyczna), a klasa wyznacza preset uprawnień, dowody, które Codex musi oddać, automatyczny przegląd i osobę zatwierdzającą. Człowiek czyta kod tylko przy zmianach klasy wysokiej i krytycznej.

Ta strona jest dla programistów, którzy prowadzą kilka wątków Codex naraz, i dla tech leadów, którzy ustalają regułę dla zespołu. Pięć wątków kończy się przed obiadem, każdy z wieloplikowym diffem. Jeśli przeczytasz wszystkie, to ty staniesz się wąskim gardłem. Jeśli scalisz je w ciemno, wpadniesz w drugą pułapkę. Raport Faros AI „AI Engineering Report 2026” (kwiecień 2026), oparty na telemetrii 22 000 programistów z platformy Faros, zmierzył wzrost mediany czasu w przeglądzie o 441,5% i o 31,3% więcej pull requestów scalanych bez żadnego przeglądu. Strategia poniżej omija obie pułapki. Polecenia sprawdzono na Codex CLI 0.157.1.

Co daje strategia przeglądu Codex oparta na ryzyku

• Tabelę czterech klas, która przypisuje każdemu zadaniu Codex preset uprawnień, wymagane dowody, automatyczny przegląd i zatwierdzenie.
• Presety /permissions i flagi CLI, które ograniczają, czego Codex może dotknąć przed startem, więc po fakcie jest mniej do przeglądania.
• Raport z dowodami, który oddaje każdy wątek, więc selekcję robisz na faktach, a nie na diffie.
• Rutynę czyszczenia kolejki wielu zakończonych wątków za jednym podejściem.
• Cztery prompty do skopiowania i sprawdzenie ścieżek, które wyłapuje źle sklasyfikowane zmiany.

Jeśli nie przeglądałeś jeszcze ani jednej zmiany Codex, zacznij od przeglądu zmian Codex przed commitem. Ta strona zakłada tę pętlę i ją skaluje.

Ile przeglądu potrzebuje zmiana z Codex?

Odpowiedź zależy od tego, co zmiana może zepsuć, a nie od rozmiaru diffu. Przypisz klasę na podstawie ścieżek, których zadanie dotknie, zanim napiszesz prompt. To klasy zmian, a nie poziomy dojrzałości; model przeglądu opartego na dowodach wyjaśnia, dlaczego człowiek najpierw czyta dowody, a kod tylko tam, gdzie dowody są słabe.

Klasa ryzyka	Typowe zadania Codex	Uprawnienia przed startem	Automatyczny przegląd	Kto zatwierdza
Niska	Dokumentacja, teksty, poprawki lintera, podbicia wersji patch zależności, generowane klienty API	Preset Default albo --approve-for-me bez nadzoru	codex exec review na innym modelu, bez P0 ani P1	Ty, na podstawie raportu z dowodami; tech lead co tydzień sprawdza kilka próbek
Średnia	Funkcja lub poprawka błędu w jednym module z mocnymi testami	Preset Default w worktree	Jak niska	Jeden recenzent czyta raport, a kod tylko tam, gdzie dowody są słabe
Wysoka	Publiczne API, biblioteki współdzielone, zmiany międzymodułowe lub wrażliwe na wydajność	Read Only na plan, potem Default w worktree	Jak średnia plus @codex review ze wskazaniem głównego ryzyka na pull requeście	Właściciel kodu przez CODEOWNERS
Krytyczna	Uwierzytelnianie, pieniądze, migracje schematu i danych, prywatność oraz wyrocznia: testy, CI, konfiguracja lintera i typów	Read Only na plan; implementacja dopiero po akceptacji planu przez człowieka	Jak wysoka plus @codex security review przy zmianach w auth, obsłudze wejścia lub sekretach	Dwie wskazane z nazwiska osoby, które czytają kod, plus przećwiczony rollback

Dwie reguły trzymają tabelę w ryzach. Zadanie dostaje klasę najbardziej ryzykownej ścieżki, której dotyka, więc „mały refaktor”, który edytuje src/auth/, jest krytyczny. A każda zmiana testów lub CI jest krytyczna, bo zmienia znaczenie „zielonego” dla każdej innej zmiany; zobacz ochronę wyroczni.

Zespołową wersję tej tabeli, z torami przeglądu, limitami WIP i rozkładaniem obciążenia między recenzentów, znajdziesz w zarządzaniu kolejką przeglądów agentów.

Ustal klasę ryzyka, zanim Codex zacznie

Kontrola przed startem jest tańsza niż przegląd po fakcie. Zadanie, które nie może pisać poza swoim worktree, albo w fazie planowania nie może pisać wcale, daje diff z mniejszą liczbą miejsc do sprawdzenia.

Selektor /permissions w TUI Codex CLI 0.157.1 oferuje trzy presety. Ich opisy w brzmieniu z binarki 0.157.1:

Preset	Co może Codex	Do czego
Read Only	„Codex can read files in the current workspace. Approval is required to edit files or access the internet.”	Planowanie pracy wysokiej i krytycznej; pytania o kod
Default	„Codex can read and edit files in the current workspace, and run commands. Approval is required to access the internet or edit other files.”	Implementacja pracy niskiej, średniej oraz zaakceptowanej wysokiej lub krytycznej
Full Access	„Codex can edit files outside this workspace and access the internet without asking for approval. Exercise caution when using.”	Tylko w jednorazowym sandboksie z ograniczoną siecią, nigdy w głównym checkoucie na twoim laptopie

Z terminala te same wybory to flagi codex:

# Krytyczna lub wysoka: plan w profilu uprawnień tylko do odczytu (beta w 0.157.1)
codex -c default_permissions=":read-only" "Plan the change described in docs/tasks/refund-idempotency.md"

# Średnia i wyżej: implementacja w nowym zarządzanym worktree Git, jeden na wątek
codex --worktree "Implement the approved plan in docs/tasks/refund-idempotency.md"

# Niska, bez nadzoru: prośby o zgodę idą do automatycznego przeglądu w sandboksie workspace-write
codex --approve-for-me "Fix every oxlint warning in src/components/ without changing behavior"

OpenAI zaleca profile uprawnień dla nowych konfiguracji. Według OpenAI profile i starszy system --sandbox „do not compose”, więc wybierz jeden mechanizm na polecenie. Nie dodawaj --sandbox ani --approve-for-me do polecenia, które ustawia default_permissions. Starszy odpowiednik pierwszej linii to codex --sandbox read-only. Kompromisy między profilami, sandboksami i politykami zatwierdzania w różnych narzędziach opisuje strona o uprawnieniach i sandboksowaniu agentów, a mechanikę worktree — worktree w Codex.

Pełny dostęp usuwa granicę, na której opiera się przegląd

--dangerously-bypass-approvals-and-sandbox i preset Full Access pomijają każdą prośbę o zgodę. Używaj ich tylko w jednorazowym sandboksie z ograniczoną siecią i bez produkcyjnych poświadczeń. Strategia oparta na klasach zakłada, że granica uprawnień wytrzymała; bez niej diff przestaje być całą historią.

Wpisz klasę do samego promptu zadania. Codex wie wtedy, których ścieżek może dotknąć i jakie dowody jest winien, a niezgodność klasy wychodzi na jaw, zanim powstanie jakikolwiek kod.

Prompt do skopiowania: start zadania z klasą ryzyka

Risk class: medium. Task: add cursor-based pagination to GET /api/orders.
You may edit src/api/orders/ and tests/api/orders/ only. Do not edit anything under
src/auth/, src/billing/, db/migrations/, .github/ or any existing test outside
tests/api/orders/. If the task cannot be done inside those paths, stop and tell me
which path you need and why, and treat the task as high risk from then on.
Before you finish, run the test suite, the type check and the linter, and end with the
evidence report I will ask for.

Niech każdy wątek Codex oddaje te same dowody

Gdy kończy się pięć wątków, selekcję robisz na pięciu raportach, a nie na pięciu diffach. Proś za każdym razem o ten sam raport, żeby brakująca linia była widoczna od razu. Pełny schemat manifestu, który powinien nieść pull request, to pakiet dowodów; prompt poniżej to skrócona wersja dla lokalnego wątku. Żeby każdy wątek był winien raport bez wklejania promptu, zapisz ten wymóg w sekcji projektowego AGENTS.md albo w projektowym skillu w .agents/skills/; zobacz konfigurację AGENTS.md w Codex.

Prompt do skopiowania: raport z dowodami dla tego wątku

Do not change any code in this turn. Write an evidence report for your change:
1. Risk class you were given, and the class the change actually needs, judged by the
   paths it touches. Say "unchanged" if they match.
2. Every file you changed, with one line on why.
3. The exact commands you ran to verify the change, each with its exit code. Do not
   report a command you did not run.
4. Every test you added, changed, skipped or deleted, with the file and test name.
5. Every changed path under src/auth/, src/billing/, db/migrations/, tests/, .github/
   or any lint, type or CI config file.
6. Behavior the tests do not cover, written as the test that is missing.
End with one line: READY FOR REVIEW, or NOT READY and the reason.

Potem sprawdź dwie linie, w których agent najczęściej się myli, bez czytania kodu:

git diff --stat origin/main...HEAD -- tests/     # czy wątek ruszył testy, o które go nie proszono?
git diff --name-only origin/main...HEAD | grep -E \
  '^(src/auth|src/billing|db/migrations|tests|\.github)/|(^|/)(tsconfig[^/]*\.json|\.?oxlintrc[^/]*|eslint[^/]*|vite\.config\.[jt]s)$|\.(test|spec)\.[jt]sx?$'

Uruchom oba polecenia w worktree wątku. Drugie wypisuje każdą ścieżkę krytyczną zmienioną na gałęzi, łącznie z główną konfiguracją lintera, typów i builda oraz testami leżącymi obok kodu źródłowego. Jeśli wypisze cokolwiek dla zadania sklasyfikowanego jako niskie lub średnie, zmień klasę, zanim zaczniesz czytać dalej. Dopasuj wzorzec do ścieżek eskalacji, plików konfiguracyjnych i wzorców nazw testów w swoim repozytorium. Pierwsze polecenie widzi tylko katalog tests/ w katalogu głównym, więc testy obok kodu wyłapuje drugie.

Skieruj każdą klasę do właściwego przeglądu Codex

Każda klasa dokłada warstwę przeglądu do tej poniżej. Zatrzymaj się na warstwie, której wymaga klasa.

1. Każda klasa: osobny przebieg przeglądu. Uruchom przegląd jako skrypt, żeby wynik trafił do pliku, który szybko przejrzysz:

   codex exec review --base origin/main -c review_model=REVIEW_MODEL -o .codex-review.md

   REVIEW_MODEL to identyfikator modelu innego niż ten, który napisał zmianę, wzięty z listy /model; aktualny zestaw modeli jest w przeglądzie modeli. Recenzent działający na modelu autora zwykle ma te same martwe pola. Przegląd oznacza każde znalezisko od P0 do P3; napraw każde P0 i P1, zanim zmiana pójdzie dalej. Jak stroić reguły, na które się powołuje, i jak mierzyć, co wyłapuje, opisuje code review z Codex.

2. Średnia i wyżej: recenzent czyta raport z dowodami. Kod otwiera tylko tam, gdzie raport jest słaby: zachowanie bez testu, zakwestionowane znalezisko, ścieżka, która cię zaskoczyła.

3. Wysoka i wyżej: przegląd na pull requeście. Skomentuj @codex review, dopisując krótko ryzyko, które podniosło klasę zmiany, na przykład wsteczną zgodność publicznej trasy. Ochrona gałęzi z opcją „Require review from Code Owners” kieruje zatwierdzenie do właściciela ścieżki.

4. Krytyczna: skupiony przegląd lokalny, przebieg bezpieczeństwa i dwie osoby czytające kod. codex review czyta własne instrukcje ze stdin, gdy podasz -, więc długą listę kontrolną trzymasz w pliku:

   codex review -c review_model=REVIEW_MODEL - < .codex/review-critical.txt

   Flaga zakresu i własny prompt nie łączą się w 0.157.1 (codex review --base main "…" kończy się błędem), więc zakres nazwij w samych instrukcjach. codex exec review przyjmuje też -m, które wprost wybiera model. Na pull requeście dodaj @codex security review, gdy zmienia się uwierzytelnianie, obsługa wejścia lub sekrety (przewodnik OpenAI po integracji z GitHubem, sprawdzony 2026-08-28). Potem dwie wskazane osoby czytają kod, a wdrożenie ma rollback, który ktoś już uruchomił; zobacz automatyzację wdrożeń z Codex.

Prompt do skopiowania: instrukcje przeglądu ścieżki krytycznej (.codex/review-critical.txt)

Review the changes on this branch against origin/main. This change is risk class
critical. Report only defects you can tie to a specific line, tagged P0 to P3:
- Authorization: any route or job that reads or writes data without checking the
  caller's tenant and role.
- Money: floating-point arithmetic on amounts, rounding in more than one place, and
  any payment or refund call that is not safe to retry.
- Migrations: statements that cannot run twice, drop or rewrite data the previous
  release still reads, or lock a large table.
- Tests and CI: any assertion removed or loosened, any test skipped, any CI step
  removed or made non-blocking.
Ignore formatting and naming. End with "patch is correct" or "patch is incorrect".

Te same warstwy w GitHub Actions, z bramką znalezisk Codex działającą w profilu uprawnień tylko do odczytu, opisuje strona Codex w CI/CD.

Wyczyść kolejkę zakończonych wątków Codex za jednym podejściem

Przeglądanie każdego wątku w chwili, gdy się kończy, zamienia dzień w ciąg przerw. Pozwól wątkom się skończyć, a potem czyść kolejkę w kolejności klas.

1. Wypisz, co czeka. codex agents przegląda wszystkie sesje na lokalnym demonie app-server, a git worktree list pokazuje gałąź każdego wątku. Jeśli pracujesz w aplikacji desktopowej (codex app, tylko macOS i Windows), jej widok wątków opisuje praca z aplikacją desktopową Codex.
2. Zbierz raporty z dowodami. Wątek bez raportu wraca z promptem o dowody, zanim ktokolwiek cokolwiek przeczyta.
3. Najpierw niska klasa. Wątek niskiej klasy z czystym raportem, bez P0 i P1 i bez ścieżek krytycznych scalasz na podstawie dowodów.
4. Średnią grupuj po modułach. Dwa wątki, które dotykają tego samego modułu, przeglądasz razem, więc konflikty wychodzą przed scaleniem, a nie po nim.
5. Zarezerwuj czas na wysoką i krytyczną. Potrzebują właścicieli innych niż ty; otwórz pull requesty i je przypisz, zamiast trzymać je w swojej kolejce.
6. Przestań zaczynać. Gdy czeka więcej wątków, niż przejrzysz w mniej więcej jednej sesji pracy, nie uruchamiaj nowych, dopóki kolejka nie opadnie. Zarządzanie kolejką przeglądów zamienia to w limit WIP dla zespołu.

Prompt do skopiowania: selekcja kolejki w sesji tylko do odczytu

Do not edit any files. Run `git worktree list`. For every worktree except the main
checkout, compare its branch with origin/main and report one row per branch:
branch name, files changed, lines added and removed, whether any changed path is under
src/auth/, src/billing/, db/migrations/, tests/ or .github/, and whether the branch has
an evidence report in its last commit message or in docs/evidence/. Sort the rows by
risk: critical paths first, then branches over 400 changed lines, then the rest.
Flag any branch whose diff touches a path its task prompt did not allow.

Uruchom tę sesję przez codex -c default_permissions=":read-only", żeby sama selekcja nie mogła zmienić żadnej gałęzi. Zasady dzielenia pracy na tory od początku opisują przepływy wieloagentowe w Codex.

Skąd wiesz, że strategia przeglądu działa, bez czytania każdej linii?

Strategia, która przepuszcza błędy, wygląda tak samo jak ta, która działa — dopóki produkcja nie powie inaczej. Co miesiąc śledź cztery liczby dla każdej klasy ryzyka i pozwól im przesuwać klasy w górę lub w dół.

Sygnał	Skąd go wziąć	Co mówi	Właściciel
Przepuszczone defekty i reverty na klasę	Oznaczaj incydenty i reverty klasą zmiany, która je spowodowała	Klasa, której zmiany przepuszczają defekty, potrzebuje cięższej warstwy przeglądu	Tech lead
Odsetek przeklasyfikowań	Licz wątki, w których sprawdzenie ścieżek lub raport podniosły klasę	Wysoki odsetek oznacza zbyt luźno określony zakres zadań	Tech lead
Skuteczność recenzenta Codex na podłożonych błędach	Test podłożonych błędów ze strony code review z Codex	Czy warstwa automatyczna znajduje defekty, na których ci zależy	Właściciel reguł przeglądu
Czas w przeglądzie na klasę	Znaczniki czasu pull requestów z twojego hostingu Git	Czy praca niskiej klasy faktycznie płynie i gdzie tworzy się kolejka	Tech lead

Klasa zmian zasługuje na lżejszy przegląd dopiero po serii scaleń bez revertów i bez przepuszczonych defektów, a traci go po jednym. Te etapy opisuje protokół przenoszenia zaufania. Zatwierdzenie nigdy nie przechodzi na Codex: każde scalenie ma właściciela — człowieka albo skonfigurowany przez ciebie pipeline — a tabela na początku strony mówi, którego.

Co się psuje, gdy skalujesz przegląd Codex według ryzyka?

Zadanie niskiej klasy po cichu dotyka ścieżki krytycznej. Prompt na to pozwolił albo Codex poprosił o zgodę, a ktoś kliknął „tak”. Naprawa: uruchamiaj sprawdzenie ścieżek na każdej gałęzi przed przeglądem i zrób z niego wymagany job CI, który pada, gdy ścieżka krytyczna zmienia się bez zatwierdzenia właściciela kodu.

Przegląd nic nie znajduje w dużym diffie. Zakres jest zły: --uncommitted pomija commity, które wątek już zrobił. Naprawa: dla wszystkiego, co żyje na gałęzi, przeglądaj z --base origin/main. Przegląd ścieżki krytycznej przyjmuje własne instrukcje, więc tam nazwij origin/main w pliku instrukcji, jak w kroku 4 kierowania przeglądu.

Recenzent za każdym razem zgadza się z autorem. Przegląd w tej samej sesji dzieli model i kontekst autora. Naprawa: ustaw review_model na inny model i uruchom przegląd w świeżym procesie, jak w krokach kierowania; test podłożonych błędów zostaje dowodem.

Testy przechodzą, bo wątek je zmienił. Każda edycja w tests/ czyni zmianę krytyczną, niezależnie od zadania. Naprawa: najpierw sprawdź git diff --stat na katalogach testów i obejmij testy oraz konfigurację CI plikiem CODEOWNERS.

--approve-for-me zatwierdził więcej, niż się spodziewałeś. Automatyczny przegląd rozstrzyga prośby o zgodę na granicy sandboksa; nie przegląda kodu. Naprawa: zostaw go dla pracy niskiej klasy w sandboksie workspace-write, a do ponowienia pojedynczej odrzuconej akcji używaj /approve, zamiast poszerzać uprawnienia całej sesji.

Kolejka ciągle rośnie. Startuje więcej wątków, niż zdążasz wyczyścić. Naprawa: przestań uruchamiać nowe wątki, tnij zadania na mniejsze (małe partie to jedna z umiejętności w DORA AI Capabilities Model, Google Cloud, 2025-09-23) i przenoś więcej pracy do niskiej klasy tylko przez etapy przenoszenia zaufania, nigdy przez pomijanie przeglądu.

Flaga uprawnień zgłasza błąd albo nic nie zmienia. Profil i --sandbox się nie łączą, a codex -a w 0.157.1 przyjmuje tylko on-request i never. Naprawa: jeden mechanizm na polecenie, a z codex exec usuń -a: nie ma takiej flagi i i tak działa z zatwierdzaniem never.

Dokąd dalej z przeglądem w Codex

Code review z Codex Strój reguły przeglądu w AGENTS.md i mierz, co wyłapuje recenzent.

Code review PR-a agenta bez czytania każdej linii Sześciokrokowa selekcja i klasy eskalacji, które człowiek nadal czyta.

Automatyzacja pull requestów z Codex Przeprowadź wątek od worktree do scalonego pull requesta.

Kolejka code review, gdy pull requesty otwierają agenci Limity WIP, tory przeglądu i rozkładanie obciążenia w całym zespole.

Używasz też innego agenta? Ta sama strategia działa z innymi mechanizmami kontroli w automatyzacji przeglądów z Claude Code i w kierowaniu i zatwierdzaniu PR-ów w Cursor.