# Konfiguracja Codex w config.toml: model, uprawnienia i profile URL: https://developertoolkit.ai/pl/codex/quick-start/configuration/ Description: Świadomie ustaw config.toml w Codex: kolejność warstw, model i effort, profile uprawnień, filtrowanie sekretów, profile i dowód, że każde ustawienie działa. 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](/pl/codex/quick-start/installation/) i [uwierzytelnianie w Codex](/pl/codex/quick-start/authentication/). ## 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/.config.toml` | Tylko gdy podasz `--profile ` | | 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](/pl/codex/team/enterprise-governance/). CLI, aplikacja desktopowa i rozszerzenie IDE czytają ten sam `CODEX_HOME`. Zadania Codex w chmurze nie czytają plików lokalnych; [środowiska chmurowe Codex](/pl/codex/automate/cloud-environments/) 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: ```toml #: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: ```bash 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](/pl/ecosystem/models/); 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](/pl/codex/operate/cost-management/). - 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](/pl/codex/build/context-patterns/), 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](/pl/workflows/harness/permissions-and-sandboxing/). ### 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]`: ```toml [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`: ```bash 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: ```bash 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: ```toml # .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](/pl/workflows/ship/evidence-bundle/). Instrukcje projektu należą do `AGENTS.md`, nie tutaj; zobacz [AGENTS.md dla Codex](/pl/codex/quick-start/agents-md/). Serwery MCP mogą trafić do dowolnego z tych plików jako tabele `[mcp_servers.]`; zobacz [konfigurację MCP w Codex](/pl/codex/quick-start/mcp-setup/). ## Przełączaj zestawy ustawień profilami Profil to osobny plik `$CODEX_HOME/.config.toml`, nakładany na konfigurację użytkownika, gdy podasz `--profile ` (albo `-p`). Starsze tabele `[profiles.]` w `config.toml` nadal są parsowane, ale zastąpiono je plikami; używaj plików. **review** ```toml # ~/.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** ```toml # ~/.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** ```toml # ~/.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](/pl/codex/automate/non-interactive/), które obejmują też sekrety i niezaufane pull requesty. **local** ```toml # ~/.codex/local.config.toml oss_provider = "ollama" # or "lmstudio" ``` Uruchom `codex --profile local --oss`. Wybór modelu lokalnego opisuje strona [bramki i modele lokalne](/pl/ecosystem/agent-tools/gateways-local-models/). 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: ```bash 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 ` i `disable ` 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`: ```bash 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** ```text 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** ```text 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** ```text 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.""]` 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](/pl/workflows/harness/permissions-and-sandboxing/). **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](/pl/codex/automate/advanced-techniques/). **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](/pl/codex/quick-start/agents-md/) — Przekaż Codex konwencje projektu, polecenia i kroki weryfikacji, których nie wyrazisz w config.toml. - [Pierwsze zadanie w Codex](/pl/codex/quick-start/first-task/) — Wykorzystaj nową konfigurację przy zmianie, którą weryfikujesz testami i drugim przeglądem. - [Uprawnienia, sandboksy i tryby zatwierdzania](/pl/workflows/harness/permissions-and-sandboxing/) — 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](/pl/codex/build/cli-commands/) — Uzupełnianie w powłoce, flagi exec i polecenia, których z tą konfiguracją będziesz używać na co dzień.