# Wykonaj swoje pierwsze zadanie w Codex

URL: https://developertoolkit.ai/pl/codex/quick-start/first-task/
Description: Pierwsze prawdziwe zadanie w Codex od początku do końca: zadanie do udowodnienia testem, prompt z kryteriami, CLI lub chmura i weryfikacja diffa.

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](/pl/codex/quick-start/installation/), 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ę](/pl/codex/quick-start/installation/) i [uwierzytelnianie](/pl/codex/quick-start/authentication/).

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

   ```bash
   git status --short        # should print nothing
   ```

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](/pl/codex/quick-start/agents-md/) 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**

```text
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**

```text
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:

   ```bash
   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.1 Sol jest domyślnym modelem Codex od codex-cli 0.159.1 (2026-09-29), 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](/pl/ecosystem/models/).

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](/pl/codex/quick-start/error-recovery/).

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:

```bash
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:

```text
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](/pl/codex/quick-start/configuration/), a `codex exec` szczegółowo omawia strona o [uruchamianiu Codex bez interakcji](/pl/codex/automate/non-interactive/).

## 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](/pl/codex/build/app-mastery/).

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](/pl/codex/quick-start/installation/)), 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](/pl/codex/automate/cloud-environments/). Potem uruchom zadanie z [chatgpt.com/codex](https://chatgpt.com/codex) albo z terminala. W wersji 0.157.1 `codex cloud` ma status eksperymentalny:

```bash
codex cloud exec --env ENV_ID "$(cat first-task-prompt.txt)"
codex cloud list                 # find the task id and its status
codex cloud diff TASK_ID         # read the diff locally
codex cloud apply TASK_ID        # apply it to your working tree
```

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:

   ```bash
   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:

   ```bash
   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ść:

   ```bash
   git stash push -- src/routes/orders.ts   # the fixed source file, not the test
   npm test -- orders                       # expect a failure
   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:

   ```bash
   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](/pl/codex/quick-start/review-workflow/).

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**

```text
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](/pl/codex/quick-start/github-integration/) |

## 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](/pl/codex/quick-start/error-recovery/) |
| 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 |

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](/pl/codex/quick-start/agents-md/) — 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](/pl/codex/quick-start/review-workflow/) — Oceń uwagi z przeglądu, zostaw tylko dobre hunki i commituj na podstawie dowodów.
- [Izolowane zadania Codex w Git worktrees](/pl/codex/automate/worktrees/) — Uruchamiaj kilka zadań naraz tak, żeby nie dotykały ani siebie nawzajem, ani głównej kopii roboczej.
- [Zbuduj pierwszą funkcję z Claude Code](/pl/claude-code/quick-start/development-workflow/) — 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ć](/pl/workflows/test/protect-the-oracle/) — Nie pozwól agentowi edytować testów, które oceniają jego pracę.