Połącz Codex z GitHubem

Integracja Codex z GitHubem łączy repozytorium ze środowiskiem Codex w chmurze, dzięki czemu współpracownicy mogą skomentować pull request @codex review lub @codex security review, włączyć automatyczne przeglądy każdego nowego pull requesta albo wspomnieć @codex z poleceniem, które uruchamia zadanie w chmurze. Reguły przeglądu pochodzą z AGENTS.md, a o merge’u nadal decyduje CI.

Ta strona jest dla programistów i tech leadów, którzy używają już Codex lokalnie i chcą, żeby pracował na pull requestach zespołu. Sytuacja, którą rozwiązuje: pull requesty czekają dwa dni na pierwszy przegląd, niestabilny test zmienia CI na czerwone w piątek po południu, a backlog issues rośnie szybciej, niż ktokolwiek nadąża przeglądać zgłoszenia. Po podłączeniu Codex do GitHuba pierwszy przegląd i pierwszą próbę poprawki robi agent, a ostatnie słowo należy do wymaganego sprawdzenia CI i konkretnej osoby.

Co będziesz mieć po podłączeniu Codex do GitHuba

• Środowisko w chmurze, które instaluje zależności i uruchamia testy, sprawdzone z terminala, zanim ktokolwiek zacznie na nim polegać
• Działające na pull requestach @codex review i @codex security review, a jeśli chcesz, także automatyczne przeglądy
• Reguły przeglądu w AGENTS.md, które zamieniają pytanie „co Codex ma zgłaszać?” w wersjonowany plik przechodzący code review
• Dwa gotowe do wklejenia komentarze, które uruchamiają zadania w chmurze z czerwonego pull requesta i z issue
• Bramkę merge’a, która sprawdza pracę Codex testami i wymaganymi sprawdzeniami CI, a nie czytaniem każdej linii przez człowieka

Czego potrzebujesz, zanim połączysz Codex z GitHubem

• Planu ChatGPT z Codex: Plus, Pro, Business, Edu lub Enterprise. Funkcje chmurowe wymagają logowania kontem ChatGPT; klucz API nie daje dostępu do Codex w chmurze. Zobacz uwierzytelnianie w Codex.
• Uprawnień do instalacji aplikacji GitHub na koncie lub w organizacji, do której należy repozytorium. W organizacji zwykle oznacza to, że prośbę zatwierdza właściciel (owner).
• Komendy testów, która przechodzi na czystym checkoucie. Przegląd i poprawki Codex są warte tyle, ile sprawdzenia, które agent potrafi uruchomić. Jeśli npm test wymaga lokalnej bazy uruchamianej ręcznie, zapisz to, zanim zaczniesz.
• Pliku AGENTS.md w katalogu głównym repozytorium. Jeśli go jeszcze nie masz, utwórz go najpierw według przewodnika po AGENTS.md.

Połącz repozytorium i utwórz środowisko w chmurze

Integracja z GitHubem działa na Codex w chmurze: każdy przegląd i każde zadanie @codex wykonuje się w kontenerze zbudowanym ze zdefiniowanego przez ciebie środowiska. Zacznij od niego.

1. Otwórz Codex w przeglądarce pod adresem chatgpt.com/codex i zaloguj się kontem ChatGPT, na którym masz plan.

2. Połącz GitHuba, gdy Codex o to poprosi. GitHub pokaże ekran instalacji aplikacji; nadaj jej dostęp tylko do tych repozytoriów, na których Codex ma pracować, a nie do wszystkich repozytoriów organizacji.

3. Utwórz środowisko dla repozytorium. Wybierz domyślną gałąź i dodaj komendy instalacyjne, które instalują zależności dokładnie tak jak CI, na przykład npm ci albo pip install -r requirements.txt.

4. Dodaj zmienne środowiskowe potrzebne testom. Podaj wyłącznie dane testowe. Wszystko w środowisku może przeczytać agent i każde zadanie uruchomione komentarzem.

5. Zapisz środowisko i zanotuj jego ID. Używają go komendy z następnej sekcji.

Etykiety menu w Codex w przeglądarce zmieniają się między wydaniami; opisany przebieg odpowiada przewodnikom OpenAI o GitHubie i środowiskach w chmurze w wersji z 2026-08-28. Cache kontenerów, dostęp do internetu i próby best-of-N opisuje strona środowiska Codex w chmurze.

Sprawdź środowisko z terminala

Źle skonfigurowane środowisko to częsty powód, dla którego zadania @codex się nie udają, a błąd wychodzi dopiero później jako mglisty komentarz na pull requeście. Sprawdź je raz z CLI, zanim powiesz o nim zespołowi. W Codex CLI 0.157.1 codex cloud ma oznaczenie [EXPERIMENTAL], a wszystkie poniższe podkomendy pochodzą z --help tej wersji.

codex cloud list --env ENV_ID          # the environment is reachable and lists its tasks
codex cloud exec --env ENV_ID --branch main "Run the full test suite and report the exact command, the pass and fail counts, and any setup step that failed. Do not change any files."
codex cloud status TASK_ID             # poll until the task finishes
codex cloud diff TASK_ID               # should be empty: the prompt forbade changes

ENV_ID to ID środowiska z kroku 5; TASK_ID wypisuje codex cloud exec. --branch domyślnie wskazuje twoją bieżącą lokalną gałąź; ustaw gałąź, na której CI ostatnio przeszło na zielono, żeby liczby dało się porównać. Jeśli liczba testów zgłoszona przez Codex różni się od tej z CI dla tego samego commita, popraw teraz polecenia przygotowania środowiska. Agent, który nie potrafi uruchomić twoich testów, recenzuje na ślepo.

Prompt do skopiowania: smoke test środowiska

Run the full test suite for this repository exactly as CI does. Report: the command you ran, the number of tests passed, failed and skipped, the total runtime, and every setup or install step that printed an error or warning. Do not modify any files and do not open a pull request.

Włącz przeglądy kodu Codex dla repozytorium

Przegląd kodu to ustawienie per repozytorium w Codex w przeglądarce. Otwórz ustawienia Codex, znajdź sekcję przeglądu kodu (code review) i włącz ją dla podłączonego repozytorium. W tym samym miejscu są automatyczne przeglądy, po których Codex przegląda każdy nowy pull request bez proszenia (przewodnik OpenAI o GitHubie, stan na 2026-08-28; etykiety mogą się różnić).

Od czego zacząć, zależy od zespołu:

Sytuacja	Zacznij od	Dlaczego
Pierwsze dwa tygodnie, reguły jeszcze nie spisane	@codex review na żądanie	Widzisz, co Codex zgłasza na prawdziwych pull requestach, zanim zacznie komentować każdy
Reguły w AGENTS.md dopracowane na 10 lub więcej pull requestach	Automatyczne przeglądy	Każdy pull request dostaje pierwsze przejście, także te, o których nikt nie pamiętał
Publiczne repozytorium z zewnętrznymi kontrybutorami	Tylko na żądanie	Agent zajmuje się tylko pull requestami, które maintainer już obejrzał

Poproś o przegląd komentarzem @codex review

Na dowolnym pull requeście w podłączonym repozytorium dodaj komentarz:

@codex review

Codex przegląda zmiany i publikuje uwagi w wątku pull requesta. Przegląd skupiony na bezpieczeństwie uruchamia druga komenda opisana przez OpenAI:

@codex security review

OpenAI wymienia też GitLaba jako miejsce przeglądów: @codex review działa na merge requestach, a obsługa GitLaba jest w becie na wszystkich planach ChatGPT (przewodnik OpenAI po GitLabie, sprawdzone 2026-10-12). Konfiguracja wygląda inaczej, więc ta strona opisuje tylko GitHuba.

Trzymaj przegląd bezpieczeństwa osobno od ogólnego. Odpowiada na inne pytanie, a jego ustalenia zasługują na innego właściciela. Codex Security, czyli co raportuje i jak ustalenia trafiają do obsługi, ma osobną stronę: Codex Security.

Zapisz w AGENTS.md reguły przeglądu, których Codex przestrzega

Przewodnik OpenAI o GitHubie mówi, że Codex przeszukuje repozytorium w poszukiwaniu plików AGENTS.md, i każe: „Add a ## Code Review Rules section to the file closest to the code the rules govern” (odczyt 2026-10-13). Gdy ta witryna sprawdzała przewodnik 2026-08-28, sekcja nazywała się ## Review guidelines, więc w starszym pliku zmień nagłówek. Trzymaj reguły pod tym nagłówkiem, żeby łatwo znaleźli je i ludzie, i Codex. Reguły, które wskazują ścieżkę i sprawdzalny warunek, działają lepiej niż ogólne rady, bo po fakcie widać, czy Codex je zastosował.

## Code Review Rules

- Flag any new or changed HTTP handler under `src/api/` that does not call `requireSession()`.
- Flag any SQL built with string concatenation or template literals; parameterized queries only.
- Flag any change under `src/billing/` that has no matching change under `tests/billing/`.
- Flag a new dependency in `package.json` and state what it replaces or why nothing existing fits.
- Flag user-facing string changes in `src/i18n/en.json` that have no matching key in `src/i18n/pl.json`.
- Do not comment on formatting or import order; `dprint` and `oxlint` enforce those in CI.

Ostatnia reguła jest równie ważna jak pozostałe. Każdy komentarz Codex o czymś, co już pilnuje linter, to komentarz, który recenzenci uczą się pomijać.

Jeśli jedna część monorepo potrzebuje ostrzejszych reguł, dodaj AGENTS.md w tym pakiecie, na przykład packages/payments/AGENTS.md, z własną sekcją ## Code Review Rules. Codex łączy pliki AGENTS.md od katalogu głównego repozytorium w dół do katalogu, w którym pracuje, co wyjaśnia przewodnik po AGENTS.md. Źródła, które mogliśmy sprawdzić 2026-09-26, nie mówiły, jak przegląd pull requesta obejmującego kilka pakietów uwzględnia zagnieżdżone pliki. Przewodnik odczytany 2026-10-13 każe: „Put repository-wide rules in the root AGENTS.md and service-specific rules in a nested file” i mówi, że Codex „applies the root and more-specific guidance that covers each changed file”, więc każdą regułę, która ma obowiązywać zawsze, trzymaj w pliku głównym.

Traktuj reguły jak kod: zmieniają się przez pull requesty, a gdy Codex przeoczy coś istotnego, dodaj regułę w tym samym pull requeście co poprawkę.

Uruchamiaj zadania w chmurze z issues i pull requestów

@codex review i @codex security review to komendy przeglądu. Przewodnik OpenAI po Codex w chmurze w wersji z 2026-08-28 wymieniał GitHuba, obok przeglądarki, GitLaba, Lineara i Slacka, jako miejsce startu pracy w chmurze. Przepisany przewodnik (sprawdzony 2026-10-12) już ich nie wymienia: opisuje zadania startujące z opublikowanych środowisk chmurowych, które kontynuujesz „from the web, mobile, or desktop app”. Start zadania w chmurze przez wspomnienie @codex z poleceniem w issue lub pull requeście jest więc 2026-10-12 niepotwierdzony; wypróbuj go na testowym pull requeście, zanim na nim polegasz.

Wzmianka to prompt, więc obowiązuje ją ta sama zasada co każdy prompt: podaj cel, granice i dowody, których oczekujesz w odpowiedzi. Gołe @codex fix this daje diff, który potem musisz przeczytać linia po linii, żeby go zrozumieć.

Komentarz do skopiowania: napraw czerwony pull request

@codex The CI run on this pull request is failing. Read the failing job's log, reproduce the failure in your environment, and fix the cause in the code under test. Do not skip, delete or loosen any test, and do not change CI configuration. In your reply, list the failing test names before and after your change and the command you ran to verify.

Komentarz do skopiowania: zaimplementuj issue z kryteriami akceptacji

@codex Implement this issue. Before writing code, restate the acceptance criteria from the issue as a numbered list. Add or update tests so that each criterion has at least one test that fails without your change and passes with it. Keep the change inside the modules the issue names. In your reply, map each criterion to its test name and paste the test command output.

Każde zadanie śledzisz w Codex w przeglądarce albo z terminala przez codex cloud list. Żeby sprawdzić wynik zadania na swojej maszynie, zanim trafi do pull requesta, obejrzyj go przez codex cloud diff TASK_ID i nałóż na drzewo robocze przez codex cloud apply TASK_ID.

Zrób przegląd lokalnie, zanim wypchniesz zmiany

Najtańszy przegląd to ten, który odbywa się, zanim powstanie pull request. Codex CLI 0.157.1 ma nieinteraktywną komendę codex review, a w TUI to samo robi /review.

codex review --uncommitted                     # staged, unstaged and untracked changes
codex review --base main                       # this branch against main
codex review --commit "$(git rev-parse HEAD)"  # the last commit only
codex review "Review the changes on this branch against main. Apply the Code Review Rules section in AGENTS.md; report only findings you can point to a line for."

W 0.157.1 własnego promptu nie da się połączyć z --base, --uncommitted ani --commit: CLI kończy działanie błędem the argument '--base <BRANCH>' cannot be used with '[PROMPT]'. Podaj albo flagę wskazującą zmiany, albo prompt, nie oba naraz. --commit przyjmuje SHA, więc najpierw zamień HEAD na SHA przez git rev-parse.

codex review --base main uruchomione przed git push wyłapuje to samo co @codex review, tylko jedną rundę wcześniej. Panel przeglądu i lokalną pętlę opisuje workflow przeglądu w Codex.

Jak sprawdzić pracę Codex bez czytania każdej linii?

Przegląd Codex to jeden sygnał, a nie zatwierdzenie, a poprawka Codex jest propozycją, dopóki sprawdzenia nie powiedzą inaczej. Ustal, kto czego dowodzi, zanim ruszy pierwsze zadanie:

Dowód	Kto go wytwarza	Czego dowodzi	Kto zatwierdza
Wymagane status checki (testy, sprawdzanie typów, lint)	Twoje CI, na ostatnim commicie pull requesta	Zmiana się buduje, a dotychczasowe zachowanie nadal przechodzi	Nikt; reguła ochrony gałęzi blokuje merge
Nowe lub zmienione testy przypisane do kryteriów akceptacji	Codex, na prośbę z komentarzy powyżej	Każde kryterium ma test, który bez zmiany nie przechodzi	Autor pull requesta, sprawdzając przypisanie
Uwagi z @codex review, rozwiązane lub z odpowiedzią	Codex, według AGENTS.md	Spisane reguły zostały zastosowane do tego diffu	Autor zamyka każdy wątek
Przegląd ryzykownych ścieżek	Człowiek z CODEOWNERS dla src/billing/, src/auth/, migracji	Ktoś odpowiedzialny spojrzał tam, gdzie błąd jest drogi	Ten code owner

Trzy ustawienia GitHuba zamieniają tę tabelę z umowy w egzekwowaną regułę: reguła ochrony gałęzi (lub ruleset) na gałęzi domyślnej, która wymaga przejścia status checków, wymaga review pull requesta i wymaga review od code ownerów. Z nimi pull request, który Codex otworzył, zrecenzował i „naprawił”, i tak nie wejdzie do gałęzi, dopóki CI nie będzie zielone, a odpowiedzialna osoba go nie zatwierdzi.

Dla ludzkiej połowy tej pracy procedura z code review PR-a agenta bez czytania każdej linii zamienia „przeczytaj diff” w krótką sekwencję: różnica względem specyfikacji, dowody, flagi ryzyka, zmienione testy, próbkowane hotspoty.

Co się psuje, gdy Codex działa na twoim repozytorium GitHub?

@codex nie odpowiada na pull requeście. Zwykle aplikacja GitHub nie ma dostępu do tego repozytorium albo przegląd kodu nie jest dla niego włączony. W GitHubie otwórz zainstalowane aplikacje GitHub organizacji, sprawdź, czy repozytorium jest na liście dostępu aplikacji, a potem potwierdź w ustawieniach Codex, że przegląd kodu jest włączony dla tego repozytorium. Po zmianie którejkolwiek z tych rzeczy dodaj komentarz jeszcze raz.

Zadania padają podczas przygotowania środowiska albo raportują inne wyniki testów niż CI. Polecenia przygotowania środowiska rozjechały się z CI. Powtórz test z sekcji Sprawdź środowisko z terminala i przepisz komendy instalacji i testów z pliku workflow CI do środowiska, linia po linii.

Przeglądy są hałaśliwe albo pomijają to, co ważne. Codex stosuje reguły, które dostał. Usuń komentarze o stylu, wskazując w AGENTS.md formatter i linter, i dodaj regułę dla konkretnej ścieżki przy każdym przeoczeniu, które trafiło na main. Po 10 pull requestach policz, ile uwag Codex skończyło się zmianą w kodzie; jeśli mniej niż połowa, wycinaj reguły zamiast dokładać nowe.

Poprawka Codex daje zielone CI, bo osłabia test. Dzieje się tak, gdy prompt tego nie zabronił. Wymagany status check tego nie wyłapie, bo osłabiony test przechodzi. Napisz w komentarzu „do not skip, delete or loosen any test” i dodaj regułę przeglądu, która zgłasza każdy diff usuwający asercje albo dodający .skip.

Issue od zewnętrznego kontrybutora steruje agentem. Zakładaj, że treść issue i pull requesta może stać się wejściem promptu dla każdego zadania uruchomionego z tego wątku. W publicznych repozytoriach uruchamiaj zadania tylko z issues, które maintainer już przejrzał, trzymaj sekrety produkcyjne poza środowiskiem i ogranicz dostęp środowiska do internetu do tego, czego potrzebuje instalacja zależności (ustawienia dostępu do internetu).

Codex otwiera pull request, o który nikt nie prosił. Ktoś wspomniał @codex z otwartym poleceniem. Zamknij go, a potem umówcie się w zespole, że każdy komentarz uruchamiający zadanie @codex podaje kryteria akceptacji, tak jak prompty na tej stronie.

Co dalej z Codex na GitHubie

Workflow przeglądu w Codex Przeglądaj, poprawiaj i scalaj zmiany Codex w panelu przeglądu i przez /review, zanim cokolwiek trafi na GitHuba.

Code review z Codex Głębsze reguły przeglądu, strategie przeglądu i przegląd na każdej powierzchni, od CLI po pull requesty.

Automatyzacja pull requestów Automatyzuj cykl życia pull requesta od issue do merge’a przez @codex i GitHub Action.

CI/CD z Codex GitHub Action Uruchamiaj Codex we własnym workflow GitHub Actions, gdy przegląd musi odbywać się w kontrolowanym przez ciebie CI.

Porównanie botów do AI code review Przegląd Codex obok Code Review w Claude Code, Cursor Bugbot i zewnętrznych botów do przeglądu.

Code review PR-a agenta Sześciokrokowa procedura, którą człowiek wykonuje zamiast czytać każdą linię diffu agenta.