Konfiguracja Codex w config.toml: model, uprawnienia i profile

Konfiguracja Codex mieszka w plikach config.toml, które nakładają się w stałej kolejności: wbudowane wartości domyślne, konfiguracja systemowa, plik użytkownika ~/.codex/config.toml, opcjonalny plik --profile, .codex/config.toml zaufanego repozytorium i na końcu nadpisania z wiersza poleceń. Literówkę w kluczu Codex pomija, zgłaszając jedynie ostrzeżenie przy starcie.

Ten przewodnik jest dla programistów, którzy konfigurują Codex dla siebie, i dla tech leadów, którzy piszą konfigurację projektu commitowaną dla całego zespołu. Sytuacja, której zapobiega, jest znajoma: ustawiasz web_search = "live", a wyniki wyszukiwania nadal pochodzą z cache’u, bo Codex pominął literówkę, zgłaszając tylko ostrzeżenie, którego nie zauważyłeś. Albo test przechodzi u kolegi, a u ciebie nie, bo konfiguracja repozytorium, której nigdy nie czytałeś, nadpisała twój sandbox.

Co daje świadomie napisany config.toml

• Plik użytkownika ~/.codex/config.toml, którego każdą linię umiesz wyjaśnić, walidowany w edytorze względem schematu samego Codex
• Commitowany .codex/config.toml, który daje całemu zespołowi te same uprawnienia i to samo filtrowanie sekretów
• Profile do review, szybkiej iteracji, uruchomień bez nadzoru i modeli lokalnych, przełączane jedną flagą
• Cztery kontrole (codex doctor, /status, /debug-config, codex sandbox), które pokazują, co faktycznie działa, zamiast ufać plikowi
• Trzy prompty do skopiowania, które audytują konfigurację, wyjaśniają, czemu ustawienie nie zadziałało, i szkicują konfigurację zespołu

Każdy klucz i każde polecenie na tej stronie sprawdziliśmy 2026-09-26 na codex-cli 0.157.1, łącznie z uruchomieniem codex exec --strict-config dla każdego przykładowego pliku (konfiguracji startowej, konfiguracji projektu i czterech profili). Klucze konfiguracji z tych plików sprawdziliśmy ponownie ze schematem konfiguracji 0.162.1 dnia 2026-10-12 i każdy nadal się w nim znajduje; każde zachowanie pozostaje opatrzone stemplem 0.157.1, o ile jego sekcja nie mówi inaczej. Stwierdzenia o modelu, effort i szybkości, które podają GPT-6.1 Sol, codex-cli 0.159.1 lub nowszy albo datę 2026-10-12, pochodzą z katalogu modeli 0.162.1 i ze stron OpenAI odczytanych 2026-10-12. Najpierw zainstaluj Codex i zaloguj się: zobacz instalację Codex i uwierzytelnianie w Codex.

Skąd Codex czyta konfigurację?

Codex składa jedną efektywną konfigurację z kilku warstw. Późniejsza warstwa nadpisuje wcześniejszą, klucz po kluczu:

Kolejność	Warstwa	Ścieżka	Uwagi
1	Wbudowane wartości domyślne	Wewnątrz Codex	To, co dostajesz bez żadnego pliku
2	Systemowa	/etc/codex/config.toml (Unix), %ProgramData%\OpenAI\Codex\config.toml (Windows)	Wartości domyślne dla całej maszyny
3	Konfiguracja zarządzana	Zarządzane preferencje macOS, fragmenty firmowej konfiguracji w chmurze	Ustawiają ją administratorzy; nadpisuje wartości systemowe
4	Użytkownika	$CODEX_HOME/config.toml (CODEX_HOME domyślnie wskazuje ~/.codex)	Twoje osobiste ustawienia
5	Profil	$CODEX_HOME/<name>.config.toml	Tylko gdy podasz --profile <name>
6	Projekt	.codex/config.toml od katalogu głównego repozytorium w dół do katalogu roboczego	Ignorowana, dopóki projekt nie jest zaufany
7	Sesja	-c key=value, -m, -a, -s, --enable, --search, wybór modelu w UI	Tylko to uruchomienie

Kolejność pochodzi z loadera konfiguracji w kodzie Codex (codex-rs/config/src/loader, sprawdzone 2026-09-26). Dwie konsekwencje zaskakują ludzi:

• Konfiguracja projektu wygrywa z twoim profilem. Jeśli repozytorium ustawia model_reasoning_effort = "medium", to codex --profile review z high nadal działa na medium. Na jedno uruchomienie nadpiszesz to przez -c model_reasoning_effort="high".
• Administratorzy mogą też ograniczać wartości. Zarządzane pliki requirements.toml (/etc/codex/requirements.toml albo firmowy pakiet konfiguracji w chmurze) nie ustawiają wartości, tylko ograniczają, które wartości może wybrać dowolna warstwa. Gdy Codex odrzuca wartość, którą ustawiłeś, ograniczenie jest tam, a nie w twoim pliku. Wdrażanie polityk opisuje zarządzanie Codex w firmie.

CLI, aplikacja desktopowa i rozszerzenie IDE czytają ten sam CODEX_HOME. Zadania Codex w chmurze nie czytają plików lokalnych; środowiska chmurowe Codex konfigurujesz osobno.

Niezaufany projekt nie zmieni twoich ustawień

Przy pierwszym otwarciu repozytorium Codex pyta, czy mu ufasz. .codex/config.toml niezaufanego projektu Codex wczytuje, ale wyłącza, a od codex-cli 0.150.0 niezaufany projekt nie dostarcza też instrukcji z AGENTS.md. To celowe: sklonowane repozytorium nie może poszerzyć twojego sandboksa. Zaufanie zapisuje się w konfiguracji użytkownika jako [projects."/abs/path"] z trust_level = "trusted".

Napisz startowy config.toml

Poniższy plik to kompletna konfiguracja użytkownika. Każda sekcja po krokach wyjaśnia jedną zawartą w nim decyzję.

1. Utwórz ~/.codex/config.toml (albo otwórz istniejący) i wklej:

   #:schema https://raw.githubusercontent.com/openai/codex/rust-v0.157.1/codex-rs/core/config.schema.json
   
   # Model: leave `model` unset to follow Codex's bundled default (GPT-6.1 Sol).
   # Tune effort first; switch model only when your own results say so.
   model_reasoning_effort = "medium"
   
   # Permissions: the built-in workspace profile writes only the workspace
   # and grants no network. Do not also set sandbox_mode.
   default_permissions = ":workspace"
   approval_policy = "on-request"
   
   # Web search: "cached" is the default; "live" fetches in real time.
   web_search = "cached"
   
   # Clickable file citations in your editor.
   file_opener = "vscode"
   
   # Keep variables named like keys, secrets and tokens out of commands.
   [shell_environment_policy]
   ignore_default_excludes = false
   
   [tui]
   notifications = ["agent-turn-complete", "approval-requested"]

2. Zainstaluj rozszerzenie edytora, które rozumie dyrektywę #:schema (Even Better TOML w VS Code lub Cursorze). Nieznane klucze dostają czerwone podkreślenie już w trakcie pisania. Przypnij URL schematu do tagu wersji Codex, której używasz, bo klucze pojawiają się i znikają między wydaniami.

3. Zwaliduj plik zainstalowanym binarnym Codex. --strict-config zamienia nieznany klucz z ostrzeżenia w błąd:

   codex exec --strict-config --ephemeral "Reply with OK."

   Uruchom je wewnątrz zaufanego repozytorium (albo dodaj --skip-git-repo-check); wykonuje jedno krótkie wywołanie modelu.

   Literówka zatrzymuje uruchomienie i podaje plik, linię i klucz: config.toml:14:1: unknown configuration field, a po nim nazwę klucza.

4. Uruchom codex doctor i przeczytaj blok Configuration (model, pliki konfiguracji, ostrzeżenia startowe z każdym zignorowanym kluczem) oraz wiersz sandbox pod nim (polityka zatwierdzania, ograniczenia systemu plików i sieci).

Wybierz model i reasoning effort

GPT-6.1 Sol jest domyślnym modelem dołączonym do Codex od codex-cli 0.159.1 (2026-09-29), a jego domyślny effort w Codex to low; Codex opisuje go jako „Latest workhorse model for coding and everyday work”. Pod nim w pickerze są GPT-6 Astra („Frontier intelligence for the most demanding work”), GPT-6 Sol („Previous generation workhorse model”) i GPT-6 Luna („Fast and affordable model for easier tasks”). Starsze modele GPT-5.6 nadal można wybrać. Strona OpenAI o modelach (sprawdzona 2026-10-12) zaleca GPT-6.1 Sol do złożonego kodowania i przepływów agentowych, a GPT-6 Luna do wąskich, powtarzalnych zadań, i każe wybierać Astrę, „when a task needs the strongest capability across steps and tools”, więc traktuj Astrę jako model wybierany ręcznie do najtrudniejszej pracy. Ceny, okna kontekstu i to, kiedy wybrać który model, są w hubie modeli; ta strona ich nie powtarza.

GPT-5.5, który katalog 0.162.1 opisuje jako „Legacy coding model.”, znika z ChatGPT, ChatGPT Work i Codex 2026-10-14, we wszystkich planach (strona OpenAI o modelach, sprawdzona 2026-10-12); API OpenAI nie jest tym objęte. Katalog 0.162.1 nadal nie podaje dla niego daty wycofania, więc datę egzekwuje serwer: przenieś wcześniej każde przypięcie model = "gpt-5.5".

Zasada, której trzyma się cały serwis: zacznij od modelu domyślnego, najpierw dostrój effort, a model zmieniaj dopiero wtedy, gdy twoje własne wyniki za tym przemawiają. W praktyce:

• Nie ustawiaj model w pliku użytkownika, żeby nowy domyślny model trafił do ciebie z aktualizacją. model = "gpt-6-luna" przypinaj tylko w profilu, który istnieje z powodów kosztowych.
• Do codziennej pracy ustaw model_reasoning_effort na medium lub high. GPT-6.1 Sol i Astra przyjmują poziomy od low do max oraz codeksowe ultra („Maximum reasoning with automatic task delegation”); Luna nie ma ultra. Na żywo zmienisz to przez /model.
• Prędkość to osobne ustawienie niż model i effort. Poziomy Fast i Ultrafast wymieniają limit na prędkość, a Ultrafast wymaga w Codex planu Pro za 500 USD albo kwalifikującego się planu Enterprise lub Edu; jak współdziałają service_tier, fast_mode i /fast, opisuje strona kredyty, limity użycia i optymalizacja kosztów Codeksa.
• Dla modeli GPT-6 Codex domyślnie otwiera okno 272K tokenów. Gdy zadanie tego wymaga, podniesiesz je kluczem model_context_window do sufitu katalogu, czyli 872K. Najpierw przeczytaj wzorce pracy z kontekstem w Codex, bo większe okno kosztuje więcej w każdej turze.

Wybierz uprawnienia: profile uprawnień albo starszy sandbox

O tym, co Codex może zrobić, decydują dwa niezależne ustawienia. Uprawnienia określają, czego polecenie może technicznie dotknąć. Polityka zatwierdzania określa, czy Codex może poprosić cię o przekroczenie tej granicy.

Do uprawnień OpenAI zaleca teraz profile uprawnień (beta, codex-cli 0.138.0 i nowsze): default_permissions = ":workspace" pozwala pisać w workspace i nie daje dostępu do sieci, a ":read-only" nie pozwala pisać nigdzie. Starszy klucz sandbox_mode (read-only, workspace-write, danger-full-access) nadal działa. W jednym pliku wybierz jeden system: OpenAI pisze, że „the profile and legacy sandbox systems do not compose”, więc nigdy nie ustawiaj razem default_permissions i sandbox_mode.

approval_policy	Zachowanie	Kiedy
on-request (domyślna)	Działa w granicach uprawnień; pyta przed ich przekroczeniem	Praca interaktywna
untrusted	Usunięta: codex-cli 0.157.1 odmawia startu z tą wartością („no longer supported; remove this setting”, sprawdzone 2026-09-26)	Do niczego; użyj on-request albo granular
granular	Tabela przełączników dla kategorii (polecenia powłoki, reguły, skrypty skilli, prompty MCP); kategoria ustawiona na false jest odrzucana zamiast pytania	Zespoły, które potrzebują drobniejszej kontroli
never	Nigdy nie pyta; akcja poza uprawnieniami kończy się błędem, który trafia do modelu	Uruchomienia bez nadzoru w profilu, nigdy jako twoje ustawienie domyślne

W wierszu poleceń -a przyjmuje w 0.157.1 tylko on-request i never, i dotyczy interaktywnego codex. codex exec odrzuca -a i go nie potrzebuje: działa z zatwierdzaniem never (on-request przy --approve-for-me), a prefiks codex -a … exec tego nie zmienia. Ustawienie approvals_reviewer = "auto_review" sprawia, że o eskalacjach decyduje model recenzujący zamiast ciebie; --approve-for-me robi to samo dla jednego uruchomienia, ale przy okazji przełącza na starszy sandbox workspace-write, więc nie łącz go z default_permissions. Porównanie tych trybów między narzędziami i klasę ryzyka, do której pasuje każdy z nich, znajdziesz w przewodniku uprawnienia i sandboksy.

Wybierz tryb wyszukiwania w sieci

web_search przyjmuje cached (domyślnie), live, indexed i disabled. cached odpowiada z wcześniej pobranych wyników i w większości prac jest bezpieczniejszym wyborem. live ustaw w profilu albo uruchom sesję z codex --search, gdy potrzebujesz wydania sprzed kilku dni. W profilach bez nadzoru ustaw disabled: pobrana strona to niezaufane wejście, którego nikt nie czyta.

Nie wpuszczaj sekretów do poleceń, które uruchamia Codex

Domyślnie każde polecenie uruchomione przez Codex dziedziczy całe środowisko twojej powłoki, łącznie z poświadczeniami do chmury. Steruje tym [shell_environment_policy]:

[shell_environment_policy]
inherit = "all"                  # "all" (default), "core" (HOME, PATH, SHELL, USER…), or "none"
ignore_default_excludes = false  # default true: set false to drop *KEY*, *SECRET*, *TOKEN* names
exclude = ["AWS_*", "AZURE_*"]   # extra patterns to drop
set = { NODE_ENV = "test" }      # injected into every command

Efekt da się zaobserwować. Z ignore_default_excludes = false w 0.157.1 ten test kanarkowy wypisał MY_VAR=1 i nic więcej; z wartością domyślną wypisał też FAKE_API_KEY=abc:

FAKE_API_KEY=abc MY_VAR=1 codex sandbox -- sh -c 'env | grep -E "FAKE_API_KEY|MY_VAR"'

exclude i include_only to starsza forma tablicowa; forma kanoniczna to tabela [shell_environment_policy.filters] z wpisem "AWS_*" = "exclude". Nie mieszaj obu form w jednym pliku.

Przygotuj powłokę, zanim uruchomisz Codex

Skoro Codex dziedziczy powłokę, uruchamiaj go z przygotowanej. Najpierw aktywuj środowisko wirtualne, uruchom usługi potrzebne testom i wyeksportuj zmienne, które nie są sekretami. Inaczej Codex spędzi kilka tur na odkrywaniu, że brakuje pytest albo że Postgres nie działa:

source .venv/bin/activate
docker compose up -d postgres redis
export DATABASE_URL="postgresql://localhost:5432/myapp_test"
codex

Zmienna potrzebna testom, której nazwa pasuje do *KEY*, *SECRET* lub *TOKEN*, jest teraz odfiltrowywana. Przekaż wartość testową przez set, nigdy produkcyjną.

Commituj konfigurację projektu dla całego zespołu

.codex/config.toml w repozytorium to miejsce, w którym tech lead ujednolica zachowanie Codex u każdego, kto zaufa projektowi. Trzymaj w nim tylko ustawienia należące do kodu, a wybór modelu zostaw każdemu z osobna:

# .codex/config.toml: committed; reviewed like CI config
default_permissions = ":workspace"
approval_policy = "on-request"
web_search = "cached"

[shell_environment_policy]
ignore_default_excludes = false
set = { NODE_ENV = "test", TZ = "UTC" }

Plik projektu nie może wybrać, dokąd trafiają poświadczenia ani jakie lokalne polecenia się uruchamiają: klucze model_provider, notify, profile i klucze z bazowym URL są w nim ignorowane i muszą trafić do konfiguracji użytkownika albo systemowej (sprawdzone w codex-rs/config/src/loader, 0.157.1).

Zmianę tego pliku traktuj jak zmianę harnessu: zmienia to, co wolno agentowi każdego programisty. Wymagaj review od właściciela harnessu i dołącz do pull requesta wynik testu kanarkowego codex sandbox z następnej sekcji, tak jak opisuje pakiet dowodów. Instrukcje projektu należą do AGENTS.md, nie tutaj; zobacz AGENTS.md dla Codex. Serwery MCP mogą trafić do dowolnego z tych plików jako tabele [mcp_servers.<name>]; zobacz konfigurację MCP w Codex.

Przełączaj zestawy ustawień profilami

Profil to osobny plik $CODEX_HOME/<name>.config.toml, nakładany na konfigurację użytkownika, gdy podasz --profile <name> (albo -p). Starsze tabele [profiles.<name>] w config.toml nadal są parsowane, ale zastąpiono je plikami; używaj plików.

review

~/.codex/review.config.toml

model_reasoning_effort = "high"
review_model = "gpt-6-astra"   # model used by /review
approval_policy = "on-request"

Uruchom codex --profile review, a potem /review. default_permissions profil dziedziczy z pliku użytkownika.

quick

~/.codex/quick.config.toml

model = "gpt-6-luna"
model_reasoning_effort = "low"

Uruchom codex -p quick "Rename getUserData to fetchUserProfile across src/" do mechanicznych zmian, których poprawność potwierdza zestaw testów.

unattended

~/.codex/unattended.config.toml

approval_policy = "never"
default_permissions = ":workspace"
web_search = "disabled"
hide_agent_reasoning = true

Uruchom codex exec --profile unattended --ephemeral "…" do skryptowych zadań na własnej maszynie. never usuwa pytania, ale nie granicę uprawnień. Na runnerach CI stosuj wzorce z Codex w trybie nieinteraktywnym, które obejmują też sekrety i niezaufane pull requesty.

local

~/.codex/local.config.toml

oss_provider = "ollama"   # or "lmstudio"

Uruchom codex --profile local --oss. Wybór modelu lokalnego opisuje strona bramki i modele lokalne.

Profil działa tylko wtedy, gdy podasz go w wierszu poleceń. Żeby zobaczyć, które warstwy wczytała sesja, uruchom /debug-config.

Nadpisz jedno ustawienie na jedno uruchomienie

Żeby zmienić jedno uruchomienie, nie musisz edytować pliku:

codex -m gpt-6-sol                               # model for this session
codex -c model_reasoning_effort="high"           # any key, as TOML
codex -c shell_environment_policy.inherit=core   # nested keys use dots
codex --enable memories                          # same as -c features.memories=true
codex --search                                   # live web search for this session
codex exec --ephemeral "Run the linter and report."  # exec: approval is never

Które flagi funkcji mają znaczenie

codex features list wypisuje każdą flagę z jej etapem i efektywnym stanem; codex features enable <name> i disable <name> zapisują zmianę w config.toml w sekcji [features]. Flagi są czytane przy starcie, więc po zmianie uruchom Codex ponownie. W 0.157.1:

Flaga	Etap	Domyślnie	Co robi
shell_snapshot	stable	włączona	Zapisuje migawkę środowiska powłoki, więc kolejne polecenia startują szybciej
unified_exec	stable	włączona	Wykonywanie poleceń oparte na PTY
goals	stable	włączona	Trwałe cele i automatyczna kontynuacja (/goal)
multi_agent	stable	włączona	Subagenci
memories	stable	wyłączona	Pamięć między sesjami; włączaj świadomie

Niektóre flagi nadal widnieją na liście z etapem removed, m.in. personality, steer, tool_search i js_repl. Ich przełączanie niczego nie zmienia. To samo dotyczy klucza konfiguracji personality: „friendly and pragmatic no longer select a style” (sprawdzone w config_toml.rs, 2026-09-26).

Udowodnij, że konfiguracja robi to, co myślisz

Plik konfiguracji to deklaracja. Poniższe kontrole zamieniają ją w dowód i żadna nie wymaga czytania wyników agenta linijka po linijce:

1. Codex parsuje każdy klucz. Uruchom codex doctor --all. W sekcji Configuration wartość „startup warnings” musi wynosić 0; każdy zignorowany klucz jest wypisany z nazwą i warstwą.

2. Wygrywa właściwa warstwa. W TUI /debug-config pokazuje warstwy konfiguracji i źródła wymagań, a /status pokazuje model, zatwierdzanie i sandbox bieżącej sesji. Uruchomienie nieinteraktywne wypisuje ten sam nagłówek: model:, approval:, sandbox:.

3. Granica się trzyma. Uruchom test kanarkowy w tym samym sandboksie, który dostaje agent. Z default_permissions = ":workspace" w 0.157.1 wypisał ok, a potem Read-only file system dla /etc/probe:

   codex sandbox -- sh -c 'echo ok > probe.txt && cat probe.txt; echo x > /etc/probe'

4. Sekrety zostają na zewnątrz. Uruchom test kanarkowy env z sekcji o sekretach. Nie może pojawić się żadna nazwa pasująca do *KEY*, *SECRET* ani *TOKEN*.

Programista uruchamia te kontrole po każdej zmianie własnego pliku. Przy commitowanym .codex/config.toml tech lead lub właściciel harnessu zatwierdza wynik testu kanarkowego w pull requeście, a nie sam diff ustawień. Po każdej aktualizacji Codex powtórz wszystkie cztery, bo klucze i wartości domyślne zmieniają się między wydaniami.

Prompt do skopiowania: audyt konfiguracji Codex

Audit my Codex configuration without changing any file. Run `codex doctor --all` and `codex features list`, then read ~/.codex/config.toml and .codex/config.toml in this repository if it exists. Report a table with each key that is set, the layer it comes from, and whether doctor lists it as ignored. Flag explicitly: default_permissions and sandbox_mode set in the same file; approval_policy = "never" in my user config rather than a profile; shell_environment_policy leaving ignore_default_excludes at its default of true; any removed feature flag still set under [features]. Never print the value of an environment variable.

Prompt do skopiowania: dlaczego ustawienie nie działa

My setting web_search = "live" in ~/.codex/config.toml does not seem to take effect in this repository. Find out why without editing anything. Check `codex doctor --all` for ignored keys, check whether .codex/config.toml in this repository or any parent directory sets web_search, check whether I started this session with --profile or -c, and check whether this project is trusted. Tell me which layer wins and why, quoting the exact lines you relied on.

Prompt do skopiowania: szkic konfiguracji projektu dla zespołu

Draft a .codex/config.toml for this repository that the whole team can commit. Read AGENTS.md, the package manifests, and the CI config first. Include only project settings: default_permissions = ":workspace", approval_policy = "on-request", web_search = "cached", and a [shell_environment_policy] with ignore_default_excludes = false plus a `set` table for the non-secret variables the test suite needs. Do not set model or model_reasoning_effort. Put a one-line comment above each key saying why. Do not write the file; show it to me with the `codex sandbox` canary command that proves it.

Kiedy konfiguracja Codex się psuje

Ustawienie nie działa, a nic nie zgłasza błędu. Codex pomija nieznane klucze z ostrzeżeniem przy starcie, więc web_serach = "live" albo przestarzały klucz personality nic nie robią. Uruchom codex doctor --all i przeczytaj listę zignorowanych kluczy albo uruchom raz z --strict-config, a potem popraw pisownię według schematu.

Konfiguracja projektu jest ignorowana. Projekt nie jest zaufany. Otwórz Codex w repozytorium ponownie i zaakceptuj pytanie o zaufanie albo sprawdź wpis [projects."<path>"] w konfiguracji użytkownika. Zaufaj projektowi dopiero po przeczytaniu jego katalogu .codex/.

Ustawienie z profilu przegrywa. .codex/config.toml zaufanego projektu stoi nad profilami. Na jedno uruchomienie użyj -c key=value albo uzgodnij inną wartość w pliku projektu.

Polecenie kończy się „invalid value” dla -a. W 0.157.1 -a przyjmuje tylko on-request i never; on-failure i untrusted są tam odrzucane. Jeśli potrzebujesz drobniejszej kontroli niż on-request, ustaw w config.toml politykę granular (tabelę), której -a nie wyrazi; untrusted jest odrzucane także w config.toml. -a po exec kończy się błędem „unexpected argument”; przenieś flagę przed podpolecenie.

Codex odrzuca wartość sandboksa lub zatwierdzania, którą ustawiłeś. Ogranicza ją zarządzany requirements.toml. Uruchom /debug-config, żeby zobaczyć źródło wymagań, i zanieś pytanie do właściciela polityki.

Testy padają w Codex, a w twoim terminalu przechodzą. Polityka środowiska usunęła zmienną, której potrzebują testy. Sprawdź to testem kanarkowym env, a potem dodaj wartość testową w set. Nigdy nie poszerzaj inherit ani nie przestawiaj ignore_default_excludes z powrotem na true, żeby naprawić jedną zmienną.

Uruchomienie nie ma dostępu do sieci. :workspace nie daje dostępu do sieci. Zainstaluj zależności przed uruchomieniem Codex albo zdefiniuj nazwany profil [permissions] z dostępem do sieci per domena; pokazuje to przewodnik po uprawnieniach i sandboksach.

Nazwa modelu jest odrzucana. Modelu nie ma w katalogu twojej wersji albo twój plan lub workspace go nie obejmuje. Wybierz model z /model i zaktualizuj Codex przez codex update. GPT-6 Sol i Luna wymagają codex-cli 0.155.0 lub nowszego. GPT-5.5 przestaje być dostępny w Codex 2026-10-14 (strona OpenAI o modelach, sprawdzona 2026-10-12).

Własny dostawca przestaje się łączyć. Obecne wydania Codex nie obsługują wire_api = "chat" ani punktu końcowego wyłącznie z Chat Completions (strona OpenAI o modelach, sprawdzona 2026-10-12). Skieruj model_provider na punkt końcowy obsługujący Responses API; blok dostawcy pokazuje strona zaawansowane konfiguracje Codex.

Ostatnia deska ratunku. Odsuń ~/.codex/config.toml na bok, uruchom Codex i potwierdź, że działa na wartościach domyślnych. Potem dodawaj ustawienia z powrotem blok po bloku i po każdym bloku uruchamiaj codex doctor.

Dokąd dalej z konfiguracją Codex

AGENTS.md dla Codex Przekaż Codex konwencje projektu, polecenia i kroki weryfikacji, których nie wyrazisz w config.toml.

Pierwsze zadanie w Codex Wykorzystaj nową konfigurację przy zmianie, którą weryfikujesz testami i drugim przeglądem.

Uprawnienia, sandboksy i tryby zatwierdzania Macierz trybów zatwierdzania, sandboksów i dostępu do sieci w trzech narzędziach, z ustawieniem dla każdego typu uruchomienia.

Polecenia Codex CLI Uzupełnianie w powłoce, flagi exec i polecenia, których z tą konfiguracją będziesz używać na co dzień.