Codex CLI obok Claude Code: jeden zbiór zasad, dwóch agentów

TL;DR: W tych samych repozytoriach pracuję z dwoma agentami kodującymi: Claude Code jest domyślny, a Codex CLI od OpenAI dostaje zamknięte zadania ze spisanym spec. Oba czytają jeden zbiór zasad (plik instrukcji Codeksa to symlink do pliku Claude), oba przepuszczają każdą komendę powłoki przez ten sam hook uruchamiany przed wykonaniem i oba widzą te same serwery MCP oraz ten sam katalog skilli. Zmiana agenta nigdy nie oznacza zmiany zasad. Claude Code zostaje przy planowaniu, incydentach, tekstach dla klientów i długich wątkach, bo jego sesja może urosnąć do okna kontekstu 1M tokenów. Codex dostaje pracę z gotowym spec we własnym git worktree, a do tego code review jako drugą opinię. Przy podziale zadań zadaję sobie tylko jedno pytanie: "czy mam już spec?"

Po co w ogóle drugi agent kodujący?

Konkretnym problemem była przepustowość. Jedna sesja agenta to jedna kolejka. Kiedy Claude Code siedzi głęboko w wątku planowania albo w incydencie, za nim piętrzy się praca mechaniczna: lista przypadków testowych do napisania, masowa zmiana nazw, refaktor, który jest już w pełni zaplanowany. Do tego limity subskrypcji liczą się osobno dla każdego produktu, więc drugie CLI to drugi budżet, a model z innej rodziny łapie w review inne błędy.

Rozważałem trzy układy:

• Zostać przy jednym agencie i uruchamiać więcej sesji równolegle. Proste, jeden zestaw zasad, i dobrze działa z worktree, co opisałem w tekście o równoległych agentach w git worktree. Minus jest taki, że każda sesja zjada ten sam limit i ma te same ślepe plamki.
• Dodać Codeksa, ale w izolacji. Bez serwerów MCP, bez sieci, bez sekretów. Bezpieczne z założenia, ale zrobi tylko połowę każdego prawdziwego zadania, a każde zlecenie wymaga przekazania wszystkiego, do czego nie miał dostępu.
• Dodać Codeksa z pełną zgodnością. Ten sam dostęp do narzędzi, sieć, skille, pamięć projektu i zabezpieczenia co w Claude Code. Więcej konfiguracji i większa powierzchnia do utrzymania w synchronizacji.

Pierwsza wersja była izolowana. Wycofałem ją tego samego dnia. Izolacja chroniła przed rzeczami, które i tak blokują wspólne zabezpieczenia, a z przydatnego drugiego agenta robiła zabawkę. Podział pracy między nimi został, ale jako rekomendacja, co się opłaca, bez technicznego muru za nią.

Jeden zbiór zasad: instrukcje, hooki, MCP i skille

Zgodność opiera się na tym, że dla każdego rodzaju reguł istnieje dokładnie jedno źródło prawdy, a każde CLI jest na nie kierowane w sposób, który rozumie. To jest context engineering: decydowanie, co agent widzi na starcie sesji i gdzie ta treść mieszka, żeby była mała, aktualna i identyczna w obu narzędziach.

Instrukcje. Claude Code czyta CLAUDE.md, Codex czyta AGENTS.md. W każdym repo i na poziomie globalnym AGENTS.md jest symlinkiem do leżącego obok CLAUDE.md. Edytuję jeden plik, a oba agenty widzą zmianę przy następnym starcie. Nie ma drugiej kopii, która mogłaby się rozjechać.

Jeden kontrakt hooka dla obu CLI. Hook to skrypt, który harness agenta (czyli otoczka agenta: CLI owinięte wokół modelu, które uruchamia narzędzia, zarządza kontekstem i pilnuje uprawnień) wywołuje w ustalonym momencie, tutaj przed uruchomieniem każdej komendy powłoki. Oba CLI przekazują hookowi oczekującą komendę jako JSON na stdin i traktują kod wyjścia 2 jako "zablokuj i pokaż modelowi dlaczego". Kontrakt jest identyczny, więc jeden skrypt chroni oba agenty przed kategoriami nieodwracalnymi: przepisywaniem historii, force pushem, destrukcyjnym usuwaniem i kasowaniem zdalnych danych.

// illustrative shape only
stdin  -> { "tool_input": { "command": "<the shell command>" } }
exit 0 -> allow
exit 2 -> block; stderr becomes the reason the model sees

Codex ma też własne reguły komend oparte na prefiksach, które utrzymuję jako lustro listy deny z Claude Code. To słabsza warstwa: dopasowanie po prefiksie nie widzi niebezpiecznej flagi umieszczonej dalej w komendzie, więc główną ochroną pozostaje hook. Zanim Codex uruchomi nowy hook, prosi o jednorazowe zaufanie mu w swoim UI. Tego kroku nie da się zautomatyzować.

Zgodność MCP. MCP, czyli Model Context Protocol, to standardowy sposób podłączania zewnętrznych narzędzi do agenta: przeszukiwania logów, zapytań do bazy, analityki, przeglądarki. Każde repo ma mały config Codeksa, który odwzorowuje config MCP z Claude Code. Serwery używane zawsze są włączone, ciężkie są wpisane, ale wyłączone, a launcher (o nim niżej) włącza je per zadanie. Nazwy serwerów pochodzą z tych samych plików, których używa Claude Code, więc lista nazw jest jedna. Logowanie OAuth jest osobne dla każdego CLI i trzeba je raz zrobić ręcznie w przeglądarce.

Skille i pamięć. Skille są w jednym magazynie na dysku. Codex skanuje ten magazyn natywnie, a Claude Code dostaje wybór per repo przez symlinki. Jest jeden haczyk: Codex pokazuje cały magazyn, a jego katalog skilli ma budżet mniej więcej 2% kontekstu, czyli około 8000 znaków. Powyżej tej granicy opisy są ucinane. Z pamięcią projektu jest prościej: launcher każe Codeksowi przeczytać indeks pamięci projektu na początku każdej sesji.

Launchery z profilami: jedna komenda wybiera model, effort i narzędzia

Zgodność byłaby męcząca, gdyby każda sesja wymagała pięciu flag. Dlatego oba CLI startują przez jeden mały skrypt powłoki zainstalowany pod dwiema nazwami. Nazwa decyduje o backendzie. O całej reszcie decyduje plik profili w repo: każda linia to rodzaj pracy z jego słowami kluczowymi, serwerami MCP, modelem Claude, poziomem effort, jednolinijkową wskazówką dla agenta i modelem Codeksa. Uproszczony przykład:

Mogę podać nazwę profilu albo wpisać zdanie i zostawić wybór dopasowaniu słów kluczowych. Gdy nic nie pasuje, zostaje profil do codziennego kodowania. W przypadku Codeksa launcher robi jeszcze trzy rzeczy. Potrafi utworzyć osobny git worktree na własnej gałęzi od bieżącego HEAD i zainstalować w nim zależności (918 paczek w 14 sekund z lokalnego cache). Potrafi uruchomić Codeksa w trybie nieinteraktywnym ze spec wczytanym z pliku. Do każdego zadania dokleja też krótką instrukcję końcową: nikt nie odpowie na pytania, niejasny spec oznacza zatrzymanie się i raport, a końcowa wiadomość wymienia pliki, wyniki testów i commit.

Przy pierwszym uruchomieniu zepsuły się dwie rzeczy. Tryb nieinteraktywny czyta stdin, gdy nie ma terminala, i przez pełną minutę czekał na otwartym potoku. Teraz launcher zamyka stdin i przekazuje długie spec przez plik. Do tego pierwszy commit w worktree się nie udał, bo worktree trzyma metadane gita w głównym repozytorium, które leżało poza sandboxem. Codex zgłosił to w podsumowaniu, zamiast próbować obejść sandbox, i dokładnie takiego zachowania oczekuję. Poprawka polegała na jawnym nadaniu prawa zapisu do tego jednego katalogu.

Który agent dostaje które zadanie?

Kiedy zaczynam sesję bez podania profilu, zawsze trafia do Claude Code. Launcher wybiera profil na podstawie moich słów, ale nigdy nie wybiera backendu. Jedyne pytanie, które rozdziela tych dwóch agentów, brzmi: czy istnieje spec? A na nie odpowie tylko sesja. Kiedy sesja Claude dochodzi do mechanicznej pracy, która jest w pełni opisana, wskazówka z profilu każe jej zapisać spec do pliku i wypisać gotową komendę dla drugiego terminala. Kopiuję jedną linijkę.

Warto nazwać jeden wczesny błąd. Zanim cokolwiek z tego istniało, skierowałem Codeksa na leady, maile i analitykę wyszukiwania bez żadnych zasad, a wyniki były słabe. To był problem brakujących zasad. Kiedy oba agenty zaczęły czytać te same instrukcje, różnica między nimi skurczyła się do jakości modelu i ergonomii.

Poziomy modeli per zadanie, stan na wrzesień 2026

Po stronie Claude domyślnym modelem do planowania, incydentów, tekstów dla klientów, trudnego debugowania i codziennego kodu jest Fable 5.1. Opus 5 obsługuje sesje, które ładują ciężkie serwery MCP z analityką: wciągają tysiące linii JSON-a, analiza nie wymaga najmocniejszego modelu, a jego cena katalogowa w API to połowa ceny Fable. Sonnet 5, za jedną piątą ceny Fable, dostaje szybkie poprawki i profile mechaniczne. Haiku 4.5 nie ma w żadnym profilu. Jedyne dobre zastosowanie, jakie dla niego mam, to model za wieloma równoległymi subagentami wyszukującymi.

Po stronie Codeksa GPT-5.6 występuje w trzech poziomach: Sol jako koń roboczy, Terra pośrodku i Luna jako szybki i tani. W praktyce liczyły się dwa szczegóły. Domyślny poziom rozumowania (effort) Sola to low, co daje płytkie odpowiedzi, więc moje profile ustawiają high. A według mojej oceny Sol jest nieco słabszy niż Fable, więc dostaje zadania z pełnym spec i nigdy nie odkrywa, na czym polega problem.

Reguły, według których dzielę pracę: najpierw obniż effort, dopiero potem model; model dobieraj do tego, kto czyta wynik (klient dostaje najmocniejszy model, ja środkowy poziom, maszyna szybki); zmieniaj model na starcie sesji, nigdy w połowie wątku, bo cache promptu jest osobny dla każdego modelu i cały kontekst jest czytany od nowa. Więcej o tym, dlaczego effort znaczy mniej, niż się ludziom wydaje, w tekście o wyborze modelu i poziomu effort w Claude Code.

Jak duże jest okno kontekstu w Codex CLI w porównaniu z Claude Code?

To mnie zaskoczyło. Modele GPT-5.6 obsługują przez API około 1,05M tokenów, ale Codex CLI ustawia okno 272K i kompaktuje przy 95% tej wartości, czyli przy około 258K. To polityka samego CLI: OpenAI rozlicza prompty powyżej 272K tokenów wejściowych po wyższej stawce (2x za wejście i 1,5x za wyjście, stan na wrzesień 2026), więc CLI domyślnie trzyma sesje poniżej tej granicy. Okno można podnieść w configu, ale zdecydowałem się tego nie robić. Powyżej granicy limit subskrypcji topnieje dwa razy szybciej, a kiedy zmierzyłem własne użycie Claude Code, 88% tokenów poszło na tury, w których było już załadowane ponad 300K kontekstu.

Claude Code pozwala sesji urosnąć do 1M bez żadnego progu cenowego po drodze. To praktyczny powód, dla którego długie wątki zostają właśnie tam. Mimo to hamuję je hookiem, który przy 250K prosi agenta o zapisanie stanu wątku w dokumentacji repo, przy 400K i 550K o handoff, a przy 650K o zatrzymanie. Ten sam hook działa w Codeksie: czyta liczniki tokenów z logu sesji, ma punkty kontrolne przy 120K, 200K i 245K i uzbraja się ponownie po każdym kompaktowaniu. Codex nigdy nie dochodzi do wyższych progów, bo wcześniej sam przycina historię.

Czego Codeksowi wciąż brakuje i co radzę zrobić jutro

Zgodność ma dziury. Codex nie ma odpowiednika plików z definicjami agentów w Claude Code (nazwanych subagentów z własnym modelem i instrukcjami) ani odpowiednika artefaktów. Nie potrafi też zabronić czytania konkretnych plików: Claude Code ma regułę, która blokuje odczyt lokalnego pliku z sekretami, a Codex nie ma niczego, co filtrowałoby odczyty plików. Obchodzę to strukturalnie. Worktree, w którym pracuje Codex, nigdy nie zawiera lokalnych sekretów aplikacji, bo ten plik jest ignorowany przez gita, a dostęp do bazy czy analityki idzie przez serwery MCP dokładnie tak samo jak w Claude.

Drugim kosztem jest review. Sprawdzenie delegowanej gałęzi zajmuje mi około dwóch minut niezależnie od jej rozmiaru: diff, zielone testy w głównym checkoucie, brak zabłąkanego trailera co-author i zakres równy spec. Przez ten stały koszt Codex opłaca się tylko przy zadaniach wartych kilku minut pracy. Prawdziwy zysk to równoległość i czysta główna sesja. Oszczędność tokenów to drobna część tego rachunku.

Gdybym jutro ustawiał to wszystko od zera:

• Zrób symlinki plików instrukcji pierwszego dnia. Dwa zbiory zasad rozjeżdżają się w ciągu tygodnia.
• Pisz zabezpieczenia pod wspólny kontrakt hooka. Jeden skrypt, raz przetestowany, chroni oba agenty.
• Trzymaj jedną listę nazw serwerów MCP i z niej generuj albo odwzorowuj drugi config.
• Dziel pracę według pytania "czy jest spec?" zamiast według tego, który model wydaje się dziś mądrzejszy.
• Uruchamiaj drugiego agenta we własnym worktree. Dwa agenty w jednym checkoucie będą edytować te same pliki.
• Sprawdź domyślny effort każdego dodawanego modelu. Model roboczy na najniższym effort wypada gorzej, niż jest naprawdę.

Dla porównania z zupełnie innym środowiskiem, w którym agenta wybiera się za ciebie, zobacz tekst Claude Code w domu, Kiro CLI w pracy.