Codex CLI: Kompletny przewodnik techniczny

W skrócie: Codex to wieloplatformowy agent programistyczny: odczytuje bazę kodu, uruchamia polecenia w piaskownicy na poziomie systemu operacyjnego, modyfikuje pliki i deleguje zadania do chmury. Opanowanie pięciu systemów — config.toml, modelu piaskownicy i zatwierdzania, AGENTS.md, MCP oraz skills — pozwala uczynić z niego potężne narzędzie zwiększające produktywność. GPT-5.6 Sol jest zalecanym modelem domyślnym (ustawienie „Power”, średni poziom rozumowania); GPT-5.5, flagowy model poprzedniej generacji, oferuje w Codex okno kontekstowe 400K, a w API — 1M.⁸³¹¹⁷ To pierwszy kontakt z tym narzędziem? Warto przejść bezpośrednio do sekcji Instalacja i Szybki start. Śledzi Pan/Pani wydania? Najnowsza stabilna wersja to v0.153.2 (3 września 2026)¹⁴⁰¹⁴³ — opis ostatnich wersji znajduje się w sekcji Najważniejsze zmiany w wydaniach, a wszystkie aktualizacje — w Dzienniku zmian.¹¹⁶

Codex działa jako wieloplatformowy agent programistyczny, a nie chatbot piszący kod. CLI odczytuje bazę kodu, wykonuje polecenia w piaskownicy, modyfikuje pliki, łączy się z usługami zewnętrznymi za pośrednictwem MCP i deleguje długotrwałe zadania do chmury. Działa lokalnie, ale myśli globalnie; ta sama inteligencja napędza pięć odrębnych środowisk dostosowanych do różnych sposobów pracy, w tym rozszerzenie przeglądarki (Chrome, Edge, Brave, Opera i Vivaldi), które uruchamia Codex w przeglądarce bez przejmowania nad nią kontroli.⁹⁰¹²⁷

Różnica między sporadycznym a efektywnym korzystaniem z Codex sprowadza się do pięciu podstawowych systemów. Ich opanowanie pozwala uczynić z Codex potężne narzędzie zwiększające produktywność:

1. System konfiguracji: steruje działaniem za pomocą config.toml
2. Model piaskownicy i zatwierdzania: wyznacza zakres działań dostępnych dla Codex
3. AGENTS.md: określa zasady działania na poziomie projektu
4. Protokół MCP: rozszerza możliwości o usługi zewnętrzne
5. System skills: gromadzi wiedzę dziedzinową wielokrotnego użytku

Przez wiele miesięcy korzystałem z Codex równolegle z Claude Code w produkcyjnych bazach kodu, potokach CI/CD i przepływach pracy zespołów. Niniejszy przewodnik przekłada te doświadczenia na kompletne kompendium, którego brakowało mi na początku. Każdą funkcję przedstawiono z rzeczywistą składnią, praktycznymi przykładami konfiguracji oraz przypadkami brzegowymi, które sprawiają trudność nawet doświadczonym użytkownikom.

Najważniejsze informacje

• Pięć interfejsów, jeden mózg: CLI, aplikacja desktopowa, rozszerzenie IDE, zadania w chmurze oraz rozszerzenie przeglądarki (Chrome, Edge, Brave, Opera i Vivaldi) korzystają z tej samej inteligencji GPT-5.x-Codex, dlatego warto wybrać interfejs najlepiej pasujący do danego sposobu pracy.⁹⁰
• Izolacja na poziomie systemu operacyjnego: Codex egzekwuje ograniczenia systemu plików i sieci na poziomie jądra (Seatbelt w macOS, Landlock + seccomp w systemie Linux), a nie wewnątrz kontenerów.
• AGENTS.md działa w wielu narzędziach: instrukcje projektu działają w Codex, Cursor, Copilot, Amp, Jules, Gemini CLI, Windsurf, Cline, Aider, Zed oraz ponad 60 000 projektów open source. Wystarczy napisać je raz, aby korzystać z nich wszędzie.
• Profile ograniczają narzut związany z przełączaniem kontekstu: można zdefiniować nazwane zestawy ustawień (fast, careful, auto) i przełączać się między nimi za pomocą --profile.
• Zarządzanie kontekstem ma znaczenie: rodzina GPT-5.6 (Sol, Terra, Luna) korzysta z okna kontekstowego o rozmiarze 272K; GPT-5.5, flagowy model poprzedniej generacji, udostępnia 400K w Codex i 1M w API. Aby aktywnie zarządzać budżetem tokenów, warto korzystać z /compact, precyzyjnych promptów i odwołań @file.⁸³¹¹²

Jak korzystać z tego przewodnika

Ten przewodnik liczy ponad 3 300 wierszy — warto zacząć od sekcji odpowiadającej poziomowi doświadczenia:

Na końcu znajduje się Podręczna karta referencyjna, która zawiera łatwe do przejrzenia podsumowanie wszystkich najważniejszych poleceń.

Najważniejsze zmiany w wydaniach: co zmieniło się ostatnio

Opis zmian w kolejnych wersjach dla osób śledzących cykl wydań Codex. Jeśli korzystają Państwo z niego po raz pierwszy, warto pominąć tę część i wrócić do niej po sekcji Szybki start — żadna z zawartych tu informacji nie jest potrzebna, aby rozpocząć efektywną pracę.

GPT-5.6 Sol jest zalecanym modelem domyślnym w Codex — odpowiada domyślnemu ustawieniu „Power” ze średnim poziomem rozumowania, który można zmienić na Smarter lub Faster; GPT-5.5 (23 kwietnia 2026: kontekst 400K w Codex, 1M w API, 5/30 USD za MTok, wynik 82,7% i SOTA w Terminal-Bench 2.0) jest flagowym modelem poprzedniej generacji.⁸³¹¹⁷ v0.153.1 i v0.153.2 (3 września 2026) to stabilne poprawki wydane tego samego dnia; npm latest wskazuje teraz wersję 0.153.2. Najważniejszej zmiany w v0.153.1 nie wymieniono w treści wydania i można ją potwierdzić wyłącznie przez porównanie rust-v0.153.0…rust-v0.153.1: ocenianie korzystania z komputera przez Guardian respektuje teraz wymagania modelu — ocenianie przez Guardian ograniczone do korzystania z komputera oraz szybkie decyzje dotyczące zatwierdzania są uruchamiane tylko wtedy, gdy aktywny model ustawia node_repl_auto_review_required, a wcześniejsze lub trwające oceny są unieważniane, gdy po zmianie modelu ocenianie zostaje pominięte. Dzięki temu powrót do wcześniej sprawdzonego modelu nie może przywrócić nieaktualnej decyzji o zatwierdzeniu. Wymieniona zmiana w v0.153.1 przenosi wstecz wpis katalogowy modelu GPT-6-Astra, konfigurowalny wyłącznie przez API — to przygotowanie katalogu, a nie premiera: model domyślny i selektor modeli pozostają bez zmian. v0.153.2 zawiera jedną poprawkę kosmetyczną, zmieniającą opis warstwy GPT-6-Astra Fast z „1.5x” na „2x speed, increased usage” — dotyczy to wyłącznie wyświetlanego tekstu. Żadna z obserwowanych zmian z 0.154.0-alpha nie została włączona w porównaniu rust-v0.153.0…rust-v0.153.2; stabilna wersja różni się od 0.153.0 dokładnie tymi trzema zmianami.¹⁴²¹⁴³ Od CLI v0.153.0 (wersja stabilna, 3 września 2026) tryb Vim obsługuje cofanie i ponawianie zmian — u cofa, a Ctrl+R ponawia całe wersje robocze w edytorze, w tym wklejoną zawartość i załączone obrazy, z pogrupowanymi krokami edycji oraz konfigurowalną akcją mapowania klawiszy vim_normal.redo — plugin CLI może wyświetlać, instalować i usuwać pluginy ze zdalnych marketplace’ów (wpisy zdalnego katalogu pojawiają się w codex plugin list wraz ze źródłem, wersją, zasadami instalacji i zasadami uwierzytelniania w danych wyjściowych JSON), tui.auto_recap = false wyłącza automatyczne podsumowania, zachowując możliwość ręcznego użycia /recap, a plany Plus i Team wcześniej ostrzegają o zbliżeniu się do limitu, gdy w około pięciogodzinnym oknie wykorzystania pozostaje mniej niż połowa puli (w pozostałych planach nadal obowiązują progi 75/90/95%). Zakres Guardian zależy teraz od trybu zatwierdzania: Full Access pomija weryfikację przez Guardian w przypadku działań wymagających jedynie potwierdzenia, natomiast tryb zatwierdzania przez użytkownika pomija działające w tle ocenianie i wstępne rozgrzewanie Guardian, zachowując dotychczasową obsługę kontroli działań wrażliwych i próśb o dane od użytkownika. Nowa powierzchnia konfiguracji features.context_management.experimental_mode (domyślnie wyłączona) aktywuje kontekst z budżetem tokenów, notatki historii i narzędzie new_context w kwalifikujących się sesjach ChatGPT Plus, Pro i Pro Lite korzystających z backendu Codex — nadal wykluczone są sesje z kluczem API, niestandardowi dostawcy i tymczasowe wątki strukturalne — a tui.disable_paste_burst zastępuje klucz najwyższego poziomu (stara lokalizacja nadal działa awaryjnie). Poprawki: sesje TUI łączą się ponownie po zerwaniu zewnętrznego połączenia app-server, zachowując wersje robocze i transkrypcje; historia weryfikacji Guardian przetrwa kompakcję, ponowne uruchomienia i rozwidlenia utworzone przez użytkownika; zapamiętane zatwierdzenia narzędzi MCP są ograniczone do wybranego konta aplikacji, a względne ścieżki plików wykonywalnych MCP uruchamiają się niezawodniej w macOS; kompresja wdrożenia obejmuje wspólne historie; metadane wątku app-server otrzymują dopuszczające wartość null pola model i reasoningEffort oraz ustrukturyzowane pytania asynchroniczne przez request_user_input_async, jeśli katalog modeli włącza tę funkcję.¹⁴⁰ Od CLI v0.152.0 (wersja stabilna, 1 września 2026) wydano całą trzynastoelementową listę obserwacyjną 0.152-alpha — z jednym odwróceniem: update_plan trafił do wydania jako funkcja opcjonalna, a nie domyślnie włączona. Stan końcowy określa #41744 „Make the update_plan tool opt-in”: tools.update_plan.enabled ma domyślną wartość false, a gdy narzędzie jest wyłączone, dołączone wskazówki dotyczące update_plan są usuwane z promptów modelu, trybu współpracy, trybu wielu agentów, kompakcji, wstępnego rozgrzewania i kontynuacji celów (zob. Tryb planu i współpraca). Pozostałe elementy wydania to: ruchy wyszukiwania Vim (lokalne dla wersji roboczej wyszukiwanie dosłowne za pomocą / i ?, z podświetlonymi dopasowaniami oraz powtarzaniem nawigacji klawiszami n/N, które można łączyć z operatorami c/d/y; nowe wersje robocze Vim zaczynają teraz w trybie Insert), banery limitów użycia z dostępnymi działaniami w TUI (sprawdzenie wykorzystania, zarządzanie kredytami, resetowanie limitów i zarządzanie planami, z filtrowaniem według uwierzytelnionego konta), postęp odświeżania danych uwierzytelniających w TUI i codex exec, w tym ponowne uwierzytelnianie Amazon Bedrock, nazwy serwerów MCP w stylu nazw pakietów (:, @, / i . są teraz dozwolone, dzięki czemu nazwy takie jak npm:@modelcontextprotocol/server-sequential.thinking działają w poleceniach CLI, przestrzeniach nazw narzędzi środowiska uruchomieniowego i wyszukiwaniu danych uwierzytelniających OAuth), żądania formularzy MCP openai/elicitation, output_token_limit konfigurowany osobno dla każdego narzędzia MCP, z obcinaniem działającym spójnie po wznowieniu sesji, ograniczenie danych uwierzytelniających zadań w chmurze do zaufanych źródeł przy wyłączonych przekierowaniach, konfigurowalne limity czasu thread/shellCommand, również dłuższe niż godzina, oraz domyślnie włączone budżetowanie tokenów na podstawie metadanych modelu. v0.152.1 (1 września) to stabilna poprawka jednego błędu: weryfikacja zatwierdzeń Guardian pobiera zasady Node REPL z metadanych modelu.¹³⁸¹³⁹ Od CLI v0.151.0 (wersja stabilna, 29 sierpnia 2026) wydano całą listę obserwacyjną cyklu 0.150-alpha — przy czym treść wydania NIE opisuje całego wydania: wymienia tylko PR-y #41183–#41209 utworzone po odcięciu gałęzi, podczas gdy porównanie rust-v0.150.1…rust-v0.151.0 obejmuje 164 commity bez żadnych wycofań (wersja stabilna znajduje się o jeden commit za 0.151.0-alpha.6, a tym jednym commitem jest zmiana numeru wersji samej alphy). Wprowadzono wszystkie dziesięć obserwowanych elementów: /recap podsumowuje bieżącą rozmowę na żądanie, a Codex automatycznie generuje takie samo podsumowanie dla kwalifikujących się rozmów, które są bezczynne i nieaktywne, hosty trybu kodu rezygnują z transportu WebSocket (pozostają tylko stdio i gRPC; WebSocket jest dostępny wyłącznie jako opcjonalny strumień surowych śladów OTLP), trwałe wątki domyślnie korzystają ze stronicowanej historii, jeśli ich magazyn obsługuje stronicowane API (wątki efemeryczne i nieobsługujące magazyny pozostają przy starszym mechanizmie), pojawia się poziom rozumowania persistent wraz z narzędziami zegara i dołączonymi wskazówkami dotyczącymi proaktywności, domyślne ustawienia Guardian v2 przechodzą na weryfikację korzystania z komputera z obrazami, Vim otrzymuje ruchy wyszukiwania i dojścia f/F/t/T oraz skoki gg/G w buforze, app server przyjmuje aktualizacje ustawień działające na żywo w zakresie tury, w tym nadpisanie warstwy usługi dla pojedynczej tury, dodano parser ustawień worktree i metadane własności wątku dla zarządzanych worktrees, konfiguracja Amazon Bedrock dołącza do wdrażania w TUI (za flagą funkcji), a wprowadzanie danych do terminali z podwyższonymi uprawnieniami może wymagać ponownego zatwierdzenia (write_stdin_approval, domyślnie wyłączone, z limitem 8 000 bajtów sprawdzanych danych wejściowych). Własne dodatki wydania: konfigurowalny okres karencji na wykrywanie narzędzi z opcjonalnych serwerów MCP (mcp_optional_startup_grace_ms, domyślnie 1 000 ms), rozszerzenia mogą sprawdzać lub zastępować wyniki narzędzi MCP, zanim trafią one do modelu, oraz katalogi pluginów łączą konfigurację poszczególnych repozytoriów, zgłaszając nieprawidłowe marketplace’y projektu bez ukrywania prawidłowych pluginów; poprawki utrzymują właściwą dostępność narzędzi i poziom rozumowania podczas zmian modeli i przełączania awaryjnego, ulepszają egzekwowanie zdalnej piaskownicy przy użyciu rzeczywistego katalogu domowego, systemu operacyjnego i konwencji ścieżek executora, wliczają użycie tokenów przez zagnieżdżonych subagentów do budżetów celów agenta głównego, uniemożliwiają nieaktualnym klasyfikacjom Guardian autoryzowanie działań po zmianie uprawnień oraz zapobiegają osłabianiu ograniczeń piaskownicy przez /cd, zachowując przywrócone profile uprawnień.¹³⁴¹³⁵ Od CLI v0.150.0 (wersja stabilna, 26 sierpnia 2026) hooks obsługują zdarzenie Interrupt — dwunasty wpis w HOOK_EVENT_NAMES, uruchamiający polecenia lub procedury obsługi MCP po przerwaniu aktywnej tury najwyższego poziomu (domyślny limit czasu 1 sekunda, maksymalnie 3 sekundy, nigdy dla subagentów) — /copy otwiera selektor obejmujący pełną odpowiedź, poszczególne bloki kodu i cytaty blokowe, zadania stają się dostępne z terminala (można odwoływać się do innych zadań Codex za pomocą wzmianek @, pozwalać agentom odczytywać, tworzyć lub wysyłać wiadomości do zadań oraz automatycznie nadawać opisowe tytuły zadaniom bez nazwy, przy czym /rename proponuje edytowalną nazwę), linki Markdown są renderowane jako klikalne etykiety w obsługiwanych terminalach, skróty mogą przełączać tryby uprawnień, a tryb Vim otrzymuje powtarzanie za pomocą ., natomiast niezaufane projekty nie dostarczają już instrukcji z pliku AGENTS.md na poziomie projektu; features.network_proxy.credential_broker oraz review_scope.computer_use_only w Guardian v2 są dostępne jako konfigurowalne, domyślnie wyłączone funkcje (v0.151.0 później domyślnie włączyła ustawienia Guardian v2). Wydanie naprawia również redagowanie danych uwierzytelniających app-server, zdalne wyszukiwanie tokenów bearer MCP i uruchamianie wymaganych serwerów, piaskownicę Windows z podwyższonymi uprawnieniami dla ścieżek użytkownika zawierających znaki Unicode, zawieszanie zamykania systemu Unix przez odłączone procesy oraz zgodność kompakcji Amazon Bedrock z trybem wielu agentów.¹³² v0.150.1 (27 sierpnia) to poprawka jednego błędu (npm latest do wydania v0.151.0): zdalna kompakcja domyślnie uwzględnia teraz zachowane obrazy w swoim budżecie tokenów, usuwając w razie potrzeby starsze obrazy — domyślne zachowanie z 0.151-alpha (#40994) przeniesiono wstecz do wersji stabilnej (#41003).¹³³ Od CLI v0.149.0 (wersja stabilna, 20 sierpnia 2026) zasada zatwierdzania untrusted została wycofana — konfiguracje, które nadal jej używają, należy zmienić na on-request — a wydanie przenosi do wersji produkcyjnej całą listę obserwacyjną alphy: interaktywny pulpit codex agents (wyszukiwanie, uruchamianie, otwieranie, zmiana nazw i zatrzymywanie zadań, z konfigurowalnymi skrótami), /cd, /pwd i /cwd do zarządzania katalogiem roboczym w sesjach TUI, codex queue do wysyłania wiadomości do istniejących sesji lokalnych lub zdalnych, rozszerzone ruchy zmiany w Vim (cw, c$, cc, zastępowanie znaków), codex doctor, który diagnozuje teraz ochronę punktów końcowych, awarie sieci/proxy, stan aplikacji komputerowej i łączność z usługą aktualizacji, a także poziomy rozumowania max/ultra w SDK z dokładnymi nadpisaniami konfiguracji CLI; wznowione i rozwidlone wątki przywracają również aktywny profil uprawnień, zamiast po cichu wracać do ustawień domyślnych. v0.149.1 (24 sierpnia) to stabilna poprawka obejmująca pięć commitów, która dodaje codex exec --thread-source <SOURCE> (klasyfikowanie nowo utworzonych lub rozwidlonych wątków jako user, subagent, memory_consolidation albo nazwa funkcji; domyślnie user; threadSource w TypeScript SDK) wraz z przeniesionymi wstecz zmianami dotyczącymi kompakcji obrazów w sesjach zdalnych i konsolidacji pamięci; była to wersja npm latest aż do v0.150.1.¹²⁰¹²⁶ Niezależnie od tego OpenAI obniżyło cenę GPT-5.6 Sol o ponad 20% na trzy miesiące od 21 sierpnia (co najmniej do 21 listopada 2026) — spadły zarówno ceny API, jak i zużycie kredytów Codex; opublikowana tabela stawek kredytowych podaje teraz dla Sol 100 kredytów za 1M tokenów wejściowych (10 za buforowane, 500 za wyjściowe), zamiast 125/12,5/750.¹²¹ Od CLI v0.148.0 (wersja stabilna, 18 sierpnia 2026) kompletne rozmowy TUI można eksportować do Markdown za pomocą /export (do schowka lub nowego pliku), codex exec fork rozwidla sesje z poziomu wiersza poleceń, a selektor wznawiania w TUI umożliwia ich archiwizowanie i przywracanie, /status, wiersze stanu i tytuły terminala pokazują szacowane kredyty lub koszt wątku w kwalifikujących się obszarach roboczych, Amazon Bedrock Runtime staje się wbudowanym dostawcą (obsługa profilu i regionu AWS oraz trasowania GPT-5.6), hooks mogą asynchronicznie uruchamiać polecenia i wywoływać narzędzia MCP, a ograniczenia piaskownicy blokują teraz operacje w razie odmowy dostępu lub nieczytelnych ścieżek zarówno w systemie Linux, jak i Windows; TUI przyjmuje również przygotowane prompty podczas inicjalizacji.¹¹⁸ Od CLI v0.147.0 (wersja stabilna, 7 sierpnia 2026) usunięto codex exec --full-auto (przestarzałe od v0.128) — skrypty, które nadal przekazują tę opcję, zgłaszają teraz błąd; należy zastąpić ją przez --sandbox workspace-write wraz z flagą zatwierdzania lub profilem. v0.147.0 wprowadza także --approve-for-me (prompty o zatwierdzenie są rozstrzygane przez automatyczną weryfikację), przenośne Agent Plugins z wyszukiwaniem w katalogach lokalnych, osobistych, obszaru roboczego i zdalnych, opcjonalny protokół MCP 2026-07-28 (stronicowane wykrywanie, żądania wieloetapowe, nieblokujące uruchamianie serwera) oraz sekcje rozmów służące do porządkowania długich transkrypcji.¹¹⁶ v0.146.0 (wersja stabilna, 29 lipca) rozszerzyła działanie skonfigurowanych proxy na wszystkie warstwy transportu, dodała manifesty Agent Plugins oraz marketplace’y Amazon Bedrock i Claude Code, nazewnictwo sesji z przypinaniem wątków i skills dostarczane przez executor; v0.146.1 (5 sierpnia) zaostrzyła domyślne ustawienia automatycznej weryfikacji dla modeli zdolnych do działań cybernetycznych.¹¹⁴¹¹⁵ Od CLI v0.145.0 (wersja stabilna, 21 lipca 2026) /import umożliwia migrację zarówno z Cursor, jak i Claude Code — ustawień, serwerów MCP, pluginów, sesji, poleceń i pamięci o zakresie projektu — obsługa głosu powraca w postaci strumieniowanych rozmów realtime V3 z dźwiękowymi danymi wejściowymi i wynikami narzędzi audio w popularnych formatach lokalnych, ustabilizowano opcjonalny tryb wielu agentów v2 z konfigurowalnymi modelami subagentów, poziomami rozumowania i współbieżnością, eksperymentalna stronicowana historia wątków usprawnia wznawianie, wyszukiwanie, zachowywanie nazw, obsługę subagentów i pamięci, udostępniono eksperymentalne logowanie Amazon Bedrock z obsługą niestandardowego punktu końcowego i uwierzytelniania (GPT-5.6 Sol jako domyślny model Bedrock), a dołączone wybory modeli GPT-5.4 przeniesiono na warianty GPT-5.6 Terra i Luna; v0.144.6 (18 lipca) skorygowała okna kontekstu GPT-5.6 Sol/Terra/Luna do 272 000 tokenów.¹¹¹¹¹² Od CLI v0.140.0 (wersja stabilna, 15 czerwca 2026) /usage pokazuje dzienną, tygodniową i łączną aktywność tokenów na koncie, sesje można trwale usuwać za pomocą codex delete / /delete (z zabezpieczeniami wymagającymi potwierdzenia), /import selektywnie przenosi konfigurację, konfigurację projektu i ostatnie rozmowy z Claude Code, wpisanie @ domyślnie otwiera ujednolicone menu wzmianek dotyczących plików, pluginów i skills, a zarządzane uwierzytelnianie Amazon Bedrock za pomocą klucza API jest dostępne wraz z szyfrowanym magazynem lokalnym dla danych uwierzytelniających OAuth używanych przez CLI i MCP; eksperymentalne sterowanie głosowe /realtime usunięto z TUI (obsługa głosu wróciła później w v0.145.0 jako strumieniowane realtime V3).¹⁰²¹¹² Od CLI v0.139.0 (wersja stabilna, 9 czerwca 2026) tryb kodu może bezpośrednio wywoływać samodzielne wyszukiwanie internetowe (również z zagnieżdżonych wywołań narzędzia JavaScript) i otrzymywać wyniki w zwykłym tekście, schematy danych wejściowych narzędzi i connectorów zachowują teraz konstrukcje oneOf/allOf, co poprawia zgodność z dużymi schematami i MCP, codex doctor dodaje szczegóły środowiska edytora i pagera (redagując poufne wartości w JSON), a marketplace pluginów udostępnia źródła w codex plugin marketplace list --json i szybciej wyświetla katalog dzięki pamięci podręcznej.¹⁴⁹ v0.138.0 (8 czerwca) dodała /app, które przekazuje sesję CLI do aplikacji komputerowej w systemach macOS i Windows, udostępniła modelowi lokalne ścieżki obrazów, uelastyczniła wybór poziomu rozumowania i zapewniła automatyzacji pluginów ustrukturyzowane dane wyjściowe JSON; rozpoczęła także szyfrowanie treści zadań przesyłanych od agenta nadrzędnego do subagenta w trybie wielu agentów v2, dzięki czemu instrukcje delegowania nie pojawiają się już w postaci zwykłego tekstu w lokalnych dziennikach sesji (zob. Wiele agentów).¹⁵⁰¹⁰⁸ v0.137.0 (4 czerwca) wprowadziła tryb wielu agentów v2 (środowisko uruchomieniowe zachowywane dla każdego wątku, przejrzystsze działania uzupełniające i domyślne metadane, domyślnie hide_spawn_agent_metadata ustawione na true), skróty klawiszowe TUI F13–F24 oraz rozszerzenie skills v1 z rozpoznawaniem katalogu dla każdej tury.¹⁵¹ Od CLI v0.135.0 (28 maja 2026) codex doctor zgłasza bardziej szczegółowe informacje o środowisku, Git, terminalu, app-server i spisie wątków; /status pokazuje szczegóły połączenia zdalnego oraz wersję serwera, gdy TUI jest połączony zdalnie; tryb vim otrzymał edycję obiektów tekstowych, ulepszone zachowanie słów i końców wierszy oraz konfigurowalne przerywanie tury; /permissions rozpoznaje teraz nazwane profile uprawnień i wyświetla profile niestandardowe; spakowane kompilacje Codex wykrywają i wykorzystują dołączony, zmodyfikowany moduł pomocniczy zsh w obsługiwanych systemach macOS; a Python SDK udostępnia przyjazne ustawienia wstępne Sandbox dla API wątków i tur.¹⁵³ v0.134.0 (26 maja 2026) wprowadziła wyszukiwanie w lokalnej historii rozmów z dopasowaniem zawartości bez uwzględniania wielkości liter i podglądem wyników, uczyniła --profile głównym selektorem profilu w CLI, uprawnieniach TUI i przepływach piaskownicy (starsze konfiguracje profili są odrzucane wraz ze wskazówkami dotyczącymi migracji), ulepszyła konfigurację MCP dzięki określaniu środowiska dla każdego serwera oraz opcjom OAuth dla serwerów streamable HTTP, zwiększyła niezawodność schematów narzędzi connectorów przez zachowywanie lokalnych $ref/$defs i kompresowanie zbyt dużych schematów, umożliwiła współbieżne uruchamianie narzędzi MCP tylko do odczytu, gdy deklarują readOnlyHint, oraz dodała bogatszy kontekst rozszerzeń i hooks, w tym historię rozmowy dla narzędzi rozszerzeń.¹⁰¹ v0.133.0 (21 maja 2026) domyślnie włączyła cele wraz z dedykowanym magazynem i śledzeniem postępu; codex remote-control otrzymał gotowość i stan pracy na pierwszym planie oraz uruchamianie i zatrzymywanie w stylu demona; profile uprawnień otrzymały listy API, dziedziczenie, zarządzany plik requirements.toml, odświeżanie w czasie działania oraz silniejszą integrację z piaskownicą Windows; wykrywanie pluginów pokazuje zainstalowane wersje, katalogi główne marketplace’ów i zdalne kolekcje; rozszerzenia mogą obserwować uruchamianie i zatrzymywanie subagentów, wykonywanie narzędzi, metadane tur oraz asynchroniczną obsługę zatwierdzeń i tur. Aktualizacja aplikacji Codex z 21 maja dodała Appshots dla aktywnych okien Mac, ogólną dostępność trybu Goal w aplikacji/IDE/CLI, ulepszenia adnotacji w przeglądarce wewnątrz aplikacji oraz opcjonalny, zablokowany tryb Computer Use dla kwalifikujących się użytkowników Mac.⁹⁹¹⁰⁰ v0.132.0 (20 maja 2026) dodała uwierzytelnianie pierwszej klasy Python SDK, prostsze tekstowe API tur, bogatszy TurnResult, codex exec resume --output-schema, szybsze uruchamianie TUI, rejestrację zdalnego executora opartą na uwierzytelnianiu oraz zachowanie wierności obrazów w turach app-server. Należy używać jawnych flag piaskownicy i zatwierdzania lub profili uprawnień — starsze --full-auto usunięto w v0.147.0; js_repl pozostaje usunięte.^{86878991969798116}

Uwaga dotycząca stabilności: Funkcje oznaczone jako [EXPERIMENTAL] lub under development mogą zmieniać się między wydaniami. Od v0.133.0 (21 maja 2026) cele są domyślnie włączone, profile uprawnień stanowią pełnoprawną zarządzaną powierzchnię, wykrywanie pluginów zapewnia lepszy wgląd, a remote-control można łatwiej uruchamiać jako polecenie app-server na pierwszym planie lub w postaci demona. Codex Cloud i tryb kodu pozostają eksperymentalne lub w fazie rozwoju, natomiast podstawowe CLI, piaskownica, AGENTS.md, config.toml, Skills, hooks, narzędzia wielu agentów, pluginy, Browser, Computer Use i Appshots są stabilnymi lub udokumentowanymi funkcjami przeznaczonymi dla użytkowników, zależnie od platformy i planu. v0.132.0 uzupełnia uwierzytelnianie Python SDK i ustrukturyzowaną automatyzację wznawiania; v0.131.0 dodała codex doctor, ujednolicone wyszukiwanie wzmianek @, polecenia marketplace CLI, udostępnianie pluginów uwzględniające wersje, zarządzany przez demona remote-control z możliwością włączania i wyłączania w czasie działania, środowiska oparte na rejestrze oraz dodatkowe wzmocnienia piaskownicy Windows.⁹⁶⁹⁷⁹⁸ Starsze --full-auto usunięto w v0.147.0 (było przestarzałe od v0.128), a js_repl pozostaje usunięte.^8687116 Lista obserwacyjna alphy 0.149.0 trafiła do stabilnej wersji v0.149.0 (20 sierpnia 2026): zasada zatwierdzania untrusted została wycofana, codex agents jest rzeczywistym poleceniem pulpitu, codex doctor obejmuje ochronę punktów końcowych oraz diagnostykę sieci, aplikacji komputerowej i aktualizacji, a SDK udostępniają poziomy rozumowania max/ultra.¹²⁰ Lista obserwacyjna alphy 0.150.0 została przy wydaniu podzielona: z dziewięciu obserwowanych elementów pięć trafiło do stabilnej v0.150.0 (26 sierpnia 2026) — zdarzenie hook Interrupt, selektor /copy, pomijanie AGENTS.md w niezaufanych projektach, features.network_proxy.credential_broker oraz zakres weryfikacji review_scope.computer_use_only Guardian v2 (konfigurowalna powierzchnia; ostateczna wartość domyślna pozostaje standardowym zakresem) — a pięć przeniesiono do linii 0.151.0-alpha: /recap z automatycznym generowaniem podsumowań, usunięcie WebSocket z trybu kodu (punkty końcowe ws:// nadal działają w 0.150.0), stronicowana historia wątków jako ustawienie domyślne dla trwałych wątków (ThreadHistoryMode nadal ma domyślną wartość legacy w 0.150.0), poziom rozumowania persistent oraz domyślna weryfikacja korzystania z komputera z obrazami w Guardian v2 (transcript.include_images ma domyślną wartość false w 0.150.0). Budżetowanie zachowanych obrazów podczas kompakcji nadrobiło tę różnicę natychmiast: domyślne zachowanie z alphy (#40994) trafiło do wersji stabilnej przez przeniesienie wsteczne w 0.150.1 (#41003).¹³²¹³³ Lista obserwacyjna 0.151.0-alpha została zrealizowana bez komplikacji: wszystkie dziesięć elementów trafiło do stabilnej v0.151.0 (29 sierpnia 2026) bez żadnych wycofań — można to udowodnić wyłącznie za pomocą porównania rust-v0.150.1…rust-v0.151.0 (164 commity), ponieważ treść wydania wymienia tylko PR-y #41183–#41209 utworzone po odcięciu gałęzi.^137134135 Kolejna lista obserwacyjna 0.152.0-alpha (¹³⁶) została w całości włączona z jednym odwróceniem: wszystkie trzynaście elementów trafiło do stabilnej v0.152.0 (1 września 2026), ale update_plan wydano jako funkcję opcjonalną, a nie domyślnie włączoną — obserwowaną zmianę zachowania (domyślne włączenie z #41630) odwrócił przed odcięciem gałęzi #41744 „Make the update_plan tool opt-in”, dlatego tools.update_plan.enabled ma domyślną wartość false, a wcześniejsze zastrzeżenie notatki obserwacyjnej („zmiana zachowania, jeśli trafi do wersji stabilnej”) ostatecznie nie oznaczało zmiany domyślnego zachowania.¹³⁶¹³⁸ Stabilna v0.153.0 (3 września 2026) pojawiła się dwa dni później, a wydane tego samego dnia poprawki v0.153.1 i v0.153.2 (obecnie npm latest) dodały poprawkę respektowania wymagań modelu przez Guardian, przeniesiony wstecz wpis katalogowy GPT-6-Astra oraz jedną kosmetyczną poprawkę opisu — porównanie rust-v0.153.0…rust-v0.153.2 nie przenosi żadnego z obserwowanych elementów alphy.^140142143 Następna w cyklu jest linia 0.154.0-alpha, która dotarła do 0.154.0-alpha.3 (103 commity przed 0.153.0 na 3 września 2026; 19 commitów od alpha.1) i pozostaje wersją przedpremierową — żaden z jej elementów nie został opisany w głównej treści tego przewodnika, dopóki nie trafi do wersji stabilnej, a treści wydań w tej linii alphy są pustymi szablonami, dlatego jedynym źródłem są porównania. Lista obserwacyjna, najpierw elementy alpha.1: tryb zastępowania Vim (#42194), tworzenie zarządzanych worktrees (#42196), oddzielenie preferencji TUI od konfiguracji serwera (#42202), natywny zestaw środowiska obsługi głosu dla systemów macOS, Linux i Windows (#42204, #42208, #42209, #42332), bieżący stan kompakcji kontekstu w TUI (#42319), konfigurowalne opóźnienie zwalniania wątku app-server (#42320), zaprzestanie wykonywania modułów pomocniczych PATH przed uzyskaniem zaufania do obszaru roboczego (#42324, poprawka bezpieczeństwa), zestaw zmian w usłudze przygotowywania piaskownicy Windows (#42309–#42353), trwałe aktualizacje konfiguracji rozumowania (#42328) oraz swobodne asynchroniczne wiadomości użytkownika (#42354). Nowości w różnicy alpha.1…alpha.3: dołączony katalog modeli GPT-6-Astra (#42607) wraz z katalogami Amazon Bedrock (#42619), stanowiący przygotowanie do premiery modelu; zestaw zmian związanych z bezpieczeństwem i wzmacnianiem ochrony (piaskownica macOS zabezpieczona przed wstrzykiwaniem danych wejściowych terminala, #42590; weryfikacja przez Guardian wymagana dla niezgodnych punktów kontrolnych kompakcji, #42588; zaufane nagłówki dla zdalnych WebSocket wykonywania, #42606; uzgadnianie Noise ograniczone limitem czasu inicjalizacji exec-server, #42623); oraz prace nad kontekstem Guardian (flaga kontekstu wątku, #42529; trwałe zapisywanie zweryfikowanych odpowiedzi użytkownika, #42579). Porównania alphy nakładają się na zmiany przeniesione do wersji stabilnej (#42256 występuje zarówno w porównaniu stabilnych wersji rust-v0.152.1…rust-v0.153.0, jak i w linii alphy), dlatego podczas promocji każdy obserwowany element należy ponownie zweryfikować względem porównania wersji stabilnych.¹⁴¹¹⁴⁴

Jak działa Codex: model mentalny

Zanim przejdziemy do funkcji, warto zrozumieć, w jaki sposób architektura Codex wpływa na wszystkie wykonywane w nim działania. System działa w ramach pięciu interfejsów opartych na wspólnej warstwie inteligencji:

┌─────────────────────────────────────────────────────────┐
│                    CODEX SURFACES                       │
├─────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐   │
│  │   CLI    │  │ Desktop  │  │   IDE    │  │ Cloud  │   │
│  │ Terminal │  │   App    │  │Extension │  │  Tasks │   │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘   │
│  Local exec     Multi-task    Editor-native  Async      │
│  + scripting    + worktrees   + inline edits detached   │
│  ┌──────────┐                                           │
│  │ Browser  │  Signed-in browser workflows              │
│  │Extension │  (launched May 2026)                      │
│  └──────────┘                                           │
├─────────────────────────────────────────────────────────┤
│  EXTENSION LAYER                                        │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐     │
│  │   MCP   │  │ Skills  │  │  Apps   │  │  Search │     │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘     │
│  External tools, reusable expertise, ChatGPT            │
│  connectors, web search (cached + live)                 │
├─────────────────────────────────────────────────────────┤
│  SECURITY LAYER                                         │
│  ┌─────────────────────────────────────────────────┐    │
│  │    Sandbox (Seatbelt / Landlock / seccomp)      │    │
│  │    + Approval Policy (on-request → never)       │    │
│  └─────────────────────────────────────────────────┘    │
│  OS-level filesystem + network restrictions             │
├─────────────────────────────────────────────────────────┤
│  CORE LAYER                                             │
│  ┌─────────────────────────────────────────────────┐    │
│  │         GPT-5.x-Codex Intelligence              │    │
│  │   Tools: Shell, Patch, Read, Web Search         │    │
│  │   (legacy artifact, read_file, grep_files       │    │
│  │    removed in v0.117.0)                         │    │
│  └─────────────────────────────────────────────────┘    │
│  Shared model across all surfaces; costs tokens         │
└─────────────────────────────────────────────────────────┘

Warstwa podstawowa: Wszystkie funkcje są obsługiwane przez rodzinę modeli GPT-5.x. Według stanu na sierpień 2026 zalecanym modelem domyślnym jest gpt-5.6-sol — ustawienie „Power” ze średnim poziomem rozumowania — obok którego dostępne są Terra (do codziennych zadań) i Luna (szybki i przystępny cenowo); gpt-5.5 to flagowy model poprzedniej generacji (kontekst 400K w Codex i 1M w API), a gpt-5.4 zostanie wycofany z Codex 31 sierpnia 2026.⁸³¹¹⁷ Model odczytuje pliki, zapisuje poprawki, wykonuje polecenia powłoki i analizuje bazę kodu. Gdy kontekst się zapełnia, Codex kompaktuje rozmowę, aby zwolnić miejsce. Korzystanie z tej warstwy zużywa tokeny.

Warstwa zabezpieczeń: Każde polecenie wykonywane przez Codex przechodzi przez piaskownicę na poziomie systemu operacyjnego. W systemie macOS mechanizm Seatbelt firmy Apple wymusza ograniczenia na poziomie jądra. W systemie Linux Landlock + seccomp filtrują dostęp do systemu plików i wywołań systemowych. Piaskownica działa na poziomie jądra, a nie wewnątrz kontenerów. Następnie zasady zatwierdzania określają, kiedy należy poprosić człowieka o potwierdzenie.

Warstwa rozszerzeń: MCP łączy usługi zewnętrzne (GitHub, Figma, Sentry). Skills zawierają wielokrotnego użytku przepływy pracy, które Codex wczytuje na żądanie. Apps łączą się z konektorami ChatGPT. Wyszukiwanie w sieci zapewnia aktualny kontekst z internetu.

Warstwa interfejsów: CLI dla zaawansowanych użytkowników terminala i automatyzacji. Aplikacja komputerowa do wielowątkowego zarządzania projektami. Rozszerzenie IDE do cykli edycji, kompilacji i testowania. Cloud do zadań asynchronicznych wykonywanych niezależnie.

Kluczowy wniosek: Większość użytkowników korzysta tylko z jednego interfejsu. Zaawansowani użytkownicy korzystają ze wszystkich pięciu: Cloud do długotrwałych zadań, CLI do deterministycznych operacji na repozytorium, rozszerzenia IDE do krótkich cykli programowania, aplikacji komputerowej do planowania i koordynacji oraz rozszerzenia przeglądarki do przepływów pracy wymagających zalogowanej sesji w przeglądarce.

Spis treści

1. Jak zainstalować Codex?
2. Szybki start: pierwsza sesja
3. Podstawowe interfejsy obsługi
4. Szczegółowe omówienie systemu konfiguracji
5. Który model wybrać?
6. Ile kosztuje Codex?
7. Schematy podejmowania decyzji
8. Jak działa system piaskownicy i zatwierdzania?
9. Jak działa AGENTS.md?
10. Hooks
11. Czym jest MCP (Model Context Protocol)?
12. Tryb Code Mode
13. Środowisko uruchomieniowe REPL JavaScript
14. Czym są Skills?
15. Plugins
16. Tryb Plan Mode i współpraca
17. System pamięci
18. Zarządzanie sesjami
19. Tryb nieinteraktywny (codex exec)
20. Codex Cloud i zadania w tle
21. Aplikacja Codex Desktop App
22. GitHub Action i CI/CD
23. Codex SDK
24. Optymalizacja wydajności
25. Jak diagnozować problemy? — w tym codex doctor
26. Wdrożenie w przedsiębiorstwie
27. Dobre praktyki i antywzorce
28. Przepisy na przepływy pracy
29. Przewodnik po migracji
30. Podręczna karta referencyjna
31. Dziennik zmian
32. Materiały źródłowe

Jak zainstalować Codex?

Menedżery pakietów

# npm (recommended)
npm install -g @openai/codex

# Homebrew (macOS)
brew install --cask codex

# winget (Windows)
winget install OpenAI.Codex

# Upgrade to latest
npm install -g @openai/codex@latest

Jak zaktualizować, obniżyć wersję lub odinstalować Codex CLI?

Od wersji v0.128.0 Codex udostępnia polecenie do samodzielnej aktualizacji; wszystkie pozostałe operacje wykonuje się za pomocą menedżera pakietów, przez który został zainstalowany.⁸⁶ Od wersji v0.146.0 artefakty wydań, metadane kanałów i aliasy instalatora są udostępniane przez infrastrukturę wydań hostowaną przez OpenAI, z GitHub jako rozwiązaniem awaryjnym.¹¹⁴ Jeśli lista dozwolonych hostów w sieci obejmuje GitHub na potrzeby instalacji i aktualizacji Codex, należy dodać do niej również host wydań OpenAI — mechanizm awaryjny sprawia, że brak hosta na liście powoduje niezauważalne przejście na zapasowe źródło zamiast wyraźnego błędu.

# Check what you are running
codex --version                          # -> codex-cli 0.153.2
npm view @openai/codex version           # Latest published version

# Update
codex update                             # Built-in self-update (v0.128.0+)
npm install -g @openai/codex@latest      # Or update via npm
brew upgrade --cask codex                # Or via Homebrew

# Pin or downgrade to an exact version
npm install -g @openai/codex@0.144.6

# Uninstall
npm uninstall -g @openai/codex
brew uninstall --cask codex
winget uninstall OpenAI.Codex

Przypięcie wersji jest właściwym rozwiązaniem, gdy nowe wydanie powoduje problemy. Codex rozwija się w ramach szybko aktualizowanej stabilnej linii, dlatego instalacja konkretnej wersji jest najszybszym sposobem na wycofanie aktualizacji — należy zgłosić problem, przypiąć wersję i kontynuować pracę. Poprawność wycofania warto sprawdzić za pomocą codex --version, ponieważ druga instalacja przesłonięta w zmiennej PATH może bez ostrzeżenia nadal uruchamiać starą wersję pliku binarnego (codex doctor sygnalizuje dokładnie ten problem w sekcji Environment).

Odinstalowanie pakietu nie usuwa stanu użytkownika. Dane uwierzytelniające, konfiguracja i historia sesji znajdują się w ~/.codex/. Pozostawienie tego folderu pozwala zachować logowania i historię po ponownej instalacji; należy go usunąć tylko wtedy, gdy potrzebny jest rzeczywiście czysty start — rm -rf ~/.codex usuwa również config.toml, auth.json oraz wszystkie zapisane sesje.

Bezpośredni skrypt instalacyjny (v0.106.0+)

Dla systemów macOS i Linux dostępny jest jednowierszowy skrypt instalacyjny jako zasób wydania GitHub:⁶⁰

curl -fsSL https://github.com/openai/codex/releases/latest/download/install.sh | sh

Skrypt automatycznie wykrywa platformę i architekturę, pobiera właściwy plik binarny i umieszcza go w ścieżce PATH.

Pobieranie plików binarnych

W środowiskach bez npm lub Homebrew należy pobrać pliki binarne odpowiednie dla danej platformy ze strony wydań GitHub¹:

Wymagania systemowe

• macOS: Apple Silicon lub Intel (pełna obsługa piaskownicy za pomocą Seatbelt)
• Linux: x86_64 lub arm64 (piaskownica za pomocą Landlock + seccomp)
• Windows: natywna piaskownica z ograniczonymi tokenami (od wersji v0.100.0 nie jest już funkcją eksperymentalną). Obsługiwany jest również WSL²

Uwierzytelnianie

codex login                  # Interactive OAuth (recommended)
codex login --device-auth    # OAuth device code flow (headless)
codex login --with-api-key   # API key from stdin
codex login status           # Check auth state (exit 0 = logged in)
codex logout                 # Clear stored credentials

Dostępne są 2 metody uwierzytelniania:

1. Konto ChatGPT (zalecane): należy zalogować się przy użyciu istniejącej subskrypcji Plus, Pro, Team, Business, Edu lub Enterprise. Zapewnia pełny dostęp do funkcji, w tym zadań w chmurze.
2. Klucz API: można go ustawić za pomocą zmiennej środowiskowej CODEX_API_KEY lub polecenia codex login --with-api-key. Niektóre funkcje (wątki w chmurze) mogą być niedostępne.

Wskazówka dla zaawansowanych: sposób przechowywania danych uwierzytelniających można skonfigurować za pomocą cli_auth_credentials_store w config.toml. Dostępne opcje: file (domyślna), keyring (pęk kluczy systemu operacyjnego) lub auto (pęk kluczy, jeśli jest dostępny, a w przeciwnym razie plik).

Logowanie do Amazon Bedrock (v0.145.0, eksperymentalne): zespoły korzystające z dostępu do modeli przez Amazon Bedrock otrzymują eksperymentalną metodę logowania z obsługą niestandardowego punktu końcowego i uwierzytelniania. Jest ona dostępna obok istniejącego zarządzanego uwierzytelniania kluczem API (v0.140.0+) oraz łańcucha danych uwierzytelniających AWS (zob. Niestandardowi dostawcy modeli). GPT-5.6 Sol jest domyślnym modelem Bedrock.¹¹² Wersja v0.150.0 naprawia kompresję konwersacji oraz zgodność modeli Amazon Bedrock z trybem wieloagentowym.¹³² Wersja v0.151.0 dodaje objętą flagą funkcji opcję Amazon Bedrock do kwalifikujących się procesów logowania w TUI: podczas wdrażania wykrywane są istniejące profile AWS i dane uwierzytelniające ze zmiennych środowiskowych, a także dostępna jest ręczna konfiguracja profili, kluczy dostępu, zmiennych środowiskowych i kluczy API Bedrock. Proces zbiera również region AWS, maskuje wpisywane dane poufne i ponownie uruchamia osadzony serwer po zmianie dostawcy.¹³⁵ Wersja v0.152.0 wyświetla postęp odświeżania danych uwierzytelniających: TUI oraz codex exec pokazują postęp, gdy dostawca modelu odświeża wygasłe dane uwierzytelniające, w tym podczas ponownego uwierzytelniania sesji Amazon Bedrock. Mechanizm wykorzystuje stabilne powiadomienia serwera aplikacji modelProvider/authRecoveryStarted i modelProvider/authRecoveryCompleted, zawierające wątek, turę, dostawcę oraz komunikat przeznaczony dla użytkownika.¹³⁸

Uzupełnianie poleceń w powłoce

# Generate completions for your shell
codex completion bash > /etc/bash_completion.d/codex
codex completion zsh > ~/.zsh/completions/_codex
codex completion fish > ~/.config/fish/completions/codex.fish

Weryfikacja instalacji

codex --version
# codex-cli 0.153.2

Szybki start: pierwsza sesja

Od rozpoczęcia do produktywnej pracy w 5 minut.

1. Instalacja i uwierzytelnianie:

npm i -g @openai/codex          # Install
codex login                      # Log in with your OpenAI account

2. Przejście do projektu:

cd ~/my-project                  # Any git repo works

3. Uruchomienie Codex:

codex

Zostanie wyświetlony interaktywny TUI. Codex automatycznie odczyta strukturę projektu.

4. Zadanie pytania:

> What does this project do? Summarize the architecture.

Codex odczyta kluczowe pliki i objaśni bazę kodu. Takie pytanie nie powoduje żadnych zmian — Codex modyfikuje pliki wyłącznie po otrzymaniu prośby o zmianę, a piaskownica i approval policy określają, kiedy musi najpierw poprosić o zgodę.

5. Wprowadzenie zmiany:

> Add input validation to the login endpoint

Codex przedstawia proponowane zmiany jako diff. Można je przejrzeć i zatwierdzić klawiszem y albo odrzucić klawiszem n.

6. Użycie slash command:

> /plan Refactor the database layer to use connection pooling

Codex tworzy plan bez jego wykonywania. Należy przejrzeć plan, a następnie zatwierdzić rozpoczęcie realizacji.

7. Sprawdzenie wyników pracy:

> /diff

Wyświetlone zostaną wszystkie zmiany wprowadzone przez Codex w bieżącej sesji.

Co dalej: - Skonfigurować AGENTS.md z instrukcjami dotyczącymi projektu (zob. Jak działa AGENTS.md?) - Skonfigurować profil odpowiedni do sposobu pracy (zob. Profile) - Wypróbować codex exec do automatyzacji nieinteraktywnej (zob. Tryb nieinteraktywny)

Główne interfejsy interakcji

Codex udostępnia pięć odrębnych interfejsów opartych na tej samej inteligencji. Każdy z nich jest zoptymalizowany pod kątem innego sposobu pracy.

1. Interaktywny CLI (interfejs terminalowy)

codex                        # Launch TUI
codex "fix the failing tests" # Launch with initial prompt
codex -m gpt-5.5            # Specify model
codex --sandbox workspace-write --ask-for-approval on-request

Interfejs terminalowy jest aplikacją pełnoekranową obejmującą:

• Edytor poleceń: wpisywanie promptów, dołączanie plików za pomocą @ oraz uruchamianie poleceń powłoki z prefiksem !
• Panel wyników: strumieniowe odpowiedzi modelu, wywołania narzędzi i wyniki poleceń
• Pasek stanu: model, użycie tokenów, gałąź git i tryb sandbox

Najważniejsze skróty TUI:

Zmiana paska stanu (v0.121.0): Dotychczasowy wskaźnik okna kontekstu na pasku stanu zastąpiono wskaźnikiem procentowego wykorzystania kontekstu, pokazującym stopień zapełnienia okna kontekstu. Jeśli skrypty lub hooks analizują pasek stanu, należy uwzględnić tę zmianę formatu.⁸² Codex wyświetli również w CLI powiadomienie o dostępności nowej wersji.

Slash commands dostępne w TUI:

Przeprojektowany selektor przepływu pracy (v0.129.0): Wznowienie i rozwidlenie są teraz łatwiej dostępne dzięki przeprojektowanemu selektorowi, a nowy surowy tryb historii terminala umożliwia przewijanie niewyrenderowanego zapisu rozmowy, gdy trzeba skopiować polecenia lub wynik modelu w niezmienionej postaci. Przydaje się to podczas analizowania długiej sesji debugowania lub przekazywania wyników potokiem do innego narzędzia.⁸⁹

Ujednolicone menu wzmianek @ (v0.140.0): Wpisanie @ w edytorze poleceń otwiera teraz domyślnie jedno menu wzmianek obejmujące pliki, plugins i skills, zastępując dotychczasowy mechanizm dołączania wyłącznie plików — wystarczy jeden klawisz, aby odwołać się do dowolnego zasobu projektu.¹⁰²

2. Codex Desktop App (macOS + Windows)

codex app                    # Launch desktop app (auto-installs if missing)

Aplikacja desktopowa oferuje funkcje niedostępne w CLI:

• Wielozadaniowość: jednoczesne uruchamianie wielu równoległych agentów w różnych projektach
• Izolacja za pomocą git worktree: każdy wątek pracuje na odizolowanej kopii repozytorium
• Wbudowany przegląd różnic: dodawanie zmian do poczekalni, wycofywanie ich i tworzenie commitów bez opuszczania aplikacji
• Zintegrowany terminal: osobny terminal dla każdego wątku, służący do uruchamiania poleceń
• Rozwidlanie rozmów: tworzenie odgałęzień rozmowy w celu sprawdzania alternatywnych rozwiązań
• Pływające odłączane okna: wydzielanie rozmów do przenośnych okien
• Automatyzacje: planowanie cyklicznych zadań (segregowanie zgłoszeń, monitorowanie CI, reagowanie na alerty)
• Appshots: dołączanie do wątku okna aktywnej aplikacji na Macu wraz ze zrzutem ekranu i dostępnym tekstem
• Komentarze w przeglądarce w aplikacji: podgląd stron lokalnych lub publicznych, dodawanie komentarzy do elementów bądź obszarów i umożliwienie Codex uwzględnienia precyzyjnych uwag wizualnych
• Computer Use: umożliwienie Codex obsługi dozwolonych aplikacji na Macu w ramach ściśle określonych zadań w interfejsie graficznym; użycie przy zablokowanym urządzeniu wymaga świadomego włączenia w kwalifikujących się zdalnych turach Mac Computer Use

ChatGPT Voice, obsługiwany przez GPT-Live (desktop 26.715, 23 lipca 2026): Aplikacją desktopową można teraz sterować głosowo — omawiać pracę i koordynować zadania w Chat, Work oraz Codex bez pisania. W systemie macOS włączenie funkcji Screen context udostępnia w rozmowie appshot aktywnego okna, dzięki czemu można zapytać o widoczną zawartość zamiast ją opisywać. Funkcja jest dostępna w planach Plus, Pro, Business, Edu i Enterprise, w aplikacji desktopowej oraz zdalnie na iOS. Jest to obsługa głosowa interfejsu desktopowego; transkrypcja głosu uruchamiana spacją w samym CLI stanowi osobną funkcję eksperymentalną.¹¹³

Udostępniane migawki wątków (20 sierpnia 2026): We wszystkich planach Codex aplikacja desktopowa na macOS umożliwia udostępnienie migawki lokalnego wątku Codex w trybie tylko do odczytu. Migawka nie aktualizuje się po zmianie oryginalnego wątku; łącza z kont osobistych może otworzyć każda osoba, która je ma, natomiast łącza z kont obszaru roboczego są dostępne wyłącznie dla członków obszaru, z którego pochodzą. Przed udostępnieniem Codex usuwa znane wzorce sekretów, jednak OpenAI zaleca sprawdzenie udostępnianej treści, ponieważ mogą w niej pozostać dane poufne. Łącza można wyświetlić lub unieważnić w sekcji Shared links w ustawieniach kontroli danych ChatGPT.¹²⁸

Kiedy używać aplikacji, a kiedy CLI: Aplikacja desktopowa najlepiej sprawdza się przy koordynowaniu wielu równoległych strumieni pracy lub wizualnym przeglądaniu różnic. CLI warto wybrać, gdy istotna jest możliwość komponowania narzędzi terminalowych, tworzenie skryptów lub integracja z CI/CD.

3. Rozszerzenie IDE (VS Code, Cursor, Windsurf)

Rozszerzenie Codex IDE integruje się bezpośrednio z edytorem:

• Domyślny tryb agenta: odczytuje pliki, wprowadza zmiany i uruchamia polecenia
• Edycja bezpośrednio w kodzie: sugestie uwzględniające kontekst aktywnych plików
• Współdzielone sesje: sesje są synchronizowane między CLI a rozszerzeniem IDE
• To samo uwierzytelnianie: logowanie za pomocą konta ChatGPT lub klucza API

Rozszerzenie można zainstalować z VS Code Marketplace albo sklepów z rozszerzeniami Cursor/Windsurf.³

4. Codex Cloud [EXPERIMENTAL]

Zadania w chmurze działają asynchronicznie w środowiskach zarządzanych przez OpenAI:

• Uruchomienie i pozostawienie zadania: dodawanie do kolejki zadań wykonywanych niezależnie od komputera lokalnego
• Wykonywanie równoległe: jednoczesne uruchamianie wielu zadań w chmurze
• Tworzenie PR: Codex tworzy pull requests na podstawie ukończonych prac
• Zastosowanie lokalne: pobieranie wyników z chmury do lokalnego repozytorium za pomocą codex apply <TASK_ID>

codex cloud list             # List recent cloud tasks
codex apply <TASK_ID>        # Apply diff from a specific cloud task

Zadania w chmurze są również dostępne pod adresem chatgpt.com/codex.⁴

5. Rozszerzenie przeglądarki (Chrome, Edge, Brave, Opera, Vivaldi)

Codex jest dostępny jako rozszerzenie do Google Chrome, Microsoft Edge, Brave, Opera i Vivaldi, tworząc piąty interfejs obok CLI, aplikacji desktopowej, rozszerzenia IDE i chmury. Rozszerzenie zadebiutowało w Chrome w maju 2026; w dzienniku zmian z 25 sierpnia 2026 dodano pozostałe cztery przeglądarki, konfigurowane w aplikacji desktopowej ChatGPT przez Settings > Computer Use. Wszystkie pięć obsługuje wzmianki o kartach i sterowanie przeglądarką; Opera nie obsługuje rozmowy w panelu bocznym, dlatego zadania dla niej należy rozpoczynać w aplikacji desktopowej. Rozszerzenie zaprojektowano tak, aby towarzyszyło zwykłemu przeglądaniu internetu, zamiast przejmować nad nim kontrolę: Codex pracuje równolegle w tle na wielu kartach, a użytkownik zachowuje kontrolę nad tym, z którymi witrynami może wchodzić w interakcję.⁹⁰¹²⁷

• Równoległa obsługa kart: Codex działa jednocześnie na wielu kartach bez blokowania karty na pierwszym planie.
• Kontrola dla poszczególnych witryn: należy wskazać dozwolone witryny, z którymi Codex może wchodzić w interakcję; domyślnie nie ma dostępu do żadnej.
• Przeglądarka jako środowisko pracy: rozszerzenie najlepiej sprawdza się w pracy z aplikacjami i witrynami, w której źródłem prawdy jest strona — na przykład w konsolach administracyjnych, wewnętrznych pulpitach, interfejsach systemów zarządzania treścią i systemach obsługi zgłoszeń — nie zastępuje jednak CLI podczas pracy z lokalnymi repozytoriami.
• Ta sama inteligencja: rozszerzenie przeglądarki korzysta z tej samej inteligencji GPT-5.x-Codex co pozostałe interfejsy, dlatego konfiguracja AGENTS.md lub skills działająca w CLI przenosi te same konwencje do pracy wykonywanej za pośrednictwem przeglądarki.

Rozszerzenie można zainstalować, korzystając z dokumentacji rozszerzenia przeglądarki, na stronie wcześniej zatytułowanej Codex for Chrome.¹²⁷

Szczegółowy opis systemu konfiguracji

Codex używa formatu TOML do konfiguracji. Zrozumienie hierarchii pierwszeństwa jest kluczowe, ponieważ określa ona, które ustawienia mają pierwszeństwo w przypadku konfliktu.

Kolejność pierwszeństwa (od najwyższej do najniższej)

1. Nadpisania sesji (najwyższe): flagi CLI (--model, --sandbox, --ask-for-approval, --search, --enable/--disable, --profile) oraz nadpisania -c key=value
2. Konfiguracja projektu (.codex/config.toml, wykrywana od CWD w górę aż do katalogu głównego projektu; pierwszeństwo ma najbliższy katalog)
3. Konfiguracja użytkownika ($CODEX_HOME/config.toml, domyślnie ~/.codex/config.toml)
4. Konfiguracja systemowa (/etc/codex/config.toml w systemach Unix)
5. Wbudowane wartości domyślne (najniższe)

requirements.toml działa jako warstwa ograniczeń zasad, która po standardowym scaleniu konfiguracji ogranicza wartości dostępne do wyboru przez użytkowników. Zobacz Wdrożenie w przedsiębiorstwie.

Lokalizacje plików konfiguracyjnych

Wskazówka ekspercka: Zmienna środowiskowa CODEX_HOME zastępuje domyślny katalog ~/.codex. Jest to przydatne w CI/CD lub konfiguracjach z wieloma kontami.

Projekty wielofolderowe w aplikacji desktopowej (26.715, 23 lipca 2026): Projekt lokalny w aplikacji desktopowej ChatGPT może teraz obejmować kilka powiązanych folderów, z których jeden jest oznaczony jako folder główny (menu projektu → Edytuj projekt). Automatyczne wykrywanie pliku config.toml odbywa się wyłącznie w odniesieniu do folderu głównego. Foldery dodatkowe pozostają dostępne do wyszukiwania, odczytywania i edytowania plików, ale nie wnoszą żadnej konfiguracji. Plik .codex/config.toml znajdujący się w folderze dodatkowym jest plikiem, który Codex może odczytać, lecz nie jest wczytywaną konfiguracją. Dotyczy to zakresu projektu w aplikacji desktopowej, a nie zmiany opisanych wyżej reguł pierwszeństwa — CLI nadal rozpoznaje konfigurację projektu, przechodząc w górę od bieżącego katalogu roboczego.¹¹³

Pełna dokumentacja konfiguracji

# ~/.codex/config.toml — annotated reference

# ─── Model Selection ───────────────────────────────────
model = "gpt-5.6-sol"                  # Recommended default (the "Power" setting)
model_provider = "openai"               # Provider (openai, oss, or custom provider id)
model_context_window = 272000           # Token count available to active model (override)
model_auto_compact_token_limit = 200000 # Threshold triggering automatic history compaction
model_reasoning_effort = "medium"       # minimal|low|medium|high|xhigh (model-dependent)
model_reasoning_summary = "auto"        # auto|concise|detailed|none
model_verbosity = "medium"              # low|medium|high
personality = "pragmatic"               # none|friendly|pragmatic
review_model = "gpt-5.5"               # Optional model for /review command
service_tier = "fast"                  # Preferred service tier for new turns
oss_provider = "lmstudio"              # lmstudio|ollama (used with --oss)

# ─── Sandbox & Approval ───────────────────────────────
sandbox_mode = "workspace-write"        # read-only|workspace-write|danger-full-access
approval_policy = "on-request"          # on-request|never (untrusted retired in v0.149.0)

[sandbox_workspace_write]
writable_roots = []                     # Additional writable paths
network_access = false                  # Allow outbound network
exclude_tmpdir_env_var = false          # Exclude $TMPDIR from sandbox
exclude_slash_tmp = false               # Exclude /tmp from sandbox

# ─── Web Search ────────────────────────────────────────
web_search = "live"                     # Web search mode (constrained by allowed modes)

# ─── Tools ─────────────────────────────────────────────
tools.update_plan.enabled = false       # Planning tool opt-in (v0.152.0); exposes update_plan when true

# ─── Instructions ──────────────────────────────────────
developer_instructions = ""             # Additional injected instructions
model_instructions_file = ""            # Custom instructions file path
compact_prompt = ""                     # Custom history compaction prompt

# ─── Shell Environment ─────────────────────────────────
allow_login_shell = false               # Allow login shell semantics (loads .profile/.zprofile)

[shell_environment_policy]
inherit = "all"                         # all|core|none
ignore_default_excludes = false         # Set true to keep KEY/SECRET/TOKEN vars
exclude = []                            # Glob patterns to exclude
set = {}                                # Explicit overrides
include_only = []                       # Whitelist patterns

# ─── Authentication ────────────────────────────────────
cli_auth_credentials_store = "file"     # file|keyring|auto
forced_login_method = "chatgpt"         # chatgpt|api
mcp_oauth_callback_port = 0            # Fixed port for MCP OAuth callback (0 = random)
mcp_oauth_credentials_store = "auto"   # auto|file|keyring

# ─── History & Storage ─────────────────────────────────
[history]
persistence = "save-all"                # save-all|none
max_bytes = 0                           # Cap size (0 = unlimited)

tool_output_token_limit = 10000         # Max tokens per tool output (global; per-tool MCP overrides in v0.152.0)
log_dir = ""                            # Custom log directory
sqlite_home = ""                        # Override SQLite-backed resumable state location

# ─── UI & Display ──────────────────────────────────────
file_opener = "vscode"                  # vscode|vscode-insiders|windsurf|cursor|none
hide_agent_reasoning = false
show_raw_agent_reasoning = false
check_for_update_on_startup = true

[tui]
notifications = false                   # Enable notifications
notification_method = "auto"            # auto|osc9|bel
animations = true
show_tooltips = true
alternate_screen = "auto"               # auto|always|never
status_line = ["model", "context-remaining", "git-branch"]

# ─── Project Trust ─────────────────────────────────────
project_doc_max_bytes = 32768           # Max AGENTS.md size (32 KiB)
project_doc_fallback_filenames = []     # Alternative instruction filenames
project_root_markers = [".git"]         # Project root detection

# ─── Feature Flags ─────────────────────────────────────
# Use `codex features list` for current names/stages/defaults.
[features]
shell_tool = true                       # Shell command execution (stable)
unified_exec = true                     # PTY-backed exec (stable)
shell_snapshot = true                   # Shell env snapshots (stable)
enable_request_compression = true       # zstd request compression where supported (stable)
fast_mode = true                        # Service-tier selection and Fast-tier commands (stable)
goals = true                            # Goal mode; stable and on by default in v0.133.0+
hooks = true                            # Lifecycle hooks (stable)
multi_agent = true                      # Enable multi-agent collaboration tools (stable)
personality = true                      # Personality selection (stable)
plugins = true                          # Plugin system (stable)
plugin_hooks = true                     # Plugin-bundled hooks (stable)
plugin_sharing = true                   # Workspace plugin sharing (stable)
browser_use = true                      # In-app browser automation (stable)
browser_use_external = true             # Browser-extension browser use (stable)
computer_use = true                     # macOS Computer Use (stable, plan/region gated)
in_app_browser = true                   # Shared rendered-page preview (stable)
image_generation = true                 # Image-generation tool (stable)
guardian_approval = true                # Auto-review approval path (stable)
skill_mcp_dependency_install = true     # Prompt/install missing skill MCP deps (stable)
tool_suggest = true                     # Tool/plugin suggestion surface (stable)
workspace_dependencies = true           # Workspace dependency discovery (stable)
memories = true                         # Memories (experimental)
network_proxy = false                   # Sandboxed-command network proxy (experimental); boolean or table, see below
prevent_idle_sleep = true               # Keep machine awake during active turns (experimental)
terminal_resize_reflow = true           # Terminal reflow improvements (experimental)

# Removed or deprecated feature names still appear in `codex features list`
# for migration diagnostics. Do not set removed flags such as
# `collaboration_modes`, `request_rule`, `codex_git_commit`,
# `apply_patch_freeform`, `search_tool`, or `js_repl` in new configs.

# ─── Multi-Agent Roles (v0.102.0+) ───────────────────
[agents]
max_threads = 4                         # Maximum concurrent agent threads

[agents.explorer]
description = "Read-only codebase navigator"
config_file = "~/.codex/profiles/explorer.toml"

# ─── Notifications ────────────────────────────────────
notify = ["terminal-notifier", "-title", "Codex"]  # Command for notifications

# ─── Per-Project Overrides ────────────────────────────
[projects."/absolute/path/to/repo"]
trust_level = "trusted"                 # Per-project trust override

features.network_proxy ma typ boolean | table. Forma logiczna jedynie uruchamia lub zatrzymuje proxy; forma tabeli zawiera zasady. Proxy wymusza reguły domen profilu uprawnień dla poleceń wykonywanych w sandboxie: gdy jest wyłączone, reguły domen [permissions.<name>.network] nie są egzekwowane, a dostęp poleceń do sieci jest bezpośredni. Nie filtruje ono wyszukiwania w internecie, aplikacji, serwerów MCP ani innych narzędzi hostowanych.¹³⁰

[features.network_proxy]
enabled = true
allow_local_binding = false
proxy_url = "http://127.0.0.1:3128"

[features.network_proxy.domains]
"api.github.com" = "allow"
"*.npmjs.org" = "allow"          # subdomains only
"**.example.com" = "deny"        # apex plus subdomains; deny wins on conflicts

Zarządzane przez administratora wymagania experimental_network w pliku requirements.toml mogą uruchomić proxy bez features.network_proxy.¹³⁰

Profile

Nazwane ustawienia konfiguracji przeznaczone do różnych trybów pracy. Od wersji Codex 0.134.0 każdy profil jest osobnym plikiem — ~/.codex/<name>.config.toml, zawierającym wyłącznie klucze najwyższego poziomu — a --profile <name> nakłada ten plik na ~/.codex/config.toml. Starsze tabele [profiles.<name>] w pliku config.toml oraz selektor najwyższego poziomu profile = "<name>" nie są już odczytywane. Pozostawiona tabela [profiles.<name>] sprawia, że --profile <name> odmawia uruchomienia do czasu przeniesienia jej kluczy do pliku profilu.¹²²

# ~/.codex/fast.config.toml
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
personality = "pragmatic"

# ~/.codex/careful.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
approval_policy = "on-request"   # `untrusted` retired in v0.149.0
sandbox_mode = "read-only"

# ~/.codex/auto.config.toml
model = "gpt-5.6-sol"
model_reasoning_effort = "medium"
approval_policy = "never"
sandbox_mode = "workspace-write"

Plik profilu stanowi warstwę nad podstawową konfiguracją użytkownika, a pod konfiguracją projektu i CLI, dlatego musi zawierać jedynie wartości różniące się od konfiguracji podstawowej.¹²²

Aby aktywować profil:

codex --profile fast "quick refactor"
codex --profile careful "security audit"
codex -p auto "fix CI"

Wskazówka ekspercka: Domyślny profil można ustawić za pomocą profile = "fast" na najwyższym poziomie konfiguracji. Dla konkretnej sesji można go zastąpić za pomocą --profile.

Niestandardowi dostawcy modeli

Połączenie z Azure, AWS Bedrock, modelami lokalnymi lub usługami proxy:

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://YOUR_PROJECT.openai.azure.com/openai"
wire_api = "responses"
query_params = { api-version = "2025-04-01-preview" }
env_key = "AZURE_OPENAI_API_KEY"

# Built-in amazon-bedrock provider (v0.123.0+, first-class in v0.124.0+)
# AWS SigV4 signing + credential-based auth; AWS profile selectable via the
# nested `aws.profile` field (NOT a top-level `aws_profile` key).
# v0.130.0+ also accepts credentials from `aws login` (the AWS console-login
# flow) — Codex resolves the cached console-login session for the chosen
# profile if static keys are absent.
# v0.140.0+ adds managed Amazon Bedrock API-key authentication, and stores
# CLI and MCP OAuth credentials in encrypted local storage.[^184]
[model_providers.amazon-bedrock]
name = "Amazon Bedrock"

[model_providers.amazon-bedrock.aws]
profile = "default"                   # any profile from ~/.aws/credentials
# Region/credential resolution otherwise follows the standard AWS chain;
# v0.130.0 added support for `aws login` console-login profiles in addition
# to static access keys and IAM role assumption.[^168]

[model_providers.ollama]
name = "Ollama (Local)"
base_url = "http://localhost:11434/v1"
wire_api = "chat"

Ostrzeżenie: Format przewodowy chat/completions API (wire_api = "chat") został wycofany dla modeli hostowanych przez OpenAI, a OpenAI zapowiedziało jego usunięcie w lutym 2026 roku.³⁴ Dostawcy lokalni (Ollama, LM Studio) mogą nadal obsługiwać ten format. W przypadku punktów końcowych OpenAI należy zamiast niego używać wire_api = "responses".

Aby używać modeli lokalnych z flagą --oss:

codex --oss "explain this function"               # Uses default OSS provider
codex --oss --local-provider lmstudio "explain"   # Explicit LM Studio
codex --oss --local-provider ollama "explain"      # Explicit Ollama

Można też ustawić to w konfiguracji:

model_provider = "oss"
oss_provider = "lmstudio"   # or "ollama"

Nadpisywanie konfiguracji w wierszu poleceń

Dowolną wartość konfiguracji można nadpisać z poziomu wiersza poleceń:

codex -c model="gpt-5.5" "refactor the API"
codex -c 'sandbox_workspace_write.network_access=true' "install dependencies"
codex -c model_reasoning_effort="xhigh" "debug the race condition"

Który model wybrać?

Dostępne modele (sierpień 2026)

GPT-5.5 (23 kwietnia 2026) był w momencie premiery modelem zalecanym przez OpenAI do większości zadań Codex: złożonego programowania, obsługi komputera, pracy opartej na wiedzy oraz procesów badawczych. Udostępniony w Codex CLI / wersji webowej / aplikacji komputerowej 23 kwietnia użytkownikom ChatGPT Plus / Pro / Business / Enterprise / Edu / Go, a w OpenAI API — 24 kwietnia. Okno kontekstu: 400K w Codex, 1M w API — Codex ogranicza je do 400K, aby zachować równowagę między przepustowością a kosztami w różnych planach subskrypcji; API udostępnia pełne 1M. Ceny (API): 5 USD za wejściowy / 30 USD za wyjściowy MTok (2× stawka GPT-5.4; według OpenAI rzeczywisty wzrost wynosi około 20% dzięki poprawie efektywności wykorzystania tokenów). Wyniki testów: 82,7% w Terminal-Bench 2.0 (obecny wynik SOTA wśród publicznie dostępnych modeli), 84,9% w GDPval (44 zawody), 78,7% w OSWorld-Verified, 98,0% w Tau2-bench Telecom (bez dostrajania promptów). Przed premierą OpenAI wykorzystało GPT-5.5 i Codex do wewnętrznego przepisania infrastruktury obsługującej modele, co zwiększyło szybkość generowania tokenów o 20%.⁸³

GPT-5.4 i GPT-5.4 mini zostaną wycofane z Codex 31 sierpnia 2026.¹¹⁷ Do tego czasu GPT-5.4 pozostaje dostępny do wyboru na wszystkich platformach Codex.⁶⁴ Dokładna lista modeli zależy od konta i etapu wdrożenia. Można ją sprawdzić w lokalnej pamięci podręcznej: ~/.codex/models_cache.json.

Informacja o wycofaniu (11 marca 2026): modele GPT-5.1 nie są już dostępne w ChatGPT. Istniejące rozmowy są automatycznie kontynuowane przy użyciu GPT-5.3 Instant, GPT-5.4 Thinking lub GPT-5.4 Pro. GPT-5.1-Codex-Mini pozostawał dostępny przez API i CLI aż do wyłączenia 23 lipca 2026.⁷¹⁸⁸

Informacja o planie bezpłatnym (5 maja 2026): GPT-5.5 Instant udostępniono w bezpłatnym planie ChatGPT 5 maja 2026. Poszerza to grono odbiorców rodziny GPT-5.5 poza płatne plany, choć dostęp do Codex CLI nadal wymaga odpowiedniej subskrypcji Plus / Pro / Business / Enterprise / Edu / Go albo klucza API.⁹²

GPT-5.4 mini (17 marca 2026): mniejszy i szybszy wariant GPT-5.4 z kontekstem 400K, kosztujący 0,75 USD/4,50 USD za MTok — wykorzystuje zaledwie 30% limitu GPT-5.4. Doskonale nadaje się do delegowania zadań subagentom: GPT-5.4 może odpowiadać za planowanie i koordynację, natomiast subagenty GPT-5.4 mini mogą równolegle wykonywać węższe zadania (przeszukiwanie bazy kodu, przegląd plików, przetwarzanie dokumentów).⁷⁶

Bedrock GPT-5.6 (Sol, Terra, Luna) (v0.143.0, 8 lipca 2026): w Codex dodano bezpośrednią obsługę trzech wariantów modelu GPT-5.6 hostowanych w Amazon Bedrock, w tym poziomu nakładu na rozumowanie max. Zespoły korzystające z modeli za pośrednictwem dostawcy Bedrock mogą wybierać je tak samo jak inne modele niestandardowych dostawców (zob. Niestandardowi dostawcy modeli); poziom max jest przeznaczony do najtrudniejszych zadań wymagających rozumowania i autonomicznego działania.¹⁰⁶ W wersji v0.144.6 (18 lipca 2026) zaktualizowano dołączone instrukcje dla modeli Sol, Terra i Luna oraz skorygowano ich okna kontekstu do 272 000 tokenów.¹¹¹ Wersja v0.145.0 (21 lipca 2026) dodaje eksperymentalne logowanie do Bedrock z obsługą niestandardowego punktu końcowego i uwierzytelniania, ustanawia GPT-5.6 Sol domyślnym modelem Bedrock oraz przenosi dołączone wybory modeli GPT-5.4 do odpowiadających im wariantów Terra i Luna.¹¹²

GPT-6-Astra (v0.153.1, wyłącznie etap przygotowania katalogu): wersja v0.153.1 przenosi wpis GPT-6-Astra w katalogu modeli do wersji stabilnej, z możliwością konfiguracji wyłącznie przez API — model domyślny i selektor modeli pozostają bez zmian, a dostępność, ceny ani możliwości nie zostały ogłoszone. Należy to traktować jako przygotowanie katalogu przed ewentualną premierą, a nie samą premierę: linia 0.154.0-alpha przygotowuje dołączone katalogi GPT-6-Astra i Amazon Bedrock (#42607, #42619), natomiast jedyna poprawka w wersji v0.153.2 koryguje tekst opisu wariantu Astra Fast z „1.5x” na „2x speed, increased usage” — jest to wyłącznie zmiana wyświetlanego tekstu.^142143144

Schemat wyboru modelu

Is this a quick fix or simple question?
├─ Yes → gpt-5.6-luna (fastest, most affordable)
└─ No
   ├─ Do you need real-time pairing speed?
   │  ├─ Yes → gpt-5.3-codex-spark (near-instant, Pro only)
   │  └─ No
   │     ├─ Subagent or parallel subtask (search, review, processing)?
   │     │  ├─ Yes → gpt-5.6-luna (the bundled subagent pick since v0.145.0)
   │     │  └─ No
   │     │     ├─ Everyday coding task (refactor, migration, feature build)?
   │     │     │  ├─ Yes → gpt-5.6-terra (everyday model, 272K context)
   │     │     │  └─ No → gpt-5.6-sol (flagship — the default "Power" setting)
   └─ Still unsure? → gpt-5.6-sol

Nakład na rozumowanie

Można kontrolować, jak długo model „myśli” przed udzieleniem odpowiedzi:

Obsługiwane poziomy zależą od modelu. Poziom minimal jest dostępny wyłącznie dla modeli GPT-5. Nie każdy model obsługuje wszystkie poziomy.

Szczegóły dotyczące persistent (v0.151.0): w turach działających z nakładem persistent domyślnie włączane są przypomnienie o bieżącym czasie oraz przerywalne narzędzie clock.sleep (jawne ustawienia features.current_time_reminder i zarządzane wymagania zostają zachowane), a także dołączane są wskazówki dotyczące proaktywności i dalszych działań, które metadane modelu mogą zastąpić lub wyłączyć za pomocą persistent_instructions.¹³⁵

codex -c model_reasoning_effort="xhigh" "find the race condition"

Wskazówka dla ekspertów: przy tym samym prompcie rozumowanie xhigh może zużywać od 3 do 5 razy więcej tokenów niż medium. Warto zarezerwować je dla naprawdę trudnych problemów, w których dodatkowe rozumowanie przynosi wymierne korzyści.

Szybkie sterowanie poziomem rozumowania w TUI (v0.124.0+).⁸⁵ W interaktywnej sesji TUI klawisze Alt+, obniżają poziom rozumowania o jeden stopień, a Alt+. podnoszą go o jeden stopień — jest to przydatne, gdy trudny problem napotkany w trakcie sesji uzasadnia tymczasowe zwiększenie poziomu medium → high → xhigh bez używania /effort ani -c. Po zaakceptowaniu uaktualnienia modelu w trakcie sesji poziom rozumowania zostaje przywrócony do wartości domyślnej nowego modelu zamiast zachowania wcześniejszego poziomu.

Przełączanie modeli

Model można przełączyć w trakcie sesji za pomocą slash command /model albo ustawić dla pojedynczego uruchomienia przy użyciu --model / -m:

codex -m gpt-5.3-codex-spark "pair with me on this component"

Ile kosztuje Codex?

Informacje o możliwościach zawiera również sekcja Wybór modelu, a wskazówki dotyczące doboru odpowiedniego modelu do zadania — sekcja Ramy decyzyjne.

Dostęp w ramach planów ChatGPT

Dostępność Codex zależy od planu ChatGPT i ustawień organizacji:⁵¹

Aktualizacja cen z kwietnia 2026: roczna cena planu Business spadła z $25 do $20 za stanowisko miesięcznie. W przestrzeniach roboczych Business i Enterprise są teraz dostępne stanowiska tylko z Codex rozliczane zgodnie z użyciem — bez stałej opłaty za stanowisko, z rozliczeniem na podstawie zużycia tokenów.⁷⁹ Na stronie z cennikiem limity są obecnie publikowane jako przedziały zależne od modelu (zob. tabela powyżej), a nie jako promocyjne mnożniki 2x z premiery Codex Desktop App w lutym 2026.¹⁶¹⁴⁶

Zwiększenie limitów użycia w maju 2026 (wygasło 31 maja 2026): Codex w planie Plus działał z 25-krotnie zwiększonym limitem 5-godzinnym (w porównaniu ze standardowym zwiększeniem 20x), a limit w planie za $100 miesięcznie został podwojony na ten sam okres.⁸⁹

Obsługa limitów użycia w TUI (v0.152.0–v0.153.0): osiągnięcie limitu nie oznacza już braku możliwości kontynuowania pracy. W wersji v0.152.0 nad polem wprowadzania są wyświetlane banery limitów użycia z dostępnymi działaniami — sprawdzeniem użycia, zarządzaniem kredytami, resetowaniem limitów, powiadomieniem właściciela przestrzeni roboczej oraz zarządzaniem planami — filtrowane odpowiednio do uwierzytelnionego konta i użytkownika; dane o użyciu są odświeżane po błędach związanych z limitami, a gdy wskazuje to baner, Codex przełącza się na pierwszy dostępny model zapasowy bez zmiany niezwiązanych z tym ustawień wątku.¹³⁸ W wersji v0.153.0 dodano wcześniejsze ostrzeżenia dla planów Plus i Team: ostrzeżenie pojawia się, gdy w około 5-godzinnym oknie użycia pozostaje mniej niż połowa przydziału, natomiast w innych planach i dla okien o innej długości nadal obowiązują dotychczasowe progi 75%, 90% i 95%.¹⁴⁰

Koszty w kredytach

Operacje Codex zużywają kredyty z przydziału w ramach planu:

W praktyce „użycie GPT-5.6 wynosi średnio 5–40 kredytów na wiadomość”; tryb szybki zużywa kredyty w większym tempie w obsługiwanych modelach, a generowanie obrazów wyczerpuje uwzględnione limity 3–5 razy szybciej niż porównywalne interakcje obejmujące wyłącznie tekst.¹⁴⁶

W planach Enterprise i Edu liczba kredytów skaluje się zgodnie z przydziałem określonym w umowie. Bieżące użycie można sprawdzić za pomocą /status w TUI.

Rozliczenia API

Podczas korzystania z Codex za pośrednictwem API OpenAI nalicza opłaty za każdy token zgodnie ze standardowym cennikiem OpenAI dla API wybranego modelu (z uwzględnieniem ewentualnych rabatów za buforowanie promptów). Aktualne stawki można znaleźć na oficjalnej stronie cennika API.²⁰

Strategie optymalizacji kosztów

1. Korzystanie z profili: utworzyć profil fast z modelem gpt-5.6-luna i ustawieniem model_reasoning_effort = "low" do rutynowych zadań
2. Rezerwowanie intensywnego rozumowania: używać xhigh wyłącznie do rzeczywiście trudnych problemów, ponieważ zużywa 3–5 razy więcej tokenów
3. Korzystanie z --ephemeral: pominąć utrwalanie sesji w CI/CD, aby zmniejszyć narzut
4. Ograniczenie podsumowań rozumowania: ustawić model_reasoning_summary = "none", gdy wyjaśnienia nie są potrzebne
5. Przetwarzanie wsadowe w trybie exec: codex exec eliminuje narzut TUI w zautomatyzowanych przepływach pracy
6. Monitorowanie użycia: sprawdzać /status w TUI oraz panele rozliczeniowe organizacji — od wersji v0.148.0 /status, wiersze stanu i tytuły terminali pokazują szacunkową liczbę kredytów lub koszt wątku w obsługiwanych przestrzeniach roboczych¹¹⁸

Przykłady rzeczywistych kosztów

Reprezentatywne koszty API typowych zadań (według cennika gpt-5.3-codex z połowy 2026 roku, przy średnim poziomie rozumowania — względne proporcje pozostają podobne w różnych modelach):

Koszty zależą od poziomu rozumowania, buforowania i długości rozmowy. Do rutynowych zadań warto używać gpt-5.6-luna, aby znacząco ograniczyć związane z nimi wydatki. Tokeny wejściowe z pamięci podręcznej są rozliczane według obniżonej stawki.

Ukryty narzut tokenów

Każde wywołanie narzędzia zużywa dodatkowe tokeny, które nie są widoczne w prompcie:

Wskazówka dla ekspertów: rzeczywiste użycie można monitorować za pomocą /status w TUI. Liczba tokenów obejmuje cały narzut, a nie tylko widoczne wiadomości. Jeśli koszty okażą się zaskakujące, warto sprawdzić liczbę połączonych serwerów MCP — każdy z nich dodaje definicje narzędzi do każdego wywołania API.

Zarządzanie kosztami zespołu

Strategie kontrolowania kosztów zespołu: - Ustawić requirements.toml, aby wymusić w całej organizacji limity dotyczące modeli i poziomu rozumowania - Używać gpt-5.6-luna w CI/CD — zautomatyzowane potoki rzadko wymagają maksymalnego poziomu rozumowania - Budżetowanie oparte na profilach — zdefiniować profile ci, review i dev z odpowiednimi limitami kosztów - Monitorowanie za pomocą OpenTelemetry — wdrożenia korporacyjne mogą eksportować dane telemetryczne dotyczące użycia do istniejących stosów obserwowalności

Schematy decyzyjne

Kiedy używać poszczególnych interfejsów

Kiedy używać poszczególnych trybów sandbox

Kiedy używać poszczególnych poziomów rozumowania

Tryb planowania a bezpośrednie wykonanie

Will Codex need to change more than 3 files?
│
├── YES → Use Plan Mode (/plan)
│         Codex designs the approach BEFORE making changes.
│         You review and approve the plan.
│         Best for: refactors, new features, migrations
│
└── NO → Is the change well-defined?
         │
         ├── YES → Direct execution
         │         Just describe the task. Codex executes immediately.
         │         Best for: bug fixes, small features, test additions
         │
         └── NO → Use Plan Mode (/plan)
                  Let Codex explore and propose an approach first.
                  Best for: unfamiliar codebases, ambiguous requirements

Tryb sterowania: Enter a Tab

Praktyczna zasada: Enter = „zatrzymaj się i wysłuchaj tego teraz”. Tab = „po zakończeniu wykonaj również to”.

Aplikacja komputerowa a CLI

How do you prefer to work?
│
├── Terminal-first → Use CLI
│   │
│   ├── Single focused task → codex (interactive TUI)
│   ├── Scripted automation → codex exec (non-interactive)
│   └── Quick one-shot → codex exec "prompt" -o result.txt
│
└── Visual/multi-project → Use Desktop App
    │
    ├── Multiple parallel tasks → Multi-thread with worktree isolation
    ├── Visual diff review → Built-in Git diff viewer
    ├── Scheduled automation → Automations tab
    └── Voice-driven → Ctrl+M for voice dictation

Który profil wybrać?

Należy dopasować zadanie do wstępnie skonfigurowanego profilu:

Pliki profili (po jednym dla każdego ustawienia wstępnego, w ~/.codex/; starszy układ pojedynczego pliku profile = "default" + [profiles.*] nie jest odczytywany od wersji 0.134.0¹²²):

# ~/.codex/fast.config.toml
model = "gpt-5.6-luna"
model_reasoning_effort = "low"

# ~/.codex/careful.config.toml
model = "gpt-5.5"
model_reasoning_effort = "xhigh"

# ~/.codex/pair.config.toml
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "high"

# ~/.codex/ci.config.toml
model = "gpt-5.6-luna"
model_reasoning_effort = "low"
sandbox_mode = "workspace-write"

Przełączanie profili dla poszczególnych sesji: codex --profile careful

Jak działa system sandbox i zatwierdzania?

Codex korzysta z dwuwarstwowego modelu zabezpieczeń, który oddziela to, co jest technicznie możliwe, od tego, kiedy Codex prosi człowieka o zatwierdzenie. Podejście to zasadniczo różni się od systemu uprawnień Claude Code — Codex wymusza ograniczenia na poziomie jądra systemu operacyjnego.⁵ Informacje o ograniczeniach requirements.toml, które administratorzy egzekwują w całej organizacji, znajdują się również w sekcji Wdrożenie korporacyjne.

Wzmocnienie zabezpieczeń w wersji v0.148.0: ograniczenia sandbox działają teraz zgodnie z zasadą fail closed — ścieżka, do której odmówiono dostępu lub której nie można odczytać, jest uznawana za zablokowaną, a nie po cichu dozwoloną — zarówno w systemie Linux, jak i Windows.¹¹⁸

Warstwa 1: sandbox (co jest możliwe)

Sandbox kontroluje dostęp do systemu plików i sieci za pomocą natywnych mechanizmów systemu operacyjnego:

Mechanizmy wymuszania zależne od platformy:

• macOS: framework Seatbelt firmy Apple używany za pośrednictwem sandbox-exec, z profilami właściwymi dla poszczególnych trybów, kompilowanymi podczas działania i wymuszanymi przez jądro systemu⁶. Od wersji v0.121.0 profile sandbox w systemie macOS mogą umieszczać określone gniazda Unix na liście dozwolonych (np. docker.sock i gniazda IPC edytora), a prywatne rozpoznawanie DNS nie jest już domyślnie blokowane.⁸²
• Linux: Landlock do ograniczania dostępu do systemu plików oraz seccomp do filtrowania wywołań systemowych. Samodzielny proces pomocniczy (codex-linux-sandbox) zapewnia wielowarstwową izolację.⁵ Bubblewrap (bwrap) jest dostarczany wraz z projektem i kompilowany jako część wydania dla systemu Linux (od wersji v0.100.0 nie jest już składnikiem opcjonalnym)⁷. Wersja v0.117.0 zwiększyła niezawodność sandbox w starszych dystrybucjach ze starszymi konfiguracjami jądra.⁷⁵ Wersja v0.129.0 wzmocniła uruchamianie sandbox w systemie Linux i zaktualizowała dołączony Bubblewrap do wersji 0.11.2 wraz z poprawkami zabezpieczeń z projektu źródłowego; wersja v0.130.0 dodała kolejne zabezpieczenia procesu uruchamiania.⁸⁹⁹¹
• Windows: natywny sandbox z tokenami o ograniczonych uprawnieniach (od wersji v0.100.0 nie jest już funkcją eksperymentalną). Obsługiwany jest również WSL (dziedziczy Landlock i seccomp z systemu Linux). Wersja v0.117.0 zawiera ulepszenia sandbox wykorzystującego tokeny o ograniczonych uprawnieniach, które zapewniają lepszą izolację procesów.⁷⁵ Wersja v0.130.0 przyznaje użytkownikom sandbox dostęp do pamięci podręcznej binariów środowiska wykonawczego aplikacji komputerowej, dzięki czemu sandbox systemu Windows może niezawodnie odnajdywać binaria środowiska wykonawczego użytkowników korzystających z sandbox obszaru roboczego.⁹¹

Dlaczego ma to znaczenie: w przeciwieństwie do sandbox opartego na kontenerach (Docker) rozwiązanie działające na poziomie systemu operacyjnego jest szybsze, lżejsze i trudniejsze do obejścia. Jądro wymusza ograniczenia, zanim Codex w ogóle zobaczy wywołanie systemowe.

Poprawki zabezpieczeń: - Obejście sandbox przez zsh-fork (v0.106.0): usunięto lukę, która pozwalała wykonywaniu poleceń powłoki przez rozwidlanie procesów zsh omijać ograniczenia sandbox.⁶⁰ W przypadku korzystania ze starszej wersji należy natychmiast przeprowadzić aktualizację. - Limit rozmiaru danych wejściowych (v0.106.0): Codex wymusza teraz limit danych wejściowych wynoszący około 1 miliona znaków, aby zapobiegać zawieszaniu się programu wskutek przetwarzania nadmiernie dużych danych.⁶⁰ - Bezpieczny profil devcontainera (v0.121.0): nowy, wzmocniony profil klienta dla devcontainerów Docker używa Bubblewrap do tworzenia sandbox wewnątrz kontenera. WSL2 jest obsługiwany; WSL1 jest jawnie odrzucany (Bubblewrap nie jest zgodny z warstwą pośrednią jądra WSL1).⁸² - Przegląd Guardian i hooks (v0.121.0): hooks są wyłączone podczas sesji przeglądu Guardian, aby hooks uruchamiane przed użyciem narzędzia i po nim nie mogły wpływać na decyzje subagenta Guardian.⁸² Jeżeli hooks służą do rejestrowania zdarzeń lub walidacji, należy pamiętać, że przegląd Guardian je pomija — gdy wymagany jest pełny ślad audytowy, należy skorzystać z obserwowalności serwera aplikacji. - System plików /dev w systemie Linux (v0.105.0): polecenia uruchamiane w sandbox w systemie Linux otrzymują teraz minimalny system plików /dev, co zwiększa zgodność z narzędziami oczekującymi węzłów urządzeń.⁶¹

Zasady ReadOnlyAccess (v0.100.0+): konfigurowalna struktura zasad umożliwiająca precyzyjną kontrolę dostępu do odczytu. Pozwala ograniczyć katalogi, z których Codex może odczytywać dane, nawet w trybie workspace-write:

[sandbox_workspace_write]
read_only_access = ["/etc", "/usr/local/share"]  # Only these paths readable outside workspace

Warstwa 2: zasady zatwierdzania (kiedy pytać)

Zasady zatwierdzania określają, kiedy Codex wstrzymuje działanie, aby poprosić człowieka o potwierdzenie:

on-failure nadal występuje w niektórych starszych przykładach i ścieżkach zgodności, jednak aktualna dokumentacja konfiguracji OpenAI oznacza tę wartość jako przestarzałą. W przypadku sesji interaktywnych należy preferować on-request, a przy uruchomieniach nieinteraktywnych, które mają już zewnętrzną granicę bezpieczeństwa — never.⁸⁷

Od wersji v0.150.0 można przypisać skrót klawiszowy przełączający cyklicznie tryby uprawnień z poziomu edytora poleceń — należy skonfigurować go za pomocą /keymap.¹³²

Odrębne identyfikatory zatwierdzeń (v0.104.0+)

Codex przypisuje teraz odrębny identyfikator zatwierdzenia każdemu poleceniu w ramach wieloetapowego wykonania w powłoce. Dzięki temu zatwierdzanie jest precyzyjne — zatwierdzenie jednego polecenia w sekwencji nie powoduje automatycznego zatwierdzenia kolejnych poleceń w tym samym wywołaniu powłoki.⁴⁹

Elastyczne mechanizmy zatwierdzania (v0.105.0+)

Proces zatwierdzania obsługuje teraz dodatkowe uprawnienia sandbox oraz precyzyjne odrzucanie:⁶¹

• Dodatkowe uprawnienia sandbox: gdy polecenie potrzebuje dostępu wykraczającego poza bieżący tryb sandbox, Codex może poprosić o konkretne dodatkowe uprawnienia zamiast wymagać pełnej zmiany trybu
• Precyzyjne odrzucanie: poszczególne wywołania narzędzi można odrzucać wraz z informacją zwrotną, aby Codex mógł dostosować swoje podejście zamiast ponawiać dokładnie to samo polecenie

Żądania uprawnień podczas działania (v0.113.0+)

Codex zawiera teraz wbudowane narzędzie request_permissions, które umożliwia modelowi żądanie dodatkowych uprawnień podczas działania.⁶⁹ Gdy model napotka zadanie wymagające rozszerzonego dostępu, może formalnie poprosić o konkretne uprawnienia (do ścieżek systemu plików, sieci itd.) w ramach procesu zatwierdzania w TUI, zamiast po cichu zakończyć się niepowodzeniem lub wymagać od użytkownika ponownego uruchomienia z innymi flagami.

Tryb zatwierdzania aplikacji writes (v0.144.0+)

Aplikacje i konektory otrzymują pośredni poziom zatwierdzania: tryb zatwierdzania aplikacji writes pozwala wykonywać zadeklarowane przez aplikację działania tylko do odczytu bez wyświetlania monitu, a jednocześnie nadal wstrzymuje każdą operację zapisu.¹⁰⁷ Wcześniej zatwierdzanie aplikacji było bliższe zasadzie „wszystko albo nic”; writes odpowiada modelowi zaufania, którego większość operatorów rzeczywiście oczekuje od integracji — swoboda przeglądania, pytanie przed wprowadzeniem zmian.

Automatycznie weryfikowane zatwierdzenia: --approve-for-me (v0.147.0+)

Nowa flaga CLI --approve-for-me zmienia monity o zatwierdzenie w automatycznie weryfikowane zatwierdzenia: zamiast przerywać pracę użytkownika, każde żądanie jest oceniane w ramach przeglądu i zatwierdzane lub odrzucane w jego imieniu.¹¹⁶ Rozwiązanie to znajduje się pomiędzy „zatwierdzaniem wszystkiego” (postawą, do której zachęcało usunięte już --full-auto) a „przerywaniem działania przy każdej operacji” — monity nadal stanowią punkty decyzyjne, ale odpowiada na nie mechanizm przeglądu. Warto połączyć tę flagę z bezpieczniejszymi ustawieniami domyślnymi automatycznego przeglądu dla modeli obsługujących zadania cyberbezpieczeństwa z wersji v0.146.1, które flaga ta dziedziczy. Należy traktować ją jak każde przekazanie uprawnień: sprawdza się podczas długich, nienadzorowanych zadań, w których przerwanie oznacza zatrzymanie pracy, lecz nie nadaje się do sesji obejmujących dane uwierzytelniające lub stan produkcyjny, gdy przegląd powinien należeć do użytkownika.

Zatwierdzanie rozszerzonego dostępu do wejścia terminala (v0.151.0)

Flaga funkcji write_stdin_approval — domyślnie wyłączona — wymaga nowego zatwierdzenia przed wysłaniem niepustych danych wejściowych do terminala unified-exec działającego z rozszerzonymi uprawnieniami. Te przeglądy są przekazywane przez hooks, Guardian, serwer aplikacji oraz TUI jako zatwierdzenia writeStdin; środowisko terminala, katalog uruchomienia i stan rozszerzonych uprawnień są zachowywane między turami, a po zatwierdzeniu tożsamość procesu jest ponownie weryfikowana przed zapisaniem jakichkolwiek bajtów. W pełni sformatowane działanie i powód zatwierdzenia muszą mieścić się w 8 000 bajtów — działania przekraczające ten limit lub ucięte są odrzucane, zanim pojawi się prośba o zatwierdzenie lub cokolwiek trafi do terminala.¹³⁵

Profile uprawnień (v0.113.0+, rozszerzone w wersjach v0.128.0 i v0.133.0)

Profile uprawnień rozdzielają zasady sandbox dotyczące systemu plików i sieci na nazwane sekcje wielokrotnego użytku. Dla default_permissions należy ustawić wbudowany profil, taki jak :read-only lub :workspace, albo wskazać niestandardową tabelę [permissions.<name>].⁸⁷ Wersja v0.133.0 ustanawia profile jako zarządzany element konfiguracji: listy API udostępniają metadane dostępnych profili, profile mogą dziedziczyć po sobie, zarządzany plik requirements.toml może deklarować wymagania dotyczące uprawnień, aktywne profile są odświeżane podczas działania, a konfiguracja sandbox systemu Windows korzysta teraz z wynikowego profilu zamiast z osobnych zasad tworzonych ad hoc.⁹⁸

default_permissions = "project-safe"

[permissions.project-safe.filesystem]
"/usr/local" = "read"
glob_scan_max_depth = 3

[permissions.project-safe.filesystem.":project_roots"]
"." = "write"
"**/*.env" = "none"

[permissions.project-safe.network]
enabled = true
mode = "limited"

[permissions.project-safe.network.domains]
"api.github.com" = "allow"
"registry.npmjs.org" = "allow"

W przypadku poufnych plików i globów, które powinny pozostać nieczytelne nawet wtedy, gdy można zapisywać w katalogu głównym projektu, należy używać none. Dla jednorazowych wyjątków dotyczących poleceń lepiej stosować reguły niż szeroko rozszerzać profil.⁸⁷

v0.151.0: przywrócone wątki serwera aplikacji zachowują swoje profile uprawnień zamiast przekształcać je w starsze, indywidualne nadpisania sandbox dla każdej tury — profile pozostają aktywne podczas przekierowywania tur i zgodnych zmian katalogu za pomocą /cd, natomiast polecenie /cd, które nie może bezpiecznie odwzorować przywróconego profilu jako starszego trybu sandbox, zostaje odrzucone zamiast po cichu osłabiać ograniczenia.¹³⁴

Starsze zalecenia dotyczące --full-auto

Starsze przewodniki opisywały --full-auto jako wygodny alias dla:

codex --sandbox workspace-write --ask-for-approval on-request

W informacjach o wydaniu v0.128.0 opcję --full-auto oznaczono jako przestarzałą, a aktualna pomoc CLI nie wymienia jej już dla uruchomień interaktywnych. Zamiast niej należy używać powyższych jawnych flag lub nazwanego profilu uprawnień.⁸⁶

Wersja v0.147.0 kończy proces usuwania tej opcji: codex exec --full-auto już nie istnieje. Skrypt, który nadal przekazuje tę flagę, kończy się teraz błędem zamiast się uruchomić. Migracja jest mechaniczna — należy zastąpić ją opcją --sandbox workspace-write (oraz flagą zatwierdzania lub profilem, jeżeli stare wywołanie polegało na zachowaniu zatwierdzania zapewnianym przez --full-auto). Przed aktualizacją należy sprawdzić każdą automatyzację wywołującą codex exec za pośrednictwem powłoki: problem objawia się awarią potoku, a nie ostrzeżeniem o przestarzałej funkcji.¹¹⁶

Niezawodność sandbox (v0.129.0): wzmocnienie procesu uruchamiania sandbox w systemie Linux ogranicza sytuacje wyścigu w przypadku wolnych systemów plików lub katalogów roboczych używających dowiązań symbolicznych; ulepszenia niezawodności sandbox w systemie Windows eliminują kilka awarii występujących w przypadkach brzegowych podczas długotrwałych zadań; ponadto dołączony Bubblewrap zaktualizowano do wersji 0.11.2 wraz z poprawkami zabezpieczeń z projektu źródłowego. Zmiany konfiguracji nie są wymagane. Aby je uzyskać, należy uruchomić codex update.⁸⁹

Zalecane konfiguracje

Codzienna praca programistyczna (bezpieślne ustawienie domyślne):

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Zaawansowany użytkownik (pełny dostęp, człowiek w procesie decyzyjnym):

sandbox_mode = "danger-full-access"
approval_policy = "on-request"   # `untrusted` retired in v0.149.0

Materiały społeczności polecają to połączenie jako „idealny kompromis”⁸; przed powielaniem tej porady warto jednak zrozumieć, co naprawdę oznacza: monity o zatwierdzenie pojawiają się, gdy polecenie musi wyjść poza sandbox lub uzyskać dostęp do sieci, natomiast danger-full-access usuwa obie te granice, przez co przy on-request niemal nie pozostaje nic do eskalowania. Jest to konfiguracja zapewniająca maksymalne możliwości przy minimalnej liczbie pytań, a nie maksymalne możliwości z kontrolą człowieka nad każdym poleceniem; aby uzyskać ten drugi wariant, należy zachować workspace-write i pozwolić, by granica sandbox wywoływała monity.¹²³

Automatyzacja CI/CD:

sandbox_mode = "workspace-write"
approval_policy = "never"

Inteligentne zatwierdzanie z subagentem Guardian (v0.115.0+)

Smart Approvals może przekazywać żądania przeglądu do subagenta Guardian, eliminując konieczność zatwierdzania każdego działania przez człowieka. Sesja Guardian jest zachowywana pomiędzy zatwierdzeniami, aby ponownie wykorzystywać pamięć podręczną promptów i unikać narzutu związanego z uruchamianiem. Każdy przegląd otrzymuje czystą historię (wcześniejsze decyzje nie przenikają do kolejnych przeglądów).⁷³

Mechanizm przeglądu należy skonfigurować w pliku config.toml:

approvals_reviewer = "guardian_subagent"   # "user" (default) or "guardian_subagent"

Jest to szczególnie przydatne w procesach CI/CD, w których potrzebny jest automatyczny przegląd wraz z uzasadnieniem, a nie ogólne ustawienie approval_policy = "never".

Odwrócenie ustawień domyślnych Guardian v2 (v0.151.0): Guardian v2 domyślnie przeprowadza teraz przeglądy operacji obsługi komputera wraz z obrazami. Wartość domyślna features.guardianv2.review_scope.computer_use_only to true — aby zachować szerszy zakres przeglądu narzędzi, należy ustawić ją na false — natomiast wartość domyślna features.guardianv2.transcript.include_images to true — aby wykluczyć obrazy z transkrypcji Guardian, należy ustawić ją na false. Obie funkcje pojawiły się w wersji v0.150.0 jako konfigurowalne i domyślnie wyłączone; dopiero wersja v0.151.0 włączyła je domyślnie.¹³⁵

Zakres Guardian jest zgodny z trybem zatwierdzania (v0.153.0): dwa tryby pomijają teraz pracę Guardian, która nie może zmienić wyniku. W trybie Full Access (który już łączy approvalPolicy: "never" z nieograniczonymi uprawnieniami) żądania Guardian i MCP wymagające wyłącznie potwierdzenia są zatwierdzane bez synchronicznego przeglądu, wstępnego rozgrzewania samplera ani oceniania w tle — środowiska oczekujące, uszkodzone lub ograniczone nie są uznawane za Full Access, a aktywny stan uprawnień jest ponownie oceniany w każdej turze, dzięki czemu istniejący wątek może bezpiecznie przechodzić do trybu Full Access i z niego wychodzić. W trybie zatwierdzania przez użytkownika (approvals_reviewer = "user") pomijane są wstępne rozgrzewanie Guardian i asynchroniczne ocenianie, a zwykłe potwierdzenia wykonania node_repl.js są akceptowane automatycznie; kontrole działań poufnych i żądania danych wejściowych od użytkownika zachowują dotychczasowe działanie.¹⁴⁰ Zawęża to zakres sytuacji, w których uruchamiany jest Guardian, a nie warstwę zatwierdzania przez człowieka: opisane w tym przewodniku monity dla danger-full-access przy on-request wynikają z zasad zatwierdzania, czyli osobnego mechanizmu. Ponadto v0.152.1 pozwala przeglądowi zatwierdzeń Guardian pobierać zasady Node REPL z metadanych modelu (auto_review.node_repl_policy), a gdy pole jest nieobecne, używa dołączonych zasad.¹³⁹

Ocenianie obsługi komputera przez Guardian respektuje wymagania modelu (v0.153.1): ocenianie Guardian ograniczone do obsługi komputera oraz szybkie decyzje zatwierdzające są teraz wykonywane tylko wtedy, gdy aktywny model ma ustawioną w metadanych wartość node_repl_auto_review_required, a wcześniejsze lub trwające oceny zostają unieważnione, gdy zmiana modelu powoduje pominięcie oceniania — dzięki temu powrót do modelu podlegającego przeglądowi nie może przywrócić nieaktualnej decyzji zatwierdzającej. Jest to najważniejsza zmiana poprawki v0.153.1, choć nie została wymieniona w treści informacji o wydaniu: #42422 (cherry-pick zmiany 38ba8cdc) można potwierdzić wyłącznie za pomocą porównania rust-v0.153.0…rust-v0.153.1.¹⁴²

Zaostrzenie klasyfikatora PowerShell (v0.142.2): polecenia PowerShell zawierające wykonywalne regiony AST, których klasyfikator bezpieczeństwa nie może sprawdzić, wymagają teraz zatwierdzenia, zamiast przechodzić przez mechanizm automatycznego zatwierdzania — eliminuje to lukę, dzięki której zaciemnione lub dynamicznie tworzone polecenia PowerShell mogły unikać klasyfikacji w systemie Windows.¹⁰⁵

Rozszerzone wykrywanie niebezpiecznych poleceń (v0.144.5): mechanizm wykrywania rozpoznaje teraz więcej wymuszonych wariantów polecenia rm, a odrzucone polecenia otrzymują jaśniejsze uzasadnienia odrzucenia zamiast nieprzejrzystej odmowy — jest to przydatne podczas dostrajania zasad zatwierdzania, gdy trzeba ustalić, dlaczego polecenie zostało zablokowane.¹¹⁰

Włączanie dostępu do sieci

Codex domyślnie blokuje dostęp do sieci w trybie workspace-write. W razie potrzeby można go włączyć:

# Per-run
codex -c 'sandbox_workspace_write.network_access=true' "install the packages"

# In config.toml
[sandbox_workspace_write]
network_access = true
writable_roots = ["/path/to/extra/dir"]   # Additional writable directories
exclude_slash_tmp = false                  # Prevent /tmp from being writable
exclude_tmpdir_env_var = false             # Prevent $TMPDIR from being writable

Obsługa proxy WebSocket (v0.104.0+)

W środowiskach firmowych, które kierują ruch WebSocket przez proxy, Codex obsługuje teraz zmienne środowiskowe WS_PROXY i WSS_PROXY:⁴⁹

export WSS_PROXY="https://proxy.corp.example.com:8443"
codex "update the README"

Uzupełniają one istniejącą obsługę proxy HTTPS_PROXY i SOCKS5 (v0.93.0+).

Wersja v0.146.0 sprawiła, że określenie „wszystkie warstwy transportowe” stało się faktycznie prawdziwe. Skonfigurowane proxy są teraz respektowane podczas uwierzytelniania, pobierania pluginów, autoryzacji MCP, wykonywania zdalnego, połączeń WebSocket, przekierowań HTTP oraz połączeń z LM Studio — dziennik zmian wymienia siedem ścieżek, które wcześniej ignorowały proxy.¹¹⁴ Jeżeli przed wersją v0.146.0 Codex działał za firmowym proxy, a logowanie lub instalowanie pluginów kończyło się niepowodzeniem mimo poprawnego działania zwykłych wywołań modelu, prawdopodobną przyczyną była właśnie ta luka.

Systemowe proxy w macOS (v0.142.2+): po włączeniu respect_system_proxy klienci uwierzytelniania w systemie macOS respektują ustawienia systemowego proxy, PAC i WPAD — dzięki temu firmowe komputery Mac, na których konfiguracja proxy jest wdrażana za pomocą profili, nie wymagają już zmiennych środowiskowych proxy ustawianych osobno dla każdej powłoki w celu obsługi ruchu uwierzytelniającego.¹⁰⁵ Od wersji v0.143.0 dotyczy to również systemu Windows oraz ruchu Responses API: Codex kieruje zarówno uwierzytelnianie, jak i wywołania Responses API przez systemowe proxy macOS lub Windows, w tym automatyczną konfigurację PAC i WPAD, eliminując ostatnią lukę w ściśle kontrolowanych sieciach firmowych na obu systemach operacyjnych.¹⁰⁶

Testowanie sandbox

Przed uznaniem sandbox za zaufany należy sprawdzić jego działanie:

codex sandbox macos --permissions-profile :workspace -- ls /etc/passwd   # macOS test
codex sandbox linux --permissions-profile :workspace -- cat /etc/shadow  # Linux test

Jeżeli sandbox działa prawidłowo, oba polecenia powinny zakończyć się błędem odmowy dostępu w profilu ograniczonym do obszaru roboczego. Jeśli którekolwiek polecenie powiedzie się, konfiguracja sandbox wymaga zbadania.

Jak działa AGENTS.md?

AGENTS.md to system instrukcji projektowych Codex — otwarty standard⁹, którym obecnie zarządza Agentic AI Foundation działająca przy Linux Foundation. Obsługują go Codex, Cursor, Copilot, Amp, Jules (Google), Gemini CLI, Windsurf, Cline, Aider, Zed, Factory, RooCode oraz ponad 60 000 projektów open source. Określa on sposób działania Codex w konkretnym repozytorium lub folderze. Pakiety wiedzy wielokrotnego użytku, które uzupełniają AGENTS.md, opisano w sekcji Skills.

Hierarchia wykrywania

Na początku sesji Codex tworzy łańcuch instrukcji, przechodząc po drzewie folderów:

1. Globalnie (~/.codex/): AGENTS.override.md > AGENTS.md
2. W projekcie (od głównego folderu repozytorium git do bieżącego folderu): Na każdym poziomie sprawdzane są kolejno AGENTS.override.md > AGENTS.md > zastępcze nazwy plików
3. Scalanie: Pliki są łączone od głównego folderu w dół; pliki znajdujące się bliżej bieżącego folderu pojawiają się później w prompcie i zastępują wcześniejsze wytyczne

~/.codex/AGENTS.md                     ← Global defaults
  └─ /repo/AGENTS.md                   ← Project-wide rules
      └─ /repo/services/AGENTS.md      ← Service-specific rules
          └─ /repo/services/payments/
               AGENTS.override.md      ← Overrides everything above for this dir

Niezaufane projekty pomijają projektowy AGENTS.md (v0.150.0): opisane powyżej przechodzenie zakłada, że projekt jest zaufany. Od wersji v0.150.0 „niezaufane projekty nie dostarczają już instrukcji z projektowego pliku AGENTS.md, a zarządzane reguły odmowy odczytu pozostają egzekwowane po zmianach uprawnień” — wykrywanie w zakresie projektu jest pomijane, natomiast instrukcje użytkownika z ~/.codex/AGENTS.md zostają zachowane, dzięki czemu niezaufana kopia robocza nie może wstrzyknąć zasad działania przed oznaczeniem jej jako zaufanej.¹³²

Projekty wielofolderowe w aplikacji desktopowej (26.715, 23 lipca 2026): opisane powyżej przechodzenie dotyczy CLI, który rozpoznaje wszystko względem bieżącego folderu roboczego. Aplikacja desktopowa ChatGPT pozwala teraz, aby lokalny projekt obejmował kilka powiązanych folderów, ale wykrywanie odbywa się względem dokładnie jednego z nich: „Nowe czaty, operacje Git oraz automatyczne wykrywanie AGENTS.md, skills i config.toml korzystają z folderu głównego. Foldery dodatkowe pozostają dostępne na potrzeby wyszukiwania, odczytywania i edytowania plików”. Folder główny można wybrać z menu projektu za pomocą opcji Edytuj projekt.¹¹³

To jedno ustawienie steruje jednocześnie 3 z 5 podstawowych systemów Codex — instrukcje, skills i konfiguracja korzystają z folderu głównego. W praktyce AGENTS.md znajdujący się w folderze dodatkowym jest plikiem, który Codex może otworzyć, a nie wczytywanym zestawem reguł działania. Jeśli repozytorium zawierające reguły zostało dołączone jako drugie, należy wyznaczyć je jako folder główny albo powtórzyć te reguły w pliku AGENTS.md folderu głównego; to samo dotyczy folderów skills w repozytorium, które miały być automatycznie wykrywane. W sposobie przechodzenia po folderach przez CLI nic się nie zmieniło — jest to jedynie określenie zakresu projektu w aplikacji desktopowej.

Co wyróżnia świetny plik AGENTS.md

Na podstawie bezpośrednich wytycznych samego Codex oraz wzorców stosowanych przez społeczność¹⁰:

NALEŻY: - Formułować konkretne instrukcje: "Use rg --files for discovery" jest lepsze niż "search efficiently" - Określić kryteria ukończenia: Co oznacza „gotowe”? (testy przechodzą, lint nie zgłasza błędów itd.) - Podawać polecenia: budowanie, testowanie, lintowanie i formatowanie (dokładne wywołania) - Organizować treść według zadań: sekcje dotyczące kodowania, przeglądu, wydania oraz incydentów/debugowania - Określić zasady eskalacji: Co zrobić w przypadku blokady lub napotkania nieoczekiwanego stanu

NIE NALEŻY: - Umieszczać całych przewodników po stylu bez reguł wykonawczych - Używać niejednoznacznych poleceń („zachowaj ostrożność”, „zoptymalizuj”) - Łączyć sprzecznych priorytetów (szybkość + wyczerpująca weryfikacja + brak budżetu na uruchamianie) - Pisać dokumentacji opisowej (AGENTS.md to zasady operacyjne, a nie README)

Przykład: produkcyjny AGENTS.md

# Repository Guidelines

## Build, Test, and Development Commands
- Run API (dev): `python3 -m uvicorn main:app --reload`
- Install deps: `pip install -r requirements.txt`
- Lint: `python3 -m ruff check .` (auto-fix: `--fix`)
- Format: `python3 -m ruff format .`
- Tests: `python3 -m pytest -v`
- Coverage: `python3 -m pytest --cov=app --cov-report=term-missing`

## Coding Style & Naming Conventions
- Python 3.11+. Type hints on all functions.
- Ruff enforced: 88-char lines, double quotes, spaces for indent.
- Naming: modules `snake_case.py`, classes `PascalCase`, functions `snake_case`.

## Commit & Pull Request Guidelines
- Conventional Commits: `feat:`, `fix:`, `docs:`, `refactor:`, `chore:`, `test:`
- Commits should be small and focused.
- PRs must include: description, test plan, and screenshots for UI changes.

## Security
- Never commit secrets. Use `.env` for local config.
- Validate all external API calls with proper error handling.

Obsługa sekretów w sesjach agenta

Historię widoczną dla Codex należy traktować jako powierzchnię ataku, a nie tylko kod źródłowy. Informacje o wydaniach Codex opisują prace nad migawkami powłoki i redagowaniem zmiennych środowiskowych, a system pamięci skanuje zapisywane dane w poszukiwaniu sekretów. Zabezpieczenia te nie sprawiają jednak, że dane wyjściowe poleceń, transkrypcje sesji, migawki powłoki, lokalne logi czy skrypty pomocnicze stają się bezpiecznymi miejscami do wyświetlania danych uwierzytelniających.³⁷⁵⁵⁹⁵

Reguła działania jest prosta: nie należy wyświetlać sekretów, aby model mógł je analizować; dane uwierzytelniające narzędzi pomocniczych trzeba przechowywać w konfiguracji wymaganej przez środowisko; podczas audytów należy rozdzielać wykonywalny kod źródłowy, dokumentację, wygenerowane pamięci podręczne, transkrypcje sesji, migawki powłoki, logi oraz celowo utworzone magazyny sekretów; lokalną historię trzeba redagować po wykryciu wzorca z dużym prawdopodobieństwem wskazującego na sekret; natomiast hooks zapobiegawcze należy wdrażać dopiero po potwierdzeniu skuteczności ręcznych procedur higieny. Publicznie należy udostępniać mapę powierzchni i kryteria akceptacji, a nie prywatne wartości tokenów, dokładne ścieżki czy szczegóły działania detektorów.⁹⁵

Mechanizm zastępowania

AGENTS.override.md na dowolnym poziomie folderów zastępuje standardowy plik AGENTS.md w danym zakresie. Można go używać na potrzeby:

• Zamrożenia wydania: „Bez nowych funkcji, tylko poprawki”
• Trybu incydentu: „Wszystkie zmiany muszą zostać sprawdzone przez osobę pełniącą dyżur”
• Tymczasowego wzmocnienia zabezpieczeń: „W tym sprincie bez aktualizacji zależności”

Konfiguracja

# Custom fallback filenames (in addition to AGENTS.md)
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]

# Increase max size for large instruction files
project_doc_max_bytes = 65536    # 64 KiB (default: 32 KiB)

Generowanie szkieletu

codex                           # Launch TUI
/init                           # Generate AGENTS.md scaffold

Łańcuch instrukcji można również zweryfikować:

codex --ask-for-approval never "Summarize your current instructions"

Hooks

Codex wprowadził hooks w wersjach v0.99.0 i v0.100.0 pod wcześniejszymi nazwami AfterAgent i AfterToolUse, w wersji v0.114.0 dodał eksperymentalny silnik hooks z wydarzeniami SessionStart i Stop,⁷⁰ a w wersji v0.124.0 (23 kwietnia 2026) nadał hooks status stabilny.⁸⁵ Silnik dostarczany w rust-v0.150.0 rejestruje dwanaście wydarzeń (HOOK_EVENT_NAMES w codex-rs/hooks/src/lib.rs) — jedenaście w wersji v0.149.1, a Interrupt dodano jako dwunaste w wersji v0.150.0¹³² — natomiast wcześniejsze nazwy zniknęły z konfigurowalnego interfejsu: AfterToolUse nie występuje już nigdzie w drzewie źródłowym, a AfterAgent zachowano wyłącznie jako wewnętrzną nazwę ładunku wcześniejszego mechanizmu pośredniczącego notify.¹²⁴ Hooks uruchamiają skrypty lub narzędzia MCP podczas pętli agentowej. Uruchamiane są wszystkie pasujące hooks z wielu plików, wiele pasujących hooks poleceń dla jednego wydarzenia jest uruchamianych równolegle, a każdy hook niezarządzany musi przed uruchomieniem zostać sprawdzony i oznaczony jako zaufany.¹²⁴ Wersja v0.148.0 rozszerza silnik: hooks mogą uruchamiać polecenia asynchronicznie i wywoływać narzędzia MCP — ustawienie async = true w procedurze obsługi polecenia pozwala uruchomić ją w tle, podczas gdy Codex kontynuuje pracę, natomiast procedura obsługi mcp_tool umożliwia korzystanie z tych samych serwerów MCP, których używa agent.¹¹⁸¹²⁴

Dostępne wydarzenia hooks

Narzędzia hostowane, takie jak WebSearch, nie przechodzą przez ścieżkę hooks, a niektóre wyspecjalizowane ścieżki narzędzi mogą ją pomijać; według OpenAI jest to „przydatne zabezpieczenie, lecz nie kompletna granica egzekwowania zasad”.¹²⁴

Konfiguracja hooks

Hooks są zorganizowane na trzech poziomach — wydarzenie, grupa dopasowania oraz co najmniej jedna procedura obsługi — i znajdują się w pliku hooks.json (~/.codex/hooks.json, <repo>/.codex/hooks.json albo hooks/hooks.json wtyczki) lub bezpośrednio w config.toml i requirements.toml. Lokalne hooks projektu są wczytywane tylko wtedy, gdy warstwa .codex/ projektu jest zaufana.¹²⁴ Wbudowana forma TOML:

# ~/.codex/config.toml or <repo>/.codex/config.toml
[[hooks.SessionStart]]
matcher = "startup|resume"

[[hooks.SessionStart.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/session_start.py"
additionalContextLimit = 5000

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = '/usr/bin/python3 "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use_policy.py"'
timeout = 30
statusMessage = "Checking Bash command"

[[hooks.PostToolUse]]
matcher = "^Bash$"

[[hooks.PostToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/post_tool_use_review.py"
async = true
timeout = 120

Pola procedury obsługi: type (command lub mcp_tool; procedury obsługi prompt i agent są analizowane, lecz pomijane), command, timeout w sekundach (domyślnie 600; dla SessionEnd 1 sekunda, maksymalnie 3), statusMessage, additionalContextLimit (określa, jaka część additionalContext trafia do modelu, zanim Codex zapisze pełny tekst na dysku i wyśle podgląd), commandWindows (nadpisanie tylko dla systemu Windows) oraz async. Polecenia są uruchamiane z katalogiem roboczym ustawionym na cwd sesji, dlatego hooks lokalne dla repozytorium powinny wyznaczać ścieżki na podstawie git rev-parse --show-toplevel, zamiast używać względnej ścieżki .codex/hooks/....¹²⁴

Weryfikacja i zaufanie. Codex zapisuje zaufanie względem bieżącego skrótu każdego niezarządzanego hooka; nowe lub zmienione hooks są oznaczane jako wymagające weryfikacji i pomijane do czasu uznania ich za zaufane. Polecenie /hooks pozwala sprawdzić źródła hooks, zweryfikować je, oznaczyć jako zaufane lub wyłączyć pojedyncze hooks; gdy podczas uruchamiania hooks wymagają weryfikacji, Codex wyświetla ostrzeżenie wskazujące /hooks. Zarządzane hooks ze źródeł systemowych, MDM, chmurowych lub requirements.toml są zaufane na mocy zasad i nie można ich wyłączyć w przeglądarce hooks użytkownika. Opcja --dangerously-bypass-hook-trust uruchamia włączone hooks bez trwałego zapisywania zaufania dla pojedynczego wywołania; służy do automatyzacji, która weryfikuje źródła hooks w innym miejscu.¹²⁴

Dane wyjściowe stdout hooka SessionStart trafiają do kontekstu modelu, dzięki czemu hook ten doskonale nadaje się do wstrzykiwania dynamicznych informacji (dat, nazw gałęzi, zmiennych środowiskowych) podczas rozpoczynania sesji.

Odtwarzanie wzorców hooks z Claude Code

Dla zaimplementowanych wydarzeń Codex używa tych samych nazw co Claude Code, dlatego większość konfiguracji hooks można przenieść, umieszczając JSON w hooks.json i oznaczając ją jako zaufaną za pomocą /hooks:

Wskazówka ekspercka: nowe wydarzenia hooks nadal pojawiają się w kolejnych wersjach — w wersji v0.150.0 dodano wydarzenie Interrupt (¹³²) — dlatego aktualną listę należy sprawdzać w HOOK_EVENT_NAMES w codex-rs/hooks/src/lib.rs oraz w dzienniku zmian Codex.

Przeglądarka hooks w TUI (v0.129.0): polecenie /hooks w TUI pozwala odkrywać dostępne hooks, sprawdzać, które są obecnie aktywne, oraz przełączać poszczególne hooks bez edytowania config.toml. Przydaje się to podczas diagnozowania nieprawidłowo działającego hooka dostarczanego z wtyczką albo tymczasowego wyłączania lintera PostToolUse na czas intensywnej sesji edycji.⁸⁹

Czym jest MCP (Model Context Protocol)? [EKSPERYMENTALNE]

MCP rozszerza możliwości Codex przez połączenie z zewnętrznymi narzędziami i usługami. Grupa poleceń codex mcp jest obecnie oznaczona jako eksperymentalna, a polecenia i format konfiguracji mogą zmieniać się między wydaniami. Codex obsługuje dwa typy transportu: STDIO (procesy lokalne) oraz Streamable HTTP (serwery zdalne).¹¹

Zmiany w MCP w wersji v0.121.0: narzędzia są teraz rejestrowane w przestrzeni nazw, dlatego ich nazwy na listach mają postać <server>:<tool> zamiast samych nazw — należy zaktualizować skrypty i prompty, które wyszukują niekwalifikowane nazwy narzędzi za pomocą grep. Nowa flaga supports_parallel_tool_calls jest przekazywana do dołączonych MCP, umożliwiając równoległe wykonywanie operacji przez serwery deklarujące taką obsługę. Metadane stanu sandbox są teraz przekazywane w metadanych narzędzi MCP, dzięki czemu serwery mogą dostosowywać swoje działanie (np. ostrzegać o uruchomieniu w sandbox w trybie read-only). Niestandardowe żądanie codex/sandbox-state zostało usunięte — zamiast niego należy korzystać ze ścieżki metadanych. W tej wersji pojawia się 3. etap wdrażania aplikacji MCP, obejmujący obsługę wywołań narzędzi; spłaszczone odroczone wywołania narzędzi są teraz obsługiwane przez serwery korzystające ze wzorca wywołań odroczonych.⁸²

Zmiany w MCP w wersji v0.142.2 (25 czerwca 2026): narzędzia MCP używają teraz domyślnie wyszukiwania narzędzi, jeśli jest ono obsługiwane — zamiast wczytywać z góry definicje wszystkich narzędzi, Codex odnajduje je na żądanie. Usprawnia to wyszukiwanie w konfiguracjach zawierających wiele narzędzi, przy zachowaniu zgodności ze starszymi modelami i dostawcami. Zdalne serwery stdio MCP akceptują również bezwzględne katalogi robocze zapisane w formacie ścieżek platformy zdalnej (ścieżkę w stylu Windows z klienta macOS lub odwrotnie).¹⁰⁵

Zmiany w MCP w wersji v0.147.0 (7 sierpnia 2026): Codex dodaje opcjonalną obsługę wersji protokołu MCP z 2026-07-28 — stronicowane wykrywanie (duże katalogi narzędzi są przesyłane stronami zamiast w ramach jednej nadmiernie rozbudowanej listy), żądania wieloetapowe (serwer może przeprowadzić wieloetapową wymianę w obrębie jednego logicznego żądania) oraz nieblokujące uruchamianie serwera. Narzędzia MCP zapisane w pamięci podręcznej są udostępniane przed zakończeniem uruchamiania serwera, dzięki czemu powolny serwer nie wstrzymuje już rozpoczęcia sesji. Funkcję należy włączyć, więc serwery korzystające ze starszej wersji protokołu nadal działają bez zmian.¹¹⁶

Zmiany w MCP w wersji v0.151.0 (29 sierpnia 2026): opcjonalne serwery MCP otrzymują konfigurowalny okres prolongaty uruchamiania – mcp_optional_startup_grace_ms (domyślnie 1,000 ms) określa, jak długo przechwytywanie katalogu narzędzi oczekuje na opcjonalne serwery, wartość 0 wyłącza wspólny okres prolongaty, przez co opcjonalne serwery korzystają ze skonfigurowanego dla nich ustawienia startup_timeout_sec, a zaktualizowane wartości są stosowane podczas działania oraz odświeżania konfiguracji MCP. Rozszerzenia mogą również sprawdzać lub zastępować wyniki narzędzi MCP, zanim trafią one do modelu: ToolLifecycleContributor::on_mcp_tool_result jest uruchamiane przed opublikowaniem ukończenia operacji MCP i przed przygotowaniem wyniku dla modelu, zarówno w przypadku wyników pomyślnych, jak i błędów, również za pośrednictwem Code Mode.¹³⁴

Zmiany w MCP w wersji v0.152.0 (1 września 2026): trzy dodatkowe zmiany. Dodano żądania formularzy openai/elicitation: Codex deklaruje obsługę formularzy, gdy klient zgłasza możliwość form o wartości będącej obiektem, obsługuje żądania openai/elicitation/create oraz przekazuje ich metadane i nieprzezroczysty schemat przez serwer aplikacji jako openaiForm (z zachowaniem adnotacji x-openai-*); starsza obsługa openai/form pozostaje niezależna, a TUI automatycznie odrzuca żądania formularzy, których nie może wyświetlić. Limity danych wyjściowych dla poszczególnych narzędzi: każdy wpis w konfiguracji tools serwera MCP przyjmuje dodatnią wartość output_token_limit (na przykład [mcp_servers.context7.tools.search] z output_token_limit = 2000); w razie nakładania się zasad plugin i użytkownika obowiązuje najbardziej restrykcyjny limit, a efektywny budżet jest przechowywany w historii konwersacji, dzięki czemu dane wyjściowe narzędzi, odpowiedzi hooks uruchamianych po narzędziu oraz wznowione sesje są skracane do tego samego limitu – niezależnie od globalnego ustawienia tool_output_token_limit. Nazwy serwerów w stylu pakietów: nazwy serwerów MCP mogą teraz zawierać znaki :, @, / oraz . (dlatego npm:@modelcontextprotocol/server-sequential.thinking jest prawidłową nazwą). Są one zachowywane w operacjach mcp add/get/list/remove, przestrzeniach nazw narzędzi podczas działania oraz podczas wyszukiwania poświadczeń OAuth, a nazwy o złożonej postaci są ujmowane w cudzysłowy w generowanych wskazówkach dotyczących odzyskiwania pliku config.toml.¹³⁸

Konfigurowanie serwerów MCP

Serwery STDIO (procesy lokalne):

# In ~/.codex/config.toml or .codex/config.toml

[mcp_servers.context7]
enabled = true
required = true                         # Fail startup if unavailable
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env = { "MY_VAR" = "value" }            # Static env vars
env_vars = ["PATH", "HOME"]             # Forward host env vars
cwd = "/path/to/project"                # Optional working directory
startup_timeout_sec = 10
tool_timeout_sec = 60
enabled_tools = ["search", "summarize"]  # Tool allowlist
disabled_tools = ["slow-tool"]           # Tool denylist

Serwery HTTP (zdalne):

[mcp_servers.figma]
enabled = true
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }
env_http_headers = { "X-Org-Id" = "FIGMA_ORG_ID" }  # Headers from env vars
startup_timeout_sec = 10
tool_timeout_sec = 60

Zarządzanie za pomocą CLI

codex mcp add context7 -- npx -y @upstash/context7-mcp
codex mcp add context7 --env API_KEY=... -- npx -y @upstash/context7-mcp   # With env vars
codex mcp add figma --url https://mcp.figma.com/mcp --bearer-token-env-var FIGMA_OAUTH_TOKEN
codex mcp list                          # List all configured servers
codex mcp list --json                   # JSON output
codex mcp get context7                  # Show server config
codex mcp get context7 --json           # JSON output
codex mcp login <server>                # OAuth flow for HTTP servers
codex mcp logout <server>               # Remove OAuth credentials
codex mcp remove <server>               # Delete server definition

W trakcie sesji: /mcp wyświetla aktywne serwery i dostępne narzędzia. /mcp verbose (v0.123.0+)⁸⁴ zwraca pełne informacje diagnostyczne serwerów, zasoby oraz szablony zasobów — przydaje się, gdy serwer nie może się załadować lub narzędzia nie pojawiają się w oczekiwanym miejscu. Zwykłe /mcp nadal działa szybko. Od wersji v0.144.0 narzędzia MCP mogą żądać uwierzytelnienia interaktywnie, bez eksperymentalnej opcji wymagającej włączenia — serwer potrzebujący uwierzytelnienia w trakcie sesji wyświetla monit w ramach standardowego procesu, zamiast zgłaszać błąd do czasu wcześniejszego uwierzytelnienia za pomocą codex mcp login.¹⁰⁷

Wczytywanie MCP z plugin (v0.123.0+) obsługuje zarówno standardowy schemat mcpServers, jak i mapy serwerów najwyższego poziomu w pliku .mcp.json, dzięki czemu plugin utworzone zgodnie z dowolną z tych konwencji wczytują się prawidłowo.⁸⁴

Uruchamianie Codex JAKO serwera MCP

Przestarzałe (24 sierpnia 2026). Zgodnie z oficjalnym dziennikiem zmian: „Polecenie codex mcp-server jest obecnie przestarzałe. Zamiast niego należy używać serwera aplikacji Codex. Aby korzystać z Codex z poziomu Claude Code, należy użyć plugin Codex dla Claude Code”. Od wersji v0.149.0 plik binarny wypisuje do stderr komunikat warning: `codex mcp-server` is deprecated and will be removed in a future release., po czym mimo to się uruchamia (PR #39657). Nowe integracje powinny korzystać z protokołu app-server, czyli interfejsu stanowiącego podstawę rozszerzenia VS Code i aplikacji komputerowej (uwierzytelnianie, historia konwersacji, zatwierdzenia i strumieniowane zdarzenia agentów), lub — w przypadku Claude Code — z plugin Codex dla Claude Code: „Korzystaj z Codex z poziomu Claude Code, aby przeglądać kod lub delegować zadania”.¹²⁵

Dopóki polecenie jest dostępne, Codex nadal może udostępniać własne funkcje jako serwer MCP na potrzeby orkiestracji wieloagentowej (funkcja jest przestarzała, ale nadal działa w wersji 0.150.0, która wyświetla jednoznaczne ostrzeżenie o wycofaniu):^12125132

codex mcp-server                        # Start as MCP server (stdio transport); deprecated, prints a warning

Serwer udostępnia dwa narzędzia: 1. codex(): rozpoczyna nową sesję z parametrami promptu, sandbox, modelu i zatwierdzania 2. codex-reply(): kontynuuje istniejącą sesję z użyciem threadId i promptu

Użycie z Agents SDK (Python):

from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async with MCPServerStdio(
    name="Codex CLI",
    params={"command": "npx", "args": ["-y", "codex", "mcp-server"]},
    client_session_timeout_seconds=360000,
) as codex_mcp_server:
    agent = Agent(name="Developer", mcp_servers=[codex_mcp_server])
    result = await Runner.run(agent, "Fix the failing tests")

Godne uwagi serwery MCP

Praktyczne wzorce

Wzorzec 1: programowanie z uwzględnieniem kontekstu — należy połączyć Context7 z dokumentacją używanego frameworka, aby Codex zawsze miał aktualne materiały referencyjne dotyczące API:

[mcp_servers.context7]
enabled = true
required = true
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Wzorzec 2: limity danych wyjściowych — odpowiedzi narzędzi MCP są domyślnie skracane do około 25 tys. znaków. W przypadku narzędzi zwracających duże ilości danych (zapytania do bazy danych, przechwycone logi) warto użyć enabled_tools, aby ograniczyć dostęp do konkretnych narzędzi i zachować zwięzłość odpowiedzi.

Wzorzec 2a: multimodalne dane wyjściowe narzędzi (v0.107.0) — niestandardowe narzędzia mogą teraz zwracać multimodalne dane wyjściowe (obrazy i treści rozszerzone) wraz z tekstem. Dzięki temu narzędzia tworzące materiały wizualne — zrzuty ekranu, diagramy i wyrenderowane wykresy — mogą przekazywać je bezpośrednio do modelu w celu analizy.⁶²

Wzorzec 3: nadzór organizacyjny nad MCP — za pomocą pliku requirements.toml można ograniczyć serwery MCP, z których mogą korzystać programiści:

# In /etc/codex/requirements.toml — only approved servers allowed
[mcp_servers.approved-internal]
identity = { command = "npx @company/internal-mcp" }

Każdy serwer, który nie odpowiada tożsamości określonej w pliku requirements.toml, zostanie zablokowany podczas uruchamiania. Pełną konfigurację zasad opisano w sekcji Wdrożenie w przedsiębiorstwie.

Code Mode [EKSPERYMENTALNY]

Code mode (v0.114.0) zapewnia bardziej odizolowane przepływy pracy programistycznej, ograniczając zakres działania agenta do operacji związanych z kodem.⁷⁰ Po włączeniu agent koncentruje się na odczytywaniu, pisaniu i testowaniu kodu bez szerszych interakcji z systemem.

Od wersji v0.139.0 code mode może wywoływać samodzielne wyszukiwanie w internecie bezpośrednio — również z poziomu zagnieżdżonych wywołań narzędzi JavaScript — i otrzymuje wyniki w postaci zwykłego tekstu, dzięki czemu przepływ pracy w code mode może pobierać aktualne informacje bez opuszczania izolowanego kontekstu programistycznego.¹⁴⁹ Wersja v0.146.0 rozszerza samodzielne wyszukiwanie w internecie na zgodnych niestandardowych dostawców modeli, więc funkcja nie jest już ograniczona do modeli hostowanych przez OpenAI.¹¹⁴

Wersja v0.146.0 umożliwiła app-server łączenie się ze zdalnymi hostami Code Mode, dzięki czemu środowisko wykonawcze code mode nie musi już działać na tym samym urządzeniu co klient — pierwotnie po WebSocket.¹¹⁴ Wersja v0.151.0 usuwa transport WebSocket (#40692): połączenia app server --code-mode-host akceptują wyłącznie punkty końcowe gRPC http:// i https://, a samodzielny host code mode obsługuje tylko odbiorniki stdio i gRPC — w tagu rust-v0.151.0 dokumentacja odbiornika brzmi dosłownie: „Transport endpoint: stdio, stdio://, or grpc://IP:PORT”. WebSocket pozostaje jedynie opcjonalnym punktem końcowym przesyłającym strumieniowo nieprzetworzone partie śladów OTLP na potrzeby śledzenia, a nie transportem sesji.¹³⁵

Ta funkcja jest eksperymentalna. Aktualne informacje należy sprawdzać w informacjach o wydaniach.

Środowisko wykonawcze REPL JavaScript [USUNIĘTE]

W Codex v0.100.0 dodano eksperymentalne środowisko wykonawcze REPL JavaScript (js_repl), a w wersji v0.106.0 udostępniono je za pośrednictwem /experimental.⁶⁰ Te informacje mają już charakter historyczny. W dzienniku zmian wersji v0.128.0 znajduje się wpis „Remove js_repl feature”, a bieżąca lista funkcji oznacza zarówno js_repl, jak i js_repl_tools_only jako usunięte.⁸⁶

Do nowych konfiguracji nie należy dodawać features.js_repl = true. Gdy potrzebna jest powtarzalna logika wykonywalna, należy używać poleceń powłoki, skryptów zapisanych w repozytorium, narzędzi MCP albo skills Codex z folderem scripts/.

Czym są skills?

Skills to wielokrotnego użytku pakiety funkcji przeznaczone do konkretnych zadań, które Codex ładuje na żądanie. Są zgodne z otwartym standardem agent skills.¹³

Struktura skill

my-skill/
  SKILL.md           (required: instructions)
  scripts/           (optional: executable scripts)
  references/        (optional: reference docs)
  assets/            (optional: images, icons)
  agents/openai.yaml (optional: metadata, UI, dependencies)

Lokalizacje wykrywania

Codex przechowuje skills zainstalowane przez użytkownika w $CODEX_HOME/skills (domyślnie: ~/.codex/skills), w tym wbudowane skills systemowe w .system/. Codex obsługuje foldery skills będące dowiązaniami symbolicznymi.

Tworzenie skill

Format SKILL.md:

---
name: security-audit
description: Run a thorough security audit on the codebase.
---

## Security Audit Procedure

1. Scan for hardcoded secrets using `rg -i "(api_key|password|secret|token)\s*=" --type py`
2. Check for SQL injection: look for string interpolation in queries
3. Verify input validation on all API endpoints
4. Check dependency vulnerabilities: `pip audit` or `npm audit`
5. Review authentication and authorization patterns
6. Report findings with severity levels (Critical/High/Medium/Low)

Metadane (agents/openai.yaml):

interface:
  display_name: "Security Audit"
  short_description: "Full codebase security review"
  icon_small: "./assets/shield.svg"
  brand_color: "#DC2626"
  default_prompt: "Run a security audit on this repository"

policy:
  allow_implicit_invocation: false    # Require explicit $skill

dependencies:
  tools:
    - type: "mcp"
      value: "snyk"
      transport: "streamable_http"
      url: "https://mcp.snyk.io/mcp"

Wywoływanie skills

• Jawnie: menu /skills lub wzmianka $skill-name w poleceniu
• Niejawnie: Codex automatycznie wykrywa pasujące skills na podstawie opisu zadania (jeśli allow_implicit_invocation: true)
• Kreator: $skill-creator umożliwia interaktywne utworzenie nowej skill
• Instalator: $skill-installer install <name> umożliwia zainstalowanie skills społeczności
• Udostępniane przez executor (v0.146.0): Codex wykrywa skills oferowane przez executor i odczytuje powiązane z nimi zasoby, w tym skills wybrane jawnie¹¹⁴

Budżety kontekstu powodują skracanie katalogów skills. Wersja v0.146.0 zachowuje więcej dostępnych skills przy ograniczonym kontekście i ostrzega, gdy katalog musi zostać skrócony.¹¹⁴ Wcześniej duża biblioteka skills mogła zostać skrócona bez ostrzeżenia, przez co oczekiwana skill nie była oferowana w bieżącym zakresie. Jeśli korzysta się z niejawnego wywoływania wielu skills, należy zwracać uwagę na to ostrzeżenie.

Włączanie i wyłączanie

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

Skills a slash commands

Debugowanie skills

Jeśli skill się nie aktywuje:

1. Sprawdzić wykrywanie: /skills powinno wyświetlać ją w TUI
2. Zweryfikować ścieżkę: upewnić się, że folder skill znajduje się w rozpoznawanej lokalizacji (~/.codex/skills/, katalogu głównym projektu lub /etc/codex/skills/)
3. Sprawdzić enabled: skills z ustawieniem enabled = false w config.toml nie zostaną załadowane
4. Sprawdzić niejawną aktywację: jeśli używane jest automatyczne wykrywanie, upewnić się, że w agents/openai.yaml ustawiono allow_implicit_invocation: true
5. Użyć słów kluczowych: uwzględnić w poleceniu terminy z pola description danej skill, aby zwiększyć skuteczność niejawnego dopasowania

Przykład produkcyjny: skill do wdrażania

Kompletna, wieloplikowa skill pokazująca współdziałanie materiałów referencyjnych i skryptów:

deploy-skill/
  SKILL.md
  references/
    runbook.md
    rollback-checklist.md
  scripts/
    pre-deploy-check.sh
    smoke-test.sh
  agents/openai.yaml

SKILL.md:

---
name: deploy
description: Deploy the application to staging or production. Runs pre-flight checks, executes deployment, and verifies with smoke tests.
---

## Deployment Procedure

### Pre-flight
1. Run `scripts/pre-deploy-check.sh` to verify:
   - All tests pass
   - No uncommitted changes
   - Branch is up to date with remote
2. Review the runbook at `references/runbook.md` for environment-specific steps.

### Deploy
3. Execute the deployment command for the target environment.
4. Monitor logs for errors during rollout.

### Verify
5. Run `scripts/smoke-test.sh <environment-url>` to confirm critical paths.
6. If smoke tests fail, follow `references/rollback-checklist.md`.

Wywołanie: $deploy to staging lub $deploy production with canary rollout

Plugins

Plugins łączą skills, wpisy MCP, hooks i konektory aplikacji w jeden instalowalny pakiet (v0.110.0+).⁶⁵ Od v0.117.0 plugins są pełnoprawnymi elementami produktu: plugins o zakresie produktowym synchronizują się automatycznie podczas uruchamiania, a /plugins udostępnia przeglądarkę w TUI służącą do ich wyszukiwania i zarządzania nimi.⁷⁵ W v0.128.0 rozszerzono przepływy pracy związane z plugins o instalowanie z marketplace, buforowanie zdalnych pakietów, zdalne punkty końcowe odinstalowywania API, hooks dołączane do plugins, stan włączenia hooks oraz import konfiguracji zewnętrznych agentów.⁸⁶ v0.129.0 (7 maja 2026) dodaje udostępnianie plugins w workspace (przekazywanie zestawu plugins członkom zespołu bez ponownego publikowania), kontrolę dostępu do udostępnionych zasobów (włączanie lub wyłączanie dla poszczególnych odbiorców oraz cofanie dostępu), filtrowanie źródeł (ograniczanie marketplace, z których korzysta workspace) oraz operacje marketplace, które można wywoływać bezpośrednio z przeglądarki /plugins zamiast z CLI.⁸⁹ v0.133.0 (21 maja 2026) ułatwia kontrolowanie procesu wyszukiwania plugins: dane wyjściowe listy uwzględniają marketplace, widoczne są zainstalowane wersje i katalogi główne marketplace, a zdalne kolekcje plugins można wyświetlać bez zgadywania, z którego rejestru pochodzi dany wynik.⁹⁸ v0.130.0 (8 maja 2026) zwiększa przejrzystość pakowania plugins i zapewnia większą kontrolę nad przepływem udostępniania:⁹¹

• Hooks dołączone do plugin są widoczne w jego szczegółach. Widok szczegółów /plugins pokazuje teraz każdy hook cyklu życia dołączony do plugin (SessionStart, UserPromptSubmit, Stop itd.). Przed zainstalowaniem plugin można dokładnie sprawdzić, które hooks zarejestruje w sesji — koniec z niespodziewanymi skutkami ubocznymi hooks pochodzących z plugin, któremu zaufano wyłącznie ze względu na jego narzędzia.
• Metadane udostępniania plugin w shareContext. Gdy plugin jest udostępniany z workspace, ładunek odsyłacza do udostępniania ujawnia teraz metadane odsyłacza (twórcę, zakres i aktualność), dzięki czemu sesje odbierające mogą wyświetlić pochodzenie i zdecydować, czy go zaakceptować.
• Kontrola wykrywalności w ustawieniach udostępniania. Ustawienia udostępniania zawierają przełącznik wykrywalności, dzięki któremu zespoły mogą publikować plugins w określonych workspaces lub dla konkretnych list odbiorców, nie udostępniając ich jednocześnie w ogólnych wykazach całej organizacji.

v0.143.0 (8 lipca 2026) domyślnie włącza zdalne plugins. Zdalne plugins są teraz dostępne bez flagi wyrażającej zgodę, katalog /plugins otrzymuje bardziej szczegółowe wiersze (źródła marketplace npm obok git i źródeł lokalnych), a każdy wpis pokazuje zarówno wersję zdalną, jak i zainstalowaną lokalnie, dzięki czemu rozbieżności są widoczne na pierwszy rzut oka.¹⁰⁶ Zespoły standaryzujące wspólny zestaw plugins nie muszą już włączać ich oddzielnie na każdym komputerze, co wcześniej blokowało wdrożenie.

Źródła plugins

Od v0.147.0 wyszukiwanie plugins obejmuje w jednym zapytaniu katalogi lokalne, osobiste, workspace i zdalne — wyszukuje się funkcję, a nie katalog, w którym akurat się ona znajduje. W połączeniu z przenośnymi pakietami Agent Plugins oznacza to, że plugin utworzony w jednym środowisku można bezproblemowo zainstalować w innym, bez przywiązania do komputera lub workspace, w którym powstał.¹¹⁶

Wyszukiwanie plugins

Codex informuje model na początku sesji, które plugins są włączone (v0.111.0), co ułatwia wykrywanie zainstalowanych MCP, aplikacji i skills.⁶⁵ Na podstawie kontekstu zadania model może sugerować podczas sesji odpowiednie plugins. W v0.117.0 plugins o zakresie produktowym są synchronizowane podczas uruchamiania, dzięki czemu najnowszy katalog plugins jest dostępny bez ręcznej ingerencji.⁷⁵ Od v0.142.0 menu /plugins porządkuje zdalne plugins w sekcjach Wyselekcjonowane przez OpenAI, Workspace oraz Udostępnione mi, a w kwalifikujących się turach można bezpośrednio rekomendować i instalować odpowiednie plugins.¹⁰⁴ Od v0.151.0 plugin/list i plugin/installed wczytują obowiązującą konfigurację plugins dla każdego żądanego cwd – lokalne marketplaces są łączone w kolejności żądań, stan instalacji i włączenia jest scalany między repozytoriami, a nieprawidłowe konfiguracje projektu są zgłaszane za pośrednictwem marketplaceLoadErrors bez pomijania prawidłowych katalogów lokalnych ani globalnie włączonych katalogów zdalnych.¹³⁴

Wzmianki @plugin (v0.112.0+)

Do dowolnego zainstalowanego plugin można odwołać się bezpośrednio na czacie za pomocą @plugin-name.⁶⁸ Po wspomnieniu plugin jego kontekst (możliwości, narzędzia i konfiguracja) jest automatycznie dołączany do okna kontekstowego modelu — nie trzeba opisywać jego działania.

@deploy push this branch to staging with canary rollout
@linter check for unused imports in src/

Mechanizm ten działa z każdym zainstalowanym plugin, w tym z niestandardowymi skills, serwerami MCP i konektorami aplikacji.

Marketplace plugins (v0.113.0+)

Marketplace plugins oferuje teraz bogatsze możliwości wyszukiwania dzięki metadanym, kategoriom i ocenom.⁶⁹ Kontrole uwierzytelniania przeprowadzane podczas instalacji sprawdzają, czy plugins wymagające kluczy API lub OAuth mają prawidłowe dane uwierzytelniające. Punkt końcowy odinstalowywania umożliwia prawidłowe usunięcie plugins i powiązanej z nimi konfiguracji.

Dodawanie zewnętrznych marketplaces (v0.121.0+)

Aktualna dokumentacja OpenAI Codex opisuje zarządzanie źródłami marketplace w ramach codex plugin marketplace. Formalizuje to dystrybucję plugins innych firm poza własnym marketplace OpenAI i obsługuje skróconą notację repozytoriów GitHub, adresy URL Git przez HTTP(S), adresy URL SSH oraz lokalne katalogi główne marketplace; opcja --ref pozwala przypiąć konkretny ref Git, natomiast powtarzalnej opcji --sparse PATH należy używać wyłącznie w przypadku repozytoriów marketplace opartych na Git.⁹³

# GitHub repository (shorthand)
codex plugin marketplace add owner/repo

# Arbitrary git URL
codex plugin marketplace add https://git.example.com/team/plugins.git

# SSH Git URL
codex plugin marketplace add git@example.com:team/plugins.git

# Local directory
codex plugin marketplace add /path/to/local/marketplace

# Upgrade or remove a configured marketplace
codex plugin marketplace upgrade <marketplace-name>
codex plugin marketplace remove <marketplace-name>

Po dodaniu plugins z danego marketplace pojawiają się w przeglądarce /plugins obok domyślnych pozycji. Wywołujący serwer aplikacji (integracje IDE/aplikacji desktopowych) mają do dyspozycji równoległy punkt końcowy umożliwiający programowe rejestrowanie marketplaces.⁸²

Kwestia bezpieczeństwa: Marketplaces innych firm uruchamiają dowolny kod plugins z uprawnieniami Codex. Przed dodaniem należy zweryfikować źródła, a przy pierwszych uruchomieniach preferować wykonywanie w sandbox.

Agent Plugins: standard obsługiwany przez różnych dostawców (v0.146.0–v0.147.0)

„Agent Plugins” to nie tylko nazwa funkcji Codex — jest to otwarty, neutralny względem dostawców standard pakowania, opublikowany jako Agent Plugins 1.0.0 6 sierpnia 2026, którego oficjalna strona opisuje go jako „przenośny format pakietów wielokrotnego użytku, które rozszerzają agentów AI”.¹⁴⁵ Plugin jest katalogiem z wymaganym manifestem plugin.json (zamkniętym schematem zawierającym dokładnie 10 dozwolonych pól najwyższego poziomu — $schema, name, version, description, author, homepage, repository, license, keywords, extensions — przy czym „klienci MUSZĄ zgłaszać i ignorować każde nieznane pole”), opcjonalnym folderem skills/ (każdy bezpośredni katalog podrzędny zawierający SKILL.md stanowi jedną skill), opcjonalnym plikiem mcp.json deklarującym serwery stdio, Streamable HTTP lub starsze HTTP+SSE oraz opcjonalnymi katalogami przestrzeni nazw klienta w odwrotnej notacji domenowej, które inni klienci „MUSZĄ ignorować”. Jego normatywnym zakresem jest pakowanie: specyfikacja „definiuje kanoniczną specyfikację Agent Plugins v1.0.0 służącą do pakowania komponentów wielokrotnego użytku, które rozszerzają agentów AI, w dystrybuowalne plugins” — Agent Skills i MCP zachowują własne, bazowe specyfikacje.¹⁴⁵

Kluczową rolę odgrywa tu model zarządzania. Vercel zainicjował propozycję i opracował specyfikację 1.0 wspólnie z Amazon, Anysphere (Cursor), GitHub, Microsoft i OpenAI; lista opiekunów repozytorium specyfikacji obejmuje przedstawicieli Amazon, Cursor, Microsoft, OpenAI i Vercel, a Google ogłosiło w dniu premiery, że dołącza do grona głównych opiekunów.¹⁴⁵ Wśród wymienionych klientów dostępnych w dniu premiery znajdują się ChatGPT, Codex, Cursor, GitHub Copilot, Kiro i VS Code. Zwraca uwagę brak Anthropic, twórcy bazowego formatu Agent Skills i samego MCP, którego nie ma w gronie opiekunów — Claude Code zachowuje własny format plugins, a Codex niweluje tę różnicę po swojej stronie za pomocą źródła marketplace Claude Code (v0.146.0) oraz /import.¹⁴⁵

W terminologii Codex: v0.146.0 dodaje manifesty Agent Plugins, publikowanie plugins w workspace oraz 2 dodatkowe marketplaces plugins — Amazon Bedrock i Claude Code¹¹⁴ — natomiast v0.147.0 domyka cały proces, umożliwiając instalowanie przenośnych Agent Plugins oraz wyszukiwanie w katalogach lokalnych, osobistych, workspace i zdalnych.¹¹⁶ Dla zespołów najbardziej praktycznym elementem jest publikowanie w workspace: plugins można publikować we własnym workspace, zamiast uruchamiać publiczny marketplace lub wymagać od każdego dewelopera ręcznego dodania źródła Git.

Informacje o wydaniu zapowiadają interfejsy Codex, lecz nie podają ich kluczy konfiguracyjnych ani składni CLI. Ten wpis dokumentuje udostępnienie funkcji oraz zakres określony przez standard, ale nie sposób korzystania z niej w Codex — przepływ tworzenia manifestu i każde wywołanie codex plugin publish należy traktować jako niezweryfikowane, dopóki nie zostaną opisane w dokumentacji OpenAI.

Zarządzanie plugins

codex plugin marketplace add <src>       # Add a marketplace source
codex plugin marketplace upgrade [name]  # Upgrade one marketplace or all
codex plugin marketplace remove <name>   # Remove a configured marketplace
codex plugin list                        # List plugins; includes remote catalog entries (v0.153.0)
codex plugin list --json                 # JSON adds source, version, install + auth policy (v0.153.0)

v0.153.0 rozszerza CLI plugin z zarządzania marketplace na operacje dotyczące poszczególnych plugins w zdalnych marketplaces: codex plugin list uwzględnia wpisy zdalnego katalogu (wraz z ich źródłem, wersją, zasadami instalacji i zasadami uwierzytelniania w danych wyjściowych JSON), a zdalne plugins można dodawać i usuwać za pomocą istniejącego CLI plugin. Zdalne katalogi są przechowywane w pamięci podręcznej według zakresu i kolekcji – preferowane są aktualne wyniki z pamięci podręcznej, żądanie dodania plugin nieznalezionego w pamięci podręcznej powoduje jednorazowe ponowne pobranie, a lokalny wyselekcjonowany katalog pozostaje dostępny, gdy nie powiedzie się niefiltrowane wyświetlenie zdalnej listy (błędy nadal są zgłaszane w przypadku jawnie wybranych zdalnych marketplaces).¹⁴⁰

W TUI należy użyć /plugins (v0.117.0+), aby interaktywnie przeglądać, instalować i usuwać poszczególne plugins bez opuszczania sesji.⁷⁵

Wskazówka ekspercka: Plugins konsolidują elementy, które wcześniej wymagały oddzielnej konfiguracji MCP, instalacji skills i konfiguracji konektorów aplikacji. Pojedynczy plugin może obejmować wszystkie 3 elementy — przyspieszając wdrażanie członków zespołu i zwiększając przenośność konfiguracji.

Tryb planowania i współpraca

Tryb planowania pozwala Codex opracować podejście przed wprowadzeniem zmian. Jest domyślnie włączony (od wersji v0.94.0).¹⁴ Drzewo decyzyjne „Tryb planowania a bezpośrednie wykonanie” znajduje się w sekcji Kryteria podejmowania decyzji.

Tryb planowania a narzędzie update_plan (v0.152.0): są to dwie różne rzeczy, a tylko jedna z nich jest domyślnie włączona. Tryb planowania — opisany w tej sekcji tryb współpracy, w którym Codex przedstawia propozycję przed wykonaniem działań — jest domyślnie włączony od wersji v0.94.0 i nie uległ zmianie. update_plan to narzędzie do planowania, które model może wywołać, aby utrzymywać uporządkowany plan w ramach jednej tury. W wersji v0.152.0 zostało udostępnione jako funkcja wymagająca jawnego włączenia: tools.update_plan.enabled ma domyślną wartość false, a gdy jest wyłączone, Codex usuwa również dołączone wytyczne dotyczące update_plan ze swoich promptów modelu, trybu współpracy, wielu agentów, kompakcji, wstępnego uruchamiania i kontynuowania celu (niestandardowe instrukcje bazowe, instrukcje katalogu modeli, zasady współpracy oraz treść celu użytkownika są zachowywane, nawet jeśli wspominają o planowaniu). Aby je włączyć, należy jawnie ustawić tools.update_plan.enabled = true w pliku config.toml.¹³⁸

Włączanie trybu planowania

/plan                              # Switch to plan mode
/plan "redesign the API layer"     # Plan mode with initial prompt

W trybie planowania Codex: - Odczytuje pliki i analizuje bazę kodu - Proponuje plan implementacji - Nie wprowadza zmian bez zatwierdzenia - Przesyła plan strumieniowo w osobnym widoku TUI

Tryb sterowania

Tryb sterowania (domyślnie włączony od wersji v0.98.0) umożliwia przekazywanie nowych instrukcji podczas pracy Codex bez przerywania bieżącego zadania.¹⁴

Instrukcje można przekazać na dwa sposoby:

Praktyczne przykłady:

# Codex is refactoring the auth module...

[Enter] "Use bcrypt instead of argon2 — we already have it as a dependency"
→ Codex adjusts immediately, mid-turn

[Tab] "Once auth is done, update the migration script too"
→ Codex finishes auth refactor, then starts the migration

Tryb sterowania jest zawsze aktywny w TUI. Aby poczekać z przekazaniem instrukcji do zakończenia pracy przez Codex, wystarczy wpisać je w zwykły sposób po zakończeniu tury — nie jest potrzebny żaden specjalny tryb.

Ulepszenia TUI (v0.105.0–v0.106.0)

Podświetlanie składni (v0.105.0): TUI podświetla teraz składnię bloków kodu wydzielonych znacznikami oraz różnic wyświetlanych bezpośrednio w treści. Polecenie /theme umożliwia wybór schematu kolorów.⁶¹

Nowe polecenia TUI (v0.105.0+):⁶¹

Transkrypcja głosowa (v0.105.0, funkcja eksperymentalna): Naciśnięcie spacji pozwala dyktować prompty za pomocą transkrypcji głosowej. Ta funkcja jest eksperymentalna i może wymagać uprawnień dostępu do mikrofonu.⁶¹ Od wersji v0.107.0 sesje głosowe w czasie rzeczywistym obsługują wybór mikrofonu i głośnika, co pozwala wskazać konkretne urządzenia wejścia i wyjścia audio.⁶² Usunięto w wersji v0.140.0, przywrócono w v0.145.0: eksperymentalne elementy sterujące głosem /realtime oraz ich zależności audio zostały usunięte z TUI w wersji v0.140.0 (nie wpłynęło to na transkrypcję głosową uruchamianą spacją).¹⁰² Wersja v0.145.0 przywraca obsługę głosu w nowej postaci: dane wejściowe audio i wyniki narzędzi audio w popularnych lokalnych formatach audio oraz strumieniowe rozmowy realtime V3.¹¹²

Pozostałe ulepszenia: - Długie linki pozostają teraz klikalne nawet po zawinięciu do kolejnych wierszy TUI (v0.105.0)⁶¹ - Linki do plików lokalnych są wyświetlane z ulepszonym formatowaniem (v0.106.0)⁶⁰ - Markdown w TUI zachowuje klikalność linków internetowych dzięki metadanym OSC 8, a tabele, dla których brakuje miejsca, są zastępowane czytelnymi rekordami klucz/wartość bez utraty adresów docelowych linków (v0.136.0)¹⁵² - Linki Markdown są wyświetlane jako klikalne etykiety w obsługiwanych terminalach, a w pozostałych przypadkach zachowywane są widoczne adresy URL (v0.150.0)¹³² - Poprawiono obsługę Ctrl+C dla sub-agentów, aby prawidłowo kończyć procesy podrzędne (v0.106.0)⁶⁰

System pamięci

Codex ma trwały system pamięci (v0.100.0+), który przechowuje fakty, preferencje i kontekst projektu między sesjami.²⁴

Polecenia pamięci

Informacje są przechowywane w plikach Markdown w folderze ~/.codex/memory/. Codex ładuje je podczas uruchamiania sesji i wykorzystuje do kształtowania swojego działania we wszystkich przyszłych sesjach.

Co warto przechowywać

Pamięć najlepiej sprawdza się w przypadku trwałych preferencji i faktów dotyczących projektu:

• Konwencje projektu: „Ten projekt używa tabulatorów zamiast spacji” lub „Odpowiedzi API zawsze zawierają pole meta”
• Preferencje dotyczące narzędzi: „Używaj pnpm zamiast npm” lub „Uruchamiaj testy za pomocą pytest -x --tb=short”
• Decyzje architektoniczne: „Moduł uwierzytelniania znajduje się w src/core/auth/, a nie w src/middleware/”
• Preferencje dotyczące przepływu pracy: „Zawsze uruchamiaj linter przed wyświetleniem różnic”

Pamięć w potokach

Podczas uruchamiania codex exec informacje z pamięci są ładowane automatycznie. Dzięki temu potoki CI/CD i skrypty korzystają z tego samego kontekstu co sesje interaktywne — nie trzeba powtarzać instrukcji przy każdym wywołaniu.

Udoskonalenia pamięci (v0.101.0–v0.107.0)

• Usuwanie poufnych danych: Informacje są automatycznie skanowane pod kątem poufnych danych przed zapisaniem na dysku
• Uwzględnianie CWD: Pliki pamięci zawierają teraz kontekst katalogu roboczego, co ułatwia przywoływanie informacji dotyczących konkretnego projektu
• Wykluczanie komunikatów deweloperskich: Komunikaty deweloperskie/systemowe są wykluczane z danych wejściowych pamięci fazy 1, co poprawia jej jakość dzięki skupieniu się na interakcjach z użytkownikiem
• Zapominanie oparte na różnicach (v0.106.0): Pamięć wykorzystuje teraz mechanizm zapominania oparty na różnicach do usuwania nieaktualnych faktów, dzięki czemu z czasem pozostaje zwięzła i trafna⁶⁰
• Wybór uwzględniający użycie (v0.106.0): Pobieranie informacji z pamięci uwzględnia teraz częstotliwość użycia, nadając priorytet informacjom często wykorzystywanym i ostatnio istotnym⁶⁰
• Konfigurowalna pamięć (v0.107.0): Pamięć można teraz w pełni konfigurować. Polecenie codex debug clear-memories pozwala wyczyścić wszystkie zapisane informacje i rozpocząć od nowa — jest to przydatne podczas przełączania się między niepowiązanymi projektami lub gdy stan pamięci przestał odpowiadać aktualnemu kontekstowi⁶²
• Aktualizacja modelu fazy 2 (v0.121.0): Modelem konsolidacji pamięci fazy 2 jest teraz gpt-5.4 (zamiast poprzedniego modelu domyślnego). Potok fazy 2 działa między sesjami, przekształcając transkrypcje fazy 1 w trwałe fakty; zmiana modelu poprawia jakość przywoływania informacji przy takim samym koszcie tokenów.⁸²
• Menu pamięci w TUI (v0.121.0): Nowy interfejs dostępny w trakcie sesji udostępnia tryb pamięci, usuwanie poszczególnych informacji oraz przycisk resetowania. Resetowanie pamięci zachowuje wcześniejsze przebiegi zamiast je unieważniać, dzięki czemu czyści zakres informacji przywoływanych w przyszłości bez zakłócania odtwarzania sesji.⁸²

Pamięć a AGENTS.md

Wskazówka: Polecenie /m_update służy do zapisywania faktów, które powinny być przechowywane bezterminowo. Kontekst dotyczący tylko bieżącej sesji wystarczy przekazać Codex bezpośrednio w rozmowie. Współdzielony kontekst zespołowy należy umieścić w AGENTS.md.

Zarządzanie sesjami

Codex zapisuje sesje w ~/.codex/sessions/, umożliwiając ich wznawianie, rozwidlanie oraz pracę wielowątkową w CLI i aplikacji komputerowej.

Wersja v0.146.0 umożliwia bezpośrednie odwoływanie się do wątków. Polecenia /new i /clear przyjmują teraz nazwę sesji, ważne wątki można przypinać, a poboczne rozmowy pozostają otwarte — nie trzeba już zamykać jednej, aby przejść do innej.¹¹⁴ W praktyce długotrwały projekt przestaje być listą znaczników czasu, które trzeba rozpoznawać po dacie. Wersja v0.147.0 dodaje sekcje rozmów: rozmowy można organizować w trwałe sekcje uporządkowane ręcznie, a długie transkrypcje przeglądać stopniowo zamiast wczytywać je w całości.¹¹⁶ Wersja v0.148.0 dodaje /export i rozwidlanie z wiersza poleceń: /export zapisuje całą rozmowę w formacie Markdown (do schowka lub nowego pliku), codex exec fork rozwidla sesję nieinteraktywnie, a selektor wznawiania pozwala archiwizować i przywracać sesje.¹¹⁸ Wersja v0.149.0 dodaje codex queue — wysyłanie wiadomości z wiersza poleceń do istniejących sesji lokalnych lub zdalnych — oraz naprawia przywracanie aktywnego profilu uprawnień we wznowionych i rozwidlonych wątkach.¹²⁰ Wersja v0.150.0 dodaje automatyczne tytuły: nienazwane zadania terminalowe automatycznie otrzymują opisowe tytuły, a /rename proponuje edytowalny tytuł na podstawie rozmowy.¹³² Wersja v0.151.0 dodaje /recap: na żądanie można uzyskać krótkie podsumowanie ostatnich postępów w rozmowie i kolejnych kroków; Codex generuje też takie samo podsumowanie automatycznie dla kwalifikujących się, bezczynnych rozmów, które nie są aktualnie aktywne, i dodaje je do transkrypcji, przy czym żądania są ograniczone i izolowane, a ponowienia następują wyłącznie po niepowodzeniach automatycznych.¹³⁵ Wersja v0.153.0 pozwala wyłączyć automatyczną część tej funkcji: tui.auto_recap = false anuluje zaplanowane automatyczne kontrole podsumowań i odrzuca oczekujące wyniki automatyczne, natomiast ręczne /recap nadal działa.¹⁴⁰

codex agents (v0.149.0) to interaktywny panel wszystkich aktywnych sesji agentów na komputerze: z jednego ekranu można wyszukiwać, uruchamiać, otwierać, zmieniać nazwy i zatrzymywać zadania, korzystając z konfigurowalnych skrótów. W obrębie sesji /agents służy do przełączania się między wszystkimi aktywnymi sesjami agentów, a /subagents — między subagentami bieżącej sesji.¹²⁰¹²⁹ Wersja v0.150.0 umożliwia bezpośrednie odwoływanie się do zadań z poziomu rozmowy: można wskazywać inne zadania Codex za pomocą wzmianek @ oraz prosić agentów z terminala o odczytywanie, tworzenie lub przesyłanie wiadomości do zadań.¹³²

Wznawianie

Kontynuowanie pracy od miejsca jej przerwania:

codex resume                          # Interactive picker (sorted by recency)
codex resume <SESSION_ID>             # Resume a specific session
codex exec resume --last "continue"   # Non-interactive: resume most recent

Polecenie slash /resume w TUI otwiera ten sam interaktywny selektor z funkcją wyszukiwania.

Stronicowana historia wątków (v0.145.0, przeniesiona do funkcji standardowych w v0.151.0): Stronicowana historia wątków usprawnia wznawianie sesji, przeszukiwanie historii, zachowywanie nazw wątków, obsługę subagentów i wspomnień — historia jest wczytywana strona po stronie, a nie od razu w całości, co ma znaczenie w przypadku długo używanych katalogów roboczych zawierających setki sesji. Funkcję wprowadzono jako eksperymentalną w wersji v0.145.0; wersja v0.151.0 przenosi APIs poza obszar funkcji eksperymentalnych (thread/turns/list, thread/items/list i thread/revert nie wymagają już eksperymentalnej funkcji API) oraz ustawia tryb stronicowany jako wynikową wartość domyślną WYŁĄCZNIE dla trwałych wątków, których magazyn obsługuje thread/turns/list i thread/items/list, i tylko wtedy, gdy thread/start pomija historyMode. Wątki tymczasowe oraz wątki korzystające z magazynów bez tych APIs nadal domyślnie używają trybu starszego typu, jawne wybory zachowują swoje działanie, a wyliczenie ThreadHistoryMode na poziomie protokołu nadal domyślnie przyjmuje wartość Legacy w tagu rust-v0.151.0 (protocol.rs:755-758) — jest to wynikowa wartość domyślna dla obsługiwanych trwałych wątków, a nie powszechna zmiana trybu.¹¹²¹³⁵

Rozwidlanie

Rozgałęzienie rozmowy pozwala analizować alternatywne rozwiązania bez utraty dotychczasowych postępów:

/fork                              # Fork current conversation
/fork "try a different approach"   # Fork with new prompt

Rozwidlenia tworzą niezależne wątki współdzielące tę samą historię do punktu rozwidlenia. Od wersji v0.146.0 historia rozwidleń jest stronicowana, a rozwidlenia mogą być tworzone jako tymczasowe — tymczasowe rozwidlenie nie pojawia się na listach wątków, dzięki czemu jednorazowe eksperymenty nie zaśmiecają faktycznie używanej listy.¹¹⁴ Zmiany w jednym rozwidleniu nie wpływają na drugie. Przydaje się to do porównywania podejść (np. „utworzyć rozwidlenie i wypróbować Redis zamiast Memcached”) lub bezpiecznego testowania ryzykownych zmian.

Rozwidlanie wątków do subagentów (v0.107.0): Wątki można teraz rozwidlać do niezależnych subagentów, dzięki czemu rozmowa może uruchamiać równoległe strumienie pracy wykonywane autonomicznie. Rozszerza to dotychczasowy model rozwidleń — zamiast jedynie rozgałęziać rozmowę, rozwidlony wątek staje się subagentem z własnym kontekstem wykonania.⁶² Od wersji v0.117.0 subagenci używają adresów opartych na ścieżkach (np. /root/agent_a) oraz ustrukturyzowanej komunikacji między agentami, co sprawia, że koordynacja wielu agentów jest bardziej przejrzysta i łatwiejsza do debugowania.⁷⁵

Szyfrowane wiadomości między agentami (v0.138.0+): Multi-agent v2 szyfruje teraz treść zadania wysyłaną przez agenta nadrzędnego podczas tworzenia subagenta lub przesyłania mu wiadomości. Parametry wiadomości funkcji spawn_agent, send_message i followup_task są oznaczone jako szyfrowane: API Responses szyfruje ładunek, gdy model nadrzędny emituje wywołanie narzędzia, lokalnie działający Codex przenosi wyłącznie szyfrogram (InterAgentCommunication.encrypted_content, z pustą treścią jawną), a API odszyfrowuje go po stronie serwera podczas przekazywania do modelu odbierającego.¹⁰⁸ Ma to 3 praktyczne konsekwencje:

• Lokalne dzienniki sesji nie zawierają już jawnej treści delegowanych zadań. Można zobaczyć, że agent nadrzędny utworzył subagenta i co otrzymał w odpowiedzi, lecz nie dokładną treść przesłanej instrukcji. W przypadku audytu lub debugowania uruchomień wielu agentów na podstawie historii sesji ten zapis nie jest już dostępny; według stanu na połowę lipca 2026 otwarte zgłoszenie regresji dotyczące tego problemu nie ma powiązanej poprawki.¹⁰⁹ Pozostałymi mechanizmami pozwalającymi odtworzyć przebieg zdarzeń są zdarzenia cyklu życia rozszerzeń (uruchomienie/zatrzymanie subagenta, wykonanie narzędzia, metadane tury — v0.133.0+) oraz obserwowalność app-server.⁹⁸
• Modele niestandardowych dostawców mogą przestać działać. Punkt końcowy modelu, który nie został skonfigurowany do obsługi szyfrowanych wywołań narzędzi, odrzuca zaszyfrowany schemat spawn_agent z błędem 400 ("declares encrypted parameters but is not configured for encrypted tool use"). Jeśli delegowanie do wielu agentów kończy się takim błędem u niestandardowego dostawcy, przyczyną jest zmiana dotycząca szyfrowania, a nie konfiguracja użytkownika.¹⁰⁹
• Powiadomienia generowane przez Codex pozostają czytelne. Powiadomienia o zakończeniu pracy agenta podrzędnego generuje sam Codex, dlatego pozostają one zapisane tekstem jawnym i są teraz renderowane jako elementy typu agent_message, a nie serializowane koperty JSON.¹⁰⁸

OpenAI nie opublikowało modelu zagrożeń stojącego za tą zmianą; PR opisuje przepływ szyfrogramu, lecz nie wskazuje, przed czym ma on chronić.

Ustabilizowany Multi-agent v2 (v0.145.0, funkcja opcjonalna): Środowisko Multi-agent v2, które zadebiutowało w wersji v0.137.0 i otrzymało szyfrowane delegowanie w wersji v0.138.0, zostało teraz ustabilizowane jako funkcja opcjonalna. Wersja v0.145.0 dodaje konfigurowalne modele subagentów, indywidualne poziomy rozumowania dla poszczególnych subagentów, konfigurowalną współbieżność, przywrócone role wielu agentów oraz usprawnioną nawigację między agentami. Jeśli zrezygnowano z v2 podczas początkowych problemów wersji v0.137/v0.138, właśnie w tym wydaniu interfejs konfiguracji się stabilizuje — wybór modelu i poziomu rozumowania subagenta znajduje się teraz w konfiguracji, zamiast być na stałe określany przez środowisko uruchomieniowe.¹¹²

Lista wątków

Wyświetlanie aktywnych sesji i zarządzanie nimi:

/status                            # Current session info and token usage
/ps                                # Show background terminals in session

W aplikacji komputerowej wątki są widoczne na pasku bocznym wraz z pełną historią i podglądami różnic.

Cykl życia sesji

Sesje synchronizują się między CLI a aplikacją komputerową — można rozpocząć pracę w jednym środowisku i kontynuować ją w drugim.

Tryb nieinteraktywny (codex exec)

codex exec uruchamia Codex nieinteraktywnie na potrzeby skryptów, CI/CD i automatyzacji.¹⁵

Podstawowe użycie

codex exec "summarize the repository structure"
codex exec --sandbox workspace-write -c approval_policy=on-request "fix the CI failure"   # exec has no -a flag; set the policy via -c or config
codex exec --json "triage open bugs" -o result.txt

Domyślnie codex exec zapisuje postęp i zdarzenia do stderr, a końcową wiadomość agenta do stdout. Dzięki takiej konstrukcji można go łączyć ze standardowymi potokami Unix.

Archiwizowanie sesji (v0.136.0)

Sesje można archiwizować, aby zachować przejrzystość listy wznawiania i rozwidlania bez usuwania historii. Archiwizację można wykonać w TUI za pomocą /archive albo z poziomu powłoki:¹⁵²

codex archive <session-id>     # archive a session
codex unarchive <session-id>   # restore it

Zarchiwizowana sesja jest chroniona przed wznowieniem lub rozwidleniem do czasu cofnięcia archiwizacji — to zabezpieczenie przed przypadkowym kontynuowaniem sesji, która miała zostać wycofana. W tym samym wydaniu: codex app-server --stdio uruchamia app-server w trybie stdio na potrzeby integracji z edytorami i hostami, a /diff nie może już wykonywać dostarczonych przez repozytorium pomocniczych narzędzi Git (poprawka bezpieczeństwa poleceń). W systemie Windows ścieżka aprowizacji w wersji alfa dodaje polecenie codex sandbox setup --elevated przeznaczone dla administratorów.¹⁵²

Dane wyjściowe w wierszach JSON

Z opcją --json strumień stdout staje się strumieniem zdarzeń JSONL:

codex exec --json "fix the tests" | jq

Typy zdarzeń: thread.started, turn.started/completed/failed, item.started/completed, error

{"type":"thread.started","thread_id":"019c5c94-..."}
{"type":"turn.started"}
{"type":"item.started","item":{"id":"item_1","type":"command_execution","status":"in_progress"}}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"..."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"cached_input_tokens":24448,"output_tokens":122}}

Ustrukturyzowane dane wyjściowe

Wymuszanie struktury odpowiedzi za pomocą schematu JSON:

codex exec "Extract project metadata" \
  --output-schema ./schema.json \
  -o ./project-metadata.json

-o / --output-last-message zapisuje końcową wiadomość do pliku.

Wznawianie i przeglądanie sesji

codex exec resume --last "continue where you left off"
codex exec resume <SESSION_ID> "fix the remaining issues"
codex exec review --base main           # Code review against a branch

Najważniejsze flagi

Uwierzytelnianie w CI

codex exec obsługuje CODEX_API_KEY na potrzeby nieinteraktywnego uwierzytelniania w środowiskach automatyzacji.

Baner startowy codex exec (v0.130.0). Baner startowy codex exec nie wyświetla już starszego określenia „research preview”. Jeśli system CI analizuje dane wyjściowe podczas uruchamiania, tekst banera jest teraz krótszy; ustrukturyzowane zdarzenia --json pozostają bez zmian.⁹¹

codex remote-control (v0.130.0+)

codex remote-control to polecenie najwyższego poziomu, które uruchamia app-server bez interfejsu graficznego, przeznaczony do sterowania przez inny proces — rozszerzenia IDE, niestandardowe orkiestratory lub zdalne płaszczyzny sterowania. Zastępuje ono wieloflagowe wywołanie codex app-server, które wielu integratorów składało dotąd ręcznie, i zapewnia narzędziom innych firm jeden stabilny punkt dostępu do tego samego środowiska wykonawczego app-server, które jest dostarczane w aplikacji desktopowej i interfejsach IDE.⁹¹ Wersja v0.133.0 usprawnia sposób działania polecenia: może ono działać jako polecenie pierwszoplanowe, oczekiwać na gotowość, raportować stan maszyny, a jednocześnie udostępniać jawne polecenia start / stop w stylu demona dla długotrwale działających konfiguracji kontrolera.⁹⁸ Wersja v0.143.0 dodaje codex remote-control pair, które generuje kod ręcznego parowania na podstawie działającego demona, dzięki czemu kontroler może nawiązać połączenie bez automatycznego uzgadniania wykrywania — jest to przydatne, gdy proces sterujący działa na innym hoście lub w innym segmencie sieci niż demon.¹⁰⁶

# Start a headless, remotely controllable app-server
codex remote-control

# Generate a manual pairing code for an out-of-band controller (v0.143.0+)
codex remote-control pair

# Same lifecycle as a TUI session: thread store, hooks, plugins, MCP, sandbox
# all initialize from your normal config.toml.

Podczas tworzenia interfejsów, które muszą wyliczać obszerne historie wątków bez jednoczesnego wczytywania do pamięci wszystkich tur, warto połączyć codex remote-control z opisanymi poniżej APIs stronicowania app-server.

Stronicowanie wątków app-server (v0.130.0+)

Klienty app-server mogą teraz stronicować obszerne wątki przy użyciu 3 odrębnych widoków elementów tur:⁹¹

Stronicowanie warto połączyć z interfejsem ThreadStore, wprowadzonym w wersji v0.121.0, aby sprawnie przeglądać długotrwale działające wątki — szczególnie we wdrożeniach remote-control, w których orkiestrator może znajdować się na innej maszynie niż pliki przebiegu.⁸² Wersja v0.143.0 rozszerza zakres danych dostępnych kontrolerowi: klienty app-server mogą teraz wyliczać dostępne środowiska, wyświetlać wątki potomne danego wątku i rozwidlać historię od określonej tury — są to podstawowe mechanizmy potrzebne interfejsowi do utworzenia odgałęzienia przebiegu od wcześniejszego punktu bez ponownego odtwarzania kolejnych kroków.¹⁰⁶ Wersja v0.151.0 przenosi APIs stronicowanej historii wątków poza fazę eksperymentalną i domyślnie stosuje historię stronicowaną do trwałych wątków z obsługującymi ją magazynami, gdy w wywołaniu thread/start pominięto historyMode (wątki efemeryczne i magazyny bez takiej obsługi nadal korzystają ze starszego trybu); wczytywanie pełnej historii jest przestarzałe w przypadku stronicowanych wątków (#40676).¹³⁵

Odświeżanie konfiguracji app-server na żywo (v0.130.0+)

Aktywne wątki app-server uwzględniają teraz zmiany w config.toml bez konieczności ponownego uruchamiania — wystarczy zmodyfikować i zapisać konfigurację, a działający wątek zastosuje nowe wartości podczas następnej tury. Jest to poprawka uzupełniająca codex remote-control: długotrwale działający serwer bez interfejsu graficznego można rekonfigurować na miejscu zamiast go wyłączać.⁹¹

Ustawienia zakresu aktywnej tury (v0.151.0): ustawienia działającej tury można teraz zmieniać w trakcie jej wykonywania. Eksperymentalna metoda app-server turn/settings/update aktualizuje model, effort, summary i serviceTier dla kolejnych kroków określonej aktywnej tury bez zmieniania przyszłych tur oraz informuje, czy aktualizacja została zastosowana, odrzucona, czy też utraciła swój cel; zarządzane ograniczenia są ponownie sprawdzane, a zatwierdzone właściwości dotyczące akceptacji i zabezpieczeń Guardian danej tury zostają zachowane przed opublikowaniem zaktualizowanej migawki ustawień. turn/start przyjmuje również serviceTierForTurn, dzięki czemu jedna nowa tura może zastąpić poziom usługi bez zmiany poziomu zapisanego dla wątku („default” oznacza standardową szybkość; pominięcie wartości lub null powoduje odziedziczenie poziomu wątku).¹³⁵

Szyfrowane zdalne moduły wykonawcze (v0.141.0)

Od wersji v0.141.0 (stabilnej, 18 czerwca 2026) zdalne moduły wykonawcze łączą się przez uwierzytelnione, kompleksowo szyfrowane kanały Noise-relay — płaszczyzna sterowania i moduł wykonawczy nie muszą już ufać przekaźnikowi znajdującemu się między nimi, co ma znaczenie zawsze wtedy, gdy orkiestrator steruje app-server ponad granicą sieci. To samo wydanie sprawiło, że zdalne wykonywanie między różnymi platformami zachowuje natywny katalog roboczy i powłokę modułu wykonawczego, dzięki czemu kontroler działający w jednym systemie operacyjnym i sterujący modułem wykonawczym w innym nie powoduje już niejawnego przepisywania ścieżek ani semantyki powłoki. TLS akceptuje teraz również podpisy certyfikatów P-521, co zapewnia zgodność z firmowymi serwerami proxy.¹⁰³

Codex Cloud i zadania w tle [EXPERIMENTAL]

Obsługa GitLab (beta, 19 sierpnia 2026): Codex Cloud może teraz łączyć się z projektami GitLab we wszystkich planach ChatGPT — można połączyć projekt, tworzyć środowiska, uruchamiać zadania na podstawie zgłoszeń i merge requestów oraz prosić o przeglądy; Self-Managed GitLab wymaga wersji 19.0 lub nowszej.¹¹⁹

Status: Codex Cloud jest funkcją eksperymentalną. Interfejsy, ceny i dostępność mogą ulec zmianie. OpenAI zarządza środowiskami chmurowymi, a użytkownik nie ma kontroli nad infrastrukturą.

Codex Cloud wykonuje zadania asynchronicznie w środowiskach zarządzanych przez OpenAI.⁴ Od wersji CLI v0.150.0 do zadań można także odwoływać się w rozmowie prowadzonej w terminalu: można wskazywać inne zadania Codex za pomocą wzmianek @ oraz prosić agentów o odczytywanie, tworzenie lub przesyłanie wiadomości do zadań.¹³² Informacje o integracji Codex z potokiem CI znajdują się również w sekcji GitHub Action i CI/CD.

Wzmocnione zabezpieczenia danych uwierzytelniających zadań w chmurze (v0.152.0): żądania zadań w chmurze mogą zawierać zapisane dane uwierzytelniające ChatGPT, dlatego ich miejsce docelowe jest teraz ograniczane jeszcze przed wczytaniem uwierzytelniania — CODEX_CLOUD_TASKS_BASE_URL jest sprawdzany pod kątem zgodności z zaufanymi źródłami HTTPS ChatGPT na porcie 443 (adresy URL zawierające informacje o użytkowniku, zapytania lub fragmenty są odrzucane), a przekierowania zostały wyłączone w zapleczu zadań w chmurze oraz klientach wykrywania środowisk, dzięki czemu dane uwierzytelniające nigdy nie są przekazywane do miejsca docelowego przekierowania.¹³⁸

Jak to działa

1. Przesłać zadanie (za pośrednictwem chatgpt.com/codex, integracji ze Slack lub CLI)
2. Codex klonuje repozytorium do odizolowanego środowiska uruchomieniowego w chmurze
3. Agent działa niezależnie: odczytuje kod, uruchamia testy i wprowadza zmiany
4. Po zakończeniu Codex tworzy PR lub udostępnia różnice do przeglądu
5. Zastosować wyniki lokalnie za pomocą codex apply <TASK_ID>

Dostęp do internetu w chmurze

Dostęp agenta do internetu jest domyślnie wyłączony i konfigurowany osobno dla każdego środowiska:

• Wyłączony: brak dostępu agenta do internetu (ustawienie domyślne)
• Włączony: opcjonalna lista dozwolonych domen i ograniczenia metod HTTP

Allowed domains: pypi.org, npmjs.com, github.com
Allowed methods: GET, HEAD, OPTIONS

Skrypty konfiguracyjne mogą nadal korzystać z internetu w celu instalowania zależności, nawet jeśli dostęp agenta do internetu jest wyłączony.

Integracja ze Slack

Aby uruchomić zadanie w chmurze, należy wspomnieć @Codex na kanale lub w wątku Slack.

Wymagania wstępne: 1. Odpowiedni plan ChatGPT (Plus, Pro, Business, Enterprise lub Edu) 2. Połączone konto GitHub 3. Co najmniej jedno skonfigurowane środowisko chmurowe 4. Aplikacja Slack zainstalowana w przestrzeni roboczej

Codex odpowiada, podając link do zadania, a po jego ukończeniu publikuje wyniki.

CLI w chmurze

codex cloud exec --env <ENV_ID> "Fix failing tests"  # Start a cloud task
codex cloud status <TASK_ID>                          # Check task progress
codex cloud diff <TASK_ID>                            # View task diff
codex cloud list                                      # List recent tasks
codex cloud list --json                               # JSON output
codex cloud apply <TASK_ID>                           # Apply from cloud subcommand
codex apply <TASK_ID>                                 # Apply diff (top-level shortcut)

Aplikacja Codex Desktop App

Aplikacja Codex Desktop App (macOS i Windows) udostępnia interfejs graficzny zoptymalizowany pod kątem zarządzania wieloma projektami.¹⁶ Wersja dla Windows została wydana 4 marca 2026 i oferuje natywną obsługę PowerShell oraz natywne środowisko uruchomieniowe Windows.⁶⁶

Instalacja

codex app                      # Auto-downloads and installs on first run

Można też pobrać ją bezpośrednio: Codex.dmg (macOS) | Dostępna w Microsoft Store (Windows)

Najważniejsze funkcje

Appshots, komentarze w przeglądarce i Computer Use

Aktualizacje aplikacji z 21 maja sprawiają, że aplikacja desktopowa staje się bogatszym źródłem kontekstu, a nie tylko menedżerem wątków. Z funkcji Appshots warto korzystać, gdy przed podjęciem działania Codex potrzebuje informacji o stanie innej aplikacji na Macu: Codex przechwytuje okno znajdujące się na pierwszym planie oraz dostępny tekst widoczny i poza ekranem, udostępniany przez aplikację, a następnie zapisuje załącznik lokalnie w historii sesji.⁹⁹

W przypadku prac nad stronami internetowymi i frontendem należy w pierwszej kolejności użyć przeglądarki w aplikacji, jeśli strona nie wymaga uwierzytelnienia: zapewnia ona użytkownikowi i Codex wspólny podgląd wyrenderowanej strony, obsługuje działania w przeglądarce, takie jak klikanie, wykonywanie zrzutów ekranu, pobieranie zasobów i inspekcja JavaScript tylko do odczytu, a także pozwala oznaczać obszary strony komentarzami, do których Codex może odnieść się w następnej turze.⁹⁹ W przypadku stron wymagających logowania należy nadal korzystać z rozszerzenia przeglądarki (Chrome, Edge, Brave, Opera lub Vivaldi; Opera nie ma czatu bocznego). Narzędzia witryn (WebMCP, 25 sierpnia 2026): w przeglądarce wbudowanej w aplikację desktopową ChatGPT Work i Codex mogą korzystać z narzędzi udostępnianych przez witrynę do pracy ze stroną; należy używać GPT-5.6 Sol lub GPT-5.6 Terra w najnowszej wersji aplikacji desktopowej, ponieważ narzędzia witryn nie są dostępne w GPT-5.6 Luna ani w przestrzeniach roboczych Enterprise lub Edu.¹²⁷

Z funkcji Computer Use należy korzystać tylko wtedy, gdy zadania nie można zweryfikować za pomocą integracji strukturalnej ani podglądu w przeglądarce. Może ona sprawdzać i obsługiwać dozwolone aplikacje na Macu, ale w przypadku edycji plików i poleceń powłoki podlega regułom zatwierdzania i środowiska uruchomieniowego Codex. Używanie po zablokowaniu pozostaje ściśle ograniczone: po zablokowaniu Maca Codex może tymczasowo uzyskiwać dostęp do dozwolonych aplikacji podczas aktywnych, zaufanych tur Computer Use, z mechanizmami ponownego blokowania i wykrywania lokalnych działań użytkownika.⁹⁹

Tryby wątków

Każdy wątek działa w jednym z trzech trybów wybieranych podczas jego tworzenia:

Mechanizm izolacji Worktree:

Po uruchomieniu wątku Worktree aplikacja desktopowa: 1. Tworzy nowy git worktree (git worktree add) w katalogu tymczasowym 2. Pobiera świeżą gałąź z bieżącego HEAD 3. Uruchamia agenta w worktree — wszystkie zmiany plików są odizolowane 4. Po zakończeniu przedstawia różnice do przeglądu — można wybrać zmiany, które mają zostać scalone z powrotem

Dzięki temu wiele wątków Worktree może działać jednocześnie w tym samym repozytorium bez konfliktów. Każdy otrzymuje własną gałąź i katalog roboczy.

Ustawienia Worktree i własność wątków (v0.151.0): zarządzane działanie worktree jest ustalane na podstawie istniejącej konfiguracji [desktop] przez dedykowany parser ustawień — domyślnym katalogiem głównym worktree jest $CODEX_HOME/worktrees, automatyczne czyszczenie jest domyślnie włączone, a zachowywanych jest 15 worktree; skonfigurowane katalogi główne, flagi czyszczenia i liczby zachowywanych worktree są sprawdzane przed użyciem. Każdy zarządzany, połączony worktree może również zawierać wersjonowany rekord własności codex-thread.json w swoich metadanych Git, wiążący go z wątkiem: zapisy są atomowe i nie zastępują istniejących danych (powtórne powiązania są idempotentne, a konfliktowi właściciele odrzucani), natomiast podstawowe, zagnieżdżone i niezarządzane checkouty są odrzucane, zanim metadane własności zostaną zmodyfikowane.¹³⁵

Automatyzacje

Automatyzacje działają lokalnie w aplikacji, dlatego aplikacja musi być uruchomiona, a projekt dostępny na dysku:

• W repozytoriach Git automatyzacje korzystają z dedykowanych worktree działających w tle (odizolowanych od katalogu roboczego)
• W projektach bez Git zadania są wykonywane bezpośrednio w katalogu projektu
• Automatyzacje korzystają z domyślnych ustawień środowiska uruchomieniowego

Konfigurowanie automatyzacji: 1. Otworzyć projekt w aplikacji desktopowej 2. Kliknąć kartę Automations na pasku bocznym 3. Zdefiniować wyzwalacz (harmonogram, webhook lub ręczny) 4. Napisać prompt i wybrać tryb wykonywania (lokalny lub worktree) 5. Ustawić poziom rozumowania dla uruchomienia automatyzacji (App v26.312)⁷² 6. Automatyzacje są uruchamiane zgodnie z harmonogramem, a wyniki trafiają do kolejki przeglądu

Przykładowe zastosowania: - Klasyfikacja zgłoszeń: automatyczne kategoryzowanie nowych zgłoszeń i nadawanie im priorytetów - Monitorowanie CI: śledzenie niepowodzeń kompilacji i sugerowanie poprawek - Reagowanie na alerty: odpowiadanie na alerty monitoringu za pomocą analizy diagnostycznej - Aktualizacje zależności: sprawdzanie i stosowanie poprawek zabezpieczeń

Wyniki pojawiają się w kolejce przeglądu i wymagają zatwierdzenia przez człowieka.

Obsługa Windows

Aplikacja Codex Desktop App została wydana dla Windows 4 marca 2026 (App v26.304) i oferuje natywną obsługę PowerShell, natywne środowisko uruchomieniowe Windows oraz pełną zgodność funkcjonalną, obejmującą skills, automatyzacje i worktrees bez konieczności korzystania z WSL.⁶⁶

GitHub Action i CI/CD

Oficjalny GitHub Action integruje Codex z potokiem CI/CD.¹⁸

Podstawowe użycie

# .github/workflows/codex.yml
name: Codex
on:
  pull_request:
    types: [opened]

jobs:
  codex:
    runs-on: ubuntu-latest
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: workspace-write
          safety-strategy: drop-sudo

Opcje konfiguracji

Dane wyjściowe: final-message, tekst końcowej odpowiedzi Codex przeznaczony dla kolejnych kroków/zadań.

Strategie bezpieczeństwa

Kontrola dostępu

with:
  allow-users: "admin,maintainer"     # Limit who can trigger
  allow-bots: false                   # Block bot-triggered runs

Domyślnie: przepływy pracy Codex mogą wyzwalać wyłącznie współpracownicy z uprawnieniami do zapisu.

Codex SDK

TypeScript SDK umożliwia osadzanie funkcji agenta Codex w niestandardowych aplikacjach.¹⁹

Instalacja

npm install @openai/codex-sdk

Podstawowe użycie

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();

// Multi-turn conversation
const turn1 = await thread.run("Diagnose CI failures and propose a fix");
console.log(turn1.finalResponse);

const turn2 = await thread.run("Implement the fix and add tests");
console.log(turn2.items);

// Resume a previous session
const resumed = codex.resumeThread("<thread-id>");
await resumed.run("Continue from previous work");

Zaawansowane funkcje SDK

• runStreamed(...): Asynchroniczny strumień zdarzeń dostarczający aktualizacje pośrednie
• Uwierzytelnianie Python SDK (v0.132.0+): logowanie za pomocą klucza API, przepływy ChatGPT wykorzystujące przeglądarkę/kod urządzenia, sprawdzanie konta i wylogowywanie są pełnoprawnymi ścieżkami SDK.⁹⁷
• Uproszczenie tur tekstowych (v0.132.0+): API tur Python przyjmują zwykłe ciągi tekstowe i zwracają bogatsze metadane TurnResult, obejmujące zgromadzone elementy, czas wykonania i użycie zasobów.⁹⁷
• outputSchema: Wymusza końcowe dane wyjściowe zgodne ze strukturą JSON
• Dane multimodalne: Można przekazywać tekst i obrazy lokalne ({ type: "local_image", path: "..." })
• Przepływy pracy z obrazami (v0.117.0): view_image zwraca adresy URL, wygenerowane obrazy można ponownie otwierać, a historia obrazów jest zachowywana po wznowieniu sesji⁷⁵
• view_image w wielu środowiskach (v0.130.0): W sesjach obejmujących wiele środowisk (wprowadzonych w v0.124.0 wraz z możliwością wyboru środowiska i katalogu roboczego dla każdej tury, a następnie udoskonalonych w v0.125.0 poprzez trwałe przypisanie środowisk) view_image rozpoznaje teraz ścieżki plików za pośrednictwem wybranego środowiska, a nie lokalnego systemu plików koordynatora. Obraz dołączony ze środowiska zdalnego jest pobierany względem katalogu roboczego tego środowiska, a nie hosta, na którym działa SDK.⁹¹

Konfiguracja wątku i klienta

// Custom working directory, skip git check
const thread = codex.startThread({
  workingDirectory: "/path/to/project",
  skipGitRepoCheck: true,
});

// Custom environment and config overrides
const codex = new Codex({
  env: { CODEX_API_KEY: process.env.MY_KEY },
  config: { model: "gpt-5.5" },
});

Sesje są przechowywane w ~/.codex/sessions.

Środowisko uruchomieniowe: Node.js 18+.

Optymalizacja wydajności

Zarządzanie kontekstem

Rozmiary okien kontekstu zależą od modelu. Obecna rodzina GPT-5.6 (Sol, Terra, Luna) korzysta z okna 272K; GPT-5.5, flagowy model poprzedniej generacji, oferuje 400K w Codex (1M w API); GPT-5.4 / GPT-5.4-mini (wycofywane z Codex 31 sierpnia 2026) oferują 1M / 400K; starsza rodzina GPT-5.3-Codex obsługiwała 272K danych wejściowych + 128K danych wyjściowych (łączny budżet 400K). Wszystkie te okna zapełniają się szybciej, niż można się spodziewać — warto aktywnie nimi zarządzać:

1. Regularnie używać /compact: Podsumowuje historię rozmowy, zwalniając tokeny
2. Udostępniać lokalną dokumentację: Wysokiej jakości AGENTS.md i dokumentacja lokalna ograniczają nakład pracy związany z eksploracją (która zużywa kontekst)
3. Używać @ do dołączania konkretnych plików: Wskazywać pliki bezpośrednio, zamiast prosić Codex o ich znalezienie
4. Tworzyć precyzyjne prompty: Prompty o jasno określonym zakresie i wskazanych plikach zużywają mniej kontekstu niż otwarta eksploracja

Eksperymentalne zarządzanie kontekstem (v0.153.0, domyślnie wyłączone): features.context_management.experimental_mode aktywuje skoordynowany stos kontekstu — kontekst z budżetem tokenów, notatki historii oraz narzędzie new_context — w kwalifikujących się sesjach ChatGPT Plus, Pro i Pro Lite korzystających z backendu Codex. Sesje z kluczem API, niestandardowi dostawcy, endpointy inne niż Codex oraz tymczasowe wątki ustrukturyzowane są wykluczone, a sama flaga pozostaje wyraźnie oznaczona jako funkcja w trakcie rozwoju: należy traktować ją jako zapowiedź kierunku rozwoju obsługi kontekstu, a nie podstawę do tworzenia przepływów pracy.¹⁴⁰

Efektywność wykorzystania tokenów

Optymalizacja szybkości

1. gpt-5.3-codex-spark: Wariant o mniejszych opóźnieniach do interaktywnej pracy
2. --profile fast: Wstępnie skonfigurowany gpt-5.6-luna z niskim poziomem rozumowania
3. Równoległe wykonywanie operacji narzędzi: Codex wykonuje niezależne odczyty i kontrole równocześnie, dlatego warto konstruować prompty tak, aby to umożliwiały
4. Pętle ukierunkowane na rezultat: Zamiast instrukcji krok po kroku warto poprosić o „wdrożenie, przetestowanie, poprawienie i zakończenie po uzyskaniu prawidłowego wyniku”

Jak debugować problemy?

Typowe problemy i rozwiązania

Objaśnienia komunikatów o błędach

Do czego służy codex doctor?

codex doctor to podstawowe polecenie, które należy uruchomić przed zgłoszeniem błędu lub debugowaniem uszkodzonej instalacji. Gromadzi ono w jednym raporcie informacje o lokalnym środowisku uruchomieniowym, konfiguracji, uwierzytelnianiu, terminalu, sieci i stanie, a szablon zgłoszenia projektu wymaga wklejenia jego danych wyjściowych.¹⁴⁷

codex doctor                           # Full human-readable report (the default)
codex doctor --summary                 # Compact view
codex doctor --json                    # Redacted structured JSON, for bug reports
codex doctor --all                     # Expand truncated lists
codex doctor --no-color                # Strip ANSI color

Raport jest podzielony na stałe sekcje, dzięki czemu można szybko przejść do potrzebnej części:¹⁴⁷

Każde sprawdzenie ma oznaczenie stanu — ✓ poprawnie, ✗ błąd, ⚠ ostrzeżenie, ○ bezczynność — oraz wiersz podsumowania. Opcja --json przypisuje każdemu sprawdzeniu stabilny identyfikator, dzięki czemu wynik nadaje się do użycia w CI lub skrypcie pomocy technicznej, a nie tylko do ręcznego przeglądania.¹⁴⁷

Możliwości tego polecenia rozwijały się wraz z kolejnymi wersjami: pojawiło się w v0.131.0, w v0.135.0 wzbogacono je o raportowanie środowiska, Git, terminala, serwera aplikacji i spisu wątków, a w v0.139.0 dodano szczegóły edytora i programu stronicującego (z ukryciem poufnych wartości w JSON).^96153149

Należy użyć go na początku, nie na końcu. Większość zgłoszeń typu „Codex nie działa” wynika z problemu, który doctor już wskazuje: nieaktualnego trybu uwierzytelniania, błędu analizy składni config.toml lub drugiej instalacji przesłaniającej tę dostępną w PATH.

Narzędzia diagnostyczne

codex doctor                           # Full local diagnostic (start here)
codex --version                        # Check CLI version
codex login status                     # Verify authentication
codex mcp list                         # Check MCP server status
codex debug app-server --help          # Debug app server issues

Diagnostyka TUI w ramach sesji:

/status                                # Token/session overview
/debug-config                          # Show config layers and requirement sources
/compact                               # Summarize history to reclaim context

Uwaga: codex --verbose nie jest prawidłową flagą najwyższego poziomu. Należy użyć powyższych podpoleceń debugowania i diagnostyki TUI.

Czysta ponowna instalacja

npm uninstall -g @openai/codex && npm install -g @openai/codex@latest

Zachowuje ~/.codex/ (uwierzytelnianie, konfigurację i sesje). Informacje o przypinaniu konkretnej wersji, powrocie do starszej wersji po wadliwym wydaniu lub całkowitym wyczyszczeniu stanu zawiera sekcja Aktualizowanie, przywracanie starszej wersji lub odinstalowywanie.

Tryb debugowania

codex debug app-server send-message-v2  # Test app-server client

Zgłaszanie problemów

/feedback                              # Send logs to Codex maintainers (in TUI)

Problemy można również zgłaszać pod adresem github.com/openai/codex/issues.¹

Codex Security [WERSJA ZAPOWIEDZIOWA]

6 marca 2026 r. Codex Security udostępniono w ramach badawczej wersji zapowiedzi, wprowadzając do środowiska Codex analizę bezpieczeństwa aplikacji uwzględniającą kontekst.⁷⁷ Funkcja jest dostępna dla klientów ChatGPT Pro, Enterprise, Business i Edu za pośrednictwem Codex web.

Sposób działania: Codex Security analizuje repozytoria, aby utworzyć model zagrożeń specyficzny dla danego projektu, identyfikuje luki w zabezpieczeniach sklasyfikowane według rzeczywistych skutków oraz poddaje ustalenia intensywnym testom w środowisku sandboxa w celu ich weryfikacji. Agent przedstawia ustalenia o wyższym poziomie wiarygodności wraz z poprawkami, ograniczając szum powodowany przez nieistotne błędy.

Skuteczność: W trakcie badawczej wersji zapowiedzi Codex Security przeskanował 1,2 mln commitów i zidentyfikował 10 561 luk o wysokim poziomie istotności. Z czasem precyzja wzrosła — szum ograniczono o 84%, zawyżanie poziomu istotności zmniejszono o ponad 90%, a odsetek wyników fałszywie dodatnich zredukowano o połowę. System wykrył rzeczywiste luki w OpenSSH, GnuTLS i Chromium, którym przypisano 14 identyfikatorów CVE.⁷⁷

Uwaga: Codex Security nie jest częścią wbudowanego modelu zabezpieczeń sandboxa CLI. Sandbox chroni komputer przed Codex, natomiast Codex Security chroni bazę kodu przed lukami w zabezpieczeniach.

Wdrożenie w przedsiębiorstwie

Kontrola administracyjna (requirements.toml)

Administratorzy egzekwują zasady organizacji za pomocą pliku requirements.toml — wymuszanej administracyjnie konfiguracji, która ogranicza ustawienia mające wpływ na bezpieczeństwo i której użytkownicy nie mogą zastąpić:²¹

Wersja v0.146.0 dodaje rozpoznawanie planu Enterprise oraz administracyjną kontrolę aktualizacji w aplikacji.¹¹⁴ W zarządzanej flocie oznacza to różnicę między samodzielnym aktualizowaniem CLI przez programistów, gdy tylko zauważą nowe wydanie, a ustalaniem terminu wdrożenia danej wersji przez administratora. Informacje o wydaniu zapowiadają tę kontrolę, ale nie podają jej klucza w pliku requirements.toml — dokładną nazwę ustawienia należy uznawać za niezweryfikowaną, dopóki OpenAI jej nie udokumentuje.

# /etc/codex/requirements.toml

# Restrict which approval policies users can select
allowed_approval_policies = ["on-request", "never"]   # `untrusted` retired in v0.149.0

# Limit available sandbox modes
allowed_sandbox_modes = ["read-only", "workspace-write"]

# Control web search capabilities
allowed_web_search_modes = ["cached"]

# Allowlist MCP servers by identity (both name and identity must match)
[mcp_servers.approved-server]
identity = { command = "npx approved-mcp-server" }

# Admin-enforced command restrictions
[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete is prohibited by IT policy"

[[rules.prefix_rules]]
pattern = [{ token = "sudo" }]
decision = "prompt"
justification = "Elevated commands require explicit approval"

W przeciwieństwie do pliku config.toml na poziomie użytkownika, który określa preferencje, requirements.toml stanowi warstwę bezwzględnych ograniczeń określającą wartości dostępne użytkownikom, której nie mogą oni zastąpić. Reguły wymagań administratora mogą jedynie wyświetlać monit lub zabraniać (nigdy nie zezwalają bez wyraźnego powiadomienia).

Konfiguracja MDM w systemie macOS

Konfigurację należy rozpowszechniać przez MDM, korzystając z domeny preferencji com.openai.codex.²¹ Codex obsługuje standardowe ładunki MDM systemu macOS (Jamf Pro, Fleet, Kandji itp.). TOML należy zakodować w formacie base64 bez zawijania wierszy:

Kolejność pierwszeństwa (od najwyższego do najniższego):

1. Zarządzane preferencje systemu macOS (MDM)
2. Wymagania pobierane z chmury (ChatGPT Business / Enterprise)
3. /etc/codex/requirements.toml (lokalny system plików)

Wymagania z chmury uzupełniają wyłącznie nieustawione pola wymagań, dlatego zawsze obowiązują zarządzane warstwy o wyższym priorytecie. Stosowanie wymagań z chmury odbywa się w miarę możliwości — jeśli pobieranie zakończy się niepowodzeniem lub przekroczeniem limitu czasu, Codex będzie kontynuować działanie bez warstwy chmurowej.

Integracja z OpenTelemetry

Codex obsługuje propagację kontekstu śledzenia OpenTelemetry ze standardowych zmiennych środowiskowych OTel aż do wywołań API OpenAI. Przed uruchomieniem Codex należy ustawić standardowe zmienne środowiskowe:

# Point Codex at your OTel collector
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel-collector.internal:4318"
export OTEL_SERVICE_NAME="codex-cli"
export OTEL_RESOURCE_ATTRIBUTES="team=platform,env=production"

# Launch Codex — trace context propagates to all OpenAI API calls
codex

• Obsługiwane są standardowe zmienne środowiskowe OTEL_* (punkt końcowy, nazwa usługi, atrybuty zasobu)
• Kontekst śledzenia jest propagowany przez Codex do wywołań API, co zapewnia kompleksową obserwowalność
• Atrybuty zasobów umożliwiają oznaczanie śladów według zespołu, środowiska lub projektu
• Podczas włączania rejestrowania promptów i narzędzi należy pamiętać o wymaganiach dotyczących prywatności — ślady mogą zawierać fragmenty kodu
• Konfigurowalne metadane śledzenia OpenTelemetry (v0.130.0+). Oprócz standardowej otoczki OTEL_RESOURCE_ATTRIBUTES pakiet codex-otel udostępnia teraz konfigurowalne metadane śledzenia. Dzięki temu administratorzy mogą oznaczać ślady wymiarami charakterystycznymi dla organizacji (centrum kosztów, identyfikator projektu, numer zgłoszenia) bez każdorazowego tworzenia OTEL_RESOURCE_ATTRIBUTES od podstaw przy każdym wywołaniu. Warto połączyć tę funkcję z bardziej rozbudowaną analityką przeglądów i opinii, wprowadzoną w tym samym wydaniu, aby ujednolicić debugowanie i segregowanie problemów w sesjach CLI, app-server oraz remote-control.⁹¹

Dostęp w przedsiębiorstwie

• ChatGPT Business / Enterprise / Edu: Dostęp kontrolowany przez administratora organizacji z automatycznym stosowaniem wymagań pobieranych z chmury. Obsługuje SSO przez SAML/OIDC za pośrednictwem dostawcy tożsamości (Okta, Entra ID itp.)
• API: Standardowe uwierzytelnianie, rozliczenia oraz mechanizmy kontroli organizacji i projektów w API. OpenAI publikuje raporty SOC 2 Type II i SOC 3; dla warstwy Enterprise dostępna jest umowa HIPAA BAA
• Codex SDK: Możliwość osadzania w narzędziach wewnętrznych i przepływach pracy
• Egzekwowanie zasad na dużą skalę: Należy używać requirements_toml_base64 rozpowszechnianego przez MDM lub pliku /etc/codex/requirements.toml na poziomie systemu plików

Przetwarzanie danych i zgodność z przepisami: - Dane wejściowe i wyjściowe API nie są wykorzystywane do trenowania zgodnie z warunkami OpenAI dotyczącymi planów Business/Enterprise/API - Domyślnie ruch OpenAI API jest kierowany przez infrastrukturę zlokalizowaną w Stanach Zjednoczonych; w sprawie wymagań dotyczących przechowywania danych w UE należy skontaktować się z zespołem sprzedaży OpenAI obsługującym klientów Enterprise - Transkrypcje sesji są przechowywane lokalnie; urządzenie opuszczają wyłącznie wywołania API - ChatGPT Enterprise obsługuje standardy zgodności, w tym SOC 2, GDPR i CCPA

Strategia wdrażania

Zalecane etapowe wdrażanie w organizacjach:

1. Program pilotażowy (tydzień 1–2): Wdrożyć rozwiązanie dla 3–5 starszych inżynierów, używając pliku requirements.toml do wymuszenia piaskownicy read-only, zatwierdzeń on-request i wyszukiwania internetowego cached. Zebrać opinie na temat wzorców AGENTS.md i zapotrzebowania na serwery MCP.
2. Rozszerzenie na zespół (tydzień 3–4): Wdrożyć rozwiązanie w całym zespole. Rozpowszechnić standardowy dla zespołu plik config.toml przez MDM lub repozytorium. Włączyć piaskownicę workspace-write dla zaufanych repozytoriów.
3. Integracja z CI (tydzień 5–6): Dodać codex-action do potoków CI/CD na potrzeby automatycznych przeglądów PR i generowania testów. Aby zachować przewidywalność kosztów, używać --ephemeral.
4. Wdrożenie w całej organizacji (od 2. miesiąca): Wdrożyć przez MDM z plikiem requirements.toml wymuszającym zatwierdzone serwery MCP, zasady piaskownicy i listy dozwolonych modeli.

Wzorce audytu

Monitorowanie użycia Codex i egzekwowanie zgodności:

• Ślady OpenTelemetry: Monitorowanie liczby wywołań API, użycia tokenów i opóźnień w poszczególnych zespołach
• Trwałość sesji: Audytowanie katalogu ~/.codex/sessions/ na potrzeby kontroli zgodności (w kontekstach obejmujących dane wrażliwe należy wyłączyć tę funkcję za pomocą --ephemeral)
• Egzekwowanie tożsamości MCP: requirements.toml rejestruje zablokowane próby użycia serwerów — należy je sprawdzać pod kątem nieautoryzowanego użycia narzędzi
• Ścieżka audytu Git: Wszystkie zmiany plików wprowadzane przez Codex przechodzą przez standardowy git — można je przeglądać w historii gałęzi i różnicach PR

Dobre praktyki i antywzorce

Wzorce tworzenia promptów

1. Prompty oparte na ograniczeniach: Należy zacząć od określenia granic. „NIE zmieniaj kontraktów API. Refaktoryzuj wyłącznie wewnętrzną implementację”.
2. Uporządkowane kroki reprodukcji: Ponumerowane kroki pozwalają skuteczniej usuwać błędy niż ogólnikowe opisy
3. Prośby o weryfikację: Na końcu warto dodać: „Uruchom lint oraz najmniejszy odpowiedni zestaw testów. Podaj polecenia i wyniki”.
4. Odwołania do plików: Aby dołączyć konkretne pliki do kontekstu, należy użyć @filename
5. Pętle ukierunkowane na rezultat: „Zaimplementuj, uruchom testy, napraw błędy i zakończ dopiero wtedy, gdy wszystkie testy przejdą pomyślnie”. Codex powtarza działania aż do ukończenia zadania

Filozofia testowania

Społeczność jest zgodna co do podejścia opartego na testach we współpracy z AI:²²

• Zdefiniować testy z wyprzedzeniem jako kryteria ukończenia
• Pozwolić Codexowi powtarzać działania, aż testy przejdą pomyślnie (czerwony → zielony → refaktoryzacja)
• Stosować wzorce programowania Tiger Style
• Przy prośbie o poprawki podawać dokładną treść pliku. Codex korzysta ze ścisłego dopasowywania, a nie z przybliżonego nakładania poprawek opartego na AST

Dobre praktyki zarządzania kontekstem

• Udostępniać wysokiej jakości dokumentację lokalną zamiast polegać na wyszukiwaniu w internecie
• Utrzymywać uporządkowane dokumenty Markdown ze spisami treści i plikami postępu („stopniowe ujawnianie informacji”)
• Ujednolicić zakończenia wierszy (LF i CRLF) we wszystkich śledzonych plikach, aby zapobiec niepowodzeniom podczas nakładania poprawek
• Zachować zwięzłość pliku AGENTS.md, ponieważ długie instrukcje są wypierane z kontekstu

Przepływ pracy z Git

• Przed uruchomieniem Codex w nieznanym repozytorium zawsze utworzyć nową gałąź
• Korzystać z przepływów pracy opartych na poprawkach (git diff / git apply) zamiast bezpośredniej edycji
• Analizować sugestie Codex tak jak zmiany w PR podczas przeglądu kodu
• Przed zatwierdzeniem zmian użyć /diff, aby je zweryfikować

Umiejętności i prompty społeczności

Repozytorium feiskyer/codex-settings zawiera konfiguracje utrzymywane przez społeczność:²³

Prompty wielokrotnego użytku (w ~/.codex/prompts/): - deep-reflector: Wyodrębnianie wniosków z sesji programistycznych - github-issue-fixer [issue-number]: Systematyczna analiza błędów i tworzenie PR - github-pr-reviewer [pr-number]: Przepływy pracy związane z przeglądem kodu - ui-engineer [requirements]: Tworzenie interfejsów frontendowych klasy produkcyjnej

Umiejętności społeczności: - claude-skill: Przekazywanie zadań do Claude Code z trybami uprawnień - autonomous-skill: Automatyzacja zadań obejmujących wiele sesji ze śledzeniem postępu - deep-research: Równoległa koordynacja podzadań - kiro-skill: Potok wymagania → projekt → zadania → wykonanie

Antywzorce

Typowe błędy, które powodują marnowanie tokenów, pogarszają wyniki lub utrudniają przepływy pracy.

Antywzorce kosztowe

Antywzorce dotyczące kontekstu

Antywzorce przepływu pracy

Antywzorce dotyczące promptów

Gotowe przepływy pracy

Kompletne wzorce dla typowych scenariuszy programistycznych.

Przepis 1: Konfiguracja nowego projektu

mkdir my-app && cd my-app && git init
codex

> Create a FastAPI project with: main.py, requirements.txt, Dockerfile,
  basic health endpoint, and a README. Use async throughout.

> /init

Przejrzeć wygenerowany plik AGENTS.md, dostosować go do własnych konwencji, a następnie:

> Run the health endpoint test and confirm it passes

Przepis 2: Codzienny przepływ pracy programistycznej

cd ~/project && git checkout -b feature/user-auth
codex

> @src/models/user.py @src/api/auth.py
  Add password reset functionality. Requirements:
  1. POST /api/auth/reset-request (email → sends token)
  2. POST /api/auth/reset-confirm (token + new password)
  3. Tests for both endpoints
  Run tests when done.

Przejrzeć zmiany za pomocą /diff, a następnie utworzyć commit.

Przepis 3: Złożona refaktoryzacja w trybie planowania

codex

> /plan Migrate the database layer from raw SQL to SQLAlchemy ORM.
  Constraints: don't change any API contracts, keep all existing tests passing.

Przejrzeć plan. Zatwierdzić go lub skorygować:

[Tab] Also add a migration script using Alembic

Po wykonaniu działań przez Codex przeprowadzić weryfikację:

> Run the full test suite and report results
> /diff

Przepis 4: Przegląd PR za pomocą codex exec

codex exec --model gpt-5.6-luna \
  "Review the changes in this branch against main. \
   Flag security issues, missed edge cases, and style violations. \
   Format as a markdown checklist." \
  -o review.md

Przepis 5: Debugowanie przy użyciu Cloud Tasks [EXPERIMENTAL]

codex cloud exec --env my-env "Diagnose why the /api/orders endpoint returns 500 \
  for orders with > 100 line items. Check the serializer, database query, \
  and pagination logic. Propose a fix with tests."

Sprawdzić postęp później:

codex cloud status <TASK_ID>
codex cloud diff <TASK_ID>

Po zakończeniu zastosować poprawkę lokalnie:

codex apply <TASK_ID>

Przewodnik migracji

Z Claude Code

Najważniejsze różnice:

• Sandbox działa na poziomie systemu operacyjnego: Codex korzysta z Seatbelt/Landlock, a nie z kontenerów. Ograniczenia działają na poziomie jądra, poniżej warstwy aplikacji.
• Hooks mają takie same nazwy zdarzeń jak w Claude Code: od wersji v0.150.0 Codex rejestruje dwanaście zdarzeń hook (jedenaście w wersji v0.149.1, przed dodaniem Interrupt) — PreToolUse, PermissionRequest, PostToolUse, PreCompact, PostCompact, SessionStart, SessionEnd, UserPromptSubmit, SubagentStart, SubagentStop, Stop, Interrupt — konfigurowanych w hooks.json lub bezpośrednio w tabelach [[hooks.<Event>]], dlatego większość konfiguracji hook z Claude Code można przenieść, kopiując JSON i oznaczając ją jako zaufaną. Różnice: każdy hook, który nie jest zarządzany, przed uruchomieniem musi zostać sprawdzony i oznaczony jako zaufany za pomocą /hooks; procedury obsługi prompt i agent są analizowane, lecz pomijane; zdarzenia Claude Code spoza tej dwunastki (na przykład Notification) nie mają odpowiedników — należy je obsłużyć za pomocą instrukcji AGENTS.md lub skills.¹²⁴
• Sub-agents v2 (v0.117.0): Sub-agents korzystają teraz z adresów opartych na ścieżkach (np. /root/agent_a), ustrukturyzowanej komunikacji między agentami oraz listy agentów.⁷⁵ Rozszerza to dotychczasowy mechanizm (maks. 6 działających równocześnie, zamiast 12 od wersji v0.91.0). Role w systemie wieloagentowym nadal można dostosowywać za pomocą konfiguracji (od wersji v0.104.0).⁴⁷ W wersji v0.105.0 dodano spawn_agents_on_csv, które umożliwia rozdzielanie wierszy między agentów oraz śledzenie postępu i przewidywanego czasu ukończenia.⁶¹ Codex nadal nie oferuje znanego z Claude Code interfejsu narzędzia Task do delegowania zadań przez użytkownika — wzorce delegowania należy realizować za pomocą zadań w chmurze lub orkiestracji SDK.
• AGENTS.md działa w różnych narzędziach: Plik AGENTS.md działa w Cursor, Copilot, Amp, Jules, Gemini CLI oraz w ponad 60 000 projektów open source. CLAUDE.md działa wyłącznie w Claude.
• Profile zastępują ręczne przełączanie: Zamiast zmieniać flagi przy każdym uruchomieniu należy zdefiniować profile w config.toml.