Codex wycofał politykę zatwierdzania untrusted: co zmienić

Codex CLI v0.149.0 (wydanie stabilne, 20 sierpnia 2026) wycofał politykę zatwierdzania untrusted w PR #39630, „Retire the untrusted approval policy” (wycofanie polityki zatwierdzania untrusted).¹ Ten PR usuwa untrusted „from the CLI, configuration schema, and MCP tool interface” (z CLI, schematu konfiguracji i interfejsu narzędzi MCP), a jawne ustawienie approval_policy = "untrusted" kończy się teraz „with an actionable error” (błędem wskazującym, co zrobić).⁴ Odtworzone na 0.149.1, 25 sierpnia 2026: uruchomienie sesji zatrzymuje się na Error: approval_policy = "untrusted" is no longer supported; remove this setting niezależnie od tego, czy wartość znajduje się w config.toml, w pliku profilu, czy w nadpisaniu -c, a plik binarny codex odrzuca -a untrusted już na etapie parsowania argumentów.⁵ Należy zmienić wartość na on-request i pozostawić tryb piaskownicy (sandbox) bez zmian; w najostrożniejszej konfiguracji warto połączyć --sandbox read-only z on-request.³ Aktualny zestaw polityk to on-request, never oraz granularna forma tabelaryczna.² Stan na v0.149.1 (24 sierpnia 2026, UTC), czyli npm latest.¹ {.answer-block}

TL;DR

• Zmiana: pełna lista zmian v0.149.0 wymienia PR #39630, „Retire the untrusted approval policy”. Informacje o wydaniu nie dają żadnego tekstu migracyjnego poza tym tytułem;¹ daje go dopiero opis PR: untrusted zniknęło z CLI, ze schematu konfiguracji i z interfejsu narzędzi MCP, a jawne ustawienia „now fail with an actionable error” (kończą się teraz błędem wskazującym, co zrobić).⁴
• Kto musi działać: każdy, kto ma approval_policy = "untrusted" w ~/.codex/config.toml lub w profilu, oraz każdy, kto przekazuje --ask-for-approval untrusted (albo -a untrusted) w skryptach, aliasach lub CI.
• Zamiennik: on-request, z trybem piaskownicy bez zmian. read-only plus on-request to opisana w dokumentacji para „Safe read-only browsing” (bezpieczne przeglądanie tylko do odczytu).² Dawne połączenie workspace-write plus untrusted nie ma bezpośredniego następcy; monity dla poszczególnych poleceń żyją teraz w regułach exec policy.⁴⁸
• Aktualny zestaw: on-request, never albo approval_policy = { granular = { ... } } dla kontroli per kategoria. Tryby piaskownicy pozostają read-only, workspace-write i danger-full-access.²
• Szybki błąd zamiast cichej zmiany: pozostawione approval_policy = "untrusted" zatrzymuje sesję z Error: approval_policy = "untrusted" is no longer supported; remove this setting, czy to w config.toml, w pliku profilu, czy w nadpisaniu -c. codex doctor zgłasza jedynie, że konfiguracji nie udało się wczytać, bez podania nazwy klucza.⁵

Co zmienił Codex 0.149?

Główne pozycje to nowe powierzchnie, między innymi panel codex agents, codex queue i rozszerzony codex doctor; zmiana zatwierdzania siedzi niżej, w pełnej liście zmian.¹ Opis PR #39630 zawiera szczegół, który informacje o wydaniu pomijają. Liczą się tu dwa z jego trzech punktów: „Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.” oraz „Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.” (usunięcie listy dozwolonych poleceń znanych jako bezpieczne; projekty oznaczone jako niezaufane proszą teraz o zgodę na każde polecenie, chyba że jawna reguła exec policy na nie pozwala).⁴ Jedna poprawka błędu z tego samego wydania ma znaczenie dla tych samych czytelników: „Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.” (wznowione i rozgałęzione wątki przywracają teraz swój aktywny profil uprawnień, zamiast po cichu wracać do bieżących wartości domyślnych).¹

Każdy wiersz cytuje informacje o wydaniu v0.149.0.¹

Kto musi cokolwiek edytować?

Wartość może znajdować się w czterech miejscach. Najpierw należy znaleźć wszystkie, bo profil albo alias powłoki przywraca starą politykę po naprawieniu głównego pliku.

Awaria przy starszej tabeli jest głośna. Na 0.149.1 codex exec --profile safe "hi" z tabelą [profiles.safe] wciąż obecną w config.toml zatrzymuje się na Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ..., więc --profile safe u współpracownika zawodzi, zanim Codex w ogóle odczyta wartość zatwierdzania.⁵

Po jednym grep dla każdej strony:

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

Pierwszy grep nie bez powodu dopasowuje klucz, a nie samo słowo. trust_level = "untrusted" to inne ustawienie; należy je zostawić. Dokumentacja konfiguracji definiuje projects.<path>.trust_level jako klucz oznaczający „a project or worktree as trusted or untrusted” (projekt lub worktree jako zaufany albo niezaufany), a projekty niezaufane „skip project-scoped .codex/ layers, including project-local config, hooks, and rules” (pomijają warstwy .codex/ o zasięgu projektu, w tym lokalną konfigurację projektu, hooki i reguły).⁷ PR #39630 zmienia to, co projekt niezaufany robi z poleceniami, a nie sam klucz: „Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Ślepe znajdź-i-zamień na untrusted psuje ten klucz.

Pliki profili to udokumentowany mechanizm zestawów ustawień (~/.codex/<name>.config.toml, wybierany przez codex --profile <name>), więc profil współpracownika może przywrócić wycofaną wartość niezależnie od tego, co mówi główna konfiguracja.²

Jaki jest aktualny zestaw polityk zatwierdzania?

Bezpieczeństwo Codex CLI opiera się na dwóch warstwach: tryb piaskownicy decyduje, co Codex może technicznie zrobić, a polityka zatwierdzania decyduje, kiedy Codex musi się zatrzymać i zapytać.² Wycofanie dotyka tylko drugiej z nich.

Forma granularna obejmuje pięć kategorii monitów: sandbox_approval, rules (monity execpolicy), mcp_elicitations, request_permissions i skill_approval.² Żadna z nich nie odtwarza untrusted, które było regułą klasyfikacji poleceń (automatyczne uruchamianie odczytów znanych jako bezpieczne, monit przy wszystkim, co mogło zmienić stan), a nie filtrem kategorii monitów.²

workspace-write plus untrusted, czyli wiersz dokumentacji „Automatically edit but ask for approval to run untrusted commands” (edytuj automatycznie, ale pytaj o zgodę na uruchamianie niezaufanych poleceń), nie ma bezpośredniego następcy.² workspace-write plus on-request przestaje pytać o polecenia uruchamiane wewnątrz piaskownicy; read-only plus on-request pyta zarówno o edycje, jak i o polecenia.² PR #39630 usunął „the known-safe command allowlist” i wskazuje mechanizm, który przetrwał dla monitów per polecenie: „Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ Reguły exec policy to ten sam mechanizm, który stoi za kategorią rules w tabeli granularnej, czyli „execpolicy-rule prompts” wymienione na stronie o zatwierdzeniach.² Osoby odpowiedzialne za bezpieczeństwo, które polegały na untrusted przy zapisywalnym obszarze roboczym, powinny zbudować te reguły. Dokumentacja reguł ogranicza je do poleceń uruchamianych poza piaskownicą; prefix_rule z decision = "prompt" pyta „before each matching invocation” (przed każdym pasującym wywołaniem):⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

Piaskownica tylko do odczytu pozostaje prostą alternatywą, która blokuje modyfikacje wprost.³

Jakie dokładnie edycje trzeba wprowadzić?

Mapowanie to jedna linia: untrusted staje się on-request, a tryb piaskownicy zostaje taki, jaki był.³

Główna konfiguracja (plik profilu wymaga identycznej edycji):

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

Skrypt:

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

Para -a/--ask-for-approval należy do pliku binarnego TUI codex. codex exec nie ma takiej flagi: na 0.149.1 codex exec --ask-for-approval untrusted "hi" kończy się error: unexpected argument '--ask-for-approval' found.⁵ Dla codex exec politykę należy ustawić w konfiguracji albo przekazać inline:

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

Dalej dwie decyzje wymagające namysłu. Po pierwsze, tam gdzie nikt nie odpowie na monit, interaktywny plik binarny codex pod on-request zawiesza się na pierwszym zatwierdzeniu; udokumentowana para nieinteraktywna to --sandbox read-only --ask-for-approval never, a codex exec --sandbox workspace-write to udokumentowany nieinteraktywny punkt wejścia.² Po drugie, jeśli untrusted było łączone z danger-full-access w duchu „pełna moc, ale pytaj za każdym razem”, ta właściwość nie przetrwa zamiany. Dwa przykłady monitu on-request z dokumentacji to wyjście poza piaskownicę i użycie sieci, a danger-full-access usuwa oba te wyzwalacze.² Monity z pozostałych czterech kategorii tabeli granularnej nadal odpalają się przy pełnym dostępie: reguły exec policy z decision = "prompt", elicytacje MCP, zatwierdzenia skilli i monity request_permissions.²⁸ Opcjonalne ustawienie approvals_reviewer = "auto_review" kieruje kwalifikujące się monity przez agenta recenzującego; dotyczy tylko polityk interaktywnych, więc pozostaje dostępne po migracji.²

Jak sprawdzić, że zmiana zadziałała?

1. Proszę uruchomić codex doctor. Z wycofaną wartością wciąż w konfiguracji jego linia config zaczyna się od ✗ config config could not be loaded, a linia szczegółów brzmi · failed to load Codex config; doctor nie podaje nazwy winnego klucza. Nazwany błąd pochodzi z uruchomienia codex lub codex exec. Czysta linia doctor oznacza, że wartość zniknęła; nieudana oznacza, że wciąż trzeba uruchomić sesję, żeby zobaczyć, o który klucz chodzi.⁵ Błąd przy uruchomieniu jest identyczny niezależnie od tego, czy wartość siedzi w config.toml, w pliku profilu wybranym przez --profile, czy w nadpisaniu -c approval_policy=untrusted.⁵ Forma z flagą zawodzi wcześniej, przy parsowaniu argumentów: codex -a untrusted --version wypisuje error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>', a po nim [possible values: on-request, never].⁵
2. Proszę uruchomić jednorazową sesję w katalogu tymczasowym i wykonać /status. Jego linia Permissions pokazuje aktywną politykę, a on-request renderuje się tam jako „Ask for approval”.⁵ /permissions otwiera menu zestawów ustawień, zamiast raportować aktywny tryb, więc lepiej czytać /status.⁵ /status wymienia też katalogi obszaru roboczego.²
3. Proszę wznowić jeden starszy wątek. PR #39153, „Restore permission profiles when resuming threads”, przywraca teraz „the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread” (ostatnio zapisaną politykę zatwierdzania, recenzenta zatwierdzeń i identyfikator aktywnego profilu uprawnień przy wznawianiu lub rozgałęzianiu wątku).⁶ Wznowiony wątek, którego zapisana polityka to untrusted, pozostaje nieprzetestowany; ten przypadek należy traktować jako nieznany, dopóki nie otworzy się takiego wątku.

Jedno zastrzeżenie co do samej dokumentacji. Oficjalna strona „Agent approvals & security”, według zrzutu z 24 sierpnia i ponownego sprawdzenia 25 sierpnia 2026, nadal pokazuje --ask-for-approval untrusted w tabeli kombinacji, nadal zawiera akapit zaczynający się od „With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically” i nadal używa approval_policy = "untrusted" w swoim przykładzie config.toml.² Wpis approval_policy w dokumentacji konfiguracji wymienia untrusted jako pierwsze w unii typów, a jego opis oznacza jako wycofaną inną wartość: „on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.”⁷ Autorytatywnym zapisem są PR i plik binarny; dokumentacja za nimi nie nadąża. Nie należy kopiować bloku przykładowego z dokumentacji do świeżej instalacji 0.149 bez podmiany wartości.

FAQ

Co zastępuje approval_policy = "untrusted" w Codex CLI?

approval_policy = "on-request", z dotychczasowym sandbox_mode bez zmian. Dla najostrożniejszej kombinacji warto ustawić obok sandbox_mode = "read-only".³

Która wersja Codex CLI wycofała politykę untrusted?

v0.149.0, stabilna od 20 sierpnia 2026, przez PR #39630 w pełnej liście zmian. v0.149.1 (24 sierpnia 2026, UTC) to aktualny npm latest.¹

Co się stanie, jeśli zostawię untrusted w config.toml?

Codex odmawia uruchomienia sesji. Na 0.149.1 codex exec zatrzymuje się na Error: approval_policy = "untrusted" is no longer supported; remove this setting, ten sam błąd pojawia się dla pliku profilu i dla -c approval_policy=untrusted, a codex doctor zgłasza tylko, że konfiguracji nie udało się wczytać.⁵ PR #39630 opisuje to zachowanie jako kończące się „with an actionable error”.⁴

Czy on-request jest mniej bezpieczne niż było untrusted?

Wewnątrz workspace-write tak: untrusted pytało przed każdym poleceniem, które mogło zmienić stan, a on-request uruchamia polecenia w piaskownicy bez pytania.² Warstwa piaskownicy odzyskuje część marginesu: read-only blokuje zapisy niezależnie od polityki, a on-request nadal pyta przed każdą eskalacją.³ Dla monitów per polecenie przy zapisywalnym obszarze roboczym należy napisać reguły exec policy, czyli mechanizm, który wskazuje PR #39630.⁴⁸

Czy trzeba też zmienić tryb piaskownicy?

Nie. Wycofanie dotyczy tylko polityki zatwierdzania; read-only, workspace-write lub danger-full-access należy zostawić tak, jak było.³

Najważniejsze wnioski

Dla pojedynczych programistów: - Przeszukać ~/.codex/*.toml pod kątem approval_policy = "untrusted" (nie samego słowa), zastąpić każde trafienie przez on-request, a sandbox_mode i ewentualne trust_level = "untrusted" zostawić w spokoju. - Uruchomić codex doctor, potem /status w sesji tymczasowej, i wznowić jeden stary wątek, żeby zobaczyć, co przywraca 0.149.

Dla zespołów utrzymujących wspólne profile i skrypty: - Poprawić pliki profili i nadpisania inline w tym samym commicie co config.toml; starsza tabela [profiles.<name>] blokuje --profile całkowicie, dopóki nie zostanie przeniesiona do ~/.codex/<name>.config.toml.⁵ - Przestawić zadania bezobsługowe na --sandbox read-only --ask-for-approval never na pliku binarnym codex albo na codex exec --sandbox workspace-write -c approval_policy=never; interaktywny plik binarny codex pod on-request blokuje się na monicie, na który nikt nie odpowie, a codex exec nie ma flagi --ask-for-approval.⁵

Dla osób odpowiedzialnych za bezpieczeństwo: - Klasyfikator untrusted (automatyczne uruchamianie bezpiecznych odczytów, monit przy modyfikacji) nie ma granularnego odpowiednika; PR #39630 wskazuje reguły exec policy („unless an explicit exec policy rule allows it”) dla monitów per polecenie,⁴ zapisywane jako prefix_rule z decision = "prompt" w ~/.codex/rules/default.rules,⁸ a piaskownica tylko do odczytu blokuje modyfikacje wprost. - Warto rozważyć approvals_reviewer = "auto_review" tam, gdzie agent recenzujący może zastąpić człowieka przy kwalifikujących się monitach.

Źródła