# Połącz Codex z GitHubem URL: https://developertoolkit.ai/pl/codex/quick-start/github-integration/ Description: Połącz Codex z GitHubem: środowisko w chmurze, @codex review, reguły przeglądu w AGENTS.md, zadania z issues i merge blokowany przez CI. 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](/pl/codex/quick-start/authentication/). - **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](/pl/codex/quick-start/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](https://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](/pl/codex/automate/cloud-environments/). ## 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. ```bash 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** ```text 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: ```text @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: ```text @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](/pl/codex/operate/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ł. ```markdown ## 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](/pl/codex/quick-start/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** ```text @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** ```text @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`. ```bash 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 ' 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](/pl/codex/quick-start/review-workflow/). ## 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](/pl/workflows/ship/agent-pr-review/) 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](#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](/pl/codex/automate/cloud-environments/)). **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](/pl/codex/quick-start/review-workflow/) — Przeglądaj, poprawiaj i scalaj zmiany Codex w panelu przeglądu i przez /review, zanim cokolwiek trafi na GitHuba. - [Code review z Codex](/pl/codex/ship/code-review/) — 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](/pl/codex/ship/pr-automation/) — Automatyzuj cykl życia pull requesta od issue do merge’a przez @codex i GitHub Action. - [CI/CD z Codex GitHub Action](/pl/codex/ship/ci-cd/) — 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](/pl/ecosystem/observability/ai-code-review-bots/) — Przegląd Codex obok Code Review w Claude Code, Cursor Bugbot i zewnętrznych botów do przeglądu. - [Code review PR-a agenta](/pl/workflows/ship/agent-pr-review/) — Sześciokrokowa procedura, którą człowiek wykonuje zamiast czytać każdą linię diffu agenta.