Aplikacja desktopowa Codex: równoległe wątki, worktrees i review

Poziom 2 Poradnik Zaktualizowano 2026-09-26

Aplikacja desktopowa Codex to graficzny klient agenta Codex na macOS i Windows: jedno okno, w którym działa kilka wątków na projekt, każdy w twoim checkoucie, w Git worktree albo w środowisku chmurowym. Aplikacja dzieli katalog ~/.codex/ z CLI i rozszerzeniem IDE. Równoległe wątki opłacają się tylko wtedy, gdy każdy kończy się bramkami, które da się sprawdzić.

Masz trzy zadania w jednej funkcji: zmianę interfejsu, testy do niej i dokumentację. W terminalu robiłbyś je po kolei albo żonglował trzema powłokami z nadzieją, że nie edytują tych samych plików. W aplikacji uruchomisz wszystkie trzy przed obiadem, ale wrócisz do trzech diffów, trzech podsumowań z „gotowe” i żadnego szybkiego sposobu, by sprawdzić, które mówi prawdę. Ta strona jest dla developera, który codziennie pracuje w aplikacji, i dla tech leada, który chce, by wątki zespołu w aplikacji trzymały ten sam poziom co praca w terminalu.

Co daje ci sprawdzalna praca równoległa w aplikacji Codex

Tabelę decyzyjną: kiedy wątek ma działać lokalnie, w worktree, a kiedy w chmurze.
Wzorzec trzech wątków dla jednej funkcji z promptami do skopiowania, które kończą się dowodami, a nie podsumowaniem.
Procedurę weryfikacji, która sprawdza każdy wątek twoimi bramkami i codex review, zanim przeczytasz choć linijkę kodu.
Kroki w Git, które przenoszą pracę z worktree na branch bez błędu „already checked out”.
Ustawienia uprawnień dla wątków i automatyzacji w aplikacji oraz sposoby wyjścia z typowych awarii.

Gdzie aplikacja desktopowa pasuje obok CLI i rozszerzenia IDE?

Wszystkie trzy klienty sterują tym samym agentem i czytają ten sam katalog domowy Codex (~/.codex/ albo CODEX_HOME), więc logowanie, config.toml, serwery MCP i skille przechodzą między nimi. Instalację i wersje opisuje strona Instalacja Codex.

Klient	Sięgnij po niego, gdy	Jak go uruchomić
Aplikacja desktopowa (macOS, Windows)	Prowadzisz kilka wątków naraz, przeglądasz diffy wizualnie, sprawdzasz UI w przeglądarce albo planujesz cykliczne zadania	`codex app` uruchamia aplikację albo otwiera instalator, jeśli jej brakuje
CLI / TUI	Potrzebujesz skryptów, `codex exec`, precyzyjnych flag albo pracujesz na Linuksie	`codex`; zobacz triki z CLI i slash commandami
Rozszerzenie IDE	Edytujesz kod i chcesz mieć Codex obok pliku	Panel Codex w VS Code lub Cursorze

Łączą je dwa mosty. W TUI /app kontynuuje bieżącą sesję w aplikacji desktopowej, a /ide pobiera z edytora bieżące zaznaczenie i otwarte pliki. codex agents przegląda sesje agentów we współdzielonym lokalnym demonie app-servera.

Aplikacja jest teraz dostarczana jako tryb Codex w aplikacji desktopowej ChatGPT, obok Chat i Work. Neowin (źródło wtórne) datuje tę zmianę na 2026-07-09. README OpenAI nadal nazywa ją Codex App, a na macOS codex app otwiera ChatGPT.app albo Codex.app — tę, która jest zainstalowana. Na Linuksa nie ma wersji: linuksowe CLI nie ma podkomendy app (sprawdzone na codex-cli 0.157.1).

Kilka możliwości aplikacji figuruje w rejestrze funkcji codex-cli 0.157.1 jako stabilne i włączone: in_app_browser, computer_use, in_app_dictation i in_app_local_automation. codex features list wypisuje ten rejestr na twojej maszynie.

Wybierz, gdzie działa każdy wątek: lokalnie, w worktree czy w chmurze

Każdy nowy wątek startuje w jednym z trzech miejsc. Ten wybór decyduje, czego wątek może dotknąć i co musisz zrobić później, by zachować jego pracę.

Uruchom wątek	Do czego	Ile cię to kosztuje
Lokalnie, w twoim checkoucie	Pytania o kod, małe poprawki w plikach, które i tak zmieniasz, praca, która musi widzieć niezacommitowane zmiany	Dwa lokalne wątki edytujące te same pliki zderzają się, a zmiany lądują w working tree bez przeglądu
W worktree, we własnym Git worktree	Funkcje, eksperymenty, które możesz wyrzucić, wszystko, co idzie równolegle	Pracę przenosisz przez Git, a każdy worktree potrzebuje własnej instalacji zależności
W chmurze, w skonfigurowanym środowisku	Długie lub ciężkie zadania, zadania wymagające czystej maszyny, próby best-of-N przy ryzykownej poprawce	Wymaga środowiska chmurowego i nie sięga do usług dostępnych tylko lokalnie

Dokumentacja worktrees OpenAI ujmuje cel w jednym zdaniu: „Worktrees let Codex run multiple independent chats in the same project without interfering with each other” (learn.chatgpt.com, odczyt 2026-08-28). Wynika z tego zasada: najwyżej jeden lokalny wątek na projekt zapisuje pliki; wszystko inne, co zapisuje, idzie do worktree albo do chmury. Mechanikę worktrees na każdej powierzchni, łącznie ze sprzątaniem, opisuje Izolowane zadania Codex w Git worktrees.

Zaczynaj wątek w worktree od czystej bazy. Worktree pobiera branch bazowy w stanie zacommitowanym, więc niezacommitowanych zmian z twojego checkoutu w nim nie ma. Jeśli wątek ich potrzebuje, najpierw zrób commit albo stash.

Poprowadź jedną funkcję jako trzy równoległe wątki

Wzorzec, który w aplikacji działa najlepiej, dzieli funkcję na implementację, testy i dokumentację. Implementacja i testy dostają po worktree na tym samym branchu bazowym; dokumentacja dostaje wątek lokalny, bo nie koliduje z kodem.

Zapisz kryteria akceptacji raz. Umieść trzy do pięciu sprawdzalnych stwierdzeń w pliku, który wątki mogą przeczytać, na przykład specs/user-id.md. Prompt każdego wątku wskazuje ten plik zamiast go powtarzać, więc trzy wątki nie rozjadą się.
Uruchom wątek implementacji w worktree. Wklej pierwszy prompt poniżej.
Uruchom wątek testów w drugim worktree na tym samym branchu bazowym. Pisze testy do kryteriów, a nie do implementacji, której jeszcze nie widzi. Tak napisane testy padają z właściwego powodu, dopóki implementacja nie trafi do kodu.
Uruchom wątek dokumentacji lokalnie. Edytuje tylko docs/, więc nie zderzy się z worktrees.
Pracuj dalej, gdy wątki działają. Zaglądaj do nich, gdy skończą albo poproszą o zgodę. Gdy wątek idzie w złą stronę, wyślij poprawkę w tym samym wątku zamiast zaczynać od nowa, bo wątek zachowuje kontekst.
Zweryfikuj, potem scal. Przejdź procedurę z następnej sekcji dla każdego worktree, przenieś oba branche i raz uruchom pełny zestaw testów na połączonym wyniku.

Implement the change described in specs/user-id.md: UserService accepts a generic ID type
instead of a numeric id. Update every direct consumer in packages/core. Do not touch tests
or docs; other threads own them.

Work in small steps. After each step run `pnpm typecheck` and fix what it reports.
When you finish, run `pnpm typecheck && pnpm lint && pnpm test --filter core` and reply with:
1. Each acceptance criterion from specs/user-id.md and the file:line that satisfies it.
2. The exact commands you ran and their final exit codes.
3. Anything you could not do, and why.
Do not say "done" if any command failed.

Write tests for the behaviour in specs/user-id.md. Follow the patterns in
tests/integration/ and reuse the fixtures in tests/fixtures/. Write one test per acceptance
criterion and name each test after the criterion it proves.

The implementation is being written in another branch, so these tests are expected to fail
now. Run them and show me that each one fails with an assertion about the missing behaviour,
not with an import error, a typo or a timeout. Do not change any file under src/.

To polecenie, by testy padały z właściwego powodu, nadaje wynikowi wątku testów wartość: test, który przechodzi, zanim powstała implementacja, niczego nie dowodzi. Po połączeniu branchy te same testy muszą przejść na zielono.

Jak zweryfikować pracę wątku bez czytania każdej linijki?

Podsumowanie wątku to deklaracja. O tym, czy zachowujesz pracę, decydują dowody, a sam czytasz tylko te linijki, których dowody nie pokrywają. Przejdź tę procedurę w każdym worktree, zanim przeniesiesz z niego pracę:

Uruchom własne bramki w katalogu wątku. Użyj tych samych poleceń co CI. Agent, który raportuje, że testy przeszły, to nie to samo co twój terminal, który to pokazuje.

# w terminalu, w worktree wątku (git worktree list wypisuje jego ścieżkę)
pnpm typecheck && pnpm lint && pnpm test
git status --short          # coś nieoczekiwanego, np. zmieniony lockfile?

Uruchom osobny przegląd. codex review --uncommitted przegląda zmiany staged, unstaged i nieśledzone z instrukcją szukania błędów, a nie bronienia kodu. Gdy praca jest już zacommitowana na branchu, użyj codex review --base main. Triaż wyników i prompty do tego przeglądu znajdziesz w Przejrzyj zmiany Codex przed commitem.
Przypisz kryteriom dowody. Każde kryterium akceptacji potrzebuje testu, który pada bez zmiany. Kryteria bez testu to linijki, które czytasz sam.
Przeglądaj diff w aplikacji, nie podsumowanie. Przejrzyj diff wątku w aplikacji. Zachowaj to, co pokrywają dowody, cofnij resztę i odpisz w wątku, co ma zmienić.

Before I merge this thread, prove it. Run `pnpm typecheck && pnpm lint && pnpm test` and paste
the last 20 lines of output. Then list every file you changed with one line on why. For each
acceptance criterion in specs/user-id.md, name the test that fails without your change, then
temporarily revert that change, run the test to show it fails, and restore it.
Flag any change you made outside packages/core.

Kto zatwierdza: developer, który uruchomił wątek, odpowiada za scalenie, a bramki i przegląd to dowody, na których opiera decyzję. Dla tech leada regułą do wpisania w AGENTS.md jest to, że żaden wątek z aplikacji nie trafia do kodu na podstawie samego podsumowania. Przewodnik po pakiecie dowodów pokazuje, jak dołączyć te dowody do pull requesta.

Przenieś pracę z worktree przez Git

Git pozwala, by branch był checkoutowany tylko w jednym worktree naraz. Jeśli wątek w worktree utworzył codex/user-id, a ty uruchomisz git switch codex/user-id w głównym checkoucie, Git odmówi z błędem „already checked out”, bo worktree wciąż trzyma ten branch. Masz dwie drogi:

Zostaw pracę na jej branchu. Zrób commit w worktree, wypchnij branch i otwórz pull request; wersja terminalowa jest poniżej. Wybierz ją, gdy możesz zweryfikować wszystko wewnątrz worktree.
Przenieś ją do swojego checkoutu. Scal albo przenieś cherry-pickiem commity z worktree na branch w głównym checkoucie. Wybierz tę drogę, gdy lokalnie możesz uruchomić tylko jedną kopię aplikacji, na przykład dlatego, że zajmuje stały port.

# w worktree: nazwij branch, zrób commit i wypchnij
git switch -c codex/user-id        # pomiń, jeśli wątek już utworzył branch
git add -A && git commit -m "Accept a generic ID type in UserService"
git push -u origin codex/user-id

# albo z głównego checkoutu: weź commity bez checkoutowania brancha
git merge --no-ff codex/user-id

Gdy praca wątku jest już scalona, zarchiwizuj wątek i usuń jego worktree (git worktree remove <path>); worktree pozostawiony na dysku trzyma własną kopię plików i każdą zależność oraz artefakt builda, które wątek zainstalował.

Sprawdzaj UI zrzutami ekranu, przeglądarką i głosem

Przy pracy wizualnej aplikacja wygrywa z terminalem. Dołącz do promptu zrzut ekranu rozjechanego układu i opisz, co ma się zmienić; w CLI to samo robi codex -i screenshot.png "...". Wbudowana przeglądarka pozwala wątkowi otworzyć twój lokalny serwer deweloperski i sprawdzić własną zmianę, co zamienia „powinno wyglądać dobrze” w coś, co wątek może zaobserwować.

The attached screenshot shows the checkout page at 375px wide: the "Pay now" button
overlaps the order summary. Find the cause in src/components/checkout/. Fix it without
changing the desktop layout. Then start the dev server with `pnpm dev`, open
http://localhost:3000/checkout in the in-app browser at 375px and 1280px, and describe what
you see at each width. Add a Playwright test in tests/e2e/checkout.spec.ts that fails on
the overlap and passes after your fix.

Dyktowanie jest w aplikacji włączone (in_app_dictation w 0.157.1) i sprawdza się przy długich opisach problemów wizualnych. Słabo radzi sobie z nazwami z kodu, więc popraw identyfikatory w transkrypcji przed wysłaniem. TUI ma własne polecenie /voice; konfiguracje głosowe dla wielu narzędzi opisuje strona o wprowadzaniu głosowym dla agentów.

Używaj skilli i automatyzacji z aplikacji

Skille ładują się ze współdzielonego katalogu domowego Codex ($CODEX_HOME/skills, domyślnie ~/.codex/skills), więc aplikacja widzi te same osobiste skille co CLI. Aby wywołać skill jawnie, podaj jego nazwę z prefiksem $ w prompcie, na przykład $skill-creator, jeden z przykładowych skilli dołączonych do Codex. Skille zespołu trzymaj w repozytorium, żeby zmiana skilla przechodziła code review. Wyszukiwanie i weryfikację skilli opisuje strona o instalowaniu i zarządzaniu skillami, a marketplace’y pluginów (codex plugin marketplace add) strona o marketplace’ach i rejestrach pluginów.

Automatyzacje uruchamiają zapisany prompt według harmonogramu, w twoim checkoucie albo w dedykowanym worktree, i raportują wyniki w aplikacji. Działają tylko wtedy, gdy aplikacja jest otwarta, a komputer nie śpi. Najpierw przetestuj prompt ręcznie, daj mu najwęższe uprawnienia, które wystarczą, i każ mu raportować zamiast zmieniać kod, dopóki mu nie zaufasz. Pełną konfigurację, łącznie z automatyzacjami wątków i zapasowym harmonogramem w CI dla zadań, które muszą ruszyć przy wyłączonym laptopie, opisuje strona Automatyzacje Codex.

Read-only task. Do not edit files, commit or push.
Run `pnpm test` and `pnpm lint` on the default branch. For each failure, report:
the test or rule name, the file:line, the most likely cause in one sentence, and whether the
failure also occurred in yesterday's report in this thread. If everything passes, reply with
exactly "No failures." and nothing else.

Ustaw uprawnienia dla wątków w aplikacji

Aplikacja czyta ten sam config.toml co CLI, więc ustawiaj uprawnienia właśnie tam. Preferowanym przez OpenAI mechanizmem są profile uprawnień (beta, Codex CLI 0.138.0 i nowsze): wbudowane :read-only, :workspace i :danger-full-access oraz nazwane profile, które definiujesz sam. Własny profil może rozszerzać tylko :read-only albo :workspace; codex-cli 0.157.1 odrzuca każdego innego wbudowanego rodzica.

# Klucze najwyższego poziomu muszą stać przed każdą [tabelą], inaczej TOML przypisze je do tej tabeli.
default_permissions = "review"

[permissions.review]
description = "Review and triage: read the repo, write nothing"
extends = ":read-only"

Zmień uprawnienia dla jednej sesji TUI przez /permissions albo dla jednego uruchomienia przez -c default_permissions=":workspace". Nie łącz profilu ze starszą flagą --sandbox: OpenAI pisze, że te dwa systemy „do not compose”. :danger-full-access zostaw dla jednorazowych sandboksów z ograniczoną siecią, nigdy dla automatyzacji na twoim laptopie. Model wspólny dla wszystkich narzędzi opisuje strona o uprawnieniach i sandboksach, a każdy klucz config.toml strona Konfiguracja Codex.

Kiedy aplikacja desktopowa Codex zawodzi

Dwa lokalne wątki nadpisały sobie nawzajem pracę. Oba edytowały ten sam plik w twoim checkoucie. Wyjście: git diff, by zobaczyć połączony stan, git restore -p, by odrzucić niechciane fragmenty, a potem jedno z zadań powtórz w worktree. Zapobieganie: jeden zapisujący wątek lokalny na projekt.

Wątkowi w worktree brakuje twoich ostatnich zmian. Były niezacommitowane, gdy wątek startował, a worktree widzi tylko zacommitowaną historię. Wyjście: zrób commit albo stash i uruchom nowy wątek od zaktualizowanej bazy; nie proś starego wątku, by „dociągnął” twoje zmiany.

git switch kończy się błędem „already checked out”. Worktree wciąż trzyma branch. Wyjście: pracuj na branchu wewnątrz worktree albo scal go ze swojego checkoutu przez git merge --no-ff codex/BRANCH, jak pokazano wyżej.

Wątek twierdzi, że testy przechodzą, a u ciebie padają. Uruchomił podzbiór, inne polecenie albo sprawdzał przed ostatnią edycją. Wyjście: wklej do wątku swój wynik z błędami i poproś o ponowne uruchomienie dokładnie tego polecenia, którego używa CI, z kodem wyjścia. Wpisz to polecenie do AGENTS.md, żeby używał go każdy wątek.

Długi wątek zaczyna ignorować specyfikację. Wcześniejsze tury, poprawki i wyniki narzędzi wypierają instrukcje podane na początku. Wyjście: uruchom nowy wątek, który wskazuje plik specyfikacji i bieżący diff, zamiast powtarzać poprawki w starym.

Aplikacja nie widzi twoich serwerów MCP, skilli ani ustawień. Czyta inny katalog domowy Codex niż CLI, zwykle dlatego, że CODEX_HOME jest ustawione w profilu powłoki, ale nie dla aplikacji. Wyjście: ustaw CODEX_HOME tak samo dla każdego klienta albo nie ustawiaj go nigdzie, żeby wszystkie używały ~/.codex/. codex doctor pokazuje, co czyta CLI.

Automatyzacja nie ruszyła albo nic nie zaraportowała. Aplikacja była zamknięta albo komputer zasnął. Wyjście: zadania, które muszą ruszyć w nocy, przenieś do harmonogramu w CI, jak opisano w Automatyzacjach Codex.

Kończy się miejsce na dysku. Stare worktrees trzymają zależności i wyniki builda. Wyjście: uruchom git worktree list, by znaleźć worktrees ze scaloną pracą, usuń każdy z nich przez git worktree remove <path> (dopiero to zwalnia miejsce), a potem uruchom git worktree prune, by wyczyścić wpisy katalogów usuniętych ręcznie.

Dokąd dalej z aplikacją desktopową Codex

Przepływy wieloagentowe w Codex: podziel większą funkcję na tory i sprawdź bramkami każdy tor przed scaleniem.
Środowiska chmurowe Codex: skonfiguruj środowisko, w którym działają wątki chmurowe i próby best-of-N.
Przejrzyj zmiany Codex przed commitem: pętla przeglądu, na której opiera się procedura weryfikacji z tej strony.
Automatyzacje Codex: cykliczne zadania z przetestowanymi promptami i wąskimi sandboksami.