Codex ciągle prosi o zatwierdzenie? Zasady zatwierdzania, piaskownica i „nie pytaj ponownie”: wyjaśnienie
Codex prosi o zatwierdzenie, gdy polecenie musi wyjść poza jego piaskownicę. Większość skarg typu „ciągle pyta” wynika ze zbyt ciasnej piaskownicy, ustawienia, które już nie istnieje, albo z „nie pytaj ponownie”, które obowiązywało tylko w danej sesji.
KRÓTKA ODPOWIEDŹ
W obecnym Codex approval_policy przyjmuje wartość on-request (domyślna: model pyta, gdy potrzebuje), never albo tabelę granular; untrusted usunięto, a on-failure to teraz po prostu inna nazwa on-request. To, jak często dostajesz pytania, zależy głównie od piaskownicy: przy sandbox_mode = "workspace-write" Codex edytuje pliki i uruchamia polecenia w twoim projekcie bez pytania. Dla poleceń, którym zawsze ufasz, dodaj prefix_rule z decision = "allow" w ~/.codex/rules/default.rules. Tam też zapisuje się opcja „nie pytaj ponownie o polecenia zaczynające się od …”.
Najpierw: co się zmieniło w Codex
Wiele poradników i odpowiedzi na forach opisuje ustawienia, które już nie działają. Zanim zaczniesz cokolwiek dostrajać, porównaj swój ~/.codex/config.toml z tą listą:
| Stare ustawienie | Obecnie |
|---|---|
approval_policy = "untrusted" | Usunięte. Codex zgłasza „approval_policy = "untrusted" is no longer supported; remove this setting”. Dokumentacja zaleca zamiast tego sandbox_mode = "read-only" z on-request. |
approval_policy = "on-failure" | Nadal akceptowane, ale tylko jako alias on-request. |
--full-auto | Nie ma go już w dokumentacji CLI. Najbliższa flaga to --approve-for-me (alias --not-so-yolo): automatyczna ocena zatwierdzeń z on-request i piaskownicą workspace-write. |
[profiles.name] w config.toml | Od Codex 0.134.0 --profile name odczytuje zamiast tego $CODEX_HOME/name.config.toml. Pozostawiony klucz profile = "x" powoduje teraz błąd. |
/approvals | Użyj /permissions („Set what Codex can do without asking first.”) |
Dokumentacja Codex również się przeniosła: stare strony developers.openai.com/codex przekierowują teraz do learn.chatgpt.com.
Jak Codex decyduje, czy zapytać
Dwa ustawienia działają razem. Piaskownica ogranicza, czego polecenie może dotknąć: plików poza projektem, sieci. Zasady zatwierdzania określają, co się dzieje, gdy polecenie potrzebuje więcej, niż pozwala piaskownica.
| sandbox_mode | Co Codex może zrobić bez pytania |
|---|---|
read-only (domyślnie) | Odczyt plików i uruchamianie poleceń w piaskownicy tylko do odczytu |
workspace-write | Automatyczny odczyt, edycja i uruchamianie poleceń w katalogu roboczym |
danger-full-access | Wszystko, bez piaskownicy. Niezalecane |
| approval_policy | Zachowanie |
|---|---|
on-request (domyślnie) | Model decyduje, kiedy zapytać. Polecenia dozwolone przez piaskownicę działają bez zatwierdzania |
never | Nigdy nie pyta. Wszystko, co się nie powiedzie, wraca do modelu i nie trafia do ciebie |
{ granular = { … } } | Niektóre kategorie monitów pozostają interaktywne, a reszta jest automatycznie odrzucana (sandbox_approval, rules, skill_approval, request_permissions, mcp_elicitations) |
Jeśli więc pracujesz w read-only, każda edycja wymaga zgody. To najczęstsza przyczyna sytuacji „Codex pyta o wszystko”. Nawet w workspace-write katalogi .git, .codex, .agents i .aws pozostają tylko do odczytu, a dostęp do sieci jest wyłączony, dopóki go nie włączysz.
To przykładowa konfiguracja z dokumentacji OpenAI z objaśnieniem opcji workspace:
Nowsze wersje oferują też profile uprawnień (default_permissions z wbudowanymi :read-only, :workspace i :danger-full-access). Używaj albo profili, albo sandbox_mode, nie obu naraz.
Ustawienia predefiniowane w CLI, rozszerzeniu IDE i aplikacji
Nie musisz edytować TOML. W CLI /permissions otwiera ustawienia predefiniowane; w aplikacji i rozszerzeniu IDE pod polem wpisywania jest kontrolka uprawnień. Ustawienia predefiniowane w CLI to:
- Read Only: odczytuje obszar roboczy; edycja plików lub dostęp do internetu wymaga zatwierdzenia.
- Default: edytuje w obszarze roboczym; dostęp do internetu lub edycja innych plików wymaga zatwierdzenia.
- Full Access: edytuje poza obszarem roboczym i korzysta z internetu bez pytania.
Aplikacja i rozszerzenie IDE opisują ten sam wybór jako Ask for approval, Approve for me i Full access. Na starszych zrzutach ekranu z IDE nazywają się one Chat, Agent i Agent (Full Access).
Zezwalanie na konkretne polecenia za pomocą reguł
Jeśli chcesz, żeby Codex uruchamiał jedno polecenie poza piaskownicą bez pytania (na przykład gh pr view), napisz regułę. Reguły są eksperymentalne i znajdują się w pliku .rules w folderze rules/ obok warstwy konfiguracji, na przykład ~/.codex/rules/default.rules:
allow: uruchom poza piaskownicą bez monitu.prompt: pytaj przed każdym pasującym poleceniem.forbidden: blokuj bez pytania.
Gdy pasuje kilka reguł, wygrywa najbardziej restrykcyjna: forbidden ma pierwszeństwo przed prompt, a ta przed allow. Zanim zaczniesz polegać na regule, przetestuj polecenie za pomocą codex execpolicy check.
Co naprawdę zapisuje „nie pytaj ponownie”
Monit zatwierdzenia w Codex CLI oferuje różne rodzaje „tak”, a każde obowiązuje przez zupełnie inny czas:
| Opcja | Jak długo obowiązuje |
|---|---|
| Yes, proceed | To jedno polecenie |
Yes, and don’t ask again for commands that start with <prefix> | Na stałe (zapisane jako reguła w ~/.codex/rules/default.rules) |
| Yes, and don’t ask again for this command in this session | Do końca sesji |
| Yes, and don’t ask again for these files | Edycje plików, w tej sesji |
Jeśli będziesz wybierać opcję sesyjną, jutro dostaniesz to samo pytanie. Wybierz opcję z prefiksem albo napisz regułę samodzielnie.
Codex w systemie Windows
To w systemie Windows problem „pyta o wszystko” był najgorszy. W zgłoszeniu #10187 członek zespołu OpenAI wyjaśnił dlaczego: „Without a sandboxing mechanism, all tool calls need to be manually approved on Windows.” Codex ma teraz natywną piaskownicę dla Windows i używa jej domyślnie:
mxc: zalecana piaskownica na zgodnych urządzeniach z systemem Windows.elevated: preferowane rozwiązanie zapasowe, gdy MXC jest niedostępne.unelevated: starsze rozwiązanie zapasowe.
Uruchom /setup-default-sandbox w CLI, żeby skonfigurować piaskownicę elevated (lub codex sandbox setup --elevated dla działu IT). Zalecany jest Windows 11; Windows 10 1809 lub nowszy jest obsługiwany w miarę możliwości. Jeśli pracujesz w WSL, Codex używa tam swojej piaskownicy dla Linuksa, a WSL1 nie jest już obsługiwany.
Konfiguracja projektu wczytuje się tylko w zaufanych projektach
Plik .codex/config.toml w repozytorium jest odczytywany tylko wtedy, gdy ufasz projektowi. Jeśli ustawienia projektu wydają się ignorowane, to właśnie dlatego. Wpis zaufania w konfiguracji użytkownika wygląda tak:
Ustawienia są warstwowe, od najwyższej: flagi wiersza poleceń i nadpisania -c, .codex/config.toml zaufanego projektu, plik --profile, twój ~/.codex/config.toml, a na końcu ustawienia domyślne systemu.
O --yolo
--dangerously-bypass-approvals-and-sandbox (alias --yolo) uruchamia każde polecenie bez zatwierdzeń i bez piaskownicy. Kod źródłowy opisuje to jako „EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed.” approval_policy = "never" z danger-full-access robi to samo z poziomu pliku konfiguracyjnego. Jeśli chcesz po prostu mniej monitów, workspace-write z kilkoma regułami allow wystarczy, a piaskownica pozostaje włączona.
Dla monitów, które pozostały
Gdy Codex pyta już tylko o rzeczy, które mają znaczenie (sieć, pliki poza projektem, push), pozostaje problem zauważenia pytania. Pet Island umieszcza zatwierdzenia poleceń i edycji plików z Codex na małej wyspie u góry ekranu, razem z poleceniem lub diffem, więc możesz je zatwierdzić lub odrzucić bez szukania właściwego terminala. Pokazuje, kiedy Codex pracuje i kiedy skończył, a pytania z Codex jednym kliknięciem przenoszą cię do właściwego okna. Działa z Codex CLI i aplikacją Codex, a gdy wyspa jest zamknięta, Codex jak zwykle pyta w swoim oknie.
CZĘSTE PYTANIA
Jak sprawić, żeby Codex nie prosił ciągle o zatwierdzenie?
Użyj sandbox_mode = "workspace-write", żeby Codex mógł edytować i uruchamiać polecenia w twoim projekcie, zostaw approval_policy = "on-request" i dodaj wpisy prefix_rule z decision = "allow" w ~/.codex/rules/default.rules dla poleceń, którym zawsze ufasz.
Czy approval_policy = "untrusted" jest nadal obsługiwane?
Nie. Obecny Codex odrzuca je komunikatem „approval_policy = "untrusted" is no longer supported; remove this setting”. Zamiast tego użyj sandbox_mode = "read-only" z approval_policy = "on-request".
Co się stało z --full-auto?
Nie ma go już w dokumentacji Codex CLI. Najbliższa opcja to --approve-for-me (alias --not-so-yolo), która korzysta z automatycznej oceny zatwierdzeń z on-request i piaskownicą workspace-write.
Dlaczego „nie pytaj ponownie” nie działa na stałe?
„Don’t ask again for this command in this session” obowiązuje tylko w danej sesji. Wybierz „don’t ask again for commands that start with …”, która zapisuje regułę w ~/.codex/rules/default.rules.
Dlaczego Codex pyta częściej w systemie Windows?
Bez piaskownicy każde wywołanie narzędzia wymaga zatwierdzenia. Codex domyślnie używa teraz natywnej piaskownicy Windows; uruchom /setup-default-sandbox, jeśli nie jest skonfigurowana.
Dlaczego plik .codex/config.toml mojego projektu jest ignorowany?
Codex wczytuje konfigurację projektu tylko dla zaufanych projektów.
Źródła
Każde ustawienie i zachowanie opisane na tej stronie zostało sprawdzone z tymi stronami 26 października 2026. Agenci szybko się zmieniają; jeśli coś przestało się zgadzać, obowiązuje strona oficjalna.
- OpenAI: Codex agent approvals and security
- OpenAI: Codex permission modes
- OpenAI: Codex config basics
- OpenAI: Codex sample config
- OpenAI: Codex rules
- OpenAI: Codex Windows sandbox
- OpenAI: Codex CLI reference
- OpenAI: Codex slash commands
- Kod źródłowy openai/codex (monit zatwierdzenia, błędy konfiguracji)
- Zgłoszenie #10187: Codex wielokrotnie prosi o zatwierdzenie polecenia
- Zgłoszenie #5131: Edycje plików zawsze trzeba zatwierdzać
- Zgłoszenie #29406: Monit zatwierdzenia pojawia się mimo don’t ask again