Środowiska chmurowe Codex: setup, cache, sieć i best-of-N

Środowisko chmurowe Codex to definicja kontenera, w którym działa każde zadanie chmurowe Codex: checkout repozytorium, skrypt setup uruchamiany z dostępem do internetu, opcjonalny skrypt maintenance dla kontenerów z cache, zmienne i sekrety dostępne tylko podczas setupu oraz polityka internetu dla fazy agenta, domyślnie wyłączona. Dobrze zbudowane środowisko sprawia, że zadania chmurowe są szybkie, powtarzalne i bezpieczne do uruchamiania bez nadzoru.

Twoje pierwsze zadanie chmurowe trwało dwanaście minut, z czego osiem zajął pnpm install. Drugie padło, bo agent nie mógł połączyć się z rejestrem pakietów, a trzecie zwróciło diff, którego testy nigdy się nie uruchomiły, bo nikt nie zainstalował przeglądarek Playwright. Każda z tych awarii to problem środowiska, nie modelu. Ta strona jest dla programisty, który odpowiada za konfigurację Codex w repozytorium, i dla tech leada, który chce, żeby zadania chmurowe całego zespołu kończyły się pull requestami gotowymi do review i popartymi testami.

Co daje produkcyjnie przygotowane środowisko chmurowe Codex

• Skrypt setup, który głośno zgłasza błędy, skrypt maintenance, który utrzymuje aktualność kontenerów z cache, i sposób na przetestowanie obu na własnym laptopie, zanim je zapiszesz.
• Jasną regułę, co trafia do zmiennych środowiskowych, a co do sekretów.
• Politykę dostępu do internetu, której obronisz na przeglądzie bezpieczeństwa, oraz prompt, który przygotowuje allowlistę.
• Przepływ w CLI do wysyłania zadań chmurowych, sprawdzania ich stanu i nakładania diffów, łącznie z próbami best-of-N i skryptem fan-out.
• Bramkę weryfikacyjną, która rozstrzyga, czy diff z chmury jest wart ludzkiej uwagi, bez czytania każdej linii.

Jak przebiega zadanie chmurowe Codex?

Każde zadanie chmurowe, niezależnie od tego, czy uruchamiasz je z przeglądarki, z CLI, z komentarza na GitHubie czy wzmianką @ChatGPT na Slacku (Cloud delegation), przechodzi przez te same fazy. Granice między fazami tłumaczą niemal każdą awarię opisaną dalej.

1. Start kontenera. Codex uruchamia kontener z obrazu bazowego universal albo wznawia kontener z cache i robi checkout repozytorium na wybranej gałęzi.

2. Skrypt setup. Twój skrypt setup działa z dostępem do internetu. To jedyna faza, w której istnieją sekrety.

3. Skrypt maintenance. Gdy Codex wznawia kontener z cache, zamiast pełnego setupu uruchamia opcjonalny skrypt maintenance.

4. Odcięcie. Sekrety są usuwane, a zaczyna obowiązywać polityka internetu dla fazy agenta. Domyślnie agent nie ma dostępu do internetu.

5. Pętla agenta. Agent czyta pliki, edytuje kod i uruchamia polecenia. Polecenia budowania, lintowania i testów bierze z AGENTS.md, więc środowisko musi jedynie sprawić, żeby dało się je uruchomić.

6. Wynik. Zadanie kończy się podsumowaniem i diffem (po jednym na próbę). Otwierasz pull request, zadajesz pytanie uzupełniające albo nakładasz diff lokalnie.

Opis faz, cache, sekretów i presetów opiera się na dokumentacji OpenAI o środowiskach chmurowych i dostępie agenta do internetu (stan na 2026-08-28); polecenia CLI sprawdzono w codex 0.157.1 i jego kodzie źródłowym. OpenAI przepisało dokumentację Codex Cloud wokół opublikowanych, wielokrotnego użytku środowisk chmurowych; model ze skryptem setup opisany na tej stronie jest tam udokumentowany jako „Codex Cloud (Legacy)”, który „continues to support environments for Code Review and the Linear and GitHub integrations” (sprawdzone 2026-10-12).

Czym są opublikowane środowiska chmurowe i czym różnią się od skryptów setup poniżej?

2026-09-29 (DevDay 2026) OpenAI przebudowało Codex Cloud wokół opublikowanych, wielokrotnego użytku środowisk chmurowych. OpenAI opisuje ten pomysł tak: „Describe your development setup, let Codex prepare and test it, then publish the environment. New tasks start in isolated workspaces using the prepared filesystem.” Przebieg na stronie OpenAI o chmurze to: utwórz lub wybierz środowisko, wybierz „Let Codex prepare your project”, wybierz „Review and publish” i uruchom zadanie. Zadania „keep working while your computer is asleep”, a zmiany możesz przejrzeć i kontynuować pracę z przeglądarki, telefonu lub aplikacji desktopowej („Review changes and continue from the web, mobile, or desktop app”; strony OpenAI o chmurze i DevDay 2026, odczyt 2026-10-12).

Dla tej strony mają znaczenie dwie konsekwencje:

• Model ze skryptem setup poniżej jest starszy. OpenAI dokumentuje go teraz jako „Codex Cloud (Legacy)”, z tym samym kontenerem, skryptem setup i obrazem universal, i pisze, że „continues to support environments for Code Review and the Linear and GitHub integrations”. Dla tych integracji korzystaj dalej z tej strony.
• Slack wymaga opublikowanego środowiska. Cloud delegation ChatGPT w Slacku „requires a published environment shared with the workspace”; zobacz Codex w Slacku i Linearze.

Cennik OpenAI wymienia Codex cloud i środowiska chmurowe dla planów Plus, Pro, Business i Enterprise, a nie dla logowania kluczem API (odczyt 2026-10-12). Ta strona nie przechodzi przez ekrany opublikowanych środowisk; skorzystaj w tym celu ze strony OpenAI o środowiskach chmurowych.

Skonfiguruj skrypt setup środowiska

Środowiska tworzysz i edytujesz w ustawieniach Codex w przeglądarce, w sekcji Environments. Każde środowisko wskazuje jedno repozytorium i przechowuje opisane niżej skrypty, zmienne, sekrety i politykę internetu.

Zacznij od automatycznego setupu, potem napisz skrypt

W projektach, które używają npm, yarn, pnpm, pip, pipenv lub poetry, Codex potrafi zainstalować zależności automatycznie. Zacznij od tego. Własny skrypt setup napisz wtedy, gdy agent potrzebuje czegoś, czego automatyczny setup nie zapewnia: pakietów systemowych, generatora kodu, przeglądarek do testów end-to-end albo kroku budowania, od którego zależą inne pakiety.

#!/usr/bin/env bash
# Setup script: expensive steps that rarely change
set -euo pipefail

apt-get update && apt-get install -y --no-install-recommends postgresql-client redis-tools

pnpm install --frozen-lockfile
pnpm exec playwright install --with-deps chromium

pnpm run codegen
pnpm run build:shared

# Prove the environment works before the agent starts
pnpm run typecheck

Trzy zasady sprawiają, że taki skrypt ma sens:

• set -euo pipefail w pierwszej linii. Bez tego nieudany apt-get install nie zatrzyma skryptu, a agent przepali potem budżet na „command not found”.
• Instalacja z lockfile’a (--frozen-lockfile, npm ci, poetry install --no-update), żeby każdy kontener rozwiązywał to samo drzewo zależności.
• Krok weryfikacyjny na końcu. Jeśli typecheck padnie tutaj, setup kończy się czytelnym logiem. Jeśli padnie w trakcie zadania, agent może „naprawić” twój kod, żeby obejść zepsute środowisko.

Utrwal zmienne potrzebne agentowi

Skrypt setup działa w innej sesji powłoki niż agent, więc export nie przechodzi dalej. Zapisz wartość do ~/.bashrc albo, lepiej, zdefiniuj ją jako zmienną środowiskową w ustawieniach:

# Does not reach the agent phase
export DATABASE_URL="postgresql://localhost:5432/test"

# Reaches the agent phase
echo 'export DATABASE_URL="postgresql://localhost:5432/test"' >> ~/.bashrc

Wybierz między zmiennymi środowiskowymi a sekretami

Ustawienie	Dostępne w fazie	Użyj do	Nigdy nie używaj do
Zmienna środowiskowa	Setup i agent	NODE_ENV=test, lokalny testowy DATABASE_URL, flagi funkcji dla testów	Czegokolwiek, czego nie wkleiłbyś do pull requesta
Sekret	Tylko skrypt setup (usuwany przed startem agenta)	Token prywatnego rejestru dla pnpm install, token do pobierania z ghcr.io	Wartości, której agent potrzebuje w trakcie pracy

Ten podział to celowa granica bezpieczeństwa: sekret, którego agent nigdy nie widzi, nie wycieknie do diffa, logu ani żądania wywołanego prompt injection. Jeśli test naprawdę potrzebuje poświadczeń w trakcie działania, daj mu poświadczenia testowe bez dostępu do produkcji albo zastąp usługę stubem.

Przetestuj skrypt setup najpierw na laptopie

Zapisanie zepsutego skryptu i czekanie na przebieg w chmurze to wolna pętla informacji zwrotnej. OpenAI publikuje codex-universal, obraz referencyjny zbliżony do chmurowego obrazu bazowego, więc fazę setupu przećwiczysz lokalnie (uruchom w katalogu głównym repozytorium):

docker run --rm -it --platform linux/amd64 \
  -e CODEX_ENV_NODE_VERSION=22 \
  -e CODEX_ENV_PYTHON_VERSION=3.12 \
  -v "$(pwd)":/workspace/"$(basename "$(pwd)")" -w /workspace/"$(basename "$(pwd)")" \
  ghcr.io/openai/codex-universal:latest

W kontenerze wklej swój skrypt setup i obserwuj przebieg. Zmienne CODEX_ENV_* wybierają wersje języków, a obsługiwane wartości wymienia README codex-universal (sprawdzone 2026-09-26). Według OpenAI to „not an identical environment”, więc lokalny sukces traktuj jako warunek konieczny, a nie wystarczający.

Prompt do skopiowania: napisz skrypty setup i maintenance

Read package.json, pnpm-lock.yaml, pyproject.toml, AGENTS.md and the CI workflow in .github/workflows/. Write two scripts for a Codex cloud environment.

1. setup.sh: starts with `set -euo pipefail`; installs only the system packages CI installs; runs `pnpm install --frozen-lockfile`; installs every lint, type-check and test tool that AGENTS.md tells the agent to run; runs codegen and the shared-package build; ends by running the type check so a broken environment fails here.
2. maintenance.sh: fast, idempotent; re-runs `pnpm install --frozen-lockfile` and codegen only.

Do not put any token in either script. List every secret the setup needs as a name only, and every environment variable the agent phase needs with a safe test value. Finally, list each command from AGENTS.md and confirm which script makes it runnable.

Przyspiesz starty kontenera dzięki cache i skryptowi maintenance

Codex przechowuje w cache stan kontenera po setupie przez maksymalnie 12 godzin. Kolejne zadania w tym samym środowisku wznawiają się z tego stanu, pomijają skrypt setup i uruchamiają zamiast niego skrypt maintenance.

Cache unieważnia się automatycznie, gdy zmienisz skrypt setup, skrypt maintenance, zmienną środowiskową albo sekret. Gdy zmiana w repozytorium psuje zgodność (duża aktualizacja zależności, nowy pakiet systemowy), użyj Reset cache w ustawieniach środowiska. Cache należy do środowiska, nie do ciebie: jeśli dzielisz środowisko z zespołem, reset sprawia, że następne zadanie każdej osoby zapłaci pełny koszt setupu, więc traktuj go jak decyzję zespołową.

Podziel pracę według tego, jak często się zmienia:

# Setup script: expensive, rarely changes
apt-get update && apt-get install -y --no-install-recommends build-essential
pnpm install --frozen-lockfile

# Maintenance script: cheap, runs on every cached resume
pnpm install --frozen-lockfile   # picks up lockfile changes since the cache was built
pnpm run codegen                 # schemas may have changed

Cache może być o kilka godzin starszy niż twoja gałąź, więc to skrypt maintenance chroni agenta przed testowaniem dzisiejszego kodu na wczorajszych zależnościach. Niech będzie szybki, bo uruchamia się przed każdym zadaniem z cache.

Zdecyduj, ile internetu dostaje agent

Skrypt setup zawsze ma dostęp do internetu. Faza agenta domyślnie nie ma go wcale, a ten domyślny stan chroni cię przed trzema rzeczami: prompt injection z pobranych treści, wyciekiem kodu i instalowaniem przez agenta pakietów, których nikt nie przejrzał.

Gdy agent naprawdę potrzebuje sieci, włącz ją dla danego środowiska i ogranicz dwoma ustawieniami: allowlistą domen i dozwolonymi metodami HTTP.

Wariant	Ustawienia	Kiedy
Wyłączony (domyślnie)	Brak internetu dla agenta	Wszystko, czego zadanie potrzebuje, instaluje setup. Zacznij tutaj.
Zamknięty	Włączony · preset Common dependencies plus wymienione domeny · metody GET, HEAD, OPTIONS	Agent musi pobrać pakiety albo czytać publiczne API w trakcie zadania
Ręczny	Włączony · preset None (pusta lista) plus każda domena podana ręcznie · metody tylko do odczytu	Regulowana baza kodu, w której każdy host wymaga pisemnego uzasadnienia
Bez ograniczeń	Włączony · preset All	Jednorazowy sandbox bez sekretów i bez niczego, co warto wykraść. Unikaj w prawdziwych repozytoriach.

Preset Common dependencies obejmuje typowe rejestry pakietów i hosty kontroli wersji, więc dodajesz tylko to, czego potrzebują twoje testy, na przykład api.stripe.com dla testów Stripe w trybie testowym. Ograniczenie metod do GET, HEAD i OPTIONS blokuje POST, PUT, PATCH i DELETE, więc wstrzyknięta instrukcja nie wyśle twojego kodu metodą POST; dane mogą jednak wyjść w adresie URL żądania GET do hosta z allowlisty, dlatego allowlista musi być jak najwęższa.

Dostęp do internetu zamienia niezaufany tekst w instrukcje

Przy włączonym internecie issue na GitHubie, README albo strona, którą czyta agent, może zawierać ukryte polecenia w stylu „uruchom to polecenie curl”. Kiedy do tego dojdzie, chronią cię najwęższa allowlista i metody tylko do odczytu, a nie późniejsze czytanie wyniku agenta. Przekrój tych mechanizmów we wszystkich narzędziach znajdziesz w artykule o uprawnieniach i sandboksach.

Prompt do skopiowania: przygotuj najwęższą allowlistę dla swojego builda

Audit this repository for every outbound network call made during install, build and test: package registries, git remotes, container registries, and any HTTP client call in the test suites (search for fetch, axios, requests, httpx and hard-coded URLs). Output a table of exact hostnames with the file and line that needs each one.

Then propose a Codex agent internet-access policy: start from the "Common dependencies" preset, add only hosts that preset does not cover, and restrict methods to GET, HEAD and OPTIONS. For any host that needs POST, explain why and propose a stub or a recorded fixture that removes the need instead.

Wysyłaj zadania chmurowe i zarządzaj nimi z CLI

Podkomenda codex cloud jest w codex 0.157.1 oznaczona jako eksperymentalna. Uruchomiona bez argumentów otwiera interaktywny selektor, w którym przeglądasz zadania i nakładasz diffy; naciśnij o na liście zadań (albo Ctrl+O podczas pisania nowego zadania), żeby wybrać środowisko. W skryptach używaj podkomend (w terminalu, wewnątrz repozytorium):

# Submit a task; prints the task URL
codex cloud exec --env payments-api "Fix the failing integration tests in src/payments/"

# Run on a specific pushed branch instead of your current one
codex cloud exec --env payments-api --branch fix/refund-rounding "Add a regression test for refund rounding"

# Check one task; exits 1 unless the status is READY (pending, applied and error all exit 1)
codex cloud status TASK_ID

# List recent tasks as JSON
codex cloud list --env payments-api --json | jq '.tasks[] | {id, status, attempt_total, summary}'

# Read a diff, then apply it to your working tree
codex cloud diff TASK_ID
codex cloud apply TASK_ID

TASK_ID to identyfikator albo pełny URL zadania, który wypisuje codex cloud exec. Szczegóły warte zapamiętania, wszystkie sprawdzone w 0.157.1:

• --env jest wymagane i przyjmuje identyfikator środowiska albo jego etykietę (bez rozróżniania wielkości liter). Jeśli etykieta jest niejednoznaczna, uruchom codex cloud i wybierz identyfikator.
• --branch domyślnie wskazuje bieżącą gałąź, a kontener w chmurze klonuje repozytorium z remote’a, więc najpierw wypchnij gałąź.
• Prompt może przyjść ze standardowego wejścia: codex cloud exec --env payments-api - < task.md.
• codex cloud list zwraca najwyżej 20 zadań na stronę (--limit 1-20) i cursor do następnej strony. Wartości status w JSON to pending, ready, applied i error.

Kiedy best-of-N jest wart swojej ceny?

--attempts uruchamia do czterech niezależnych agentów na tym samym prompcie, a każdy daje własny diff (1–4; inną wartość codex cloud exec odrzuca). Każda próba to pełny przebieg agenta, więc planuj budżet na N zadań, nie na jedno. Używaj tego, gdy błędna pierwsza odpowiedź kosztuje więcej niż dodatkowe przebiegi:

• Błąd o niejednoznacznej przyczynie, na przykład wyścig albo problem z cache.
• Refaktor lub migracja z kilkoma poprawnymi projektami, które chcesz porównać.
• Zmiana wydajnościowa, w której strategie mają różne kompromisy.

Przy zmianach mechanicznych odpuść: trzy identyczne diffy niczego ci nie mówią. Jeśli próby wracają identyczne w zadaniu, które powinno mieć warianty, nazwij alternatywy w prompcie („porównaj podejście cache-aside i write-through”).

codex cloud exec --env payments-api --attempts 3 - <<'EOF'
The /api/users endpoint returns stale data after a profile update.
First write a failing test that updates a profile and immediately reads it back.
Then find the caching bug and fix it. Run the full user-service test suite and
report the exact command and its result. Do not modify tests outside tests/users/.
EOF

# Compare attempts, then apply the one you choose
codex cloud diff TASK_ID --attempt 2
codex cloud apply TASK_ID --attempt 2

Prompt do skopiowania: porównaj próby best-of-N

I ran one Codex cloud task with --attempts 3 and saved each diff with `codex cloud diff TASK_ID --attempt N` into attempt-1.diff, attempt-2.diff and attempt-3.diff. Read all three.

For each attempt: summarize the approach in one line, list files touched outside src/users/ and tests/users/, say whether it added a test that fails without the fix, and flag any change to test assertions, snapshots, CI config or lockfiles. Then recommend one attempt to apply, with the reason, or say that none is acceptable and what the follow-up prompt should add.

Roześlij jedną zmianę po całym monorepo

Gdy ta sama, dobrze określona zmiana powtarza się w wielu pakietach, wyślij jedno zadanie na pakiet i przejrzyj diffy obok siebie. Trzymaj identyczny prompt, żeby diffy dało się porównać; popraw prompt raz, a skorzysta każdy pakiet.

#!/usr/bin/env bash
set -euo pipefail
ENV_ID="payments-api"
BRANCH="$(git branch --show-current)"
: > cloud-tasks.txt
pids=()

for pkg in api web worker; do
  codex cloud exec --env "$ENV_ID" --branch "$BRANCH" \
    "In packages/$pkg, replace lodash calls with native ES2023 equivalents. Keep behavior identical, do not touch other packages, and run that package's test suite." \
    >> cloud-tasks.txt &
  pids+=($!)
done
failed=0
for p in "${pids[@]}"; do
  wait "$p" || { echo "submit failed (pid $p)" >&2; failed=1; }
done
cat cloud-tasks.txt   # one task URL per successful submission
exit "$failed"

Jeśli chcesz rozdzielić pracę w ramach jednej lokalnej sesji, zajrzyj do przepływów wieloagentowych.

Jak zweryfikować zadanie chmurowe bez czytania każdej linii?

Diff z chmury to propozycja. Zanim go otworzysz, ustal, co ma udowodnić, a pierwsze przejście zostaw maszynom:

1. Środowisko uruchamia te same bramki co CI. AGENTS.md wymienia polecenia lintowania, sprawdzania typów i testów, a skrypt setup sprawia, że da się je uruchomić. Podsumowanie zadania musi przytaczać uruchomione polecenia i ich wyniki. Brak wyników testów oznacza, że zadanie nie jest skończone, choćby diff wyglądał dobrze.

2. Sprawdź zasięg zmian z metadanych. codex cloud list --json podaje dla każdego zadania files_changed, lines_added i lines_removed. Zadanie „napraw jeden endpoint”, które dotyka 40 plików, wraca z węższym promptem, zanim ktokolwiek je przeczyta.

   codex cloud list --env payments-api --json \
     | jq -r '.tasks[] | select(.status == "ready" and .summary.files_changed > 10) | "\(.id)  \(.title)"'

3. Uruchom bramki ponownie poza agentem. Nałóż diff w czystym worktree i sam uruchom sprawdzenia albo otwórz pull request i pozwól działać CI. TASK_BRANCH to gałąź przekazana w --branch albo ta, na której byłeś, gdy wysyłałeś zadanie. Rozstrzyga CI, nie podsumowanie agenta.

   git fetch origin TASK_BRANCH
   git worktree add ../verify-task origin/TASK_BRANCH && cd ../verify-task
   pnpm install --frozen-lockfile
   codex cloud apply TASK_ID
   pnpm run typecheck && pnpm run lint && pnpm test

4. Przepuść pull request przez automatyczne review. Poproś o @codex review w PR, a wszystko, co dotyka uwierzytelniania, płatności lub migracji, kieruj do właściciela kodu. Zobacz code review z Codex.

5. Merge robi konkretna osoba. Za merge odpowiada programista, który wysłał zadanie. Best-of-N i fan-out zmieniają liczbę diffów, a nie to, kto je zatwierdza.

Uważaj na diffy, które przechodzą testy dzięki edycji samych testów: zmienione asercje, usunięte przypadki, zaktualizowane snapshoty albo poluzowane sprawdzanie typów. Punkt „zgłoś każdą zmianę w testach” dodawaj do każdego promptu review, tak jak w prompcie do porównywania prób powyżej.

Kiedy środowiska chmurowe Codex zawodzą

Objaw	Prawdopodobna przyczyna	Co zrobić
Agent zgłasza „command not found” dla narzędzia instalowanego w setupie	Skrypt setup padł po cichu albo ścieżka narzędzia została wyeksportowana tylko w powłoce setupu	Dodaj set -euo pipefail; dopisz PATH i zmienne do ~/.bashrc albo ustaw je w interfejsie; przećwicz setup w codex-universal
Testy przechodzą w zadaniu, ale padają w CI	Kontener z cache ma nieaktualne zależności lub wygenerowany kod	Dodaj pnpm install --frozen-lockfile i codegen do skryptu maintenance; raz użyj Reset cache
Każde zadanie płaci pełny czas setupu	Częste zmiany skryptów, zmiennych lub sekretów ciągle unieważniają cache	Grupuj zmiany środowiska; zmienne kroki przenieś do skryptu maintenance
Agent nie może zainstalować potrzebnego pakietu	Internet agenta jest wyłączony (domyślnie)	Zainstaluj pakiet w skrypcie setup; jeśli musi być pobrany w trakcie, dopuść jego rejestr z metodami tylko do odczytu
Instalacja z prywatnego rejestru pada w trakcie zadania	Token jest sekretem, a sekrety znikają przed fazą agenta	Instaluj prywatne pakiety w setupie; nigdy nie kopiuj tokenu do zmiennej środowiskowej
codex cloud exec zgłasza „environment … not found” albo „ambiguous”	Zły identyfikator albo dwa środowiska mają tę samą etykietę	Uruchom codex cloud i skopiuj dokładny identyfikator
Zadanie działało na złym kodzie	Gałąź nie była wypchnięta albo --branch wskazywał gdzie indziej	Najpierw push; w skryptach zawsze podawaj --branch
codex cloud apply pada albo nakłada zmiany częściowo	Twoje drzewo robocze rozjechało się z bazą zadania	Nałóż diff w czystym worktree na gałęzi bazowej zadania albo poproś zadanie o rebase i ponowny przebieg
Wersja języka różni się od produkcyjnej	Domyślna wersja w obrazie bazowym nie zgadza się z twoją	Przypnij wersję w ustawieniach środowiska albo zainstaluj ją w skrypcie setup

Dokąd dalej z zadaniami chmurowymi Codex

• Warunek wstępny: upewnij się, że zadania chmurowe biorą polecenia z AGENTS.md, a potem dopracuj go dzięki optymalizacji AGENTS.md.
• Uruchamiaj zadania chmurowe z czatu i ticketów: integracja ze Slackiem i Linearem.
• Uruchamiaj Codex bez nadzoru we własnym CI zamiast w chmurze: tryb nieinteraktywny i Codex w CI/CD.
• Utrzymaj koszty best-of-N i fan-out w ryzach: zarządzanie kosztami Codex.
• Porównaj środowiska chmurowe Claude Code, Codex i Cursora: środowiska efemeryczne.
• Współdziel środowiska i zasady review w zespole: przepływy zespołowe w Codex.