Konfiguracja

Uwierzytelniłeś się, uruchomiłeś Codex, a on natychmiast spróbował uruchomić rm -rf node_modules bez pytania. Albo gorzej, pytał o pozwolenie na każde polecenie ls zanim zrobił cokolwiek użytecznego. Różnica między tymi doświadczeniami to jeden plik: config.toml. Skonfiguruj go dobrze, a Codex będzie działał jak zaufany starszy kolega. Skonfiguruj źle, a będzie albo nieodpowiedzialny, albo sparaliżowany.

Co wyniesiesz z tego przewodnika

Plik ~/.codex/config.toml skonfigurowany z twoim preferowanym modelem, polityką zatwierdzania i poziomem sandbox
Nadpisania na poziomie projektu w .codex/config.toml dla ustawień zespołowych
Jasne zrozumienie kolejności priorytetów konfiguracji
Flagi funkcji włączone dla potrzebnych możliwości
Tryb wyszukiwania w sieci dostrojony do twoich wymagań bezpieczeństwa

Plik konfiguracji

Codex odczytuje konfigurację z plików TOML. Twoje osobiste ustawienia domyślne znajdują się w ~/.codex/config.toml, a nadpisania specyficzne dla projektu w .codex/config.toml w katalogu głównym repozytorium.

Aplikacja desktopowa ChatGPT, CLI i rozszerzenie dla rodziny VS Code współdzielą te same lokalne warstwy konfiguracji, gdy używają tego samego CODEX_HOME. Codex Cloud ma osobną konfigurację środowiska i workspace’u; lokalny config.toml nie synchronizuje się automatycznie z zadaniami w chmurze.

Kolejność priorytetów konfiguracji

Codex rozwiązuje ustawienia w następującej kolejności, od najwyższego do najniższego priorytetu:

Flagi CLI i nadpisania --config — na przykład codex -a on-request ma priorytet nad ustawieniami z plików.
Konfiguracja projektu — Pliki .codex/config.toml, uporządkowane od katalogu głównego projektu w dół do bieżącego katalogu roboczego. Najbliższy katalog wygrywa. Ładowane tylko dla zaufanych projektów.
Plik profilu — $CODEX_HOME/<nazwa>.config.toml, wybrany przez --profile <nazwa>.
Konfiguracja użytkownika — ~/.codex/config.toml.
Konfiguracja systemowa — /etc/codex/config.toml na Unix (jeśli istnieje).
Wbudowane domyślne — Fabryczne ustawienia Codex.

Oznacza to, że .codex/config.toml z zaufanego repozytorium nadpisuje profil i ustawienia użytkownika. Do jednorazowego nadpisania użyj flagi CLI albo -c klucz=wartość; administrator może ograniczyć dozwolone wartości przez zarządzany requirements.toml.

Podstawowe ustawienia

Oto produkcyjny ~/.codex/config.toml z ustawieniami, które większość deweloperów zmienia najpierw.

Dostępność modeli w Codex zależy od planu i workspace’u: Free i Go udostępniają GPT-5.6 Terra, a kwalifikujące się konta Plus, Pro, Business i Enterprise mogą wybrać Sol, Terra lub Luna. Administrator zarządzanego workspace’u może ograniczyć modele zależnie od roli. Jawne ustawienie Terra poniżej jest przenośnym, zbalansowanym wyborem — nie oznacza, że każda powierzchnia produktu Codex ma ten sam model domyślny.

Karty modeli API podają okno kontekstowe 1 050 000 tokenów i maksymalnie 128 000 tokenów wyjściowych dla Sol, Terra i Luna. To limity API, a nie obietnica, że każda powierzchnia Codex udostępnia całe okno pojedynczemu wątkowi.

GPT-5.6 dodaje też max w ustawieniach Codex dla każdego użytkownika z dostępem do modelu, a ultra jest dostępne w Codex od planu Plus wzwyż. To kontrolki produktu: bieżąca dokumentacja config.toml nadal podaje dla model_reasoning_effort wartości tylko do xhigh, dlatego nie wpisuj max ani ultra w tym kluczu, chyba że schemat twojej zainstalowanej wersji jawnie je akceptuje.

# Wybór modelu -- dobierz poziom GPT-5.6 do zadania.
# Sol: jakość frontier; Terra: zrównoważony; Luna: wydajność masowa.
model = "gpt-5.6-terra"

# Polityka zatwierdzania -- kontroluje pytania o przekroczenie granicy uprawnień
# Używaj "on-request" interaktywnie. "never" zarezerwuj dla jawnie zaufanych
# zadań bezobsługowych; nie osłabia ono sandboxa.
approval_policy = "on-request"

# Tryb sandbox -- kontroluje dostęp do systemu plików i sieci
# Opcje: "read-only", "workspace-write" (domyślny), "danger-full-access"
sandbox_mode = "workspace-write"

# Tryb wyszukiwania w sieci
# Opcje: "cached" (domyślny, zaindeksowane wyniki), "live" (w czasie rzeczywistym),
#          "disabled" (bez wyszukiwania)
web_search = "cached"

# Nakład myślenia -- ile model myśli przed odpowiedzią
# Opcje: "minimal", "low", "medium", "high", "xhigh" (xhigh zależy od modelu)
model_reasoning_effort = "high"

# Przechowywanie poświadczeń
cli_auth_credentials_store = "auto"

Tryby zatwierdzania w szczegółach

Polityka zatwierdzania i tryb sandbox to osobne osie: sandbox określa, do czego polecenie ma techniczny dostęp, a polityka zatwierdzania — czy Codex może poprosić o przekroczenie tej granicy. Zmiana jednej osi nie zmienia automatycznie drugiej.

on-request (interaktywny)
never (bezobsługowy)

Codex działa autonomicznie wewnątrz aktywnego sandboxa i pyta, gdy musi przekroczyć jego granicę, na przykład zapisać plik poza workspace’em albo użyć zablokowanej sieci. Nie pyta przed każdą rutynową edycją czy komendą mieszczącą się w sandboxie.

approval_policy = "on-request"

Używaj gdy: Pracujesz w nieznanych bazach kodu, uruchamiasz Codex po raz pierwszy lub pracujesz w środowiskach produkcyjnych.

Codex nigdy nie otwiera monitu o zatwierdzenie. Wykonuje możliwe działania w skonfigurowanym sandboxie, a operacja poza jego granicą kończy się błędem zamiast zatwierdzeniem. Używaj tego tylko w jawnie zaufanej automatyzacji, najlepiej z workspace-write lub bardziej restrykcyjnym sandboxem.

approval_policy = "never"

Używaj gdy: Przejrzany job CI lub izolowany runner nie może czekać na człowieka. Nie łącz z danger-full-access, chyba że sam runner zapewnia równoważną izolację.

Prompt do testu trybu zatwierdzania:

Przy on-request i workspace-write spróbuj tego w interaktywnym CLI:

codex "Create a file called test-approval.txt with the text 'hello' and then run cat test-approval.txt"

Codex powinien utworzyć i odczytać plik wewnątrz workspace’u bez monitu. Prośba o zapis poza workspace’em powinna wywołać zatwierdzenie. To sprawdza obie osie.

Nadpisania na poziomie projektu

Dla ustawień zespołowych utwórz .codex/config.toml w katalogu głównym repozytorium:

# .codex/config.toml -- commitowany do repozytorium

# Standardowa polityka zatwierdzania zespołu
approval_policy = "on-request"

# Sandbox ograniczony do workspace
sandbox_mode = "workspace-write"

# Zespół preferuje wysoki nakład myślenia dla tej złożonej bazy kodu
model_reasoning_effort = "high"

Gdy deweloper sklonuje repozytorium i zaufa projektowi, te ustawienia zastosują się automatycznie. Konfiguracja projektu ma pierwszeństwo przed profilem i konfiguracją osobistą; wyżej są tylko flagi CLI i -c.

Flagi funkcji

Opcjonalne możliwości znajdują się w tabeli [features]:

[features]
# Przyspiesz powtarzane polecenia przez zrzut środowiska shell
shell_snapshot = true

# Trwałe cele i automatyczna kontynuacja są stabilne i domyślnie włączone.
goals = true

Kluczowe flagi funkcji:

Flaga	Domyślna	Co robi
`shell_snapshot`	true	Stabilna; zapisuje stan powłoki dla szybszych powtarzanych poleceń
`unified_exec`	true poza Windows	Stabilne wykonywanie przez PTY; na Windows domyślnie wyłączone
`goals`	true	Stabilne trwałe cele i automatyczna kontynuacja

Włącz z CLI bez edycji konfiguracji:

codex features list

Styl komunikacji

Codex obsługuje eksperymentalne ustawienie stylu komunikacji:

# Opcje: "friendly", "pragmatic", "none"
model_personality = "pragmatic"

Możesz też zmienić to per-sesję przez /personality w TUI.

Przekazywanie zmiennych środowiskowych

Kontroluj które zmienne środowiskowe Codex przekazuje do uruchamianych poleceń:

[shell_environment_policy]
include_only = ["PATH", "HOME", "NODE_ENV", "DATABASE_URL"]

To kluczowe dla bezpieczeństwa. Bez tej polityki Codex przekazuje całe twoje środowisko shell do każdego uruchamianego polecenia, co może doprowadzić do wycieku tajemnic.

Prompt do inspekcji bieżącej konfiguracji:

Uruchom to w CLI aby zobaczyć obowiązujące ustawienia:

codex "What are my current configuration settings? List model, approval policy, sandbox mode, and web search mode."

Szybkie nadpisania CLI

Nie zawsze musisz edytować config.toml. CLI akceptuje jednorazowe nadpisania:

# Nadpisz model dla tej sesji
codex -c model=gpt-5.6-sol

# Nadpisz politykę zatwierdzania dla sesji interaktywnej
codex -a on-request

# Sprawdź bieżący stan funkcji
codex features list

# Połącz wiele nadpisań
codex -c model=gpt-5.6-sol -c model_reasoning_effort=low

Gdy coś nie działa

Ostrzeżenie “Niezaufany projekt” i konfiguracja projektu ignorowana: Codex pyta o zaufanie do projektu przy pierwszym otwarciu. Jeśli odmówiłeś, pliki .codex/config.toml na poziomie projektu są pomijane. Uruchom ponownie Codex w projekcie i zaakceptuj pytanie o zaufanie.

Tryb zatwierdzania wydaje się być zły: Sprawdź kolejność priorytetów. Flaga CLI nadpisuje wszystko. Uruchom codex bez flag aby przetestować ustawienia pliku konfiguracji w izolacji.

Flaga funkcji nie działa: Niektóre flagi wymagają ponownego uruchomienia Codex. Zamknij Aplikację, zakończ CLI i otwórz ponownie. Flagi funkcji są odczytywane przy starcie, nie ładowane na żywo.

Błąd “sandbox_mode not allowed”: Twoja organizacja może wymuszać ograniczenia przez requirements.toml. Skontaktuj się z administratorem jeśli zarządzane polityki blokują preferowany tryb sandbox.

Żądany model GPT-5.6 jest niedostępny: Sprawdź plan i rolę w workspace przed zmianą identyfikatora modelu. Free i Go korzystają z Terra, a kwalifikujący się użytkownicy Plus, Pro, Business i Enterprise mogą wybrać wszystkie trzy poziomy, o ile polityka administratora nie zawęża dostępu.

Brakujące zmienne środowiskowe w poleceniach: Jeśli Codex uruchamia npm test i nie powiedzie się bo brakuje DATABASE_URL, sprawdź swoje [shell_environment_policy]. Albo dodaj zmienną do include_only, albo usuń politykę aby przekazywać wszystko.

Co dalej

Skonfiguruj AGENTS.md Daj Codex realny kontekst o konwencjach i oczekiwaniach twojego projektu