Jak wyjść z błędów i złych decyzji Codex

Odzyskiwanie po błędach Codex polega na przypisaniu awarii do jednego z pięciu typów — blokady sandboxa lub zatwierdzeń, nieudanego polecenia, zmiany w złym kierunku, długiego wątku, w którym Codex się pogubił, albo zerwanego połączenia — i zastosowaniu poprawki dla tego typu. Cofanie przewija rozmowę, a nie pliki: w Codex CLI 0.157.1 funkcja migawek undo jest usunięta, więc pliki przywracasz Gitem.

Ta strona jest dla programistów, którzy mają za sobą pierwsze zadanie w Codex i właśnie zobaczyli, jak kolejne idzie nie tak. Codex uruchomił npm install w repozytorium na pnpm, lockfile się zmienił i build przestał działać. Albo na błąd typów odpowiedział trzema rundami rzutowań, każda gorsza od poprzedniej. Albo przebudował moduł, o który nikt go nie prosił. Każdą z tych sytuacji cofniesz w kilka minut, jeśli wiesz, z jakim typem awarii masz do czynienia, i w całe popołudnie, jeśli nie wiesz.

Co daje ci procedura odzyskiwania w Codex

• Tabelę triage, która prowadzi od objawu do właściwej sekcji z poprawką.
• Nawyk checkpointu w Git, dzięki któremu każde inne odzyskiwanie jest tanie.
• Dokładne opcje zatwierdzania, flagi i klucze konfiguracji dla Codex CLI 0.157.1, w tym wąskie uprawnienia, które odblokowują sandbox bez jego otwierania.
• Pięć promptów do skopiowania: najpierw plan, napraw przyczynę, zmień kierunek, przekaż długi wątek i przerwij pętlę błędów.
• Trzy kontrole, które dowodzą, że naprawiona zmiana działa, bez czytania każdej linii.

Z jakim typem awarii Codex masz do czynienia?

Zacznij od objawu. Najwięcej czasu przy odzyskiwaniu traci się na dobrą poprawkę dla złej awarii, na przykład na nowy wątek, gdy prawdziwym problemem jest brak dostępu do sieci.

Objaw	Typ awarii	Pierwsze sprawdzenie	Przejdź do
Pojawia się prośba o zatwierdzenie albo polecenie kończy się „permission denied” lub błędem DNS	Blokada sandboxa lub zatwierdzeń	Czy zadanie wymaga czegoś spoza katalogu roboczego?	Napraw blokady sandboxa i zatwierdzeń
Polecenie powłoki kończy się kodem różnym od zera: błędy instalacji, builda lub testów	Nieudane polecenie	Czy AGENTS.md podaje właściwy menedżer pakietów i polecenie testów?	Napraw nieudane polecenie Codex
Kod się kompiluje, może nawet przechodzi testy, ale rozwiązuje inny problem	Zły kierunek	Czy Codex przedstawił plan przed edycją?	Cofnij zmianę w złym kierunku
Codex powtarza pracę albo przeczy wcześniejszej decyzji	Długi wątek	Co /status pokazuje w zużyciu tokenów?	Uratuj długi wątek, który się pogubił
Brakuje narzędzia MCP lub przekracza ono limit czasu, albo widzisz błędy uwierzytelniania	Połączenie	Co zgłaszają codex mcp list i codex doctor?	Napraw awarie MCP, sieci i logowania

Ustaw checkpoint w Git przed ryzykownym zadaniem

Każda ścieżka odzyskiwania poniżej kończy się tak samo: pliki wracają do znanego, dobrego stanu. Doprowadza je tam Git. Codex CLI nie robi już własnych migawek po każdej turze — codex features list w 0.157.1 pokazuje undo z etapem removed — więc checkpoint musi być twój.

W terminalu, zanim oddasz Codex refaktoryzację, zmianę zależności albo cokolwiek, co dotyka więcej niż kilku plików:

git status                        # start from a clean tree, or know what is already dirty
git add -A && git commit -m "checkpoint: before codex auth refactor"

Przy większej lub eksploracyjnej pracy trzymaj Codex całkiem z dala od głównego checkoutu. codex --worktree uruchamia sesję w nowym, zarządzanym Git worktree, a /worktree robi to samo z wnętrza sesji. Nieudana próba w worktree kosztuje cię tylko katalog, który możesz usunąć. Cały przepływ opisuje strona izolowane zadania Codex w Git worktrees.

Najtańsze odzyskiwanie to takie, którego nie potrzebujesz. Plan przed jakąkolwiek edycją wyłapuje większość pracy w złym kierunku, póki jest jeszcze akapitem tekstu.

Prompt do skopiowania: plan przed edycją

Before you change any file, read AGENTS.md and the files you expect to touch, then
reply with a plan of 3-5 bullets: which files change, which libraries and patterns
you will use, and which command proves the change works. Do not edit anything until
I reply "go".

Napraw blokady sandboxa i zatwierdzeń w Codex

Gdy odpowiesz już na pytanie o zaufanie do repozytorium, a konfiguracja nie mówi inaczej, Codex uruchamia polecenia z polityką zatwierdzeń on-request i sandboxem workspace-write (sprawdzone w kodzie źródłowym 0.157.1). Może edytować pliki w katalogu roboczym i tam uruchamiać polecenia. Zapis poza katalogiem roboczym albo dostęp do sieci wymaga twojej zgody. Polecenie, które w sandboxie kończy się błędem DNS lub połączenia, zwykle oznacza, że sandbox działa zgodnie z przeznaczeniem, a nie że masz problem z siecią.

Gdy Codex prosi o przekroczenie granicy, okno zatwierdzenia w Codex CLI 0.157.1 proponuje między innymi takie opcje:

• Yes, proceed uruchamia to jedno polecenie.
• Yes, and don’t ask again for this command in this session wyłącza powtarzające się pytania o polecenie, któremu ufasz, na przykład o runner testów.
• No, and tell Codex what to do differently anuluje polecenie i pozwala od razu zmienić kierunek.

Wybieraj tę ostatnią opcję częściej, niż podpowiada intuicja. Gdy Codex chce pisać do /usr/local albo zainstalować pakiet globalnie, właściwą poprawką jest zwykle inne podejście, a nie szerszy sandbox.

Jeśli zadanie naprawdę potrzebuje większego dostępu, przyznaj najwęższe uprawnienie, które je odblokuje:

Jeden dodatkowy katalog

W terminalu dodaj katalog z prawem zapisu tylko na tę sesję:

codex --add-dir ../shared-fixtures

Reszta sandboxa zostaje bez zmian i nic nie przechodzi do następnej sesji.

Sieć dla jednego projektu

Jeśli każde zadanie w projekcie potrzebuje sieci (na przykład rejestru pakietów), przyznaj tylko dostęp do sieci w ~/.codex/config.toml:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

OpenAI zaleca teraz profile uprawnień (beta), wybierane kluczem default_permissions i przełączane w TUI poleceniem /permissions. Profile i starsze ustawienia sandboxa nie łączą się ze sobą, więc w jednej konfiguracji wybierz jeden system. Oba opisuje strona konfiguracja Codex.

Automatyczny przegląd

Jeśli uruchamiasz Codex z --approve-for-me, o prośbach na granicy sandboxa decyduje za ciebie model recenzujący. Gdy odrzuci prośbę, o której wiesz, że jest bezpieczna, /approve ponawia tę jedną odmowę. Nic więcej w polityce się nie zmienia.

Uwaga

--dangerously-bypass-approvals-and-sandbox wyłącza zarówno zatwierdzenia, jak i sandbox. Używaj tej flagi wyłącznie w jednorazowym środowisku z ograniczoną siecią, na przykład w kontenerze do wyrzucenia, nigdy na własnej maszynie tylko po to, żeby ominąć jedno pytanie.

Prompt do skopiowania: znajdź drogę wewnątrz sandboxa

The sandbox blocked your last command. Do not ask for wider access yet. Explain what
the command needed from outside the workspace, then propose a way to reach the same
result inside this repository: a local config file, a project-level dependency, or a
script under scripts/. Only if no such path exists, tell me the single narrowest
permission you need and why.

Napraw nieudane polecenie Codex

Nieudane polecenie to najczęstszy błąd Codex i najłatwiejszy do naprawienia. Codex zwykle sam czyta wynik błędu i próbuje ponownie.

1. Daj Codex jedną próbę. Codex czyta kod wyjścia i komunikat błędu, a literówkę albo brakujący import często poprawia bez pomocy. Wkrocz, jeśli druga próba powtarza pierwszą.

2. Przeczytaj pierwszy błąd samodzielnie. Ważna jest zwykle pierwsza linia, nie ostatnia. Kaskada 40 błędów typów często bierze się z jednego złego importu.

3. Uzupełnij brakujący fakt. Codex zgadywał menedżer pakietów, polecenie testów albo stan bazy danych. Powiedz mu to w jednym zdaniu, z dokładnym poleceniem.

4. Zapisz ten fakt. Dodaj właściwe polecenia builda, testów i lintera do AGENTS.md, żeby następna sesja zaczynała od nich. Trzymaj je blisko początku pliku: Codex czyta najwyżej project_doc_max_bytes instrukcji projektu (domyślnie 32 KiB w 0.157.1). Układ pliku pokazuje strona AGENTS.md dla Codex.

Prompt do skopiowania: napraw przyczynę, nie objaw

The last command failed. Do not re-run it unchanged. Quote the first error line,
state the root cause in one sentence, and fix that cause rather than silencing the
error: no type casts, no @ts-ignore, no skipped or deleted tests. Then re-run the same
command and paste its exit code and summary line.

Jeśli polecenie pada, bo brakuje usługi (bazy danych, kolejki, lokalnego API), poprawka leży poza Codex. Uruchom usługę albo każ Codex użyć dublera testowego, który projekt już ma. Do systematycznego tropienia prawdziwego błędu służy strona debugowanie i polowanie na błędy z Codex.

Cofnij zmianę w złym kierunku

Zmiana w złym kierunku kosztuje najwięcej, bo nic nie świeci się na czerwono. Codex użył Express w serwisie na Fastify albo dodał endpoint REST tam, gdzie projekt używa GraphQL. Łap to wcześnie: obserwuj kilka pierwszych edycji i naciśnij Esc, gdy tylko kierunek wygląda źle. Codex przerywa turę i prosi, żebyś napisał modelowi, co ma zrobić inaczej.

Potem zdecyduj, jak daleko się cofnąć:

Zmień kierunek w miejscu

Jeśli dotychczasowe edycje w większości się nadają, skoryguj kurs i pozwól Codex posprzątać:

Stop. This service uses Fastify, not Express (see package.json and src/server.ts).
Remove the Express code you added, re-implement the route with Fastify's route
handler pattern, and list every file you changed.

Przewiń rozmowę

Naciśnij Esc dwa razy przy pustym polu wpisywania, żeby przeglądać wcześniejsze prompty. Strzałkami wybierz jeden i naciśnij Enter. Codex cofa wątek do chwili sprzed tego promptu i wstawia go z powrotem do pola wpisywania, więc możesz go przepisać z brakującym ograniczeniem.

Przewinięcie zmienia rozmowę, nie twoje pliki. Uruchom potem /diff: jeśli edycje z porzuconych tur nadal tam są, przywróć pliki Gitem.

Przywróć pliki Gitem

W terminalu wybierz szczegółowość:

git diff --stat                            # what changed since the checkpoint
git restore -p src/                        # discard chosen hunks interactively
git restore src/routes/ src/server.ts      # discard whole files
git stash push -u -m "codex: express attempt"   # set the whole attempt aside, recoverably

Wybieraj git stash zamiast git reset --hard: stash zachowuje nieudaną próbę razem z nowymi, nieśledzonymi plikami, na wypadek gdyby jakaś jej część była warta zachowania. git reset --hard trwale odrzuca zmiany w śledzonych plikach, a nowe pliki zostawia na miejscu.

Prompt do skopiowania: zacznij od nowa z brakującym ograniczeniem

Your last change solved the wrong problem, and I have reverted it. What I need: the
/invoices endpoint returns 404 instead of 500 when the invoice does not exist, with no
change to the response shape for existing invoices. Constraints: change only files
under src/invoices/, use the existing NotFoundError class, and add one test for the
missing-invoice case. Reply with your plan first and wait for my "go".

Uratuj długi wątek, który się pogubił

Długie wątki psują się po cichu. Gdy rozmowa zbliża się do limitu tokenów, Codex automatycznie kompaktuje starszą historię (próg ustawia model_auto_compact_token_limit w config.toml). Streszczenie po kompakcji może zgubić decyzję sprzed godziny. Objawy to powtarzana praca, ponownie otwierane decyzje i ignorowane ograniczenia.

1. Sprawdź liczby. /status pokazuje bieżącą konfigurację sesji i zużycie tokenów.

2. Kompaktuj na własnych warunkach. Uruchom /compact w naturalnym momencie, na przykład gdy funkcja przejdzie testy, zamiast czekać, aż automatyczna kompakcja trafi w środek zadania.

3. Przekaż pracę do nowego wątku, gdy kompakcja nie wystarcza. Poproś Codex o zapisanie stanu do pliku (prompt poniżej), uruchom /new i zacznij nowy wątek od tego pliku.

4. Rozgałęź zamiast nadpisywać. Żeby wypróbować alternatywę bez utraty bieżącego wątku, użyj /fork albo z powłoki codex fork --last. Żeby wrócić do wczorajszej sesji, uruchom codex resume --last.

Prompt do skopiowania: przekaż długi wątek

Write docs/handoff.md for a fresh session that has none of this conversation. Include:
the goal in one sentence; decisions made and why; files changed; commands that prove
the current state (test, type check) with their last result; what is left, as a
numbered list; and any constraint I gave you that is not in AGENTS.md. Keep it under
60 lines. Do not change any other file.

Po /new zacznij nowy wątek od: Read docs/handoff.md and AGENTS.md, summarise what you understand in five bullets, and wait for my go before you continue.

Wzorce, które od początku utrzymują wątki krótkie, opisuje strona zarządzanie kontekstem na powierzchniach Codex.

Napraw awarie MCP, sieci i logowania

Awarie połączenia zatrzymują zadanie bez jasnego komunikatu, więc zanim obwinisz model, sprawdź połączenia i konfigurację.

Serwer MCP

W terminalu:

codex mcp list            # every configured server
codex mcp get sentry      # one server's full definition

W sesji /mcp verbose pokazuje, jakie narzędzia każdy serwer faktycznie udostępnił. Powolny serwer to często limit czasu, a nie awaria. Podnieś limity albo wyłącz serwer bez usuwania konfiguracji w ~/.codex/config.toml:

[mcp_servers.sentry]
startup_timeout_sec = 30
tool_timeout_sec = 120
# enabled = false         # switch the server off and keep working without it

W uruchomieniach skryptowych required = true sprawia, że codex exec kończy się błędem, gdy ten serwer nie wystartuje, zamiast pracować dalej bez niego. Szczegóły konfiguracji są na stronie serwery MCP w Codex.

Logowanie i instalacja

codex login status        # are you signed in, and how
codex doctor              # install, config, auth and runtime health
codex login               # sign in again

codex doctor --json wypisuje raport z ukrytymi danymi wrażliwymi, który możesz dołączyć do zgłoszenia błędu. Metody logowania i użycie klucza API opisuje strona uwierzytelnianie Codex.

Zawieszone zapytanie do modelu

Jeśli Codex przestaje generować odpowiedź, naciśnij Esc, żeby przerwać turę, i wyślij krótką kontynuację, na przykład „continue from where you stopped”. Jeśli zawieszenia się powtarzają, uruchom codex doctor i sprawdź /warnings, gdzie są zachowane szczegóły diagnostyczne, zanim zrestartujesz sesję.

Przerwij pętlę błędów

Najgorsza awaria łączy dwie inne: Codex naprawia błąd, poprawka powoduje nowy, a każda runda oddala kod od działającego stanu. Kolejne tury tylko pogarszają sprawę, bo każda nieudana próba zostaje w kontekście.

1. Zatrzymaj pętlę. Naciśnij Esc w CLI albo zatrzymaj zadanie na powierzchni, której używasz.

2. Wróć do stanu sprzed pętli. Przywróć pliki do checkpointu Gitem albo odłóż próbę przez git stash. Potem uruchom /new, żeby nieudane próby zniknęły z kontekstu.

3. Znajdź pierwszy błąd. Przeczytaj błąd, od którego zaczęła się pętla, a nie ostatni.

4. Zacznij od nowa, w małym i ogrodzonym zakresie. Podaj Codex pierwotny błąd, podejście, które zawiodło, podejście, które ma zastosować, i granicę plików (prompt poniżej).

5. Weryfikuj po każdym kroku. Podziel pracę na dwa lub trzy zadania i uruchamiaj testy po każdym z nich, zanim zaczniesz następne.

Prompt do skopiowania: przerwij pętlę błędów

A previous attempt at this failed in a loop. The original error was:
TypeError: Cannot read properties of undefined (reading 'userId') at src/auth/session.ts:42
The earlier fix added optional chaining everywhere and broke three tests. Do not do
that. Find where the session object is created without a user, fix it there, and
change only files under src/auth/. After the change, run the auth tests and paste
the summary. If they fail, stop and report instead of trying again.

Jak udowodnić, że naprawiona zmiana jest poprawna?

Uratowana sesja wydaje się skończona, zanim naprawdę jest. Podsumowanie Codex („all tests pass”) to twierdzenie, nie dowód. Trzy kontrole potwierdzają wynik bez czytania linia po linii:

1. Zakres. Uruchom /diff albo git diff --stat i porównaj listę plików z planem. Plik spoza planu to albo pozostałość po nieudanej próbie, albo nowy zakres. Wyjaśnij go albo cofnij.
2. Bramki. Uruchom samodzielnie, we własnym terminalu, polecenia testów, sprawdzania typów i lintera z projektu i sprawdź kody wyjścia. Zwróć uwagę na testy usunięte, pominięte albo osłabione podczas odzyskiwania.
3. Niezależny przegląd. Uruchom /review albo codex review --uncommitted, żeby dostać osobny przegląd zmiany w trybie tylko do odczytu, a potem oceń jego uwagi. Całą pętlę opisuje strona przegląd zmian Codex przed commitem.

Zatwierdzasz ty, nie Codex. Commituj dopiero, gdy wszystkie trzy kontrole są czyste, i zachowaj commit z checkpointem, dopóki zmiana nie zostanie zmergowana.

Gdy samo odzyskiwanie w Codex zawodzi

Przewinięcie zadziałało, ale pliki nadal pokazują złą zmianę. Cofanie przewija wątek, a nie drzewo robocze. Przywróć pliki Gitem, jak w sekcji Cofnij zmianę w złym kierunku.

Podwójne Esc nie otwiera wcześniejszych promptów. Codex nie może cofnąć wątku w trakcie tury: najpierw ją przerwij, potem spróbuj ponownie. W rozmowie pobocznej edycja wcześniejszych promptów jest niedostępna. Wróć do głównego wątku.

Codex wciąż ignoruje twoją korektę. Instrukcja podana późno w długim wątku konkuruje ze wszystkim, co było wcześniej. Zacznij nowy wątek przez /new i umieść wszystkie ograniczenia w pierwszej wiadomości albo dopisz ograniczenie do AGENTS.md, żeby każdy wątek od niego zaczynał.

Nie ma checkpointu w Git. Jeśli w repozytorium są niezacommitowane zmiany sprzed zadania, nie uruchamiaj git restore na wszystkim. Użyj git restore -p, żeby odrzucić tylko fragmenty napisane przez Codex, i oceniaj każdy fragment, gdy się pojawi.

Zadanie w chmurze Codex dało zły diff. Zadanie w chmurze działa we własnym środowisku, więc twój checkout pozostaje bez zmian, dopóki nie zastosujesz diffa przez codex apply <id-zadania> albo nie zmergujesz pull requesta. Nie rób ani jednego, ani drugiego. Zamknij pull request, popraw prompt lub środowisko i uruchom nowe zadanie. Konfigurację środowiska opisuje strona środowiska chmurowe Codex.

Ta sama awaria powtarza się w każdej sesji. Poprawka należy do konfiguracji, a nie do kolejnego promptu: polecenie w AGENTS.md, uprawnienie w config.toml albo limit czasu serwera MCP.

Dokąd dalej po szybkim starcie z Codex

Ta strona zamyka szybki start z Codex. Umiesz już zainstalować Codex, zalogować się, skonfigurować go, napisać AGENTS.md, podłączyć serwery MCP, uruchamiać i przeglądać zadania oraz wychodzić z ich awarii.

Przegląd zmian Codex przed commitem Pętla bramek i przeglądu, która decyduje, czy zmiana trafia do repozytorium.

Debugowanie i polowanie na błędy z Codex Odtwórz, wyizoluj i napraw prawdziwe błędy, zaczynając od padającego testu.

Izolowane zadania Codex w Git worktrees Uruchamiaj ryzykowną lub równoległą pracę tam, gdzie nieudana próba kosztuje jeden katalog.

Odzyskiwanie po błędach w Claude Code Te same typy awarii w Claude Code, gdzie checkpointy i /rewind przywracają pliki.