Automatyzacja pull requestów z Codex

Automatyzacja pull requestów z Codex prowadzi jedną zmianę do merge w sześciu etapach, z których każdy zostawia dowód: izolujesz ją w worktree, Codex otwiera szkic pull requesta z dowodami, codex review robi wstępne review, @codex review — review na GitHubie, ograniczone zadanie @codex naprawia nieudane sprawdzenia, a merge odbywa się pod ochroną gałęzi z imiennie wskazanym właścicielem.

Ta strona jest dla programistów, którzy pracują z Codex na co dzień, i dla tech leadów, którzy odpowiadają za reguły merge. Problem, który rozwiązuje: Codex kończy zadanie przed południem, pull request czeka dwa dni na recenzenta, pierwsze pytanie recenzenta brzmi „co to właściwie miało robić?”, a poprawka po review psuje CI. Każde czekanie to przekazanie bez dołączonych dowodów. Polecenia sprawdzono na Codex CLI 0.157.1 w dniu 2026-09-26.

Co zyskasz dzięki automatyzacji pull requestów z Codex

• Mapę etapów: kto działa, co go uruchamia i jaki dowód zostawia każdy etap.
• Szablon pull requesta i prompt, dzięki którym Codex otwiera szkic PR z poleceniami i kodami wyjścia zamiast przymiotników.
• Ograniczony komentarz @codex, który naprawia czerwone sprawdzenie bez edytowania testów i CI, oraz sposób, by ściągnąć wynik na własną maszynę.
• Reguły CODEOWNERS i ochrony gałęzi, dzięki którym rutynowe zmiany wchodzą na podstawie dowodów, a ryzykowne trafiają do konkretnej osoby.

Reguły review i wdrażanie automatycznych review opisuje strona code review z Codex. Uruchamianie openai/codex-action w GitHub Actions opisuje Codex w CI/CD. Ta strona łączy je w jeden cykl życia pull requesta.

Jak pull request z Codex przechodzi od worktree do merge?

Każdy etap zostawia artefakt, który recenzent sprawdzi w kilka sekund. Jeśli etap nie daje niczego sprawdzalnego, jest czekaniem, a nie bramką.

Etap	Kto działa	Wyzwalacz	Zostawiony dowód	Bramka
1. Izolacja	Ty	git worktree add lub codex --worktree	Gałąź z jednym zadaniem	Brak
2. Otwarcie	Codex, w sesji	Prompt „otwórz szkic PR”	Opis PR z poleceniami i kodami wyjścia	Twoja lektura opisu
3. Wstępne review	Codex, lokalnie	codex review --base main lub /review	Uwagi P0–P3 poprawione przed pushem	Brak otwartych P0 i P1
4. Review	Codex na GitHubie	@codex review lub automatyczne review	Komentarze review na PR	Wątki rozwiązane lub z odpowiedzią
5. Naprawa	Zadanie Codex cloud albo ty lokalnie	Komentarz @codex z instrukcją	Poprawka i lista nieudanych testów przed i po; przebieg sprzątający ponownie uruchamia testy i aktualizuje tabelę Evidence	Zielone CI na nowym commicie
6. Merge	Wskazana osoba dla ryzykownych ścieżek	Ochrona gałęzi, CODEOWNERS	Akceptacja, zielone wymagane sprawdzenia	Przycisk merge lub auto-merge

Kolejność ma znaczenie. Tanie, prywatne sprawdzenia (etap 3) wykonujesz przed publicznymi (etap 4), więc recenzenci nie tracą czasu na uwagi, które Codex mógł poprawić sam.

Zaczynaj każdą zmianę we własnym worktree

Pull request powinien zawierać jedno zadanie. Daj każdemu zadaniu własną gałąź i katalog roboczy, żeby druga sesja Codex nie wmieszała swoich zmian. Dla pracy, która ma skończyć się pull requestem, od razu utwórz nazwaną gałąź. W terminalu:

git fetch origin
git worktree add -b feat/notification-prefs ../app-notification-prefs origin/main
cd ../app-notification-prefs
codex

codex --worktree jest szybsze przy eksploracji, ale zarządzany worktree startuje na odłączonym HEAD, więc przed pushem musisz utworzyć gałąź. Przygotowanie, sprzątanie i to, co zarządzany worktree przenosi, opisuje strona izolowane zadania Codex w worktree Gita. Ta sama zasada obowiązuje w aplikacji desktopowej Codex (codex app, macOS i Windows): jedno zadanie na gałąź, a diff czytasz sam, zanim poprosisz Codex o otwarcie pull requesta.

Niech Codex otworzy szkic pull requesta z dowodami

Recenzent czyta opis pull requesta przed diffem. Niech opis odpowiada na trzy pytania, które recenzent zadaje najpierw: jaki był zamiar, co dowodzi, że działa, i które linie wymagają człowieka. Zacommituj ten szablon raz, a każdy pull request, od Codex czy od człowieka, zacznie się od niego.

.github/pull_request_template.md

## Intent
<!-- One sentence: the behaviour this change adds or fixes. Link the issue or spec. -->

## What changed
<!-- At most five bullets, each naming the files involved. -->

## Evidence
<!-- Each command that was run, with its exit code. No claims without a command. -->
| Command | Exit code |
| --- | --- |

## Risk paths touched
<!-- Migrations, auth, billing, public API, tests, CI config. Write "none" if none. -->

## Not covered by tests
<!-- Behaviour the tests do not check, written as the missing test. -->

Potem poproś Codex o wypełnienie go. Push i otwarcie pull requesta wymagają sieci, a sandbox Codex w profilu :workspace nie ma dostępu do sieci (tak opisuje go README openai/codex-action, odczyt 2026-09-26). Spodziewaj się prośby o zgodę na git push i gh pr create albo uruchom te dwa polecenia sam.

Prompt do skopiowania: otwórz szkic pull requesta z dowodami

The task on this branch is complete. Prepare it for review:
1. Run the full test suite, the type check and the linter. Record each command and its
   exit code. If any fails, stop and show me the failure instead of opening a PR.
2. Run `git diff --stat origin/main...HEAD` and list every changed file under
   migrations/, src/auth/, src/billing/, src/api/, tests/ or .github/.
3. Commit any uncommitted work with a message in the imperative mood that says what
   the change does and why.
4. Push the branch to origin and open a DRAFT pull request against main with
   `gh pr create --draft --base main`, filling .github/pull_request_template.md:
   Intent, What changed, Evidence (the table of commands and exit codes from step 1),
   Risk paths touched (from step 2), Not covered by tests.
Do not claim any result you did not run. Print the pull request URL at the end.

Szkicu pull requesta nie da się zmergować i nie prosi on właścicieli kodu z CODEOWNERS o review, dopóki nie oznaczysz go jako gotowego poleceniem gh pr ready. Czytaj opis, nie diff: jeśli tabela Evidence jest pusta albo zawiera polecenie, którego nie rozpoznajesz, odeślij PR, zanim zobaczy go ktokolwiek inny.

Zrób pierwsze review, zanim spojrzy człowiek

Uruchom recenzenta Codex na gałęzi, zanim oznaczysz pull request jako gotowy. W terminalu:

codex review --base main

W sesji to samo robi interaktywnie /review. codex review --uncommitted sprawdza pracę, której jeszcze nie zacommitowałeś, a --commit SHA — pojedynczy commit. W 0.157.1 flagi zakresu, takiej jak --base, nie da się połączyć z własnym promptem, więc akcenty review umieść w AGENTS.md: według przewodnika OpenAI po integracji z GitHubem review na GitHubie czyta z niego własne reguły (stan na 2026-08-28), a lokalny przebieg Codex w zaufanym projekcie wczytuje go przed rozpoczęciem pracy. Popraw każdą uwagę P0 i P1, wypchnij zmiany i dopiero wtedy oznacz pull request jako gotowy.

Na GitHubie dodaj komentarz do pull requesta:

@codex review

Przewodnik OpenAI po integracji z GitHubem opisuje @codex review, @codex security review, automatyczne review każdego nowego pull requesta i reguły review w AGENTS.md (ostatni odczyt 2026-08-28; od tego czasu serwis jest niedostępny z naszego środowiska). Repozytorium musi być najpierw podłączone; zobacz podłączenie Codex do GitHuba. Kiedy włączyć automatyczne review i jak sprawdzić, że recenzent łapie prawdziwe błędy, opisuje code review z Codex.

Używaj jednego mechanizmu review Codex na repozytorium. Automatyczne review, ręczne komentarze @codex review i job review w openai/codex-action piszą do tego samego pull requesta, a trzech recenzentów powtarzających to samo uczy zespół ignorować ich wszystkich.

Napraw nieudane sprawdzenie zadaniem @codex

Gdy CI świeci na czerwono, wzmianka @codex z instrukcją uruchamia zadanie Codex cloud, które używa pull requesta jako kontekstu (przewodnik OpenAI po Codex cloud wymienia GitHuba jako miejsce startu pracy w chmurze, odczyt 2026-08-28). Instrukcja jest promptem, więc podaj cel, granicę i dowody, których oczekujesz. Samo „napraw CI” zaprasza do najszybszej drogi do zielonego, a to często osłabiony test.

Komentarz do skopiowania: napraw nieudane sprawdzenie CI bez ruszania testów

@codex The "test" job on this pull request fails. Read that job's log, reproduce the
failure in your environment, and fix the cause in the code under test. Do not edit,
skip or delete any test, do not change anything under .github/, and do not touch
files this pull request does not already change unless the root cause is there. In
your reply, list the failing test names before and after your change, the command
you ran to verify, and the root cause in two sentences.

Zadania Codex cloud przejrzysz z terminala poleceniem codex cloud, które w 0.157.1 ma status [EXPERIMENTAL]. Żeby przenieść wynik zadania na swoją gałąź, sprawdź go lokalnie i wypchnij sam:

codex cloud list --limit 5          # find the task ID
codex cloud diff TASK_ID            # read the patch
codex cloud apply TASK_ID           # apply it to your working tree
npm test && git add -A && git commit -m "Fix failing notification preference test" && git push

TASK_ID to identyfikator, który wypisuje codex cloud list. Zamień npm test na polecenie, które nie przeszło w CI.

Jeśli wolisz naprawić to lokalnie, sam przekaż log do Codex. GitHub CLI wypisuje tylko nieudane kroki poleceniem gh run view RUN_ID --log-failed, gdzie RUN_ID bierzesz z gh pr checks.

Prompt do skopiowania: napraw czerwony pull request z terminala

CI failed on this branch. Run `gh pr checks` to find the failing run, then
`gh run view <run id> --log-failed` and save the output to /tmp/ci-failure.log.
Reproduce the failure locally with the same command CI ran. Fix the root cause with
the smallest change. Do not edit tests to make them pass and do not touch .github/.
Run the failing command again and the full suite after it, report both exit codes,
and commit with a message that names the root cause. Do not push.

Jeśli awarie mają być naprawiane bez niczyjego komentarza, job workflow_run z openai/codex-action może zaproponować łatkę jako szkic pull requesta. Tę konfigurację, podzieloną tak, by job uruchamiający Codex nigdy nie miał tokenu z prawem zapisu, opisuje sekcja o proponowaniu poprawek po awarii CI na stronie Codex w CI/CD.

Posprzątaj gałąź, zanim poprosisz człowieka

Recenzent wykorzysta swój czas najlepiej, gdy po sesji agenta nie zostaną śmieci: wydruki debugowe, martwy kod, TODO, testy, które sprawdzają tylko, że funkcja została wywołana. Uruchom ten prompt w sesji Codex na gałęzi pull requesta, gdy uwagi z review są już poprawione.

Prompt do skopiowania: przygotuj pull request do merge

Compare this branch with origin/main and make it ready for a human reviewer.
Fix, then re-run the test suite after each category:
1. console.log, print or debugger statements added on this branch.
2. TODO or FIXME comments added on this branch: resolve them or list them in the
   pull request body under "Not covered by tests" with a reason.
3. Unused imports, unused functions and commented-out code added on this branch.
4. New tests that assert only that a mock was called: add an assertion on the
   returned value or the stored state.
Then update the pull request body's Evidence table with the final commands and exit
codes. Do not change behaviour, public signatures or files outside this branch's diff.

Merguj na podstawie dowodów, nie zielonego review

Czyste review Codex oznacza, że recenzent nie znalazł niczego, czego szukał. Nie oznacza, że zmiana jest poprawna. Decyzja o merge opiera się na sprawdzeniach, które zawodzą, gdy zachowanie jest złe, oraz na podpisie człowieka tam, gdzie pomyłka dużo kosztuje.

1. Wymagaj sprawdzeń. W regule ochrony gałęzi (lub rulesecie) dla main wymagaj zielonych jobów testów, sprawdzania typów i lintera oraz aktualności gałęzi przed merge.

2. Kieruj ryzykowne ścieżki do wskazanych właścicieli. Zacommituj plik CODEOWNERS i włącz „Require review from Code Owners”:

   # .github/CODEOWNERS
   /migrations/        @acme/data-owners
   /src/auth/          @acme/security
   /src/billing/       @acme/payments
   /src/api/public/    @acme/api-owners
   /tests/             @acme/tech-leads
   /.github/           @acme/platform

   Przy pracy agentów najważniejsze jest objęcie /tests/ i /.github/ plikiem CODEOWNERS: zmiana, która edytuje własną wyrocznię albo CI, nigdy nie może wejść tylko na słowo autora.

3. Pozwól rutynowym zmianom mergować się samym. Dla pull requesta, który nie dotyka żadnej ścieżki z CODEOWNERS, ma zielone wymagane sprawdzenia i rozwiązane wątki review Codex, autor może zakolejkować merge:

   gh pr merge --auto --squash

   GitHub zmerguje zmianę, gdy wymagania będą spełnione, i nie wcześniej.

4. Trzymaj dowody przy zmianie. Opis pull requesta, wątki review i przebieg CI zostają przypięte do commita merge. Do tego zapisu sięga później zespół analizujący incydent.

Co dowodzi	Kto sprawdza	Kto podpisuje
Zachowanie działa	Testy w wymaganych sprawdzeniach CI	CI
Typy i styl się zgadzają	Sprawdzanie typów i linter w wymaganych sprawdzeniach	CI
Nie wkradła się znana klasa błędów	Review Codex według reguł z AGENTS.md	Autor rozwiązuje każdy wątek
Zamiar zgadza się ze zmianą	Sekcje Intent i Risk paths w opisie PR	Recenzent, czytając opis
Ryzykowne ścieżki są poprawne	Review właściciela kodu	Wskazany właściciel

Praca recenzenta sprowadza się do przeczytania opisu i listy ryzyk, a potem diffu tylko ścieżek z przypisanym właścicielem. Pełną procedurę opisuje review pull requesta agenta bez czytania każdej linii, a kontrakt, który powinien nieść każdy pull request agenta, to pakiet dowodów.

Jeśli Codex ma czytać pull requesty, review i logi Actions przez narzędzia zamiast przez gh, dodaj serwer MCP GitHuba (polecenie z przewodnika instalacji GitHuba; flagi sprawdzone w codex mcp add --help w wersji 0.157.1, 2026-09-26):

codex mcp add github --url https://api.githubcopilot.com/mcp/ --bearer-token-env-var GITHUB_PAT_TOKEN

gh pokrywa ten sam zakres przy mniejszym zużyciu tokenów; konfigurację, zawężanie zestawów narzędzi i tryb tylko do odczytu opisuje strona serwer MCP GitHuba.

Co psuje się w automatyzacji pull requestów z Codex?

Codex nie może wypchnąć zmian ani otworzyć pull requesta. Sandbox Codex w profilu :workspace nie ma sieci albo gh nie jest zalogowane. Zatwierdź prośby o git push i gh pr create, gdy Codex o nie poprosi, albo uruchom je sam. Zanim obwinisz sandbox, sprawdź gh auth status.

Pull request ma konflikt z main. Worktree utworzono na starym commicie bazowym. W worktree uruchom git fetch origin && git rebase origin/main, poproś Codex o ponowne uruchomienie całego zestawu testów i aktualizację tabeli Evidence, a potem git push --force-with-lease. Po pushu poproś ponownie o @codex review, bo komentarze sprzed rebase wskazują stare linie.

Poprawka @codex daje zielone CI kosztem osłabionego testu. Odrzuć wynik zadania; nie nakładaj go. Opublikuj komentarz ponownie z granicą „do not edit, skip or delete any test” i upewnij się, że CODEOWNERS obejmuje /tests/, żeby zmiana nie weszła bez tech leada, nawet jeśli ktoś ją nałoży.

Opis pull requesta podaje wyniki, których nikt nie uruchomił. Tabela Evidence pokazuje polecenie z kodem wyjścia 0, a CI na tym samym poleceniu pada. Traktuj CI jako źródło prawdy, odeślij pull request i dopisz „Do not claim any result you did not run” do promptu, którego używa zespół. Żeby to zautomatyzować, wdróż pakiet dowodów — ta strona pokazuje, jak sprawić, by niekompletne dowody oblewały CI.

@codex review nie odpowiada. Code review nie jest włączone dla repozytorium albo połączenie z GitHubem go nie widzi. Sprawdź oba punkty w podłączeniu Codex do GitHuba i opublikuj komentarz ponownie.

Trzech recenzentów, jeden pull request. Komentarze dodały jednocześnie automatyczne review, ręczne @codex review i job review w CI. Zostaw jeden: automatyczne review, gdy reguły są dostrojone, albo job w CI, jeśli wynik ma być wymaganym sprawdzeniem. Pozostałe usuń.

Pull request z forka uruchamia Codex z twoim kluczem API. Job review, który pobiera gałąź kontrybutora, czyta jej AGENTS.md, a ten steruje przebiegiem. GitHub i tak nie przekazuje sekretów do przebiegów pull_request z forków, więc job review na pull_request w ogóle nie uruchomi tam Codex; pull requesty z forków przeglądaj ręcznie. Ryzyko tworzą joby pull_request_target lub workflow_run, które pobierają gałąź forka, mając dostęp do sekretów: jej hooki, konfiguracja .codex/ i AGENTS.md są wtedy uruchamiane albo czytane obok twojego klucza. Etykieta nadana przez opiekuna repozytorium tego nie naprawia, bo kontrybutor może dopchnąć nowe commity już po jej nadaniu. Jeśli musisz użyć takiego triggera, pobierz prompt i skrypty workflow z gałęzi domyślnej, commit forka umieść w osobnym katalogu, który Codex tylko czyta w profilu :read-only, nie ładuj z niego konfiguracji projektu, hooków ani AGENTS.md i ogranicz job do contents: read; zasady utwardzania opisuje sekcja o zabezpieczaniu GitHub Action na stronie Codex w CI/CD.

Dokąd dalej z pull requestami w Codex

Code review z Codex Reguły review w AGENTS.md, blokada pushu przy uwagach P0 i P1 oraz test recenzenta na zasianych błędach.

Codex w CI/CD z GitHub Action Joby review, bramki bezpieczeństwa i automatycznych poprawek CI z openai/codex-action, zabezpieczone pod kątem sekretów.

Przepływy wieloagentowe w Codex Uruchamiaj kilka zadań w worktree naraz i merguj ich pull requesty w bezpiecznej kolejności.

Codex w Slacku i Linear Zacznij zadanie, które stanie się pull requestem, od zgłoszenia lub wątku na czacie.

Ten sam cykl w Claude Code opisuje strona automatyczne code review z Claude Code.