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.

Zarówno CLI jak i rozszerzenie IDE współdzielą te same warstwy konfiguracji. Aplikacja też je czyta. Skonfiguruj raz, używaj wszędzie.

Wskazówka

Prompt do otwarcia pliku konfiguracji z IDE:

W rozszerzeniu Codex IDE kliknij ikonę zębatki w prawym górnym rogu, a następnie wybierz Codex Settings > Open config.toml. Otworzy to bezpośrednio twój plik konfiguracji na poziomie użytkownika.

Kolejność priorytetów konfiguracji

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

1. Flagi CLI i nadpisania --config — codex -a never ma priorytet nad wszystkim.

2. Wartości profilu — Z --profile <name> jeśli używasz nazwanych profili.

3. 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.

4. Konfiguracja użytkownika — ~/.codex/config.toml.

5. Konfiguracja systemowa — /etc/codex/config.toml na Unix (jeśli istnieje).

6. Wbudowane domyślne — Fabryczne ustawienia Codex.

Oznacza to, że twój zespół może commitować plik .codex/config.toml do repozytorium z polityką zatwierdzania specyficzną dla projektu, a poszczególni deweloperzy mogą nadpisać te ustawienia własnymi preferencjami w ~/.codex/config.toml.

Uwaga

Jeśli oznaczysz projekt jako niezaufany, Codex pomija wszystkie warstwy .codex/ (włącznie z konfiguracją projektu) i korzysta z ustawień użytkownika, systemowych i wbudowanych domyślnych. To funkcja bezpieczeństwa — niezaufane repozytoria nie mogą zmieniać twoich ustawień sandbox.

Podstawowe ustawienia

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

~/.codex/config.toml

# Wybór modelu -- GPT-5.3-Codex jest domyślny i najlepszy do zadań programistycznych
model = "gpt-5.3-codex"

# Polityka zatwierdzania -- kontroluje kiedy Codex pauzuje aby zapytać przed uruchomieniem poleceń
# Opcje: "on-request" (pytaj o wszystko), "on-failure" (auto-zatwierdzaj,
#          pytaj przy błędach), "never" (pełna autonomia -- tryb "yolo")
approval_policy = "on-failure"

# Tryb sandbox -- kontroluje dostęp do systemu plików i sieci
# Opcje: "workspace-write" (domyślny, ograniczony do projektu), "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: "low", "medium", "high"
model_reasoning_effort = "high"

# Przechowywanie poświadczeń
cli_auth_credentials_store = "auto"

Tryby zatwierdzania w szczegółach

Polityka zatwierdzania to najważniejsze ustawienie. Oto co faktycznie robi każdy tryb.

on-request (domyślny)

Codex pauzuje i prosi o pozwolenie przed każdą edycją pliku i wykonaniem polecenia. To najbezpieczniejszy tryb, ale tworzy najwięcej tarcia.

approval_policy = "on-request"

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

on-failure (zalecany)

Codex auto-zatwierdza akcje, ale pauzuje i pyta gdy coś się nie powiedzie. To idealny punkt równowagi dla większości prac programistycznych — Codex płynie gładko na szczęśliwych ścieżkach, ale konsultuje się z tobą gdy pojawiają się błędy.

approval_policy = "on-failure"

Używaj gdy: Codzienna praca programistyczna w zaufanych projektach.

never (pełna automatyzacja)

Codex uruchamia wszystko bez pytania. Edycje plików, polecenia shell, operacje Git — wszystko autonomicznie. To najszybszy tryb, ale wymaga dużego zaufania. Możesz też użyć flagi CLI --full-auto dla tego samego efektu z sandboxingiem.

approval_policy = "never"

Używaj gdy: Praca w skonteneryzowanych środowiskach, jednorazowych branchach, pipeline-ach CI/CD lub gdy chcesz niezakłóconego flow i możesz łatwo cofnąć zmiany.

Wskazówka

Prompt do testu trybu zatwierdzania:

W trybie on-failure spróbuj tego w CLI:

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

Codex powinien utworzyć plik automatycznie (bez pytania), ale poprosić o pozwolenie przed uruchomieniem cat. Jeśli tak się stanie, twój tryb zatwierdzania działa prawidłowo.

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-failure"

# 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. Jego osobisty ~/.codex/config.toml nadal ma priorytet dla ustawień, które jawnie nadpisze.

Flagi funkcji

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

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

# Włącz cofanie przez zrzuty git ghost per-tura (włączone domyślnie)
undo = true

# Włącz inteligentne zatwierdzanie sugerujące reguły prefiksów
request_rule = true

Kluczowe flagi funkcji:

Flaga	Domyślna	Co robi
shell_snapshot	false	Cache-uje środowisko shell dla szybszych powtarzanych poleceń
undo	true	Tworzy zrzuty Git per-tura dla możliwości cofnięcia zmian
request_rule	true	Inteligentne zatwierdzanie sugeruje reguły uprawnień do ponownego użycia
unified_exec	false	Używa zunifikowanego narzędzia exec opartego o PTY (beta)
remote_compaction	true	Kompresuje kontekst zdalnie (tylko uwierzytelnianie ChatGPT)

Włącz z CLI bez edycji konfiguracji:

codex --enable shell_snapshot

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.

Wskazówka

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.2

# Nadpisz politykę zatwierdzania
codex -a never

# Włącz flagę funkcji
codex --enable shell_snapshot

# Połącz wiele nadpisań
codex -c model=gpt-5.2 -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.

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