Codex w terminalu: agent OpenAI, który pisze kod na własnym komputerze

Zwykły asystent czatowy zwraca fragment kodu, który trzeba potem samodzielnie wkleić, zapisać i uruchomić. Codex CLI działa inaczej: to program uruchamiany w terminalu wewnątrz katalogu projektu, który sam czyta pliki, wprowadza w nich zmiany i uruchamia polecenia już zainstalowane na maszynie. (Codex CLI) Różnica jest praktyczna - zamiast kopiowania odpowiedzi z przeglądarki dostaje się narzędzie, które modyfikuje pliki na dysku, a więc wymaga świadomej decyzji, co wolno mu zmieniać.

Poniżej jedna kompletna ścieżka: sprawdzenie środowiska, instalacja na Windows, macOS i Linux, logowanie, ustawienie uprawnień, pierwsze zadanie na małym projekcie, weryfikacja wyniku, typowe błędy, koszty oraz sprzątanie po instalacji.

Instrukcja opiera się na dokumentacji OpenAI dotyczącej Codeksa oraz na oficjalnym repozytorium projektu, w stanie na 8 września 2026 roku. Ta data ma znaczenie praktyczne: dokumentacja Codeksa zmienia się szybko, a część opisanych tu mechanizmów jest wersjonowana albo oznaczona jako podlegająca zmianie - przy rozbieżności rozstrzyga bieżąca dokumentacja producenta, nie ten tekst. Zakres jest ograniczony: opisano CLI uruchamiane lokalnie, a nie aplikację desktopową, rozszerzenie do IDE ani Codex w chmurze - te powierzchnie mają własną dokumentację i częściowo inne zachowanie. Poradnik nie zawiera pomiarów ani wyników uruchomień na konkretnym sprzęcie; nie przeprowadzono testów instalacji na żadnym z trzech systemów, a wszystkie komendy pochodzą z dokumentacji producenta.

Co to jest i czym nie jest

Codex CLI to agent kodujący od OpenAI działający lokalnie na komputerze użytkownika. (openai/codex - README) Uruchamia się go poleceniem codex w katalogu repozytorium; program pozwala badać nieznany kod, planować zmianę, edytować pliki i uruchamiać lokalne narzędzia deweloperskie, a przebieg tury oraz poszczególne polecenia i różnice w plikach są widoczne w trakcie pracy. (Codex CLI)

Warto od razu rozróżnić trzy rzeczy, które łatwo pomylić.

Model to nie to samo co agent. Codex CLI wybiera model, którym się posługuje - w interfejsie służy do tego polecenie /model, wybierające model i poziom wysiłku rozumowania. (Codex CLI) Sam agent to program, który ten model wywołuje i wykonuje jego decyzje na plikach.

CLI to nie jedyna powierzchnia. Ta sama dokumentacja opisuje osobno aplikację desktopową ChatGPT, rozszerzenie do IDE oraz Codex w chmurze. (openai/codex - README) Konfiguracja jest przy tym częściowo wspólna: CLI i rozszerzenie do IDE korzystają z tych samych warstw konfiguracji (Config basics) i współdzielą zapisane dane logowania - wylogowanie z jednego z nich wymusza ponowne logowanie w drugim. (Authentication)

Lokalnie nie znaczy offline. Kod i pliki zostają na dysku, ale zapytania trafiają do modelu OpenAI przez sieć. Uwierzytelnianie i wywołania modelu to ruch, którego sandbox opisany niżej nie filtruje - dokumentacja wymienia żądania modelu i uwierzytelniania klienta wprost jako ruch spoza kontroli lokalnego proxy sieciowego. (Permissions)

Co powstanie na koniec

Działająca instalacja Codeksa w terminalu, zalogowana na własne konto, z uprawnieniami ustawionymi świadomie zamiast domyślnie „na wszystko”, oraz jeden mały projekt przeprowadzony od pustego katalogu do działającej strony z kontrolą wersji. Efektem nie jest gotowy zamiennik programisty: wynik każdej tury trzeba przejrzeć jak cudzy pull request, a dokumentacja producenta zaleca dokładnie takie podejście - uruchomienie ukierunkowanej weryfikacji, przegląd różnic i opisanie decyzji w komunikatach commitów na potrzeby audytu. (Agent approvals & security)

Wymagania i przygotowanie

Repozytorium projektu podaje krótką tabelę wymagań: macOS 12 lub nowszy, Ubuntu 20.04 lub nowszy albo Debian 10 lub nowszy, Windows 11 przez WSL2, opcjonalnie Git 2.23 lub nowszy dla wbudowanych pomocników do pull requestów, oraz minimum 4 GB RAM przy zalecanych 8 GB. (openai/codex - docs/install.md) Warto zauważyć rozbieżność: ta tabela wymienia dla Windows wyłącznie drogę przez WSL2, podczas gdy dokumentacja produktowa opisuje osobno działający sandbox natywny dla Windows. (Windows sandbox) Obie ścieżki są opisane niżej; przy wyborze natywnej warto liczyć się z tym, że repozytorium jej nie wymienia wśród wspieranych konfiguracji.

Poza tym kilka warunków wynika wprost z opisu poszczególnych systemów.

Konto. Zalecane jest zalogowanie się kontem ChatGPT i korzystanie z Codeksa w ramach planu Plus, Pro, Business, Edu lub Enterprise; alternatywą jest klucz API, który wymaga dodatkowej konfiguracji. (openai/codex - README) Strona cennika wymienia szerszy zestaw planów obejmujących ChatGPT Work i Codeksa - Free, Go, Plus, Pro, Business, Edu i Enterprise - przy czym dostępność poszczególnych funkcji różni się między planami. (Pricing) Przed instalacją warto sprawdzić własny plan, bo od niego zależą limity opisane w sekcji o kosztach.

Repozytorium Git. Nie jest formalnie wymagane, ale ma bezpośredni wpływ na zachowanie programu: przy starcie Codex wykrywa, czy katalog jest objęty kontrolą wersji, i dla katalogów wersjonowanych rekomenduje tryb Auto (zapis w obszarze roboczym z zatwierdzeniami na żądanie), a dla niewersjonowanych tryb read-only. (Agent approvals & security) Dokumentacja zaleca też pracę na gałęzi funkcyjnej i utrzymywanie czystego git status przed zleceniem zadania, bo to ułatwia izolowanie i cofanie zmian wprowadzonych przez agenta. (Agent approvals & security)

Windows. Zalecana jest Windows 11 jako najlepsza baza; w pełni zaktualizowana nowsza Windows 10 działa w trybie „best effort”, przy czym Codex zależy od nowoczesnej obsługi konsoli, w tym ConPTY, co w praktyce oznacza Windows 10 w wersji 1809 lub nowszej. Starsze kompilacje Windows 10 nie są rekomendowane. Dokumentacja zakłada też dostępność menedżera pakietów winget, a zalecany sandbox natywny wymaga konfiguracji zatwierdzonej przez administratora - część urządzeń zarządzanych firmowo blokuje te kroki mimo poprawnej wersji systemu. (Windows sandbox)

macOS. Sandbox działa od razu, bez instalowania czegokolwiek dodatkowego, na wbudowanym mechanizmie Seatbelt. (Sandbox) Dokumentacja nie wprowadza w tym miejscu rozróżnienia między Apple Silicon a Intelem po stronie działania programu; różnica dotyczy wyłącznie doboru pliku przy instalacji z paczek z GitHuba, gdzie osobne archiwa przygotowano dla aarch64-apple-darwin i x86_64-apple-darwin. (openai/codex - README)

Linux i WSL2. Sandbox wymaga narzędzia bubblewrap, instalowanego menedżerem pakietów dystrybucji, na przykład sudo apt install bubblewrap. Codex korzysta z pierwszego pliku wykonywalnego bwrap znalezionego w PATH; przy jego braku sięga po pomocnika wbudowanego, ale ten wymaga możliwości tworzenia nieuprzywilejowanych przestrzeni nazw użytkownika. (Sandbox)

Instalacja przez npm wymaga Node.js - jest to jedna z alternatywnych dróg instalacji obok instalatorów samodzielnych i Homebrew. (openai/codex - README)

Instalacja: trzy systemy

Producent udostępnia instalatory samodzielne oraz instalację przez menedżery pakietów. Poniżej komendy w brzmieniu z oficjalnego repozytorium.

Zanim padnie pierwsza komenda: co robi instalator potokowy

Obie komendy instalatora samodzielnego - curl … | sh na macOS i Linuksie oraz irm … | iex na Windows - działają według tego samego wzorca: pobierają skrypt z sieci i przekazują go od razu interpreterowi. Skrypt nie ląduje na dysku, nie da się go obejrzeć przed uruchomieniem i nie jest porównywany z żadną sumą kontrolną ani podpisem. Praktyczne zabezpieczenie sprowadza się więc do dwóch rzeczy: zaufania do domeny chatgpt.com i poprawności połączenia TLS.

Kto woli zobaczyć, co uruchamia, może rozdzielić te dwa kroki:

curl -fsSL https://chatgpt.com/codex/install.sh -o install-codex.sh
less install-codex.sh
sh install-codex.sh

Na Windows odpowiednikiem jest pobranie install.ps1 do pliku, przeczytanie go i dopiero potem uruchomienie.

Warto przy tym wiedzieć, czego dokumentacja Codeksa nie oferuje. Na przejrzanych stronach nie ma opisanej procedury weryfikacji instalatora ani binarki sumą kontrolną czy podpisem GPG - nie ma bloku odpowiadającego temu, co dla Claude Code opisuje sekcja o integralności wydań. W wydaniach GitHuba widać wprawdzie plik codex-package_SHA256SUMS oraz pliki .sigstore dla części artefaktów linuksowych, ale dokumentacja nie podaje procedury ich użycia, więc nie da się tu opisać kroków w sposób potwierdzony źródłowo.

Kto nie chce polegać wyłącznie na zaufaniu do domeny, ma dwie alternatywy opisane niżej: instalację przez menedżer pakietów (Homebrew, npm) albo pobranie gotowej binarki z wydań GitHuba i rozpakowanie jej ręcznie. Żadna z nich nie usuwa konieczności zaufania producentowi - przesuwa jedynie punkt zaufania na menedżer pakietów lub na infrastrukturę wydań GitHuba.

Windows

W PowerShellu:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

To polecenie z oficjalnego README projektu. (openai/codex - README) Fragment -ExecutionPolicy ByPass obchodzi zasady wykonywania skryptów PowerShella wyłącznie na czas tego jednego uruchomienia, nie zmieniając ustawień systemu na stałe.

Instalatory samodzielne pobierają pliki domyślnie z https://releases.openai.com/codex i przechodzą na wydania GitHuba, gdy pobranie metadanych lub zasobu się nie powiedzie; wymuszenie GitHuba jako źródła daje zmienna CODEX_INSTALLER_USE_RELEASES_OPENAI_COM ustawiona na false. (openai/codex - README)

Na Windows do wyboru są dwie ścieżki działania agenta. Pierwsza to praca natywna w PowerShellu z sandboksem Windows - w tym trybie tryb agenta blokuje zapisy poza katalogiem roboczym i uniemożliwia dostęp do sieci bez wyraźnej zgody. Druga to WSL2, w którym Codex korzysta z linuksowej implementacji sandboksu. (Windows sandbox, Sandbox) Domyślnie warto zostać przy sandboksie natywnym, a po WSL sięgać wtedy, gdy potrzebne są linuksowe narzędzia, gdy praca i tak toczy się w WSL2 albo gdy żaden z natywnych trybów nie działa w danym środowisku. (Windows sandbox)

Instalacja pod WSL2 wygląda inaczej niż natywna. Z podniesionego PowerShella lub Terminala Windows:

wsl --install
wsl

a następnie już z powłoki WSL:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex

Taka sekwencja pochodzi wprost z dokumentacji WSL dla Codeksa. (WSL) Uwaga na wersję: WSL1 był obsługiwany do Codeksa 0.114, a od 0.115 linuksowy sandbox przeszedł na bubblewrap i WSL1 nie jest już wspierany. (WSL)

Przy pracy w WSL istotna jest jeszcze lokalizacja repozytorium. Praca w ścieżkach zamontowanych z Windows, czyli /mnt/c/…, bywa wolniejsza niż w ścieżkach natywnie linuksowych, więc dokumentacja zaleca trzymanie repozytoriów w katalogu domowym Linuksa, na przykład ~/code/my-app, dla szybszych operacji wejścia-wyjścia i mniejszej liczby problemów z dowiązaniami i uprawnieniami; z poziomu Eksploratora Windows te pliki są dostępne pod \\wsl$. (WSL)

Osobna kwestia to katalog konfiguracji. CLI uruchamiane w WSL domyślnie korzysta z linuksowego katalogu domowego, więc nie dzieli automatycznie konfiguracji, zapisanego logowania ani historii sesji z instalacją natywną na Windows. Współdzielenie wymaga albo synchronizacji ~/.codex z %USERPROFILE%\.codex, albo wskazania katalogu Windows zmienną środowiskową:

export CODEX_HOME=/mnt/c/Users/<uzytkownik>/.codex

Żeby ustawienie działało w każdej powłoce, wpis trafia do profilu powłoki WSL, na przykład ~/.bashrc lub ~/.zshrc. (ChatGPT desktop app for Windows)

macOS

Instalator samodzielny:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Alternatywnie Homebrew:

brew install --cask codex

Obie komendy pochodzą z README projektu. (openai/codex - README) Trzecia droga to pobranie binarki z wydań GitHuba - dla Apple Silicon archiwum codex-aarch64-apple-darwin.tar.gz, dla starszego sprzętu x86_64 codex-x86_64-apple-darwin.tar.gz. Każde archiwum zawiera jeden plik z nazwą platformy w środku, więc po rozpakowaniu zwykle zmienia się jego nazwę na codex. (openai/codex - README)

Linux

Instalator samodzielny jest ten sam co na macOS:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Binarki z wydań GitHuba to codex-x86_64-unknown-linux-musl.tar.gz dla x86_64 i codex-aarch64-unknown-linux-musl.tar.gz dla arm64. (openai/codex - README)

Przed pierwszym uruchomieniem trzeba doinstalować bubblewrap, na przykład na Debianie i Ubuntu:

sudo apt install bubblewrap

Codex zgłasza ostrzeżenie przy starcie, gdy brakuje bwrap albo gdy wbudowany pomocnik nie potrafi utworzyć potrzebnej przestrzeni nazw użytkownika. (Sandbox)

Na Ubuntu bywa potrzebny jeszcze jeden krok związany z AppArmorem. Na Ubuntu 25.04 instalacja bubblewrap z repozytorium dystrybucji powinna wystarczyć, bo profil bwrap-userns-restrict jest częścią pakietu apparmor i leży w /etc/apparmor.d/bwrap-userns-restrict. Na Ubuntu 24.04 Codex może mimo instalacji nadal ostrzegać, że nie potrafi utworzyć przestrzeni nazw; wtedy profil dogrywa się osobno:

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

Polecenie apparmor_parser -r ładuje profil do jądra bez restartu; alternatywą jest przeładowanie wszystkich profili przez sudo systemctl reload apparmor.service. Dopiero gdy profil jest niedostępny albo nie rozwiązuje problemu, dokumentacja wymienia wyłączenie ograniczenia globalnie poleceniem sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0. (Sandbox) Kolejność ma znaczenie: załadowanie profilu dotyczy samego bwrap, wyłączenie sysctl obniża zabezpieczenie dla całego systemu.

Instalacja przez npm - na wszystkich systemach

npm install -g @openai/codex

Nazwa pakietu jest z przestrzenią @openai/. (openai/codex - README) Ta droga wymaga zainstalowanego Node.js.

Gdzie ląduje binarka i co z tego wynika dla PATH

Instalator samodzielny umieszcza widoczne polecenie codex w ~/.local/bin na macOS i Linuksie oraz w %LOCALAPPDATA%\Programs\OpenAI\Codex\bin na Windows; zmienna CODEX_INSTALL_DIR pozwala wskazać inny katalog. Sama pamięć podręczna pakietu standalone zostaje przy tym pod CODEX_HOME/packages/standalone. (Environment variables) Te dwie ścieżki warto zapamiętać, bo to od nich zaczyna się diagnostyka, gdy po instalacji polecenie codex nie działa.

Weryfikacja instalacji

Po instalacji warto od razu sprawdzić, czy polecenie w ogóle istnieje:

codex --version

Polecenie wypisuje numer wersji zainstalowanego CLI. (Troubleshooting) Drugi krok to uruchomienie samego codex w katalogu projektu: dokumentacja pokazuje, że program otwiera ekran startowy z nazwą modelu, katalogiem roboczym i listą poleceń w rodzaju /init, /status, /permissions, /model i /review. (Codex CLI) Jeżeli ten ekran się pojawia, instalacja jest kompletna; co dalej, opisuje sekcja o logowaniu.

Szerszą diagnostykę - instalacja, konfiguracja, uwierzytelnianie, środowisko uruchomieniowe, Git i terminal - daje osobne polecenie:

codex doctor

Dokumentacja opisuje je jako raport diagnostyczny przydatny przed zgłoszeniem błędu albo przy podejrzeniu zepsutej instalacji. (Command line options)

Aktualizacja

Dla macOS i Linuksa dokumentacja CLI podaje jako polecenie aktualizacyjne dokładnie to samo polecenie co instalacyjne, czyli ponowne uruchomienie install.sh. (Codex CLI) Dla Windows analogicznego bloku „Update Codex” w dokumentacji nie ma - ponowne uruchomienie install.ps1 jest tu rozsądnym wnioskiem z symetrii obu instalatorów, ale nie jest potwierdzone wprost. Osobno dokumentacja wymienia polecenie codex update, opisane jako sprawdzenie i zastosowanie aktualizacji, o ile zainstalowane wydanie obsługuje samoaktualizację. (Command line options) Przy instalacji przez menedżer pakietów aktualizuje się odpowiednio przez ten menedżer.

Logowanie i wybór metody uwierzytelniania

Gdy weryfikacja z poprzedniej sekcji wypada pomyślnie, wystarczy wejść do katalogu projektu i uruchomić codex. Przy pierwszym uruchomieniu program prosi o wybór metody logowania - domyślnie Sign in with ChatGPT lub inną dostępną. (Codex CLI) Logowanie kontem ChatGPT z poziomu CLI otwiera okno przeglądarki, a po zalogowaniu przeglądarka odsyła dane uwierzytelniające z powrotem do Codeksa. (Authentication)

Wybór metody to nie tylko wygoda, bo od niego zależy, jakie zasady obowiązują dane użytkownika. Przy logowaniu kontem ChatGPT korzystanie z Codeksa podlega uprawnieniom przestrzeni roboczej ChatGPT, kontroli dostępu opartej na rolach oraz ustawieniom retencji i rezydencji danych z planu ChatGPT Enterprise. Przy kluczu API obowiązują natomiast ustawienia retencji i udostępniania danych organizacji API. (Authentication) Klucz API rozlicza się według standardowych stawek API zamiast limitów zawartych w planie ChatGPT, a część funkcji zależnych od przestrzeni roboczej ChatGPT lub usług chmurowych jest wtedy ograniczona albo niedostępna. (Authentication)

Gdzie trafiają poświadczenia

To jeden z ważniejszych punktów tej instrukcji. Codex buforuje dane logowania lokalnie w postaci pliku tekstowego ~/.codex/auth.json albo w magazynie poświadczeń systemu operacyjnego. (Authentication) Zachowanie ustawia klucz cli_auth_credentials_store w config.toml:

# file | keyring | auto
cli_auth_credentials_store = "keyring"

Wartość file trzyma poświadczenia w auth.json w katalogu CODEX_HOME (domyślnie ~/.codex), keyring w magazynie systemowym, a auto używa magazynu systemowego, gdy jest dostępny, i wraca do pliku, gdy go nie ma. (Authentication)

Przy przechowywaniu plikowym dokumentacja formułuje zalecenie wprost: ~/.codex/auth.json należy traktować jak hasło, bo zawiera tokeny dostępu - nie wolno go commitować, wklejać do zgłoszeń ani wysyłać na czacie. (Authentication) Dla sesji z logowaniem ChatGPT tokeny odświeżają się automatycznie przed wygaśnięciem, więc aktywne sesje zwykle nie wymagają kolejnego logowania przez przeglądarkę. (Authentication)

Jeżeli konto loguje się adresem e-mail i hasłem, przed dostępem do Codeksa w chmurze trzeba włączyć uwierzytelnianie wieloskładnikowe; wymóg obowiązuje także wtedy, gdy konto obsługuje kilka metod logowania i jedną z nich jest e-mail z hasłem. Konta logujące się przez dostawcę społecznościowego nie mają tego wymogu po stronie ChatGPT, a przy dostępie przez SSO egzekwowanie MFA leży po stronie administratora organizacji. (Authentication)

Uprawnienia: dwie niezależne warstwy

To najważniejsza sekcja całego poradnika i miejsce, w którym najłatwiej zrobić sobie krzywdę. Zabezpieczenia Codeksa opierają się na dwóch warstwach działających razem: tryb sandboksu określa, co technicznie wolno agentowi zrobić przy wykonywaniu wygenerowanych poleceń, a polityka zatwierdzeń określa, kiedy Codex musi zapytać przed wykonaniem czynności. (Agent approvals & security)

Domyślnie agent działa z wyłączonym dostępem do sieci, a lokalnie korzysta z sandboksu egzekwowanego przez system operacyjny, który ogranicza zasięg działania zwykle do bieżącego obszaru roboczego. (Agent approvals & security)

Tryby sandboksu:

read-only - agent może przeglądać pliki, ale bez zatwierdzenia nie edytuje plików ani nie uruchamia poleceń;
workspace-write - agent czyta pliki, edytuje w obrębie obszaru roboczego i uruchamia rutynowe polecenia lokalne wewnątrz tej granicy; to domyślny tryb o niskim tarciu do pracy lokalnej;
danger-full-access - agent działa bez ograniczeń sandboksu, bez granic systemu plików i sieci. (Sandbox)

Polityki zatwierdzeń:

untrusted - agent pyta przed uruchomieniem poleceń spoza swojego zaufanego zestawu;
on-request - agent pracuje domyślnie wewnątrz sandboksu i pyta, kiedy potrzebuje wyjść poza tę granicę;
never - agent nie zatrzymuje się na monitach o zgodę. (Sandbox)

W presecie Auto, odpowiadającym --sandbox workspace-write --ask-for-approval on-request, Codex może czytać pliki, wprowadzać zmiany i uruchamiać polecenia w katalogu roboczym automatycznie, a pyta o zgodę na edycję plików poza obszarem roboczym oraz na polecenia wymagające dostępu do sieci. Do samej rozmowy i planowania bez wprowadzania zmian służy tryb read-only, przełączany poleceniem /permissions. (Agent approvals & security)

Ustawienie jawne z linii poleceń:

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

Obie formy podaje dokumentacja bezpieczeństwa; samo codex przyjmuje wartości domyślne. (Agent approvals & security)

Warto wiedzieć, co dokładnie należy do obszaru roboczego: obejmuje on bieżący katalog oraz katalogi tymczasowe w rodzaju /tmp, a listę katalogów w obszarze pokazuje polecenie /status. (Agent approvals & security)

Nawet w domyślnej polityce workspace-write część ścieżek wewnątrz zapisywalnych katalogów pozostaje chroniona i tylko do odczytu: <zapisywalny_katalog>/.git niezależnie od tego, czy jest katalogiem czy plikiem, a przy pliku wskaźnikowym gitdir: ... również rozwiązana ścieżka katalogu Git, a także <zapisywalny_katalog>/.agents i <zapisywalny_katalog>/.codex, gdy istnieją jako katalogi. Ochrona działa rekurencyjnie. (Agent approvals & security)

Sieć

Domyślnie w trybie workspace-write dostęp do sieci jest wyłączony, dopóki nie zostanie włączony w konfiguracji:

[sandbox_workspace_write]
network_access = true

(Agent approvals & security)

Samo włączenie dostępu daje polecenia z nieograniczonym bezpośrednim ruchem wychodzącym. Ograniczenie kierunków wymaga osobnej funkcji proxy sieciowego, która domyślnie jest wyłączona:

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

Dokumentacja opisuje zależność między tymi ustawieniami wprost: sieć wyłączona plus network_proxy włączone oznacza brak sieci i bezczynną funkcję; sieć włączona plus proxy wyłączone oznacza nieograniczony ruch bezpośredni; dopiero sieć włączona plus proxy włączone daje ruch ograniczony skonfigurowaną polityką. Reguły domen działają na zasadzie listy dozwolonych: dokładne hosty pasują tylko do siebie, *.example.com obejmuje subdomeny bez samej domeny nadrzędnej, **.example.com obejmuje jedno i drugie, globalne * pasuje do każdego publicznego hosta niezablokowanego regułą, a deny zawsze wygrywa nad allow. Jedno zastrzeżenie łatwo przeoczyć: globalna gwiazdka jest dopuszczalna wyłącznie jako reguła allow, więc "*" = "deny" nie zadziała jako globalna blokada - blokuje się wskazane hosty albo nie włącza się dla nich reguły dozwolonej. (Agent approvals & security)

Domyślnie zablokowane są też cele lokalne i prywatne - ustawienie allow_local_binding = false blokuje pętlę zwrotną, adresy link-local i prywatne, a nazwy hostów rozwiązujące się na adresy lokalne pozostają zablokowane nawet wtedy, gdy pasują do listy dozwolonych. (Agent approvals & security)

Osobno działa wyszukiwanie w sieci. Codex domyślnie włącza je dla czatów lokalnych i serwuje wyniki z pamięci podręcznej wyszukiwania - indeksu utrzymywanego przez OpenAI, który zwraca wyniki wstępnie zaindeksowane zamiast pobierać żywe strony. Zmniejsza to ekspozycję na wstrzyknięcie promptu z dowolnej żywej treści, ale wyniki i tak należy traktować jako niezaufane. Tryb ustawia klucz web_search z wartościami "cached" (domyślna), "indexed", "live" (odpowiednik --search) oraz "disabled". (Config basics) Przy pracy z --yolo lub innym ustawieniem pełnego dostępu wyszukiwanie domyślnie przełącza się na wyniki żywe. (Config basics)

Warto wiedzieć, czego proxy poleceń nie obejmuje. Filtruje ono skrypty, programy i procesy potomne działające wewnątrz lokalnego sandboksu poleceń, ale nie obejmuje wyszukiwania w sieci, wywołań narzędzi aplikacji i konektorów, połączeń z serwerami MCP, aktywności przeglądarki i Computer Use, zadań Codex w chmurze ani żądań modelu i uwierzytelniania klienta. (Agent approvals & security)

Uprawnienia na Windows

Przy uruchomieniu natywnym na Windows tryb sandboksu ustawia się w config.toml:

[windows]
sandbox = "elevated"   # albo "unelevated"

Tryb elevated jest preferowany - korzysta z dedykowanych kont sandboksowych o niższych uprawnieniach, granic uprawnień systemu plików, reguł zapory i zmian zasad lokalnych potrzebnych dla poleceń uruchamianych w sandboksie. Tryb unelevated to wariant zapasowy: uruchamia polecenia z ograniczonym tokenem Windows wywiedzionym z bieżącego użytkownika, stosuje granice systemu plików oparte na listach ACL i używa kontroli offline na poziomie środowiska zamiast reguły zapory dedykowanego konta offline. Jest słabszy, ale przydatny, gdy konfiguracja wymagająca zgody administratora jest zablokowana zasadami lokalnymi lub firmowymi. (Windows sandbox) Oba tryby domyślnie korzystają też z prywatnego pulpitu dla mocniejszej izolacji interfejsu; windows.sandbox_private_desktop = false przywraca starsze zachowanie Winsta0\Default i ma sens wyłącznie przy problemach ze zgodnością. (Windows sandbox)

Gdy polecenie nie działa, bo sandbox Windows nie może odczytać katalogu, w sesji pomaga:

/sandbox-add-read-dir C:\pelna\sciezka\do\katalogu

Ścieżka musi być istniejącym katalogiem bezwzględnym, a uprawnienie obowiązuje w bieżącej sesji. (Windows sandbox)

Czego sandbox nie załatwia

Dokumentacja jest w tej sprawie precyzyjna: uruchomienie Codeksa w trybie pełnego dostępu oznacza, że nie jest on ograniczony do katalogu projektu i może wykonać niezamierzone destrukcyjne działania prowadzące do utraty danych. Bezpieczniejszym wzorcem automatyzacji jest utrzymanie granic sandboksu i użycie reguł dla konkretnych wyjątków. (Windows sandbox) Osobne ryzyko dotyczy treści z sieci: włączanie dostępu sieciowego lub wyszukiwania wymaga ostrożności, bo wstrzyknięcie promptu może skłonić agenta do pobrania i wykonania niezaufanych instrukcji. (Agent approvals & security)

Konfiguracja: gdzie co ustawić

Codex czyta konfigurację z kilku miejsc. Ustawienia osobiste żyją w ~/.codex/config.toml, a nadpisania dla projektu w plikach .codex/config.toml wewnątrz repozytorium. Ze względów bezpieczeństwa warstwy projektowe .codex/ ładują się tylko wtedy, gdy projekt jest zaufany. (Config basics)

Kolejność rozstrzygania wartości, od najwyższego priorytetu:

flagi CLI i nadpisania --config,
pliki projektowe .codex/config.toml, od katalogu głównego projektu w dół do katalogu bieżącego (bliższy wygrywa, wyłącznie w projektach zaufanych),
pliki profilu wybierane przez --profile nazwa (~/.codex/nazwa.config.toml),
konfiguracja użytkownika ~/.codex/config.toml,
konfiguracja systemowa, jeśli istnieje: /etc/codex/config.toml na systemach uniksowych,
wartości domyślne wbudowane. (Config basics)

Oznaczenie projektu jako niezaufanego powoduje pominięcie warstw .codex/ - konfiguracji projektowej, haków i reguł; konfiguracja użytkownika i systemowa nadal się ładują. (Config basics)

Najczęściej zmieniane klucze to model domyślny (model), polityka zatwierdzeń (approval_policy), tryb sandboksu (sandbox_mode), tryb wyszukiwania (web_search) oraz poziom wysiłku rozumowania (model_reasoning_effort). (Config basics)

Warto znać jeszcze jeden mechanizm, bo dotyczy sekretów. Klucz [shell_environment_policy] steruje tym, które zmienne środowiskowe Codex przekazuje uruchamianym poleceniom. Ustawienie ignore_default_excludes domyślnie ma wartość true, co pomija automatyczne filtrowanie nazw zmiennych zawierających KEY, SECRET lub TOKEN; ustawienie go na false włącza to filtrowanie. (Config basics) Przy pracy w repozytorium, w którym w środowisku siedzą klucze API, jest to ustawienie warte świadomej decyzji.

Stan lokalny leży pod CODEX_HOME (domyślnie ~/.codex), gdzie typowo znajdują się config.toml, auth.json przy przechowywaniu plikowym, history.jsonl przy włączonej trwałej historii oraz inne dane, logi i pamięci podręczne. (Advanced Configuration)

Nadpisania jednorazowe robi się z linii poleceń, przy czym wartości -c/--config są parsowane jako TOML, a nie JSON:

codex --model <nazwa-modelu>
codex --config sandbox_workspace_write.network_access=true

(Advanced Configuration) Nazwy modeli celowo podano tu jako placeholder, bo zmieniają się szybciej niż reszta konfiguracji; aktualną listę pokazuje polecenie /model w uruchomionej sesji. (Codex CLI)

AGENTS.md, czyli stałe instrukcje dla projektu

Codex czyta pliki AGENTS.md przed rozpoczęciem pracy. Łańcuch instrukcji budowany jest raz na uruchomienie - w interfejsie terminalowym zwykle raz na sesję - w kolejności: najpierw zasięg globalny w katalogu domowym Codeksa (domyślnie ~/.codex, chyba że ustawiono CODEX_HOME), gdzie czytany jest AGENTS.override.md, a w razie jego braku AGENTS.md; potem zasięg projektu, od katalogu głównego (zwykle katalogu Git) w dół do katalogu bieżącego, przy czym w każdym katalogu sprawdzane są kolejno AGENTS.override.md, AGENTS.md i ewentualne nazwy zapasowe z project_doc_fallback_filenames, a brany jest co najwyżej jeden plik na katalog. Pliki łączone są od katalogu głównego w dół, więc te bliższe katalogowi bieżącemu nadpisują wcześniejsze wskazówki. (Custom instructions with AGENTS.md)

Pliki puste są pomijane, a dokładanie kolejnych kończy się po osiągnięciu limitu project_doc_max_bytes, domyślnie 32 KiB. (Custom instructions with AGENTS.md)

Szkielet pliku dla bieżącego katalogu tworzy polecenie /init, opisane jako polecenie tworzące AGENTS.md z instrukcjami dla Codeksa. (Codex CLI, Best practices) Wynik warto potem poprawić ręcznie, bo dobry AGENTS.md opisuje układ repozytorium i ważne katalogi, sposób uruchomienia projektu, komendy budowania, testów i lintowania, konwencje inżynierskie i oczekiwania wobec pull requestów, ograniczenia i reguły „nie rób”, a także to, co oznacza ukończenie zadania i jak zweryfikować pracę. (Best practices)

Pierwsze zadanie: mała lista zadań bez backendu

Poniższe ćwiczenie to propozycja pierwszego uruchomienia, a nie relacja z wykonanego testu. Nie sprawdzono go na żadnej maszynie; opisane kroki wynikają z udokumentowanego zachowania narzędzia, a nie z zaobserwowanego przebiegu.

Projekt jest celowo minimalny: strona z listą zadań w czystym HTML, CSS i JavaScripcie, bez serwera i bez zależności, z zapisem stanu w pamięci przeglądarki. Taki zakres pozwala zobaczyć pełną pętlę pracy agenta bez ryzyka, że coś pójdzie nie tak w skomplikowanym repozytorium.

Przygotowanie katalogu

Najpierw pusty katalog i repozytorium Git, żeby każda zmiana była widoczna i odwracalna:

mkdir lista-zadan
cd lista-zadan
git init
git commit --allow-empty -m "Punkt wyjścia"

Powód takiego startu jest udokumentowany: dokumentacja zaleca tworzenie punktów kontrolnych Git przed zadaniem i po nim, żeby móc cofnąć zmiany. (Codex CLI)

Wykrycie repozytorium ma też wpływ na to, co Codex zaproponuje przy starcie: dla katalogów wersjonowanych rekomendowany jest tryb Auto, dla niewersjonowanych read-only. (Agent approvals & security)

Uruchomienie i sprawdzenie ustawień

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

Zaraz po starcie warto wpisać /status, które pokazuje bieżącą konfigurację sesji, w tym katalogi wchodzące w skład obszaru roboczego. (Codex CLI, Agent approvals & security) To moment na upewnienie się, że agent widzi ten katalog, który powinien - a nie na przykład katalog nadrzędny z innymi projektami.

Prompt na pierwsze zadanie

Dokumentacja producenta podaje konkretną strukturę dobrego zapytania: cel, kontekst, ograniczenia oraz warunek ukończenia. (Best practices) Poniższy prompt trzyma się tego układu:

Cel: zbuduj w tym pustym katalogu prostą stronę z listą zadań, działającą
po otwarciu pliku index.html bezpośrednio w przeglądarce.

Kontekst: katalog jest pusty i jest repozytorium Git. Brak backendu,
brak serwera, brak menedżera pakietów.

Ograniczenia: wyłącznie index.html, styles.css i app.js; żadnych
zewnętrznych bibliotek ani odwołań do CDN; stan listy zapisywany
w localStorage; interfejs po polsku.

Ukończone, gdy: da się dodać zadanie, oznaczyć je jako zrobione,
usunąć je, a po odświeżeniu strony lista wygląda tak samo jak przed
odświeżeniem. Wypisz na koniec listę utworzonych plików.

Zapytania mniej precyzyjne też działają - dokumentacja zaznacza, że Codex bywa użyteczny nawet przy nieidealnym promcie - ale jasne polecenie daje wynik bardziej przewidywalny, zwłaszcza w większych repozytoriach i przy zadaniach o wyższej stawce. (Best practices)

Kryteria akceptacji pierwszego zadania

Test nie polega na przeczytaniu podsumowania agenta, tylko na sprawdzeniu efektu:

git status pokazuje wyłącznie trzy nowe pliki i nic więcej. Pojawienie się plików spoza zakresu to sygnał, że prompt był za szeroki.
git diff przejrzany w całości. To ten sam nawyk co przy cudzym pull requeście; dokumentacja zaleca traktowanie propozycji Codeksa dokładnie tak. (Agent approvals & security)
Otwarcie index.html w przeglądarce, dodanie dwóch zadań, oznaczenie jednego jako zrobione, odświeżenie strony klawiszem F5. Oba zadania są nadal na liście, w tym samym stanie.
Wyszukanie w app.js ciągu localStorage i sprawdzenie, że zapis faktycznie tam jest, a nie tylko w opisie odpowiedzi.
Brak odwołań do zewnętrznych adresów: sprawdzenie, czy w index.html nie ma znaczników <script src="https://…"> ani <link href="https://…">.

Ostatni punkt jest istotny, bo jest to najczęstsze ciche naruszenie ograniczeń z promptu. Po zaliczeniu testu warto zatwierdzić stan:

git add .
git commit -m "Lista zadań: pierwsza wersja"

Drugie zadanie i przegląd

Druga tura sprawdza, czy agent radzi sobie ze zmianą istniejącego kodu, a nie tylko z pisaniem od zera:

Cel: dodaj filtrowanie listy - trzy przyciski Wszystkie, Aktywne, Zrobione.

Kontekst: istniejące pliki index.html, styles.css i app.js w tym katalogu.

Ograniczenia: nie zmieniaj formatu danych zapisywanych w localStorage;
nadal bez bibliotek zewnętrznych; wybrany filtr nie musi przetrwać
odświeżenia strony.

Ukończone, gdy: każdy z trzech przycisków pokazuje właściwy podzbiór zadań,
a wcześniej zapisane zadania nadal wczytują się poprawnie po odświeżeniu.

Kryterium akceptacji jest tu ostrzejsze niż w pierwszej turze: dane zapisane przed zmianą muszą nadal działać po zmianie. Najprostsze sprawdzenie to dodanie kilku zadań przed drugą turą i upewnienie się po niej, że nie zniknęły.

Do przeglądu zmian służy osobny mechanizm. Polecenie /review uruchamia dedykowany przegląd - względem gałęzi bazowej, niezatwierdzonych zmian albo wybranego commita - a Codex zgłasza uszeregowane wnioski bez modyfikowania drzewa roboczego. (Codex CLI, Code review) Przegląd to jednak nie dowód poprawności, tylko druga para oczu; decyzja o przyjęciu zmiany zostaje po stronie człowieka.

Gdy druga tura zepsuje coś, co działało, wyjście jest szybkie - ale warto wybrać najwęższe, które załatwia sprawę. Najbezpieczniejsze jest cofnięcie pojedynczych plików:

git restore index.html app.js

Gdy trzeba odłożyć całość na bok, ale bez kasowania, zmiany można schować:

git stash push -m "nieudana druga tura"

Schowek daje się później obejrzeć przez git stash show -p i przywrócić przez git stash pop, więc nic nie ginie bezpowrotnie.

Dopiero na końcu jest wariant hurtowy:

git checkout -- .

Tu potrzebna jest ostrożność: to polecenie kasuje wszystkie niezatwierdzone zmiany w drzewie roboczym, nie tylko te wprowadzone przez agenta. Ręczna poprawka zrobiona obok, w innym pliku i niezacommitowana, zniknie razem z resztą i nie da się jej odzyskać. W świeżym katalogu ćwiczeniowym to bez znaczenia, we własnym repozytorium już nie - i właśnie dlatego nawyk warto wyrobić na węższych poleceniach.

Każdy z tych wariantów działa tylko dlatego, że pierwsza wersja została wcześniej zacommitowana. Bez commita nie ma czego przywrócić - i to jest właśnie powód, dla którego punkty kontrolne robi się przed zadaniem, a nie po awarii. Dokumentacja zaleca zresztą dokładnie takie podejście: praca na gałęzi funkcyjnej, czysty git status przed zleceniem zadania i częste commity, żeby dało się cofać w małych krokach. (Agent approvals & security)

Praca na co dzień: to, co warto znać od razu

Powrót do wcześniejszej rozmowy. codex resume otwiera ostatnią rozmowę z bieżącego repozytorium albo pozwala przeszukać lokalne rozmowy przy powrocie do starszej pracy. (Codex CLI)

Obraz jako kontekst. codex --image przekazuje zrzut błędu, diagram architektury lub referencję projektową razem z pierwszym promptem; obraz można też wkleić do kompozytora w trybie interaktywnym. (Codex CLI)

Tryb nieinteraktywny. codex exec służy do wywołań z powtarzalnych przepływów pracy i potoków CI. (Codex CLI) Dokumentacja uwierzytelniania zaleca w takich zastosowaniach klucz API i przestrzega przed wystawianiem wykonywania Codeksa w środowiskach niezaufanych lub publicznych. (Authentication)

Dłuższe prompty. W kompozytorze Ctrl+G otwiera edytor wskazany zmienną VISUAL, a przy jej braku EDITOR; po zapisaniu i zamknięciu tekst wraca do kompozytora. (CLI customization)

Uzupełnianie w powłoce. codex completion zsh generuje skrypt uzupełnień dla Bash, Z shell, Fish lub PowerShell; dla Z shell ładuje się go wpisem eval "$(codex completion zsh)" w konfiguracji powłoki, a przy komunikacie command not found: compdef trzeba najpierw zainicjować system uzupełnień poleceniem autoload -Uz compinit && compinit. (CLI customization)

Motyw kolorów. /theme otwiera wybór motywu i zapisuje wybór do tui.theme w $CODEX_HOME/config.toml; własne motywy w formacie .tmTheme umieszcza się w $CODEX_HOME/themes. (CLI customization)

Skracanie długiej rozmowy. /compact skraca kontekst bieżącego czatu, a Codex kompaktuje rozmowy również automatycznie. (Best practices) Zalecenie z dokumentacji jest przy tym prostsze niż mogłoby się wydawać: jeden czat na jedną spójną jednostkę pracy, bo jedna rozmowa na cały projekt prowadzi do rozdętego kontekstu i gorszych wyników. (Best practices)

Koszty i limity

Rozliczenie zależy od metody logowania. Przy logowaniu kontem ChatGPT obowiązują limity planu; przy kluczu API - standardowe stawki API. (Authentication)

Liczba wiadomości do wysłania zależy od użytego modelu, wielkości i złożoności zadań oraz tego, czy pracują lokalnie czy w chmurze. Małe skrypty czy rutynowe funkcje zużywają ułamek limitu, a większe projekty, zadania długotrwałe i rozbudowane sesje wymagające utrzymania większego kontekstu zużywają go znacznie więcej na wiadomość. Podobnie wyglądające zadania mogą przy tym zużyć różne ilości limitu, bo wpływ mają wybór modelu, kontekst, rozumowanie, użycie narzędzi, wyszukiwanie i buforowanie - sama długość promptu nie jest wiarygodnym szacunkiem. (Pricing)

Bieżące limity pokazuje pulpit użycia, a w trakcie aktywnej sesji Codex CLI pozostały limit wyświetla polecenie /status. (Pricing) To jedyny wiarygodny sposób sprawdzenia stanu - żadna liczba podana z zewnątrz nie zastąpi odczytu z konta.

Dokumentacja podaje też konkretne sposoby na rozciągnięcie limitu: kontrolowanie wielkości promptów przez precyzyjne instrukcje bez zbędnego kontekstu, ograniczanie materiału źródłowego do plików istotnych dla zadania, dopasowanie objętości wyniku do potrzeby, zmniejszanie pliku AGENTS.md przez zagnieżdżanie go w repozytorium, ograniczanie liczby używanych serwerów MCP (każdy dokłada kontekst do wiadomości) oraz przejście na mniejszy model przy zadaniach rutynowych. (Pricing)

Osobna uwaga o przeglądach kodu: użycie w kategorii Code Review naliczane jest tylko wtedy, gdy Codex uruchamia przeglądy przez GitHuba - przeglądy lokalne lub spoza GitHuba liczą się do ogólnych limitów użycia. (Pricing)

Błędy i sposoby ich rozwiązania

Polecenie codex nie działa zaraz po instalacji. Objawem jest codex: command not found na macOS i Linuksie albo codex: nie jest rozpoznawane jako polecenie wewnętrzne lub zewnętrzne na Windows. Pierwsza rzecz do sprawdzenia jest banalna: instalator dopisuje katalog z binarką do PATH, ale zmiana nie dotyczy okien terminala otwartych wcześniej. Zamknięcie terminala i otwarcie nowego rozwiązuje większość przypadków.

Gdy to nie pomaga, sprawdza się, czy plik w ogóle powstał w udokumentowanym katalogu instalacji - ~/.local/bin na macOS i Linuksie, %LOCALAPPDATA%\Programs\OpenAI\Codex\bin na Windows - i czy ten katalog jest w PATH. (Environment variables) Na macOS i Linuksie odpowiadają na to ls ~/.local/bin/codex oraz echo $PATH, na Windows w PowerShellu dir $env:LOCALAPPDATA\Programs\OpenAI\Codex\bin oraz $env:PATH. Brak katalogu w PATH naprawia się dopisaniem go do profilu powłoki (~/.bashrc, ~/.zshrc) albo do zmiennych środowiskowych użytkownika w Windows; alternatywą jest wskazanie własnej lokalizacji instalacji przez CODEX_INSTALL_DIR i ponowna instalacja. Gdy z kolei brakuje samego pliku, instalacja się nie powiodła i trzeba ją powtórzyć, obserwując komunikaty instalatora.

Osobny przypadek dotyczy instalacji przez npm. Polecenie npm config get prefix pokazuje prefiks aktywnej instalacji npm. Na Windows globalne pliki wykonywalne trafiają bezpośrednio do tego katalogu; na macOS i Linuksie do jego podkatalogu bin. Właśnie właściwy dla systemu katalog musi być w PATH. (Folders - npm) Nie należy kopiować ścieżki z innego komputera: przy kilku instalacjach Node.js lub menedżerze wersji sprawdzenie trzeba wykonać w tym samym terminalu i przy tej samej aktywnej wersji Node.js, z której instalowano Codeksa. Dawne npm bin -g nie jest właściwą instrukcją dla współczesnego npm.

Codex ostrzega przy starcie o braku bwrap albo o niemożności utworzenia przestrzeni nazw użytkownika. To sytuacja opisana wprost w dokumentacji sandboksu na Linuksie i WSL2. Kolejność działań: zainstalować pakiet dystrybucji dostarczający bwrap, a na Ubuntu 24.04 dograć profil bwrap-userns-restrict zgodnie z procedurą z sekcji instalacyjnej. Globalne wyłączenie ograniczenia przez sysctl jest ostatecznością, bo obniża zabezpieczenie całego systemu. (Sandbox)

Polecenie nie działa, bo sandbox Windows nie może odczytać katalogu. Rozwiązaniem sesyjnym jest /sandbox-add-read-dir C:\pelna\sciezka, przy czym ścieżka musi być istniejącym katalogiem bezwzględnym. (Windows sandbox)

Sandbox natywny na Windows nie startuje w środowisku firmowym. Dokumentacja wskazuje na trzy typowe źródła: konfigurację sandboksu, prawa logowania i uprawnienia systemu plików - rzadziej na sam edytor. Zalecana kolejność diagnozy to sprawdzenie trybu sandboksu natywnego, wersji Windows i ewentualnego błędu zasad wyświetlanego przez Codeksa. Wariant zapasowy to tryb unelevated, a przy jego niepowodzeniu WSL2. (Windows sandbox)

Codex w WSL nie widzi ustawień z instalacji na Windows. To zachowanie oczekiwane: CLI w WSL używa domyślnie linuksowego katalogu domowego i nie dzieli konfiguracji, zapisanego logowania ani historii z aplikacją Windows. Rozwiązania to synchronizacja katalogów albo ustawienie CODEX_HOME na katalog Windows. (ChatGPT desktop app for Windows)

Skrypty PowerShella nie chcą się uruchomić. Objawem bywa komunikat w rodzaju npm.ps1 cannot be loaded because running scripts is disabled on this system. Typowa poprawka to ustawienie zasady wykonywania na RemoteSigned poleceniem Set-ExecutionPolicy -ExecutionPolicy RemoteSigned, przy czym dokumentacja odsyła przed zmianą do przewodnika Microsoftu po zasadach wykonywania. (ChatGPT desktop app for Windows)

Instrukcje z AGENTS.md nie działają albo działają nie te. Dokumentacja wymienia kilka przyczyn i sprawdzeń: przy braku wczytania - potwierdzenie, że katalog jest tym właściwym i że pliki nie są puste, bo puste są ignorowane; przy złych wskazówkach - poszukanie pliku AGENTS.override.md wyżej w drzewie katalogów albo w katalogu domowym Codeksa; przy ignorowanych nazwach zapasowych - sprawdzenie wpisów w project_doc_fallback_filenames i ponowne uruchomienie programu; przy obciętych instrukcjach - podniesienie project_doc_max_bytes albo rozbicie dużego pliku na katalogi zagnieżdżone; przy podejrzeniu złego profilu - sprawdzenie echo $CODEX_HOME przed uruchomieniem. (Custom instructions with AGENTS.md)

Nie wiadomo, skąd wzięły się aktualne ustawienia uprawnień. Punktem wyjścia jest /status pokazujący konfigurację sesji oraz /permissions do obejrzenia i zmiany granic. (Codex CLI, Agent approvals & security) Przy podejrzeniu, że coś nadpisuje ustawienia, pomaga przypomnienie kolejności warstw konfiguracji z sekcji o konfiguracji.

Zadanie zatrzymało się z powiadomieniem o monitoringu bezpieczeństwa. Model GPT-6 Astra ma w Codeksie i ChatGPT Work monitoring bezpieczeństwa, który działa asynchronicznie i może wstrzymać zadanie po wykryciu potencjalnie niebezpiecznego zachowania modelu; wstrzymanie może pojawić się już po czynności, która je wywołała. W Codex CLI pełne wnioski i wznowienie nie są dostępne - zadanie się kończy. Monitoring nie zastępuje sandboksu, uprawnień ani przeglądu wyniku. (Agent approvals & security)

Sprzątanie i cofnięcie zmian

Zmiany w kodzie cofa się narzędziami Git, dlatego punkty kontrolne przed zadaniem i po nim mają praktyczne znaczenie. (Codex CLI)

Dane lokalne Codeksa leżą pod CODEX_HOME, domyślnie ~/.codex: konfiguracja config.toml, auth.json przy przechowywaniu plikowym, history.jsonl przy włączonej trwałej historii oraz logi i pamięci podręczne. (Advanced Configuration) Usunięcie tego katalogu kasuje konfigurację, zapisane logowanie i historię sesji - jeżeli celem jest tylko wylogowanie, wystarczy wyczyścić poświadczenia w interfejsie: menu profilu pokazuje aktywne konto albo status klucza API, a opcja Log out czyści bieżące dane logowania. (Authentication)

Ograniczenie zapisywania transkryptów sesji pod CODEX_HOME daje przegląd ustawień retencji history.persistence i history.max_bytes. (Agent approvals & security)

Samą binarkę usuwa się zgodnie z drogą instalacji: przy instalacji przez npm poleceniem npm uninstall -g @openai/codex, przy instalacji przez Homebrew poleceniem brew uninstall --cask codex.

Dla instalatora samodzielnego dokumentacja nie podaje osobnej procedury deinstalacji i tego braku nie da się obejść cytatem. Podaje natomiast, gdzie leżą pliki: widoczne polecenie codex w ~/.local/bin na macOS i Linuksie albo w %LOCALAPPDATA%\Programs\OpenAI\Codex\bin na Windows (lub w katalogu wskazanym przez CODEX_INSTALL_DIR), a pamięć podręczna pakietu standalone pod CODEX_HOME/packages/standalone, domyślnie ~/.codex/packages/standalone. (Environment variables) Usunięcie tych elementów jest więc wnioskiem z udokumentowanych lokalizacji, a nie procedurą opisaną przez producenta - warto przed nim sprawdzić bieżącą dokumentację i upewnić się, że kasuje się właśnie te ścieżki, na przykład przez which codex albo where.exe codex.

Kilka zasad, które oszczędzają czasu

Dokumentacja producenta wymienia typowe błędy początkujących i większość z nich da się zamienić na proste reguły. Nie pakować trwałych reguł do promptu, skoro ich miejscem jest AGENTS.md albo umiejętność. Nie pomijać planowania przy zadaniach wieloetapowych i złożonych - do tego służy tryb planu, przełączany przez /plan lub Shift+Tab. Nie dawać Codeksowi pełnych uprawnień do komputera, zanim przepływ pracy będzie zrozumiały. Nie uruchamiać równoległych zadań na tych samych plikach bez drzew roboczych Git. Nie planować zadania cyklicznego, zanim zacznie działać powtarzalnie ręcznie. (Best practices)

Ostatnia rzecz dotyczy nastawienia, a nie konfiguracji. Codex nie generuje samego kodu - przy odpowiednich instrukcjach może go też przetestować, sprawdzić i przejrzeć, ale tylko jeśli wie, jak wygląda „dobrze”. Ta wiedza pochodzi albo z promptu, albo z AGENTS.md. (Best practices) Bez niej agent zwróci coś, co wygląda na zrobione, a weryfikacja i tak spadnie na człowieka.