Automatyzacja Codexa: wybierz powierzchnię, potem udowodnij wynik

Automatyzacja Codexa to uruchamianie Codexa bez człowieka przy prompcie: codex exec w skryptach i CI, zaplanowane automatyzacje w aplikacji desktopowej Codex, zadania w Codex cloud, równoległe worktree, Codex SDK oraz delegowanie ze Slacka lub Lineara. Przebieg jest tak wiarygodny jak maszynowa kontrola, która decyduje o merge’u.

Używasz już Codexa interaktywnie i masz zadania, które mógłby robić sam: nocne polowanie na niestabilne testy, podbijanie zależności, analizę nieudanych przebiegów CI. Ten hub jest dla programistów i tech leadów, którzy decydują, która powierzchnia uruchamia każde z nich i skąd wiadomo, że wynik jest poprawny, bez czytania każdego diffa. Sprawdzono go na Codex CLI 0.157.1.

Która powierzchnia Codexa powinna uruchamiać twoje zadanie?

Wybieraj według wyzwalacza i tego, do czego przebieg musi mieć dostęp. Zadanie, które potrzebuje twoich lokalnych usług, należy do twojej maszyny. Zadanie, które ma działać, gdy laptop śpi, należy do CI albo do Codex cloud.

Twoje zadanie	Powierzchnia	Wyzwalacz	Czytaj
Krok skryptu lub CI z wynikiem czytelnym dla maszyny	`codex exec` (`--json`, `--output-schema`, `-o`)	Twój skrypt lub pipeline	Codex bez interfejsu: `codex exec`
Cykliczna kontrola lub raport	Automatyzacje w aplikacji desktopowej (macOS i Windows; działa tylko, gdy ta maszyna jest włączona) albo harmonogram w CI	Zegar	Zaplanowane automatyzacje Codexa
Długie lub zdalne zadanie, kilka podejść	Codex cloud (`codex cloud exec --env ENV_ID --attempts 3`; eksperymentalne w CLI 0.157.1; `codex cloud` pokazuje identyfikatory środowisk, `--attempts` to best-of-N)	CLI, web lub integracja	Środowiska Codex cloud
Kilka lokalnych zadań naraz	Zarządzane worktree (`--worktree`, `/worktree`)	Ty	Worktree w Codexie i przepływy wieloagentowe
Twoje narzędzie lub dashboard steruje Codexem	`@openai/codex-sdk` (TypeScript) lub `openai-codex` (Python)	Twój kod	Codex SDK
Prośba zaczyna się na czacie lub w zgłoszeniu	Integracje ze Slackiem i Linearem	Wzmianka lub przypisanie	Slack i Linear
Review pull requestów i poprawki w GitHubie	`openai/codex-action@v1`	Zdarzenie workflow	Codex w CI/CD
Bramy LLM (gateway), testy sandboksa, ślady audytowe	Konfiguracja i telemetria	Jednorazowe ustawienie	Zaawansowane konfiguracje Codexa

Te same zadania w Claude Code i Cursorze opisują hub automatyzacji Claude Code i hub automatyzacji Cursora. Jeśli wybierasz między SDK różnych dostawców, przeczytaj sterowanie agentami z kodu.

W jakiej kolejności automatyzować Codexa?

Każdy krok korzysta z tego, co udowodnił poprzedni. Przeskakiwanie oznacza debugowanie promptu, sandboksa i harmonogramu jednocześnie.

Uruchamiaj zadanie interaktywnie, aż dwa razy się powiedzie, i zapisz polecenie, które dowodzi poprawności, na przykład pnpm test albo pnpm lint. To polecenie staje się bramką przebiegu.
Uruchom je bez interfejsu z najwęższymi uprawnieniami i stałym kształtem wyniku. W terminalu:
Okno terminala
```
gh run view "$RUN_ID" --log-failed | codex exec -c default_permissions=":workspace" \
  --output-schema triage.schema.json -o triage.json \
  "Triage the failing tests in the CI log on stdin. Do not edit test files."
```
RUN_ID to identyfikator nieudanego przebiegu GitHub Actions (wypisuje go gh run list --status failure). Gdy podasz prompt jako argument, codex exec dołącza do niego dane z potoku jako blok <stdin>.

triage.schema.json ustala kształt ostatniej wiadomości:
```
{
  "type": "object",
  "additionalProperties": false,
  "required": ["failing_tests", "suspected_cause", "flaky", "confidence"],
  "properties": {
    "failing_tests": { "type": "array", "items": { "type": "string" } },
    "suspected_cause": { "type": "string" },
    "flaky": { "type": "boolean" },
    "confidence": { "type": "string", "enum": ["low", "medium", "high"] }
  }
}
```
Profile uprawnień są w wersji beta (CLI 0.138.0 i nowsze) i nie łączą się z flagą --sandbox: w 0.157.1 podanie obu nie zwraca błędu, a --sandbox po cichu zastępuje profil. Podaj jedno albo drugie i sprawdź linię sandbox: w nagłówku przebiegu. --approve-for-me działa na starszym sandboksie workspace-write, więc też nie łączy się z profilem. Wybierz jeden mechanizm. Flagi --full-auto już nie ma (usunięta w 0.147.0). Przewodnik po uprawnieniach i sandboksach podaje ustawienia dla każdego typu przebiegu.
Zrównoleglij, gdy pojedynczy przebieg jest niezawodny: jedno worktree na zadanie.
Zaplanuj je albo przenieś do chmury.
Podłącz je do CI, żeby o wyniku decydował pipeline, a nie raport samego agenta.
Po SDK sięgnij na końcu, gdy skrypt wokół codex exec nie wystarcza już do opisania przepływu.

Read AGENTS.md, package.json scripts, .github/workflows/ and the last 50 commit messages.
List up to eight recurring chores in this repository that Codex could run unattended
(for example dependency bumps, flaky-test triage, changelog drafts, lint debt).
For each one give: the trigger, the files it would touch, the existing command that
proves the result correct, and a risk level (low: read-only report; medium: opens a PR;
high: touches release or infrastructure). Rank them by "has a proving command and is
low risk" first. Do not change any files.

We want to run "weekly dependency bump for patch and minor versions" unattended with
codex exec. Write the contract as a Markdown file at docs/automation/dependency-bump.md:
1. The exact codex exec command, using -c default_permissions=":workspace" and
   --output-schema, with no --dangerously-* flag.
2. A JSON Schema for the final message: packages changed, test command run, its exit
   code, and anything skipped with a reason.
3. The gate CI runs afterwards (install, typecheck, lint, tests) and what makes it fail.
4. Stop conditions: a major version, a failing test, or a lockfile conflict means
   "report and stop", not "fix".
Show me the file before creating anything else.

Jak zweryfikować wynik Codexa działającego bez nadzoru, nie czytając każdej linii?

Ufaj bramkom, nie podsumowaniu agenta. Działająca konfiguracja ma cztery warstwy:

Stały kształt wyniku. --output-schema opisuje ostatnią wiadomość; twój skrypt i tak sprawdza, czy pole istnieje i czy model nie jest niepewny (jq -e 'has("failing_tests") and .confidence != "low"' triage.json), zanim na tej podstawie cokolwiek zrobi.
Niezależne kontrole. CI ponownie uruchamia testy, sprawdzanie typów i lint na gałęzi, którą wypchnął Codex. Agent nie może sam oznaczyć swojej pracy na zielono.
Drugi recenzent. codex exec review --base main albo @codex review w pull requeście szuka błędów, których testy nie łapią. Zobacz code review z Codexem.
Ślad audytowy. --json zapisuje każde zdarzenie jako JSONL; archiwizuj go razem z przebiegiem, żeby później odpowiedzieć na pytanie „co on zrobił?”.

Człowiek nadal zatwierdza merge, ale na podstawie dowodów: zielonych bramek, uwag z review i raportu z kontraktu. Strona o pakiecie dowodów definiuje, co ten pakiet zawiera.

Co się psuje, gdy Codex działa bez nadzoru?

Objaw	Przyczyna	Naprawa
`unexpected argument '-a'`	`codex exec` nie ma `-a` w 0.157.1 i go nie potrzebuje: bez `--approve-for-me` działa z zatwierdzaniem `never`, niezależnie od `approval_policy` czy prefiksu `codex -a … exec`. Z `--approve-for-me` nagłówek pokazuje `on-request`, a decyzje podejmuje auto-review	Usuń flagę i sprawdź linię `approval:` w nagłówku przebiegu: zwykle `never`, przy `--approve-for-me` — `on-request`. Zakres działań ogranicz sandboksem albo profilem uprawnień
Przebieg ma szerszy lub węższy dostęp niż profil	`--sandbox` podany razem z `default_permissions`; w 0.157.1 flaga po cichu wygrywa	Usuń jedno z nich i sprawdź linię `sandbox:` w nagłówku przebiegu
Skrypt pada na `--full-auto`	Flaga usunięta w 0.147.0	Użyj profilu uprawnień, jak w kroku 2
Przebieg ignoruje zasady projektu	Niezaufane projekty nie dostarczają `AGENTS.md` (od 0.150.0)	Na runnerze dodaj do `$CODEX_HOME/config.toml` sekcję `[projects."REPO_PATH"]` z `trust_level = "trusted"` (REPO_PATH to bezwzględna ścieżka checkoutu na runnerze) (konfiguracja). Ufaj tylko checkoutowi własnej gałęzi domyślnej: zaufany head kontrybutora dostarcza własne `AGENTS.md`, konfigurację projektu i hooki
Hooki projektu się nie uruchamiają	Hooki wymagają utrwalonego zaufania	Zatwierdź je raz przez `/hooks`; unikaj `--dangerously-bypass-hook-trust`
Równoległe przebiegi psują się nawzajem	Wspólne porty, baza danych lub gałąź	Jedno worktree i jeden blok portów na przebieg
Sekret wycieka z zadania uruchamianego przez PR	Niezaufany kod działał z sekretami w środowisku	Zanim włączysz wyzwalacz, wdróż zasady z tożsamości agentów i sekretów