Codex CLI to nie czat w terminalu. Pięć rzeczy, które robię po instalacji

Dokumentacja dobrze prowadzi przez instalację. Problem zaczyna się chwilę później.

Bo co robisz, kiedy Codex CLI już działa?

Najprostszy scenariusz wygląda tak: uruchamiasz narzędzie, wpisujesz prompt, dostajesz kod i pracujesz dalej. Tyle że w ten sposób wykorzystujesz tylko niewielką część tego, co faktycznie daje praca z agentem uruchamianym bezpośrednio w projekcie.

W swoim materiale na YouTube pokazałem pięć rzeczy, które robię zaraz po instalacji Codex CLI. Nie chodzi o kolejne sztuczki do zapamiętania. Chodzi o zbudowanie środowiska, w którym agent zna reguły projektu, potrafi delegować pracę, korzysta z zapisanych procedur, może działać na serwerze i, jeśli tego potrzebuję, pracować również z modelem uruchomionym lokalnie.

Jeśli wolisz zobaczyć cały proces na żywym projekcie, tutaj jest film:

Zanim zacznę pracę z Codex CLI

Po instalacji pierwszą rzeczą, którą zrobiłem w filmie, było zalogowanie się do Codeksa. Uruchomiłem codex login, przeszedłem proces logowania w przeglądarce, a następnie odpaliłem Codex CLI w katalogu projektu.

Pracowałem na projekcie napisanym w Pythonie. Testy przechodziły. To było istotne, ponieważ chciałem pokazać sytuację, w której na pierwszy rzut oka wszystko wygląda poprawnie, a dopiero dokładniejsze sprawdzenie kodu pokazuje problemy.

Po uruchomieniu Codeksa pierwszą rzeczą, na którą zwracam uwagę, jest kontekst.

Kontekst to między innymi informacje pochodzące z instrukcji systemowych, opisów narzędzi, serwerów MCP i plików wykorzystywanych podczas pracy. Jeżeli chcę zobaczyć aktualny stan, korzystam z /status.

W moim przypadku mogłem tam sprawdzić między innymi używany model, wersję, katalog, w którym pracuję, oraz wykorzystanie dostępnego limitu.

I właśnie w tym miejscu pojawia się pierwszy problem.

Im więcej zadań próbuję wykonać w jednym wątku, tym więcej informacji trafia do głównego kontekstu. Jeżeli każę jednemu agentowi analizować testy, bezpieczeństwo, wydajność i jeszcze kilka innych rzeczy, wrzucam wszystko do jednego worka.

Dlatego pierwszą rzeczą, którą konfiguruję w bardziej rozbudowanym projekcie, są subagenci.

1. W Codex CLI rozdzielam pracę między subagentów

W materiale przygotowałem trzech agentów. Każdy miał zupełnie inne zadanie:

• jeden analizował testy,
• drugi bezpieczeństwo,
• trzeci wydajność.

Nie chodziło tylko o wygodniejszy podział pracy. Główny agent nie musiał samodzielnie zajmować się wszystkimi szczegółami każdego z tych obszarów.

W konfiguracji określiłem maksymalną liczbę agentów oraz głębokość ich zagnieżdżenia. W moim przykładzie mogło działać maksymalnie sześciu agentów, a kolejne subagenty nie mogły tworzyć następnego poziomu.

Każdy agent dostał własną konfigurację.

Jednym z nich był security reviewer. W jego definicji znajdowała się nazwa, opis oraz instrukcje określające sposób działania. Szczególnie ważny jest opis, ponieważ to na jego podstawie Codex może określić, kiedy danego agenta wykorzystać.

Do tego mogłem określić poziom reasoningu i ograniczyć agenta wyłącznie do odczytu plików. To przydatne przy zadaniach typu review. Jeżeli chcę tylko otrzymać analizę, nie potrzebuję, żeby agent przy okazji zmieniał mój kod.

Kiedy konfiguracja była gotowa, zleciłem głównemu agentowi porównanie aktualnego brancha z main i wskazałem, żeby do pracy wykorzystał trzech przygotowanych wcześniej subagentów.

I tutaj zaczyna się właściwa różnica.

Zamiast jednego modelu próbującego analizować cały projekt jednocześnie dostałem trzy osobne ścieżki pracy.

W trakcie działania mogłem użyć /agents, przełączyć się na konkretnego agenta i zobaczyć, czym w danym momencie się zajmuje.

Po kilku minutach agenci wrócili z wynikami.

Agent odpowiedzialny za testy znalazł braki w testach i przypadki, dla których nie zostało określone odpowiednie zachowanie. Agent bezpieczeństwa wykrył problemy o wysokiej wadze. Agent odpowiedzialny za wydajność znalazł osobne rzeczy związane ze swoim zakresem.

Na końcu poprosiłem głównego agenta o zebranie wyników i przygotowanie raportu po polsku.

To jest model pracy, którego używam zamiast wrzucania całego zadania do jednego promptu.

Jeżeli kod ma zostać przejrzany z kilku perspektyw, rozdzielam te perspektywy. Agent od testów nie musi zajmować się bezpieczeństwem. Agent od bezpieczeństwa nie musi analizować wydajności.

To samo podejście można wykorzystać wszędzie tam, gdzie duże zadanie da się rozłożyć na osobne specjalizacje.

Ale samo dodanie agentów ujawniło w moim przykładzie jeszcze jeden problem.

Główny agent, weryfikując pracę subagentów, zauważył, że rabat na poziomie 150% prowadzi do ujemnej wartości zamówienia. Potrafił zauważyć, że coś wygląda podejrzanie. Nie wiedział jednak, jaka jest właściwa reguła biznesowa.

I nie mógł tego wiedzieć.

Znał kod, ale nie znał mojego biznesu.

2. AGENTS.md daje Codexowi reguły mojego projektu

To jeden z ważniejszych momentów całego filmu.

Model może bardzo dobrze analizować kod i nadal dochodzić do niewłaściwych wniosków, jeśli brakuje mu informacji o tym, jak aplikacja ma działać.

Kod nie zawsze odpowiada na pytanie: „czy to jest poprawne?”.

Czasami odpowiada tylko na pytanie: „czy to działa w taki sposób, w jaki zostało napisane?”.

Dlatego tworzę AGENTS.md.

W filmie użyłem /init, po czym plik został utworzony. Automatycznie wygenerowana zawartość nie była jednak końcem pracy.

To ja znam projekt. To ja znam zasady biznesowe. Codex może pomóc mi je uporządkować, ale nie powinien ich zgadywać.

Przygotowałem więc własną wersję AGENTS.md.

Umieściłem w niej informacje dotyczące projektu, struktury kodu i najważniejszych założeń. W przypadku przykładowego systemu zamówień opisałem między innymi reguły dotyczące ilości produktu, ceny jednostkowej i dopuszczalnego zakresu rabatu.

W pierwszym uruchomieniu agent patrzył na rabat 150% i sygnalizował, że coś jest z nim nie tak.

Po dodaniu reguł biznesowych sytuacja się zmieniła.

Uruchomiłem nową rozmowę i wykonałem ponownie to samo zadanie. Tym razem agent miał już informację, że procent rabatu musi mieścić się pomiędzy 0 a 30.

Nie musiał się zastanawiać.

Mógł stwierdzić wprost, że brak walidacji pozwalający przyjąć wartość spoza tego zakresu jest błędem.

To drobna różnica językowa, ale ogromna różnica w jakości pracy.

Bez reguł agent widzi kod i próbuje wywnioskować intencję.

Z regułami zna intencję i może sprawdzać, czy kod jest z nią zgodny.

Dlatego AGENTS.md nie traktuję jako pliku, który tworzę tylko po to, żeby „mieć konfigurację pod AI”. To miejsce na wiedzę, bez której agent będzie musiał zgadywać.

A zgadywanie w kodzie biznesowym jest dokładnie tym, czego chcę uniknąć.

Jeżeli pracuję nad projektem dłużej, naturalnie pojawia się kolejny problem. AGENTS.md zaczyna rosnąć.

Dochodzi nowa wiedza, nowe procedury, kolejne zasady i następne instrukcje.

Nie wszystko powinno znajdować się tam na stałe.

I tutaj przechodzę do trzeciej rzeczy.

3. Skille w Codex CLI zamiast kopiowania tych samych promptów

Skille traktuję jak zapisane procedury.

Jeżeli po raz kolejny wykonuję tę samą czynność, nie chcę pamiętać całego promptu. Nie chcę również szukać go w notatkach i wklejać za każdym razem zestawu instrukcji.

Wolę raz opisać procedurę i później po prostu ją uruchamiać.

W filmie przygotowałem skill związany z code review.

W katalogu skillu znajdował się plik SKILL.md. Podobnie jak przy agentach opisałem nazwę i description.

Description ponownie ma duże znaczenie, ponieważ mówi agentowi, w jakiej sytuacji dana umiejętność powinna zostać wykorzystana.

Dalej mogłem opisać już cały proces.

Co należy zrobić?

Jaki jest zakres zmian?

Jakie polecenia trzeba uruchomić przed przejściem dalej?

Co powinno wydarzyć się przy większej zmianie?

W moim przypadku skill mógł również zdecydować o uruchomieniu równoległego review i oddelegowaniu części pracy do agentów.

To jest moment, w którym agenci i skille zaczynają się bardzo dobrze uzupełniać.

Agent określa, kto zajmuje się danym zadaniem.

Skill określa, jak wykonać określoną procedurę.

Co ważne, nie muszę wrzucać całej treści każdego skillu na stałe do kontekstu. W materiale pokazuję różnicę pomiędzy informacjami umieszczonymi w AGENTS.md a skillami: przy skillach agent otrzymuje nazwę i opis, a pełną zawartość pobiera wtedy, kiedy stwierdzi, że konkretna umiejętność jest potrzebna.

To daje mi prostą regułę organizacyjną.

Reguły projektu trafiają do AGENTS.md.

Powtarzalne procedury przenoszę do skilli.

Jeżeli jakaś instrukcja w AGENTS.md zaczyna rozrastać się do całego procesu, zastanawiam się, czy nie powinna stać się osobnym skillem.

Przed uruchomieniem mogę sprawdzić listę dostępnych skilli. W filmie na liście widziałem między innymi przygotowany wcześniej code review.

Później mogłem wywołać go na dwa sposoby.

Mogłem po prostu poprosić agenta tekstowo o wykonanie code review albo jawnie wskazać konkretny skill za pomocą symbolu $ i jego nazwy.

Najważniejsze dzieje się jednak później.

Skill nie musi kończyć się na wygenerowaniu tekstowej opinii o kodzie.

W pokazanym przeze mnie przykładzie uruchamiał potrzebne narzędzia i polecenia. Wykorzystywał między innymi Git, uruchamiał testy, wykonywał sprawdzenia i angażował przygotowanych wcześniej agentów.

Ja nie musiałem za każdym razem pisać:

najpierw zrób to, potem uruchom to, później sprawdź tamto, a jeżeli zmiana jest większa, wykonaj jeszcze dodatkową analizę.

Zapisałem procedurę raz.

To jest dla mnie podstawowy sygnał, że coś powinno stać się skillem: jeżeli zaczynam wykonywać tę samą sekwencję kolejny raz, przestaję przechowywać ją w głowie albo w historii czatów.

Zapisuję ją.

Jeżeli interesuje Cię szerzej taki sposób pracy z narzędziami dla programisty, mam również osobny materiał o narzędziach AI dla developera w 2026 roku.

A jeśli korzystasz również z Claude Code, opisałem go osobno w tekście o Claude Code CLI. Nie będę tutaj robił rozbudowanego pojedynku między tymi narzędziami, bo ten tekst ma dotyczyć pracy z Codex CLI.

Podobnie podchodzę do narzędzi pracujących bezpośrednio w edytorze. Jeśli szukasz takiego porównania, zobacz mój tekst Windsurf vs Cursor.

Tutaj idziemy dalej, bo wszystkie opisane do tej pory automatyzacje mają jedną wspólną cechę.

Działają na komputerze, przy którym siedzę.

A nie każda automatyzacja powinna kończyć pracę razem ze mną.

4. Codex CLI na serwerze może pracować bez mojego laptopa

Jeżeli przygotowałem agentów i procedury, kolejne pytanie brzmi: gdzie mają działać?

Do tej pory wszystko uruchamiałem lokalnie.

Są jednak zadania, których nie potrzebuję wykonywać podczas pracy przy komputerze.

W filmie jako przykłady podałem raporty, analizy kodu, sprawdzanie kodu pod kątem podatności czy analizowanie bibliotek. Takie procesy mogą zostać uruchomione zdalnie i działać wtedy, kiedy mnie przy komputerze nie ma.

Ten fragment filmu powstał we współpracy z Hostingerem, który był partnerem odcinka; jeśli korzystasz z ich oferty, możesz użyć mojego kodu KACPER10.

Sam mechanizm uruchomienia Codeksa na serwerze nie jest jednak związany wyłącznie z jednym dostawcą.

Na dowolnym serwerze potrzebuję dostępu do konsoli.

W pokazanym przeze mnie przykładzie otworzyłem konsolę SSH bezpośrednio z panelu Hostingera i rozpocząłem logowanie do Codeksa.

I tutaj pojawia się istotna różnica względem pracy na własnym komputerze.

Na serwerze nie wybierałem zwykłego logowania otwierającego przeglądarkę. Wybrałem logowanie za pomocą kodu urządzenia.

Codex wyświetlił adres oraz jednorazowy kod. Otworzyłem wskazaną stronę na swoim komputerze, zalogowałem się i podałem kod.

Po chwili urządzenie zostało dodane i mogłem korzystać z Codeksa na serwerze.

W materiale zwracam również uwagę na to, że na niektórych kontach możliwość logowania za pomocą jednorazowych kodów może być wyłączona. W takim przypadku trzeba włączyć ją w ustawieniach obszaru roboczego.

Po zalogowaniu mogłem już normalnie rozpocząć rozmowę z agentem.

Po co właściwie przenosić go na serwer?

Dla mnie odpowiedź jest prosta: nie chcę uzależniać każdej automatyzacji od własnego laptopa.

Jeżeli coś ma działać w nocy, cyklicznie albo niezależnie od tego, czy mój komputer jest uruchomiony, serwer jest naturalnym miejscem do wykonania takiego zadania.

Jest jeszcze drugi aspekt.

Jeżeli obawiam się udostępniania agentowi środowiska mojego prywatnego komputera, mogę przygotować mu osobną maszynę, na której znajdują się tylko rzeczy potrzebne do wykonania pracy.

Nie muszę instalować agenta obok prywatnych plików.

Mam wydzielone środowisko przeznaczone do automatyzacji.

Dla mnie to ważniejsze niż samo pytanie, czy agent działa w terminalu mojego Maca, czy w konsoli serwera.

Chodzi o architekturę pracy.

Jeżeli proces ma być automatyzacją, powinien być możliwie niezależny ode mnie.

5. Codex CLI może pracować z lokalnym modelem

Ostatnia rzecz z mojego zestawu to uruchomienie Codeksa z modelem działającym lokalnie.

W filmie wykorzystałem LM Studio oraz pobrany lokalnie model Qwen.

Najpierw pobrałem model i uruchomiłem go w LM Studio.

Następnie wszedłem do zakładki Developer i uruchomiłem local server.

Dopiero wtedy wróciłem do Codeksa i wskazałem mu lokalnego providera oraz wybrany model.

Nie zadziałało mi to idealnie za pierwszym razem.

Przy pierwszej próbie dostałem błąd. Problem był związany między innymi z tym, że przy zalogowanym koncie GPT Codex korzystał z modeli OpenAI. Żeby uruchomić wybrany przeze mnie model lokalny, musiałem wskazać go Codeksowi w konfiguracji.

Musiałem również ustawić w LM Studio model z odpowiednio dużym kontekstem.

Po poprawieniu konfiguracji Qwen zaczął działać.

Do testu użyłem tego samego projektu, na którym wcześniej pracowałem z modelem zdalnym. Poprosiłem model o przejrzenie kodu, znalezienie błędów poprawności i brakujących przypadków brzegowych oraz zaproponowanie możliwie małej poprawki bez modyfikowania plików.

Lokalny model potrzebował więcej czasu.

W pewnym momencie zakończył nawet analizę bez wypisania mi rezultatów i musiałem go o nie poprosić.

Ostatecznie wskazał jednak problemy podobne do tych, które wcześniej znalazł model GPT.

I tutaj moje wnioski z tego testu są bardzo proste.

Model zdalny działał szybciej.

Qwen lokalnie działał wolniej.

Za lokalnym modelem przemawia natomiast prywatność, ponieważ praca odbywa się na moim sprzęcie.

Nie traktuję tego jako odpowiedzi na pytanie: „który model jest lepszy?”.

Nie taki był cel testu.

Chciałem sprawdzić, czy mogę wykorzystać Codex CLI jako warstwę pracy z modelem uruchomionym lokalnie.

Mogłem.

Dzięki temu nie jestem ograniczony wyłącznie do jednego sposobu korzystania z narzędzia. W zależności od zadania mogę pracować z modelem zdalnym albo wykorzystać model uruchomiony na własnym sprzęcie.

Co robię po instalacji Codex CLI?

Jeżeli miałbym cały ten materiał sprowadzić do jednej rzeczy, nie byłoby nią żadne konkretne polecenie.

Największy błąd polega na traktowaniu Codex CLI jak okna czatu przeniesionego do terminala.

Prompt.

Odpowiedź.

Koniec.

Ja chcę zbudować środowisko, które z każdą kolejną sesją wymaga ode mnie mniej ręcznego tłumaczenia.

Dlatego zaczynam od pięciu rzeczy.

Najpierw rozdzielam pracę między subagentów, zamiast wrzucać każdy problem do jednego wątku.

Później uzupełniam AGENTS.md, żeby agent znał reguły projektu i nie musiał zgadywać, co mój kod ma właściwie robić.

Powtarzalne procedury zapisuję jako skille.

Jeżeli jakaś automatyzacja ma działać niezależnie ode mnie, przenoszę ją na serwer.

A kiedy chcę pracować lokalnie, mogę podłączyć do Codeksa model uruchomiony na własnym sprzęcie.

Nie robiłbym jednak wszystkiego naraz.

Jeżeli właśnie zainstalowałeś Codex CLI, zacznij od jednej rzeczy.

W moim przypadku byłby to AGENTS.md.

Uruchom /init, zobacz wygenerowany plik, a później dopisz do niego reguły, których agent nie jest w stanie wyczytać z samego kodu.

Jakie wartości są poprawne?

Jakie zachowanie jest wymagane?

Co w tym projekcie jest błędem, nawet jeśli technicznie kod potrafi to wykonać?

To kilka minut pracy, które zmieniają każdą następną sesję.

Dopiero później dodawałbym agentów i wyciągał powtarzalne procesy do skilli.

Właśnie wtedy Codex CLI przestaje być dla mnie narzędziem, któremu ciągle od nowa tłumaczę, czego potrzebuję.

Zaczyna pracować w środowisku przygotowanym pod mój projekt.

Jeżeli chcesz wykorzystać podobne podejście w swoim zespole i uporządkować pracę z agentami oraz automatyzacjami AI, umów się ze mną na rozmowę.