Codex worktree: osobna kopia robocza do drugiego zadania

Na przykład używasz Codex CLI do refaktoryzacji jednego modułu, gdy pojawia się drugie zadanie: napisanie testów dla innego modułu. Otwarcie drugiej sesji w tym samym folderze jest ryzykowne: łatwo pomylić zmiany z pierwszego i drugiego zadania. Flaga --worktree tworzy osobny folder tego samego projektu na potrzeby drugiego zadania, pozostawiając pierwszy bez zmian.

Praktyczne materiały o równoległej pracy z agentami: dokumentacja Ailoot.

Co tworzy --worktree i jakie pliki trafiają do kopii#

W terminologii Gita worktree to dodatkowy folder roboczy powiązany z tym samym repozytorium: współdzieli historię commitów, ale ma własny zestaw plików na dysku. W Codex CLI 0.155.1 flaga --worktree wykorzystuje ten mechanizm Gita, aby uruchomić nową sesję agenta w osobnym folderze, pozostawiając bez zmian folder, w którym trwa już pierwsze zadanie.

Nowa kopia robocza zawiera pliki z commita, na który wskazuje HEAD oryginalnego projektu w chwili uruchomienia — z najnowszego commita, a nie z momentu ostatniego zapisania pliku w edytorze. To polecenie nie przenosi niezatwierdzonych zmian ani nowych plików. Zapisanie pliku w edytorze to nie to samo co zatwierdzenie go w Gicie. Jeśli w chwili uruchomienia drugiego zadania w pierwszym folderze nadal są niezatwierdzone zmiany, pozostaną one tylko w tym folderze.

Nie jest to kopia zapasowa całego repozytorium ani izolacja całego komputera. To drugi folder roboczy tego samego projektu, z dostępem do tej samej gałęzi i historii commitów. Informacje o podobnym mechanizmie w innym narzędziu znajdziesz w artykule Claude Code i git worktree: zadania równoległe.

Przygotowanie: wersja, zaufanie do projektu i commit#

Przed rozpoczęciem sprawdź trzy rzeczy. Polecenia uruchamiaj z folderu oryginalnego projektu.

Najpierw sprawdź wersję Codex CLI. Te instrukcje dotyczą wersji 0.155.1; w przypadku innych wersji osobno sprawdź działanie flag:

codex --version

Po drugie, potrzebujesz lokalnego projektu Gita, którego HEAD wskazuje istniejący commit — innymi słowy, repozytorium musi zawierać co najmniej jeden commit. W przeciwnym razie nie będzie źródła, z którego można utworzyć kopię.

Po trzecie, źródło musi być zaufane: jeśli projekt jest jawnie oznaczony jako niezaufany, uruchomienie z --worktree nie powiedzie się przed utworzeniem kopii. Jeśli dopiero konfigurujesz Codex CLI, podstawowe przygotowanie opisano w artykule Codex (OpenAI): czym jest i jak zacząć.

Wcześniej sprawdź listę istniejących kopii roboczych tego repozytorium. Po uruchomieniu możesz ją wykorzystać do porównania:

git worktree list

Osobne foldery pomagają rozdzielić zadania. Ogólne wskazówki dotyczące pracy z agentem znajdziesz w praktycznych materiałach w dokumentacji Ailoot.

Kroki: uruchomienie osobnej kopii do drugiego zadania#

1. Włącz funkcję eksperymentalną i uruchom sesję w osobnej kopii

   Uruchom polecenie z folderu oryginalnego projektu, w którym pracujesz już nad pierwszym zadaniem.

   codex --enable worktrees --worktree
   

   Oczekiwany wynik: Codex tworzy nową kopię roboczą projektu na podstawie bieżącego HEAD i otwiera w niej sesję agenta. Kopia jest w stanie detached HEAD, bez przypisanej nazwanej gałęzi. Tak działa ta flaga w wersji 0.155.1.

2. Ponownie wyświetl kopie robocze w drugim terminalu w oryginalnym projekcie

   git worktree list
   

   Oczekiwany wynik: w danych wyjściowych pojawia się dodatkowy wiersz z ścieżką nowej kopii i znacznikiem detached HEAD (albo nazwą gałęzi, jeśli jakaś jest przypisana). Lista pokazuje, że Git zarejestrował kopię, ale nie potwierdza, że agent ukończył zadanie. Aby sprawdzić, czy pliki są na miejscu, otwórz folder pod podaną ścieżką i sprawdź jego zawartość.

Jak sprawdzić wynik i zachować swoją pracę#

Po zakończeniu drugiego zadania w nowej kopii musisz osobno zapisać i przenieść wynik. Polecenie --worktree nie scala zmian z główną gałęzią ani nie przenosi wyniku automatycznie. Kopia pozostaje w stanie detached HEAD, więc sam commit utworzony w jej obrębie nie tworzy nowej gałęzi. Jeśli chcesz zachować te commity, przed usunięciem folderu kopii przypisz je do gałęzi albo przenieś do głównego projektu.

Nie usuwaj folderu kopii, dopóki wynik nie zostanie zachowany. Sprawdzenie, czy folder roboczy jest czysty, nie zastępuje zachowania potrzebnych commitów: nadal mogą nie być przypisane do żadnej gałęzi.

Jeśli jednocześnie pracujesz nad zadaniami w różnych narzędziach, zaplanuj wcześniej, jak zapobiec wzajemnemu zakłócaniu pracy. Współpraca z dwoma agentami jest opisana w artykule Claude Code i Codex razem.

Jeśli uruchamianie zostało przerwane: gdzie znaleźć kopię#

Uruchomienie z --worktree może się nie powieść z kilku powodów:

• funkcja nie została wcześniej włączona, a polecenie uruchamiające nie zawiera --enable worktrees: Codex odmówi uruchomienia z flagą --worktree;
• znajdujesz się w niewłaściwym folderze albo nie ma żadnego commita: jeśli bieżący folder nie jest repozytorium Gita lub nie zawiera jeszcze żadnych commitów, nie ma źródła, z którego można utworzyć kopię;
• projekt jest jawnie oznaczony jako niezaufane źródło: Codex odmówi uruchomienia sesji z --worktree. Najpierw upewnij się, że otwarto właściwy projekt. Nie zmieniaj automatycznie jego statusu zaufania.

Jeśli sesji nie udało się połączyć z nowo utworzoną kopią — na przykład z powodu przerwania procesu — folder roboczy nie zostanie automatycznie usunięty. Najpierw sprawdź listę kopii roboczych, a przed usunięciem czegokolwiek upewnij się, że żadna sesja Codex CLI nadal nie korzysta z tej kopii:

git worktree list

Otwórz folder i zapisz potrzebne zmiany, zanim go usuniesz. Kopia może pozostać nawet wtedy, gdy sesja agenta nie zakończyła uruchamiania. Jeśli kopia istnieje, nie jest już potrzebna i na pewno nie korzysta z niej żadna sesja, usuń ją ręcznie poleceniem git worktree remove, uruchomionym z oryginalnego repozytorium i z podaną ścieżką folderu. Nie dodawaj --force: jeśli kopia zawiera niezatwierdzone lub nieśledzone pliki, polecenie odmówi jej usunięcia. Jeśli tak się stanie, sprawdź zawartość folderu bez wyłączania zabezpieczenia.

Po aktualizacji Codex CLI ponownie sprawdź wersję poleceniem codex --version i ponów kontrolę za pomocą git worktree list: eksperymentalne flagi mogą działać różnie w różnych wersjach.

Więcej materiałów i narzędzi: Ailoot.