Jak automatycznie naprawiać kod z Codex CLI w GitLab - przewodnik

Większość zespołów programistycznych polega na automatycznych testach i skanach bezpieczeństwa przed wdrożeniem kodu na produkcję. Problem? Tradycyjne narzędzia wykrywają tylko znane błędy według sztywnych reguł, a potem zasypują Cię długą listą alertów, w której trudno odróżnić to, co pilne, od fałszywych alarmów. Przegląd takiego raportu to jak szukanie igły w stogu siana.

Aktualizacja 13.10.2026: przepisaliśmy konfigurację według aktualnej dokumentacji OpenAI i GitLaba (stan na 13.10.2026). Poprzednia wersja tekstu zawierała polecenia, których Codex CLI nie ma - instalację przez pip, opcje --mode, --format codeclimate, --diff-only i plik .codex.yml - oraz szacunki kosztów i czasu bez źródła. Dopisaliśmy też prostszą drogę: recenzje Codexa w GitLabie wywoływane komentarzem @codex review.

OpenAI wypuściło Codex CLI - narzędzie wiersza poleceń, które dodaje do tego procesu warstwę rozumowania. Zamiast tylko skanować kod według reguł, Codex analizuje kontekst, łączy duplikaty i podpowiada konkretne kroki naprawy. W tym przewodniku pokażę Ci, jak wpiąć to do GitLab CI/CD krok po kroku - na podstawie przykładu przygotowanego przez OpenAI, zaktualizowanego do obecnej wersji narzędzia. Bez zakładania, że jesteś ekspertem DevOps.

Zanim zaczniesz - co musisz mieć

Żeby podążać za tym poradnikiem, potrzebujesz:

• Konto GitLab i działający projekt z kodem w repozytorium Git - wyniki Code Quality w merge requeście są dostępne także w darmowym planie
• GitLab Runner z dostępem do internetu i do api.openai.com - autorzy przykładu OpenAI testowali go na runnerze z Linuksem: 2 vCPU, 8 GB RAM i 30 GB dysku. Codex wykonuje polecenia w piaskownicy, a OpenAI w przewodniku Codex Security dla GitLaba wymaga runnera obsługującego przestrzenie nazw użytkownika (user namespaces), z których ta piaskownica korzysta
• Klucz API OpenAI - utworzysz go w panelu OpenAI (platform.openai.com) po zalogowaniu. Przy logowaniu kluczem API Codex rozlicza zużycie według zwykłego cennika API, a nie limitów planu ChatGPT
• Podstawową znajomość GitLab CI/CD - wystarczy, że wiesz, czym jest plik .gitlab-ci.yml

Jeśli nigdy nie konfigurowałeś GitLab CI/CD, spokojnie. Poniżej wszystko rozpisuję na czynniki pierwsze.

Czym jest Codex CLI i dlaczego warto go używać

Codex CLI to open-source'owe narzędzie wiersza poleceń od OpenAI (licencja Apache-2.0, napisane głównie w Ruście). Możesz je znaleźć na github.com/openai/codex. W skrócie: pozwala Ci wpiąć modele OpenAI bezpośrednio do Twojego workflow programistycznego. W skryptach i CI uruchamia się je poleceniem codex exec - to tryb nieinteraktywny, który wykonuje zadanie i zwraca wynik bez otwierania okna rozmowy.

Co to daje w praktyce? Zamiast dostawać raport "znaleziono 47 problemów" bez kontekstu, możesz dostać:

• Raport w formacie GitLab Code Quality (JSON zgodny z formatem CodeClimate) - prosisz Codex o dane w tym formacie, a GitLab pokazuje znaleziska w merge requeście
• Łączenie duplikatów - ten sam błąd w wielu miejscach może trafić do raportu jako jeden wpis z listą lokalizacji
• Ranking według możliwości wykorzystania - luki bezpieczeństwa posortowane od "to trzeba naprawić dziś" do "można poczekać"
• Konkretne kroki naprawy - nie "wykryto SQL injection", tylko np. "w routes/login.ts, linia 34, użyj zapytań parametryzowanych zamiast sklejania tekstu"

W tym poradniku skupimy się na dwóch scenariuszach: automatycznej analizie jakości kodu i porządkowaniu wyników skanów bezpieczeństwa (SAST).

Krok 1: Skonfiguruj zmienne środowiskowe w GitLab

Zanim uruchomisz jakikolwiek pipeline, musisz przekazać GitLabowi Twój klucz API OpenAI. Robisz to przez zmienne CI/CD - miejsce na sekrety, które nie trafiają do repozytorium.

Otwierasz swój projekt w GitLab (potrzebujesz roli Maintainer), wybierasz Settings → CI/CD, rozwijasz sekcję Variables i klikasz Add variable.

Wypełniasz:

• Key: OPENAI_API_KEY
• Value: wklejasz swój klucz API (zaczyna się od sk-)
• Type: Variable
• Visibility: Masked and hidden - klucz jest maskowany w logach i po zapisaniu nie da się go już podejrzeć w ustawieniach (tę opcję wybierzesz tylko przy tworzeniu nowej zmiennej)
• Protect variable: zaznacz, jeśli chcesz, żeby klucz był dostępny tylko w pipeline'ach na chronionych gałęziach

Uwaga na pułapkę z chronioną zmienną: pipeline merge requesta dostaje chronione zmienne tylko wtedy, gdy obie gałęzie (źródłowa i docelowa) są chronione i należą do tego samego projektu, osoba uruchamiająca pipeline może pushować lub mergować do gałęzi docelowej, a w ustawieniach projektu włączono dostęp pipeline'ów MR do chronionych zasobów. Przy zwykłej, niechronionej gałęzi z nową funkcją job z kroku 2 po prostu się nie uruchomi, bo nie zobaczy klucza. Jeśli zostawisz zmienną niechronioną, klucz zobaczy każdy pipeline w projekcie - wtedy pilnuj, kto może zmieniać .gitlab-ci.yml. OpenAI podkreśla, że maskowanie i ukrywanie zmiennej nie chroni przed złośliwym kodem uruchomionym w tym samym jobie.

Klikasz Add variable. Gotowe. W przykładach poniżej skrypt tuż przed wywołaniem Codexa usuwa OPENAI_API_KEY ze środowiska joba i przekazuje klucz tylko samemu poleceniu codex (jako CODEX_API_KEY) - podobnie robi to przewodnik OpenAI dla GitLaba. OpenAI odradza też uruchamianie w jobie z kluczem kodu z repozytorium, np. instalacji zależności projektu czy testów, bo mógłby ten klucz odczytać.

Krok 2: Dodaj job do analizy jakości kodu

Najpierw dodajesz do repozytorium plik ze schematem odpowiedzi. Codex ma opcję --output-schema: podajesz w niej schemat JSON, a końcowa odpowiedź musi mu odpowiadać. Dzięki temu nie musisz wyłuskiwać JSON-a z tekstu, jak w pierwotnym przykładzie OpenAI. Zapisz plik jako ci/codex-code-quality-schema.json:

{
  "type": "object",
  "properties": {
    "issues": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "description": { "type": "string" },
          "check_name": { "type": "string" },
          "severity": {
            "type": "string",
            "enum": ["info", "minor", "major", "critical", "blocker"]
          },
          "location": {
            "type": "object",
            "properties": {
              "path": { "type": "string" },
              "lines": {
                "type": "object",
                "properties": { "begin": { "type": "integer" } },
                "required": ["begin"],
                "additionalProperties": false
              }
            },
            "required": ["path", "lines"],
            "additionalProperties": false
          }
        },
        "required": ["description", "check_name", "severity", "location"],
        "additionalProperties": false
      }
    }
  },
  "required": ["issues"],
  "additionalProperties": false
}

Pola odpowiadają tym, których GitLab wymaga w raporcie Code Quality: description, check_name, severity (jedno z: info, minor, major, critical, blocker), location.path i location.lines.begin. Brakujące pole fingerprint job wyliczy sam.

Teraz edytujesz (lub tworzysz) plik .gitlab-ci.yml w głównym katalogu swojego repozytorium i dodajesz job codex_code_quality:

codex_code_quality:
  stage: test
  image: node:24
  variables:
    GIT_DEPTH: "0"
  rules:
    # MR z forka: nie uruchamiaj joba, który ma dostęp do klucza API
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_PROJECT_ID != $CI_PROJECT_ID'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $OPENAI_API_KEY'
  script:
    - npm install -g @openai/codex@0.162.1
    - codex --version
    - |
      set -euo pipefail
      klucz="$OPENAI_API_KEY"
      unset OPENAI_API_KEY
      git diff "$CI_MERGE_REQUEST_DIFF_BASE_SHA" HEAD \
        | CODEX_API_KEY="$klucz" codex exec \
            --sandbox read-only \
            --ephemeral \
            -m gpt-6.1-sol \
            --output-schema ci/codex-code-quality-schema.json \
            -o codex-wynik.json \
            "Jesteś recenzentem kodu. Na wejściu masz diff tego merge requesta.
            Znajdź realne problemy jakości i bezpieczeństwa w zmienionych liniach.
            Dla każdego podaj: description (po polsku, z konkretną poprawką),
            check_name (krótka nazwa reguły), severity (info, minor, major,
            critical albo blocker), location.path (ścieżka względna w repozytorium,
            bez ./) i location.lines.begin. Zgłaszaj tylko istniejące pliki.
            Jeśli nie masz pewności, pomiń znalezisko. Gdy problemów nie ma,
            zwróć pustą listę issues."
    - |
      node -e '
        const fs = require("fs");
        const crypto = require("crypto");
        const wynik = JSON.parse(fs.readFileSync("codex-wynik.json", "utf8"));
        const raport = wynik.issues.map((i) => ({
          ...i,
          fingerprint: crypto.createHash("sha256")
            .update(i.check_name + "|" + i.location.path + "|" + i.location.lines.begin)
            .digest("hex"),
        }));
        fs.writeFileSync("gl-code-quality-report.json", JSON.stringify(raport, null, 2));
        console.log("Znaleziska: " + raport.length);
      '
  artifacts:
    when: always
    reports:
      codequality: gl-code-quality-report.json
    expire_in: 14 days

Co tu się dzieje?

• image: node:24 - obraz Dockera z Node.js, bo Codex CLI instalujesz przez npm (pakiet @openai/codex). Wersję warto przypiąć - 0.162.1 to najnowsza w npm w dniu aktualizacji (13.10.2026)
• GIT_DEPTH: "0" - pełna historia repozytorium, żeby dało się policzyć diff względem gałęzi docelowej
• rules - job działa tylko w pipeline'ach merge requestów, nie działa dla MR z forków i nie startuje, gdy klucz API nie jest dostępny
• git diff ... | codex exec - do Codexa trafia tylko diff merge requesta. Polecenie w cudzysłowie to instrukcja, a przekazany na wejście diff - kontekst
• --sandbox read-only - Codex może czytać pliki, ale nie może niczego zmieniać (to zresztą domyślne ustawienie codex exec)
• -m gpt-6.1-sol - model, który OpenAI zaleca w Codexie do złożonego kodowania (stan na 13.10.2026). Tańsza opcja do prostszych zadań to gpt-6-luna
• --output-schema i -o - odpowiedź zgodna ze schematem trafia do pliku codex-wynik.json
• node -e ... - skrypt dopisuje pole fingerprint (skrót z nazwy reguły, pliku i linii) i zapisuje raport gl-code-quality-report.json
• artifacts: reports: codequality - GitLab wczytuje raport i pokazuje znaleziska w merge requeście

Ważne: jeśli Codex się wywali albo zwróci niepoprawny JSON, job kończy się błędem, a nie pustym raportem. OpenAI w nocie do swojego przykładu wprost przestrzega, żeby nieudanego przebiegu nie traktować jak braku znalezisk. Jeśli na początek nie chcesz, żeby awaria Codexa blokowała pracę, dodaj do joba allow_failure: true - pamiętając, że brak raportu nie oznacza czystego kodu.

Zapisujesz plik, commitujesz i pushujesz. Przy następnym merge requeście GitLab uruchomi ten job automatycznie.

Krok 3: Uporządkuj wyniki skanów bezpieczeństwa (SAST)

Jeśli używasz skanera SAST (Static Application Security Testing) z GitLaba, możesz dodać Codex jako warstwę porządkującą. Podstawowy skaner SAST i raport gl-sast-report.json do pobrania są dostępne we wszystkich planach GitLaba. Codex nie skanuje kodu od zera - bierze istniejący raport, łączy duplikaty, układa znaleziska według ryzyka i opisuje, co naprawić najpierw.

Domyślnie skanery bezpieczeństwa GitLaba działają tylko w pipeline'ach gałęzi. Żeby działały w pipeline'ach merge requestów, ustaw zmienną AST_ENABLE_MR_PIPELINES na "true" (od GitLaba 18.0). Dodajesz szablon SAST, etap codex po etapie test (jeśli w pliku są już inne etapy, na przykład build i deploy, zostaw je) i nowy job:

include:
  - template: Jobs/SAST.gitlab-ci.yml

variables:
  AST_ENABLE_MR_PIPELINES: "true"

stages:
  - test
  - codex

codex_sast_priorytety:
  stage: codex
  image: node:24
  needs:
    - job: semgrep-sast
      artifacts: true
      optional: true
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_PROJECT_ID != $CI_PROJECT_ID'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $OPENAI_API_KEY'
  script:
    - npm install -g @openai/codex@0.162.1
    - |
      set -euo pipefail
      if [ ! -s gl-sast-report.json ]; then
        echo "Brak gl-sast-report.json - sprawdź, czy job SAST się uruchomił."
        exit 1
      fi
      klucz="$OPENAI_API_KEY"
      unset OPENAI_API_KEY
      CODEX_API_KEY="$klucz" codex exec \
        --sandbox read-only \
        --ephemeral \
        -m gpt-6.1-sol \
        -o priorytety-bezpieczenstwa.md \
        "Przeczytaj plik gl-sast-report.json (raport SAST z GitLaba).
        Połącz duplikaty (ten sam CWE i ta sama niebezpieczna funkcja albo ten sam
        wzorzec źródło-ujście). Uszereguj znaleziska według realnej możliwości
        wykorzystania: najpierw dane od użytkownika trafiające do niebezpiecznych
        funkcji w publicznie dostępnych miejscach. Wypisz tabelę priorytetów
        i 5 najpilniejszych działań z plikiem i linią. Opieraj się wyłącznie
        na dowodach z raportu. Odpowiedz po polsku, w formacie Markdown."
  artifacts:
    when: always
    paths:
      - priorytety-bezpieczenstwa.md
    expire_in: 14 days

Co się zmieniło?

• include: template: Jobs/SAST.gitlab-ci.yml - włącza skaner SAST GitLaba, który zapisuje raport gl-sast-report.json
• needs: semgrep-sast - job czeka na skaner Semgrep z szablonu i pobiera jego raport. optional: true sprawia, że pipeline nie wywali się na starcie, gdy skaner nie ruszy (np. brak plików w obsługiwanym języku) - wtedy job zakończy się czytelnym komunikatem
• -o priorytety-bezpieczenstwa.md - końcowa odpowiedź Codexa, czyli tabela priorytetów i lista działań, trafia do pliku
• artifacts: paths - plik pobierzesz z artefaktów joba w widoku pipeline'u

W przykładzie OpenAI jest też trzeci etap: Codex generuje dla każdej poważnej luki gotową łatkę w formacie git diff, a job sprawdza ją poleceniem git apply --check. Do takich zastosowań OpenAI ma dziś osobne narzędzie - Codex Security CLI z utrzymywanym przewodnikiem dla GitLab CI/CD. Skanuje zmiany w merge requestach, publikuje wyniki w formacie SARIF i może opcjonalnie otwierać szkice merge requestów ze sprawdzonymi poprawkami. Wymaga klucza API z dostępem do Codex Security, a wczytanie wyników do zakładki Security w GitLabie - planu Ultimate w wersji 19.2 lub nowszej.

Krok 4: Przetestuj pipeline na przykładowym projekcie

Żeby sprawdzić, czy wszystko działa, użyj celowo wadliwego projektu. Autorzy przykładu OpenAI wzięli szablon Node.js Express z GitLaba i dopisali do niego typowe błędy: command injection, path traversal, niebezpieczne eval, słabe hashowanie MD5 i klucze zapisane w kodzie. Do testu skanu bezpieczeństwa użyli OWASP Juice Shop - celowo dziurawej aplikacji Node.js.

Tworzysz projekt (z szablonu albo z własnym, celowo zepsutym kodem), dodajesz konfigurację z kroków 2-3 i tworzysz merge request.

Po zakończeniu pipeline'u zobaczysz:

• Wyniki Code Quality w merge requeście - lista znalezisk Codexa w raportach MR, także w darmowym planie. GitLab porównuje je z pipeline'em bazowym, więc widzisz, co jest nowe, a co naprawione
• Plik priorytety-bezpieczenstwa.md w artefaktach joba z kroku 3
• Znaleziska przy konkretnych liniach w widoku zmian - tylko w planie Ultimate; raport w szczegółach pipeline'u - w planach Premium i Ultimate

Jeśli coś nie działa, otwórz log joba (w widoku pipeline'u kliknij job). Najczęstsze problemy: job w ogóle się nie uruchomił, bo nie widzi klucza (patrz uwaga o chronionych zmiennych w kroku 1), Codex nie może uruchomić piaskownicy na runnerze albo nazwa pliku w artifacts nie zgadza się z tą, którą zapisuje skrypt.

Krok 5: Blokuj merge przy poważnych problemach (opcjonalnie)

Możesz skonfigurować GitLab tak, żeby nie pozwalał zmergować MR, gdy pipeline się nie powiedzie. W ustawieniach projektu (Settings → Merge requests, potrzebna rola Maintainer lub Owner) w sekcji Merge checks zaznaczasz Pipelines must succeed i zapisujesz. To ustawienie blokuje też merge, gdy dla MR nie ma żadnego pipeline'u.

Sam job Codexa możesz zaostrzyć tak, żeby kończył się błędem przy znaleziskach o wadze critical lub blocker. Na końcu skryptu node -e z kroku 2, po zapisaniu raportu, dopisz:

        if (raport.some((i) => i.severity === "critical" || i.severity === "blocker")) {
          console.log("Są znaleziska critical albo blocker - job kończy się błędem.");
          process.exit(1);
        }

Raport i tak trafi do GitLaba (artefakty z sekcji artifacts: reports GitLab zapisuje także po nieudanym jobie), a merge zostanie zablokowany do czasu poprawki.

Krok 6: Monitoruj koszty API

Przy logowaniu kluczem API każde uruchomienie Codexa jest rozliczane według zwykłego cennika API OpenAI. Koszt zależy od modelu i liczby tokenów. Stan na 13.10.2026: GPT-6.1 Sol kosztuje 2 USD za milion tokenów wejścia i 10 USD za milion tokenów wyjścia, GPT-6 Luna - 0,10 i 0,50 USD. Przykład rachunku (nie pomiar): przebieg, który zużyje 200 tys. tokenów wejścia i 10 tys. tokenów wyjścia, kosztuje na GPT-6.1 Sol około 0,40 + 0,10 = 0,50 USD.

Ile tokenów zużywa Twój job, sprawdzisz sam: z opcją --json polecenie codex exec wypisuje zdarzenia, a zdarzenie turn.completed zawiera liczbę tokenów wejścia i wyjścia.

Żeby nie przekroczyć budżetu:

1. Utwórz w panelu OpenAI osobny projekt i osobny klucz dla pipeline'u - dla projektu ustawisz własne limity zapytań i wydatków
2. Na stronie limitów ustaw alerty wydatków (mail po przekroczeniu kwoty) i, jeśli chcesz, twardy limit miesięczny - po jego osiągnięciu API przestaje obsługiwać zapytania, więc pipeline zacznie się wywracać
3. Uruchamiaj job tylko dla merge requestów i przekazuj Codexowi diff, a nie całe repozytorium
4. Pełne skany całego kodu uruchamiaj rzadziej, na przykład w harmonogramie

Jak to wygląda od strony programisty

Załóżmy, że jesteś deweloperem w zespole. Pracujesz nad nową funkcją, commitujesz kod i tworzysz merge request. Co się dzieje?

1. GitLab uruchamia pipeline - widzisz to w zakładce MR
2. Job Codexa analizuje diff Twojego MR - czas zależy od wielkości zmian i wybranego modelu
3. Dostajesz raport bezpośrednio w MR - sekcja Code Quality pokazuje znalezione problemy z plikiem, linią i opisem poprawki
4. Poprawiasz kod, commitujesz - pipeline uruchamia się ponownie
5. Naprawiony problem znika z listy nowych znalezisk - możesz mergować

Całość wygląda jak zwykły code review, tylko że część uwag generuje AI zamiast człowieka. Reviewer może skupić się na logice biznesowej zamiast łapać oczywiste błędy typu "zapomniałeś walidacji inputu".

Prostsza droga: recenzje Codexa w GitLabie bez własnego pipeline'u

Jeśli nie potrzebujesz raportu w formacie Code Quality, możesz w ogóle nie pisać joba. Codex ma integrację z GitLabem (stan na 13.10.2026 w wersji beta, dostępna we wszystkich planach ChatGPT): łączysz konto GitLab w ustawieniach Codexa, a w komentarzu do merge requesta wpisujesz @codex review. Codex czyta diff, stosuje zasady z plików AGENTS.md w repozytorium i dodaje uwagi do MR jak członek zespołu. Można też włączyć automatyczne recenzje (np. przy otwarciu MR albo przy każdym pushu), a komentarzem w rodzaju @codex fix the P1 issue poprosić o poprawkę. Dla GitLab.com potrzebne jest środowisko projektu w Codex Cloud, a ta integracja działa w chmurze Codexa, nie na Twoim runnerze.

Lokalnie, przed wypchnięciem zmian, zrobisz podobną recenzję poleceniem codex review --base main - Codex porówna Twoją gałąź z gałęzią main i wypisze znaleziska bez zmieniania plików.

Co zrobić, jeśli Codex znajdzie fałszywy alarm

Żadne narzędzie nie jest idealne - Codex też czasem zgłasza problem, którego nie ma. Na przykład oznacza coś jako "potencjalny SQL injection", a Ty wiesz, że ten kod nigdy nie dostanie zewnętrznego inputu.

Masz trzy opcje:

1. Dopisz zasady do pliku AGENTS.md - Codex czyta pliki AGENTS.md z repozytorium przed rozpoczęciem pracy, także w codex exec. To najlepsze miejsce na wyjątki dla całego projektu
2. Doprecyzuj polecenie w jobie - prompt w .gitlab-ci.yml jest Twój. Możesz dopisać, czego nie zgłaszać albo jakie katalogi pominąć
3. Dodaj komentarz w kodzie - np. // bezpieczne: dane są walidowane w middleware. Codex czyta kod, więc to dla niego dodatkowy kontekst, ale nie gwarancja, że pominie znalezisko

Przykładowy fragment AGENTS.md w głównym katalogu repo:

## Code Review Rules

- Katalog src/legacy/ przepisujemy w tym kwartale - nie zgłaszaj tam uwag o stylu.
- MD5 w src/utils/checksum.js służy tylko do sum kontrolnych plików, nie do haseł.

Nagłówek ## Code Review Rules to sekcja, której Codex szuka przy recenzjach w GitLabie - przy codex exec cały plik trafia do instrukcji, więc Codex dostanie te zasady w obu przypadkach.

Najczęstsze pytania

Czy Codex CLI działa z innymi platformami CI/CD niż GitLab?

Tak, codex exec uruchomisz w każdym systemie CI/CD, który potrafi wykonać skrypt w kontenerze, np. w Jenkinsie czy CircleCI - zmienia się tylko składnia konfiguracji. Wyjątek to GitHub Actions: tam OpenAI zaleca gotową akcję openai/codex-action zamiast samodzielnej instalacji CLI i przekazywania klucza do skryptu, bo akcja ogranicza ekspozycję klucza API.

Ile czasu zajmuje skanowanie dużego projektu?

To zależy od wielkości zmian, wybranego modelu i poziomu rozumowania - zmierz to na swoim projekcie, czas joba widać w GitLabie. Żeby skrócić czas i koszt, przekazuj Codexowi tylko diff merge requesta (jak w kroku 2), a pełne skany repozytorium uruchamiaj rzadziej, na przykład w nocnym harmonogramie. Codex nie ma do tego specjalnej opcji - zakres ustalasz tym, co mu przekażesz i o co poprosisz.

Czy mój kod jest wysyłany do OpenAI?

Tak, Codex CLI wysyła fragmenty kodu do API OpenAI do analizy. OpenAI deklaruje w dokumentacji (Your data), że od 1 marca 2023 roku dane wysłane przez API nie są używane do trenowania ani ulepszania modeli, chyba że wyraźnie się na to zgodzisz. Domyślnie OpenAI przechowuje je w logach monitorowania nadużyć do 30 dni; zatwierdzeni klienci mogą wnioskować o Zero Data Retention albo Modified Abuse Monitoring. Jeśli pracujesz z wrażliwym kodem (np. w branży finansowej lub medycznej), sprawdź te ustawienia i umowy Twojej firmy z OpenAI albo rozważ model lokalny - Codex CLI z opcją --oss korzysta z modeli uruchomionych w Ollama lub LM Studio.

Czy mogę używać Codex CLI z innymi modelami niż GPT?

Tak. W pliku config.toml możesz zdefiniować własnego dostawcę modeli (sekcja [model_providers.nazwa] z adresem base_url i nazwą zmiennej z kluczem), a Codex ma też wbudowane wsparcie dla Amazon Bedrock i lokalnych modeli przez --oss (Ollama, LM Studio). Dostawca musi udostępniać punkt końcowy zgodny z Responses API - według dokumentacji Codexa obecne wersje nie obsługują dostawców oferujących tylko Chat Completions - więc sprawdź to przed konfiguracją. Przykład: DeepSeek publikuje oficjalną instrukcję podłączenia do Codexa modeli deepseek-flash (V4.1 Flash) i deepseek-v4-pro. W opisie konfiguracji dostawców w dokumentacji Codexa nie ma przykładu dla modeli Anthropic ani Google (stan na 13.10.2026). Różne modele mają różną jakość analizy kodu, a rankingi (np. SWE-bench Pro - OpenAI od lutego 2026 nie ocenia już modeli na SWE-bench Verified, bo uznało go za zanieczyszczony) zmieniają się z każdą premierą - zamiast polegać na zestawieniach, porównaj dwa-trzy modele na kilku własnych merge requestach.

Co jeśli mój zespół nie chce używać AI w code review?

To uczciwa obawa. Niektórzy deweloperzy czują się niekomfortowo z ideą "AI ocenia mój kod". Kilka rzeczy, które warto podkreślić: po pierwsze, Codex to narzędzie wspomagające, nie zastępujące ludzi - ostateczną decyzję o merge zawsze podejmuje człowiek. Po drugie, możesz uruchomić Codex tylko jako informacyjny raport (z allow_failure: true, bez blokowania merge'a) i dać zespołowi czas na oswojenie się. Po trzecie, warto pokazać konkretne przykłady, gdzie Codex złapał rzeczywisty bug, który przeszedłby przez code review - to przekonuje lepiej niż argumenty teoretyczne.

Jeden krok na start

Codex CLI to narzędzie, które dodaje warstwę rozumowania do automatycznych skanów kodu. Zamiast dostawać setki niezrozumiałych alertów, dostajesz posortowane problemy z krokami naprawy. Integracja z GitLab to kilka kroków: dodanie klucza API, schemat odpowiedzi i job w .gitlab-ci.yml, opcjonalne porządkowanie wyników SAST, test na celowo wadliwym projekcie, blokada merge'a i kontrola kosztów.

Jeśli chcesz to przetestować bez ryzyka, zacznij od małego projektu testowego z celowo wadliwym kodem. Uruchom jeden merge request, zobacz, jak wygląda raport, sprawdź w panelu OpenAI, ile kosztował przebieg, i zdecyduj, czy to ma sens dla Twojego zespołu.

Skopiuj schemat i job z kroku 2, dodaj klucz API w Settings → CI/CD → Variables i stwórz testowy merge request. Jeśli wolisz zacząć bez konfiguracji pipeline'u - połącz GitLab z Codexem i wpisz w MR komentarz @codex review.