Wykonaj swoje pierwsze zadanie w Codex

Pierwsze zadanie w Codex to jedna mała, prawdziwa zmiana, której skuteczność da się udowodnić testem: Codex czyta repozytorium, edytuje pliki w swojej piaskownicy, uruchamia polecenie testowe projektu i raportuje, co zrobił. Punktem odniesienia jest Codex CLI. Aplikacja desktopowa, rozszerzenie IDE i Codex cloud uruchamiają tego samego agenta z inną izolacją i innym przeglądem.

Ta strona jest dla programistów, którzy mają już zainstalowany Codex, są zalogowani i patrzą na puste pole promptu. Kuszący pierwszy prompt to „zrefaktoryzuj moduł auth”, a jego wynik to diff na 14 plików, którego nie da się ocenić. Lepsze pierwsze zadanie kończy się testem, który bez zmiany pada, a ze zmianą przechodzi. Wtedy akceptujesz wynik na podstawie dowodu, a nie czytania każdej linii.

Co daje ci pierwsze zadanie w Codex

• Listę kontrolną do wyboru pierwszego zadania, które da się udowodnić testem.
• Prompt na pierwsze zadanie z kryteriami akceptacji, punktem kontrolnym planu i formatem raportu, plus wariant dla repozytoriów bez warstwy HTTP.
• Dokładne polecenia Codex CLI 0.157.1 do uruchomienia zadania interaktywnie, w worktree Gita, bez interfejsu i w Codex cloud.
• Pięciominutową procedurę weryfikacji, łącznie z kontrolą, czy nowy test w ogóle potrafi paść.
• Sposoby wyjścia z sytuacji, w których pierwsze zadanie zwykle się sypie.

Zanim zaczniesz: co musi być gotowe

1. Codex działa, a ty jesteś zalogowany. codex doctor nie zgłasza błędów. Jeśli zgłasza, najpierw przejdź przez instalację i uwierzytelnianie.

2. Drzewo robocze jest czyste. Codex edytuje prawdziwe pliki, a Git jest twoim „cofnij”. Zacommituj albo odłóż do stasha wszystko, nad czym pracujesz:

   git status --short        # nie powinno nic wypisać

3. Znasz polecenie testowe projektu i dziś przechodzi. Uruchom je raz samodzielnie. Jeśli zestaw testów już jest czerwony, Codex nie pokaże ci, że zrobił go zielonym.

4. Opcjonalnie, ale warto: AGENTS.md. Uruchom /init w Codex, żeby wygenerować szkic, a potem ręcznie popraw polecenie testowe i układ katalogów. Konfiguracja AGENTS.md w Codex wyjaśnia, co w nim umieścić. Od codex-cli 0.150.0 projekt, który nie jest oznaczony jako zaufany, nie dostarcza swojego AGENTS.md, więc odpowiedz na pytanie o zaufanie, gdy Codex pierwszy raz otworzy repozytorium.

Wybierz pierwsze zadanie, które udowodni test

Najlepsze pierwsze zadanie ma jedno obserwowalne zachowanie, dotyka od jednego do trzech plików i ma istniejący runner testów, który je potwierdzi. Dzięki temu diff jest na tyle mały, że sprawdzisz go w kilka minut, a sygnał jest obiektywny.

Dobre pierwsze zadanie	Słabe pierwsze zadanie	Dlaczego
Uzupełnij brakującą ścieżkę błędu w jednej trasie API i dodaj do niej test	„Popraw obsługę błędów wszędzie”	Jedno zachowanie, jeden test; szeroka wersja nie ma mety
Obsłuż przypadek brzegowy w czystej funkcji (pusta lista, null, strefa czasowa)	Przenieś projekt na nowy framework	Czystą funkcję da się przetestować w izolacji; migracja wymaga najpierw planu
Dodaj walidację wejścia do jednego endpointu z testem na 400	Przeprojektuj schemat bazy danych	Walidację łatwo cofnąć; zmiana schematu wymaga migracji i przeglądu
Dodaj brakujący test dla nieprzetestowanej gałęzi	„Przyspiesz testy”	„Szybciej” nie ma kryterium akceptacji

Przykład poniżej opiera się na pierwszym wierszu i przechodzi przez wszystko, co pierwsze zadanie powinno przećwiczyć: czytanie kodu, znalezienie konkretnego defektu, edycję kodu, napisanie testu i uruchamianie poleceń w piaskownicy.

Napisz prompt: rezultat, ograniczenia i dowód

Prompt na pierwsze zadanie określa rezultat, zawęża zakres i mówi, jaki dowód kończy zadanie. Punkt kontrolny planu w poniższym prompcie kosztuje jedną dodatkową turę i wyłapuje zły kierunek, póki jest jeszcze akapitem tekstu.

Prompt do skopiowania: napraw jedną lukę w obsłudze błędów z testem

Find one error-handling gap in this project's API routes: a place where an
exception can crash the request handler or return a misleading status code.

Before you edit anything, reply with: the file and line, an input that triggers
the problem, the fix you propose, and the test you will add. Wait for me to reply "go".

After I reply "go":
1. Write the test first and run it. It must fail for the reason you described.
2. Make the smallest fix that makes it pass. Touch at most 3 files.
3. Do not modify, skip, or delete any existing test.
4. Run the full test suite.

Finish with: files changed, each command you ran with its exit code, and the name
of the new test.

Jeśli projekt nie ma warstwy HTTP, skieruj tę samą strukturę na czystą funkcję. Kształt się nie zmienia: znajdź, zaproponuj, czekaj, najpierw test, poprawka, raport.

Prompt do skopiowania: obsłuż przypadek brzegowy w czystej funkcji

Find one function in src/ that returns a wrong result or throws on an edge case:
an empty collection, a null or undefined argument, a zero, or a date near a
daylight-saving change. Show me the input, the current output, and the expected
output before you change anything, and wait for "go".

After "go": add a failing test for that input, fix the function with the smallest
change, keep every existing test untouched, and run the whole suite. Report the
files changed and each command with its exit code.

Uruchom zadanie w Codex CLI

CLI pokazuje na bieżąco każdy odczytany plik, każde polecenie i każdą prośbę o zgodę, więc najlepiej widać w nim, co robi agent przy pierwszym zadaniu.

1. W katalogu głównym repozytorium uruchom Codex w nowym, zarządzanym worktree Gita, żeby zmiana nie dotknęła twojej głównej kopii roboczej:

   codex --worktree

   Samo codex też działa i edytuje bieżącą kopię roboczą. Z --worktree zmiana trafia do tego worktree, a nie do katalogu, z którego startujesz, więc kontrole z sekcji weryfikacji uruchamiaj w nim: git worktree list w głównej kopii roboczej wypisuje jego ścieżkę. W obu przypadkach, gdy uznasz repozytorium za zaufane i o ile twoja konfiguracja nie mówi inaczej, Codex działa z polityką zatwierdzania on-request i piaskownicą workspace-write: może edytować pliki i uruchamiać polecenia w obrębie workspace, a pyta, zanim zapisze coś poza nim albo sięgnie do sieci.

2. Na razie nie zmieniaj modelu. GPT-6 Astra jest domyślnym modelem Codex od codex-cli 0.153.4 (2026-09-04), a jego domyślny poziom rozumowania w Codex to low. Jeśli plan z kroku 4 okaże się płytki, podnieś poziom do medium albo high przez /model, zanim w ogóle rozważysz inny model. Kiedy inny model jest wart zmiany, opisuje przegląd modeli.

3. Wklej prompt na pierwsze zadanie i naciśnij Enter.

4. Przeczytaj plan. Sprawdź, czy plik i linia istnieją, czy wejście wywołujące błąd jest wiarygodne i czy proponowany test naprawdę używa tego wejścia. Jeśli którykolwiek z tych trzech punktów jest mglisty, dopytaj, zanim odpowiesz go.

5. Na prośby o zgodę odpowiadaj świadomie. Prośba o dostęp do sieci albo zapis poza repozytorium przy małej poprawce zwykle znaczy, że podejście jest złe, więc odmów i wskaż inny kierunek. Każdą opcję zatwierdzania wyjaśnia strona Wychodzenie z błędów Codex.

6. Gdy Codex zaraportuje wynik, sprawdź go bez wychodzenia z sesji:

   • /diff pokazuje diff Gita, łącznie z nieśledzonymi plikami.
   • /review uruchamia osobny przegląd bieżących zmian i wypisuje znalezione problemy.

Żeby zautomatyzować to samo zadanie, na przykład powtórzyć je w kilku serwisach, użyj codex exec. Działa bez interaktywnego interfejsu i zapisuje końcowy raport do pliku:

codex exec --sandbox workspace-write -o first-task-report.md "$(cat first-task-prompt.txt)"

first-task-prompt.txt zawiera prompt bez kroku „czekaj na go”, bo w przebiegu bez interfejsu nikt nie odpowie, a przez pomyłkę pozostawiony punkt kontrolny planu zatrzyma przebieg. Wariant bez interfejsu zastępuje ten akapit poleceniem, by przedstawić dowody i pracować dalej:

Find one error-handling gap in this project's API routes: a place where an
exception can crash the request handler or return a misleading status code.

State the file and line, an input that triggers the problem, the fix you
propose, and the test you will add first, then proceed:
1. Write the test first and run it. It must fail for the reason you described.
2. Make the smallest fix that makes it pass. Touch at most 3 files.
3. Do not modify, skip, or delete any existing test.
4. Run the full test suite.

Finish with: files changed, each command you ran with its exit code, and the name
of the new test.

-o (--output-last-message) zapisuje ostatnią wiadomość, a --json strumieniuje każde zdarzenie jako JSONL, jeśli chcesz parsować przebieg. Jeśli twój config.toml wybiera już profil uprawnień przez default_permissions, pomiń --sandbox: według OpenAI profile i starszy system piaskownicy „do not compose”, czyli nie łączą się. Oba opisuje Konfiguracja Codex, a codex exec szczegółowo omawia strona o uruchamianiu Codex bez interakcji.

Uruchom to samo zadanie w aplikacji, IDE lub Codex cloud

Na każdej powierzchni działa ten sam agent. Zmienia się to, gdzie pracuje, jak go obserwujesz i gdzie przeglądasz diff.

Aplikacja desktopowa

Na macOS i Windows codex app uruchamia aplikację desktopową, a jeśli jej brakuje, otwiera instalator. Z działającej sesji CLI polecenie /app przenosi tę sesję do aplikacji. Aplikacja nie ma wersji na Linuksa.

Otwórz projekt, rozpocznij wątek i wklej ten sam prompt. Sięgnij po aplikację, gdy chcesz prowadzić kilka wątków obok siebie w osobnych worktree i mieć panel przeglądu dla każdego diffa. Wątki, worktree i panel przeglądu opisuje strona o aplikacji desktopowej Codex.

README OpenAI nadal nazywa ją Codex App; od 2026-07-09 jest dostarczana jako tryb Codex w aplikacji desktopowej ChatGPT, według serwisu Neowin (źródło wtórne).

Rozszerzenie IDE

Otwórz projekt w VS Code albo Cursorze z zainstalowanym rozszerzeniem Codex (obsługiwane edytory opisuje instalacja), otwórz panel Codex i wklej prompt.

Wybierz IDE, gdy zadanie dotyczy tego, co masz na ekranie: najpierw zaznacz handler trasy i napisz w prompcie „the selected handler”. W CLI polecenie /ide wciąga do sesji terminalowej bieżące zaznaczenie, otwarte pliki i inny kontekst z edytora. Wynik przejrzyj w widoku diffa kontroli wersji w edytorze, a potem w terminalu przejdź procedurę weryfikacji opisaną niżej.

Codex cloud

Codex cloud wykonuje zadanie w zdalnym kontenerze na kopii repozytorium, więc praca trwa, nawet gdy laptop śpi. Najpierw potrzebne jest środowisko chmurowe z zainstalowanymi zależnościami; konfigurację krok po kroku opisuje strona Środowiska Codex cloud. Potem uruchom zadanie z chatgpt.com/codex albo z terminala. W wersji 0.157.1 codex cloud ma status eksperymentalny:

codex cloud exec --env ENV_ID "$(cat first-task-prompt.txt)"
codex cloud list                 # znajdź id zadania i jego status
codex cloud diff TASK_ID         # przeczytaj diff lokalnie
codex cloud apply TASK_ID        # zastosuj go w kopii roboczej

Codex cloud pracuje na gałęzi w takim stanie, w jakim jest na zdalnym repozytorium: domyślnie na bieżącej, albo na tej, którą podasz przez --branch. Lokalnych commitów, których nie wypchnięto, w zadaniu nie ma, więc najpierw zrób push.

Zamień ENV_ID na identyfikator środowiska, który pokazuje codex cloud, a TASK_ID na identyfikator z codex cloud list. Dodaj --attempts 2 do exec, żeby dostać dwie niezależne próby i zostawić lepszą. Porównaj je przez codex cloud diff TASK_ID --attempt 2 i zastosuj wybraną przez codex cloud apply TASK_ID --attempt N. Po zastosowaniu zmiana z chmury przechodzi dokładnie te same lokalne kontrole co praca z CLI.

Zweryfikuj wynik bez czytania każdej linii

Podsumowanie Codex to twierdzenie, nie dowód. Te pięć kontroli zajmuje około pięciu minut i mówi ci, gdzie w ogóle potrzebna jest twoja lektura. Akceptację podpisujesz ty; kontrole decydują, na co patrzysz. Jeśli sesja ruszyła z --worktree, uruchamiaj je w tym worktree (git worktree list wypisuje jego ścieżkę) albo zacznij od /diff w sesji.

1. Sprawdź zakres. Diff powinien odpowiadać zatwierdzonemu planowi:

   git status --short
   git diff --stat

   Plik spoza planu czytasz jako pierwszy.

2. Sprawdź, czy żaden istniejący test nie został osłabiony. Dopasuj ścieżkę do swojego katalogu testów:

   git status --short -- tests/

   git status, a nie git diff, bo git diff pomija nieśledzone pliki i nowy plik testowy nigdy by się nie pokazał. Powinien pojawić się tylko nowy test, jako ?? (nowy plik) albo M (test dopisany do istniejącego pliku). M albo D przy jakimkolwiek innym pliku testowym to sygnał alarmowy. Usunięta, pominięta albo poluzowana asercja to sposób, w jaki agent zamienia czerwony zestaw testów w zielony, i nigdy nie widać tego w podsumowaniu „testy przechodzą”.

3. Udowodnij, że nowy test potrafi paść. Tymczasowo usuń poprawkę, zostaw test i uruchom go. Musi paść:

   git stash push -- src/routes/orders.ts   # poprawiony plik źródłowy, nie test
   npm test -- orders                       # oczekiwany błąd
   git stash pop

   Zamień ścieżkę i filtr testów na własne. Jeśli poprawka jest w pliku utworzonym przez Codex, użyj git stash push -u -- <ścieżka>, bo zwykły stash pomija nieśledzone pliki. Test, który przechodzi bez poprawki, niczego nie dowodzi, więc odeślij go do poprawy.

4. Sam uruchom bramki jakości. W swoim terminalu, nie w podsumowaniu Codex: pełny zestaw testów, sprawdzanie typów i linter, na przykład npm test && npm run typecheck && npm run lint.

5. Uruchom przegląd. Użyj /review w sesji albo z powłoki:

   codex review --uncommitted

   Każdą istotną uwagę napraw albo obal. Ocenę uwag i zostawianie tylko dobrych hunków opisuje strona Przegląd zmian Codex przed commitem.

Jeśli wolisz, żeby kontrolę 3 wykonał Codex i pokazał ci wynik, poproś o to wprost:

Prompt do skopiowania: udowodnij, że nowy test jest prawdziwym testem

Prove the test you added is a real oracle. Temporarily revert only your fix in the
source file, keep the test, and run that test: show me the failing output. Then
restore the fix, run the test again, and show it passing. Finally run
`git diff --stat` and confirm that no other test file changed.

Przeczytaj wynik z błędem samodzielnie. Test powinien paść na asercji, której się spodziewasz, a nie na błędzie importu czy literówce.

Która powierzchnia Codex pasuje do którego zadania?

Po pierwszym zadaniu wybieraj powierzchnię według tego, jak długo zadanie trwa i jak chcesz je przejrzeć, a nie z przyzwyczajenia.

Zadanie	Powierzchnia	Dlaczego
Mała poprawka, którą chcesz obserwować	CLI albo rozszerzenie IDE	Każde polecenie i każda zgoda są widoczne na bieżąco
Zmiana w wielu plikach, którą możesz wyrzucić	CLI z --worktree albo aplikacja desktopowa	Worktree trzyma główną kopię roboczą w czystości; usunięcie go to „cofnij”
Długa praca albo kilka prób do porównania	Codex cloud	Działa zdalnie; --attempts daje niezależne próby do wyboru
To samo zadanie w wielu repozytoriach albo w CI	codex exec	Skryptowalne, z końcowym raportem zapisanym do pliku
Druga opinia o pull requeście	@codex review na GitHubie	Przegląd tam, gdzie zespół już pracuje; zobacz integrację z GitHubem

Co psuje się przy pierwszym zadaniu w Codex?

Objaw	Prawdopodobna przyczyna	Co zrobić
Codex zgłasza lukę, której nie umiesz odtworzyć	Plan przyjęto bez dowodu	Zażądaj wejścia wywołującego błąd w postaci padającego testu przed jakąkolwiek poprawką; odrzuć lukę, której nie potrafi pokazać
Nowy test przechodzi po usunięciu poprawki	Test nie dotyka defektu	Wyślij powyższy prompt o „prawdziwym teście”; nie scalaj, dopóki test nie pada bez poprawki
Istniejące testy zmieniły się albo zniknęły	Codex zazielenił zestaw, osłabiając go	git restore -- tests/, potem powtórz regułę 3 z promptu; dopisz do AGENTS.md „never modify existing tests without asking”
Codex uruchamia złe polecenie testowe	Brak AGENTS.md albo zgadywanie	Wpisz dokładne polecenie do AGENTS.md; zacznij nową sesję, żeby plik się wczytał
Instalacja pakietu albo pobieranie pada	Piaskownica domyślnie blokuje sieć	To piaskownica działa zgodnie z założeniem. Zainstaluj zależność samodzielnie albo przyznaj najwęższy dostęp opisany w wychodzeniu z błędów
Diff rozlewa się na wiele plików	Zadanie było za szerokie	Odrzuć zmiany (git restore . albo usuń worktree) i uruchom ponownie z limitem plików albo mniejszym zadaniem
Codex powtarza tę samą nieudaną poprawkę	Zapętlił się na jednej hipotezie	Naciśnij Esc, żeby przerwać turę, potem poproś o trzy różne hipotezy, każdą z kontrolą, która je rozróżni

Uwaga

Nie sięgaj po --dangerously-bypass-approvals-and-sandbox, żeby ominąć prośbę o zgodę przy pierwszym zadaniu. Ta flaga wyłącza jednocześnie zatwierdzanie i piaskownicę i jest przeznaczona wyłącznie do jednorazowych środowisk z ograniczoną siecią, takich jak kontener do wyrzucenia.

Dokąd iść po pierwszym zadaniu w Codex

Konfiguracja AGENTS.md w Codex Przekaż Codex polecenie testowe, układ katalogów i reguły, żeby kolejne zadanie zaczynało się od faktów, a nie domysłów.

Przegląd zmian Codex przed commitem Oceń uwagi z przeglądu, zostaw tylko dobre hunki i commituj na podstawie dowodów.

Izolowane zadania Codex w Git worktrees Uruchamiaj kilka zadań naraz tak, żeby nie dotykały ani siebie nawzajem, ani głównej kopii roboczej.

Zbuduj pierwszą funkcję z Claude Code To samo pierwsze zadanie zaczynane od testu, tym razem w Claude Code: kryteria akceptacji, tryb planowania i przegląd w świeżym kontekście.

Ochrona wyroczni: testy, których agent nie może zmienić Nie pozwól agentowi edytować testów, które oceniają jego pracę.