Codex CLI: kompletne kompendium techniczne

TL;DR: Codex to wielopowierzchniowy agent kodujący, który czyta bazę kodu, uruchamia polecenia w sandboxie na poziomie systemu operacyjnego, łata pliki i deleguje zadania do chmury. Po opanowaniu pięciu kluczowych systemów (config.toml, modelu sandbox/approval, AGENTS.md, MCP oraz skills) Codex staje się mnożnikiem siły. Profile służą do przełączania kontekstu, /compact do zarządzania budżetem kontekstu, /goal do utrwalonych celów pracy, a AGENTS.md do cross-narzędziowych instrukcji projektowych działających w Codex, Cursor, Amp i innych. GPT-5.5 (wydany 23 kwietnia 2026) jest rekomendowanym domyślnym modelem w Codex — okno kontekstu 400K w Codex (1M w API), 5/30 USD za MTok, 82,7% SOTA w Terminal-Bench 2.0.⁸³ Od CLI v0.130.0 (8 maja 2026) Codex dostarcza polecenie najwyższego poziomu codex remote-control do bezgłowego sterowania app-serverem, rozpoznawanie view_image w wielu środowiskach, uwierzytelnianie Bedrock przez poświadczenia logowania konsolowego AWS aws login, paginację wątków app-servera, widoczność szczegółów wtyczek dla wbudowanych hooks z metadanymi share-link i kontrolami wykrywalności, dynamiczne odświeżanie konfiguracji w działających wątkach, konfigurowalne metadane śladów OpenTelemetry oraz dalsze hardening sandboxa na Linux i Windows. v0.129.0 (7 maja 2026) wprowadziła modalną edycję Vim (/vim), przeprojektowany picker workflow, przeglądarkę /hooks w TUI, status line uwzględniający motyw, udostępnianie workspace wtyczek z operacjami marketplace oraz zmianę cyklu życia /goal. Należy nadal preferować jawne flagi sandbox/approval lub permission profiles zamiast starszego --full-auto; js_repl pozostaje usunięte.^86878991

Codex działa jako wielopowierzchniowy agent kodujący, a nie chatbot, który pisze kod. CLI czyta bazę kodu, wykonuje polecenia w sandboxie, łata pliki, łączy się z usługami zewnętrznymi przez MCP i deleguje długo działające zadania do chmury. Działa lokalnie, ale myśli globalnie; ta sama inteligencja zasila pięć odrębnych powierzchni w zależności od sposobu pracy, w tym nowe rozszerzenie Chrome, które uruchamia Codex w przeglądarce bez jej przejmowania.⁹⁰

Różnica między swobodnym a efektywnym używaniem Codex sprowadza się do pięciu kluczowych systemów. Po ich opanowaniu Codex staje się mnożnikiem siły:

1. System konfiguracji: kontroluje zachowanie poprzez config.toml
2. Model sandbox & approval: reguluje to, co może robić Codex
3. AGENTS.md: definiuje kontrakty operacyjne na poziomie projektu
4. Protokół MCP: rozszerza możliwości na usługi zewnętrzne
5. System skills: pakuje wielokrotnego użytku ekspertyzę dziedzinową

Spędziłem miesiące, uruchamiając Codex obok Claude Code w produkcyjnych bazach kodu, pipeline’ach CI/CD i przepływach pracy zespołowej. Niniejszy przewodnik destyluje to doświadczenie do kompletnego źródła referencyjnego, jakie chciałbym mieć na początku. Każda funkcja zawiera rzeczywistą składnię, prawdziwe przykłady konfiguracji oraz przypadki brzegowe, które potrafią zaskoczyć nawet doświadczonych użytkowników.

Uwaga o stabilności: Funkcje oznaczone [EXPERIMENTAL] lub under development mogą ulec zmianie między wydaniami. Według stanu na v0.130.0 (8 maja 2026) Codex Cloud oraz code mode pozostają eksperymentalne lub w trakcie rozwoju, podczas gdy rdzeń CLI, sandboxing, AGENTS.md, config.toml, Skills, hooks, narzędzia multi-agent i wtyczki to stabilne powierzchnie. v0.130.0 dodaje polecenie najwyższego poziomu codex remote-control (prostszy entrypoint dla bezgłowego, zdalnie sterowanego app-servera), rozpoznawanie view_image w wielu środowiskach, uwierzytelnianie Bedrock przez poświadczenia logowania konsolowego AWS aws login, paginację wątków app-servera z widokami unloaded / summary / full turn, widoczność szczegółów wtyczek dla wbudowanych hooks oraz metadane share-link i kontrole wykrywalności, dynamiczne odświeżanie konfiguracji app-servera (działające wątki przejmują zmiany konfiguracji bez restartu), usunięcie sformułowania „research preview” z bannera startowego codex exec, konfigurowalne metadane śladów OpenTelemetry, hardening startu sandboxa na Linux oraz uprawnienia sandboxa Windows dla pamięci podręcznej binariów runtime’u desktopowego.⁹¹ v0.129.0 (7 maja 2026) dodała modalną edycję Vim w composerze (/vim + konfigurowalny domyślny tryb), przeprojektowany picker workflow w TUI (łatwiejsze resume/fork, surowy scrollback), przeglądarkę /hooks, status line uwzględniający motyw z opcjonalnymi podsumowaniami PR + branch, udostępnianie workspace wtyczek + operacje marketplace + kontrole dostępu do udostępnień + filtrowanie źródeł, zmianę cyklu życia /goal (eksperymentalne cele pozostają wstrzymane między resume, chyba że zostaną ponownie włączone), hardening startu sandboxa na Linux, poprawę niezawodności sandboxa na Windows oraz aktualizację Bubblewrap do 0.11.2 z upstreamowymi łatkami bezpieczeństwa.⁸⁹ v0.128.0 (30 kwietnia 2026) wprowadziła utrwalone przepływy /goal, codex update, konfigurowalne keymapy TUI oraz rozszerzone permission profiles; starsze --full-auto pozostaje przestarzałe, a js_repl pozostaje usunięte.⁸⁶⁸⁷

Najważniejsze informacje

• Pięć powierzchni, jeden mózg: CLI, aplikacja desktopowa, rozszerzenie IDE, zadania w chmurze oraz nowe rozszerzenie Chrome — wszystkie korzystają z tej samej inteligencji GPT-5.x-Codex, dzięki czemu można wybrać powierzchnię odpowiadającą danemu przepływowi pracy.⁹⁰
• Sandboxing na poziomie systemu operacyjnego: Codex egzekwuje ograniczenia systemu plików i sieci na poziomie jądra (Seatbelt na macOS, Landlock + seccomp na Linux), a nie wewnątrz kontenerów.
• AGENTS.md działa międzynarzędziowo: Instrukcje projektu działają w Codex, Cursor, Copilot, Amp, Jules, Gemini CLI, Windsurf, Cline, Aider, Zed oraz w ponad 60 000 projektów open source. Wystarczy napisać raz, aby używać wszędzie.
• Profile oszczędzają obciążenie związane z przełączaniem kontekstu: Można definiować nazwane presety konfiguracji (fast, careful, auto) i przełączać się między nimi za pomocą --profile.
• Zarządzanie kontekstem ma znaczenie: GPT-5.4 oferuje kontekst 1M; GPT-5.4 mini zapewnia 400K do pracy subagentów; GPT-5.3-Codex zapewnia 272K wejścia. Warto stosować /compact, ukierunkowane prompty oraz odwołania @file, aby proaktywnie zarządzać budżetami tokenów.

Jak korzystać z tego przewodnika

Niniejszy dokument liczy ponad 2500 wierszy referencyjnych — proszę zacząć tam, gdzie pasuje to do poziomu doświadczenia:

Karta szybkiego odniesienia na końcu dokumentu zawiera czytelne podsumowanie wszystkich kluczowych poleceń.

Jak działa Codex: model mentalny

Zanim przejdziemy do funkcji, warto zrozumieć, jak architektura Codex kształtuje wszystko, co można z nim zrobić. System działa na czterech powierzchniach wspartych wspólną warstwą inteligencji:

┌─────────────────────────────────────────────────────────┐
│                    CODEX SURFACES                        │
├─────────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌────────┐ │
│  │   CLI    │  │ Desktop  │  │   IDE    │  │ Cloud  │ │
│  │ Terminal │  │   App    │  │Extension │  │  Tasks │ │
│  └──────────┘  └──────────┘  └──────────┘  └────────┘ │
│  Local exec     Multi-task    Editor-native  Async      │
│  + scripting    + worktrees   + inline edits detached   │
├─────────────────────────────────────────────────────────┤
│  EXTENSION LAYER                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │   MCP   │  │ Skills  │  │  Apps   │  │  Search │   │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘   │
│  External tools, reusable expertise, ChatGPT            │
│  connectors, web search (cached + live)                  │
├─────────────────────────────────────────────────────────┤
│  SECURITY LAYER                                          │
│  ┌─────────────────────────────────────────────────┐    │
│  │    Sandbox (Seatbelt / Landlock / seccomp)      │    │
│  │    + Approval Policy (untrusted → never)        │    │
│  └─────────────────────────────────────────────────┘    │
│  OS-level filesystem + network restrictions              │
├─────────────────────────────────────────────────────────┤
│  CORE LAYER                                              │
│  ┌─────────────────────────────────────────────────┐    │
│  │         GPT-5.x-Codex Intelligence              │    │
│  │   Tools: Shell, Patch, Read, Web Search         │    │
│  │   (legacy artifact, read_file, grep_files       │    │
│  │    removed in v0.117.0)                          │    │
│  └─────────────────────────────────────────────────┘    │
│  Shared model across all surfaces; costs tokens          │
└─────────────────────────────────────────────────────────┘

Warstwa rdzeniowa (Core Layer): Rodzina modeli GPT-5.x napędza wszystko. Od 23 kwietnia 2026 r. gpt-5.5 jest rekomendowanym modelem, gdy jest dostępny — kontekst 400K w Codex (1M w API), 82,7% SOTA na Terminal-Bench 2.0. gpt-5.4 pozostaje domyślnym rozwiązaniem zapasowym podczas wdrażania (kontekst 1M, natywne sterowanie komputerem).⁸³⁶⁴ Czyta pliki, pisze patche, wykonuje polecenia powłoki i analizuje bazę kodu. Gdy kontekst się zapełnia, Codex kompaktuje konwersację, aby zwolnić miejsce. Ta warstwa kosztuje tokeny.

Warstwa bezpieczeństwa (Security Layer): Każde polecenie wykonywane przez Codex przechodzi przez sandbox na poziomie systemu operacyjnego. Na macOS framework Seatbelt firmy Apple egzekwuje ograniczenia na poziomie jądra. Na Linux Landlock + seccomp filtrują dostęp do systemu plików i wywołań systemowych. Sandbox działa na poziomie jądra, a nie wewnątrz kontenerów. Zasady zatwierdzania decydują następnie, kiedy poprosić o potwierdzenie człowieka.

Warstwa rozszerzeń (Extension Layer): MCP łączy zewnętrzne usługi (GitHub, Figma, Sentry). Skills pakują wielokrotnego użytku przepływy pracy, które Codex ładuje na żądanie. Apps łączą się z konektorami ChatGPT. Wyszukiwanie internetowe dodaje kontekst w czasie rzeczywistym z sieci.

Warstwa powierzchni (Surface Layer): CLI dla użytkowników terminala i automatyzacji. Aplikacja desktopowa do wielowątkowego zarządzania projektami. Rozszerzenie IDE do pętli edycja-kompilacja-test. Chmura do zadań asynchronicznych działających niezależnie.

Kluczowa obserwacja: Większość użytkowników korzysta tylko z jednej powierzchni. Zaawansowani użytkownicy korzystają ze wszystkich czterech: Cloud do długotrwałych zadań, CLI do deterministycznych operacji na repozytorium, rozszerzenie IDE do ścisłych pętli kodowania, a aplikacja desktopowa do planowania i koordynacji.

Spis treści

1. Jak zainstalować Codex?
2. Szybki start: pierwsza sesja
3. Główne powierzchnie interakcji
4. Szczegółowa analiza systemu konfiguracji
5. Który model wybrać?
6. Ile kosztuje Codex?
7. Frameworki decyzyjne
8. Jak działa system sandbox i zatwierdzeń?
9. Jak działa AGENTS.md?
10. Hooks
11. Czym jest MCP (Model Context Protocol)?
12. Code Mode
13. Środowisko uruchomieniowe REPL JavaScript
14. Czym są Skills?
15. Plugins
16. Tryb planowania i współpraca
17. System pamięci
18. Zarządzanie sesjami
19. Tryb nieinteraktywny (codex exec)
20. Codex Cloud i zadania w tle
21. Aplikacja desktopowa Codex
22. GitHub Action i CI/CD
23. Codex SDK
24. Optymalizacja wydajności
25. Jak debugować problemy?
26. Wdrożenie korporacyjne
27. Najlepsze praktyki i antywzorce
28. Przepisy przepływu pracy
29. Przewodnik migracji
30. Karta szybkiego odniesienia
31. Lista zmian
32. Bibliografia

Jak zainstalować Codex?

Menedżery pakietów

# npm (recommended)
npm install -g @openai/codex

# Homebrew (macOS)
brew install --cask codex

# winget (Windows)
winget install OpenAI.Codex

# Upgrade to latest
npm install -g @openai/codex@latest

Bezpośredni skrypt instalacyjny (v0.106.0+)

Dla macOS i Linux dostępny jest jednowierszowy skrypt instalacyjny jako zasób wydania GitHub:⁶⁰

curl -fsSL https://github.com/openai/codex/releases/latest/download/install.sh | sh

Skrypt automatycznie wykrywa platformę i architekturę, pobiera właściwy plik binarny i umieszcza go w PATH.

Pobieranie plików binarnych

W środowiskach bez npm lub Homebrew należy pobrać pliki binarne właściwe dla danej platformy z GitHub Releases¹:

Wymagania systemowe

• macOS: Apple Silicon lub Intel (pełna obsługa sandboxa przez Seatbelt)
• Linux: x86_64 lub arm64 (sandbox przez Landlock + seccomp)
• Windows: natywny sandbox z ograniczonymi tokenami (awansowany z eksperymentalnego w v0.100.0). Obsługiwany jest także WSL²

Uwierzytelnianie

codex login                  # Interactive OAuth (recommended)
codex login --device-auth    # OAuth device code flow (headless)
codex login --with-api-key   # API key from stdin
codex login status           # Check auth state (exit 0 = logged in)
codex logout                 # Clear stored credentials

Dostępne są dwie ścieżki uwierzytelniania:

1. Konto ChatGPT (zalecane): logowanie przy użyciu istniejącej subskrypcji Plus, Pro, Team, Business, Edu lub Enterprise. Pełny dostęp do funkcji, w tym zadań w chmurze.
2. Klucz API: ustawiany przez zmienną środowiskową CODEX_API_KEY lub codex login --with-api-key. Niektóre funkcje (wątki w chmurze) mogą być niedostępne.

Wskazówka ekspercka: przechowywanie poświadczeń można skonfigurować za pomocą cli_auth_credentials_store w config.toml. Opcje: file (domyślna), keyring (pęk kluczy systemu operacyjnego) albo auto (keyring, jeśli jest dostępny; w przeciwnym razie plik).

Uzupełnianie w powłoce

# Generate completions for your shell
codex completion bash > /etc/bash_completion.d/codex
codex completion zsh > ~/.zsh/completions/_codex
codex completion fish > ~/.config/fish/completions/codex.fish

Weryfikacja instalacji

codex --version
# codex-cli 0.130.0

Szybki start: pierwsza sesja

Od zera do produktywnej pracy w 5 minut.

1. Instalacja i uwierzytelnienie:

npm i -g @openai/codex          # Install
codex login                      # Log in with your OpenAI account

2. Przejście do projektu:

cd ~/my-project                  # Any git repo works

3. Uruchomienie Codex:

codex

Pojawi się interaktywny TUI. Codex automatycznie odczytuje strukturę projektu.

4. Zadanie pytania:

> What does this project do? Summarize the architecture.

Codex odczytuje kluczowe pliki i wyjaśnia bazę kodu. W domyślnym trybie suggest nie są wprowadzane żadne zmiany.

5. Wprowadzenie zmiany:

> Add input validation to the login endpoint

Codex proponuje edycje jako diff. Należy je przejrzeć i zatwierdzić za pomocą y albo odrzucić za pomocą n.

6. Użycie slash command:

> /plan Refactor the database layer to use connection pooling

Codex tworzy plan bez wykonywania zmian. Należy przejrzeć plan, a następnie zatwierdzić rozpoczęcie wykonania.

7. Sprawdzenie pracy:

> /diff

Wyświetlane są wszystkie zmiany wprowadzone przez Codex w bieżącej sesji.

Co dalej: - Skonfigurować AGENTS.md z instrukcjami projektu (zob. Jak działa AGENTS.md?) - Skonfigurować profil dla swojego przepływu pracy (zob. Profile) - Wypróbować codex exec do nieinteraktywnej automatyzacji (zob. Tryb nieinteraktywny)

Główne powierzchnie interakcji

Codex udostępnia cztery odrębne interfejsy oparte na tej samej inteligencji. Każda powierzchnia jest zoptymalizowana pod kątem innego wzorca pracy.

1. Interaktywny CLI (Terminal UI)

codex                        # Launch TUI
codex "fix the failing tests" # Launch with initial prompt
codex -m gpt-5.5            # Specify model
codex --sandbox workspace-write --ask-for-approval on-request

Interfejs terminalowy to aplikacja pełnoekranowa z następującymi elementami:

• Composer: wpisywanie promptów, dołączanie plików znakiem @, uruchamianie poleceń powłoki z prefiksem !
• Panel wyjścia: strumieniowe odpowiedzi modelu, wywołania narzędzi i wyjście poleceń
• Pasek statusu: model, zużycie tokenów, gałąź git, tryb sandbox

Kluczowe skróty TUI:

Zmiana paska statusu (v0.121.0): Dotychczasowy miernik okna kontekstu na pasku statusu został zastąpiony wskaźnikiem procentowym kontekstu pokazującym, jak bardzo zapełnione jest okno kontekstu. Jeśli posiada Pan/Pani skrypty lub hooks parsujące pasek statusu, proszę sprawdzić tę zmianę formatu.⁸² Codex pokaże również komunikat o aktualizacji CLI, gdy dostępna będzie nowa wersja.

Slash commands dostępne w TUI:

Przeprojektowany picker workflow (v0.129.0): Wznawianie i forkowanie są teraz łatwiej dostępne z przeprojektowanego pickera, a nowy tryb surowego scrollbacka umożliwia przewijanie nieprzetworzonej transkrypcji, gdy zachodzi potrzeba dosłownego skopiowania poleceń lub odpowiedzi modelu. Przydatne podczas analizy długiej sesji debugowania lub przekierowywania wyjścia do innego narzędzia.⁸⁹

2. Codex Desktop App (macOS + Windows)

codex app                    # Launch desktop app (auto-installs if missing)

Aplikacja desktopowa dodaje możliwości, których CLI nie posiada:

• Wielozadaniowość: równoczesne uruchamianie wielu agentów równoległych w różnych projektach
• Izolacja git worktree: każdy wątek pracuje na izolowanej kopii repozytorium
• Wbudowany przegląd diff: wprowadzanie zmian do staging, cofanie i commitowanie bez opuszczania aplikacji
• Zintegrowany terminal: terminal per wątek do uruchamiania poleceń
• Forkowanie rozmów: rozgałęzianie rozmów w celu eksploracji alternatyw
• Pływające okna pop-out: odłączanie rozmów do przenośnych okien
• Automations: planowanie zadań cyklicznych (triaż issues, monitoring CI, reagowanie na alerty)

Kiedy używać aplikacji vs CLI: warto sięgnąć po aplikację desktopową przy koordynowaniu wielu strumieni pracy lub gdy potrzebny jest wizualny przegląd diff. Z CLI należy korzystać, gdy pożądana jest kompozycyjność terminalowa, skryptowanie lub integracja CI/CD.

3. Rozszerzenie IDE (VS Code, Cursor, Windsurf)

Rozszerzenie Codex IDE integruje się bezpośrednio z edytorem:

• Tryb agenta domyślnie: czyta pliki, wprowadza edycje, uruchamia polecenia
• Inline edits: kontekstowe sugestie w aktywnych plikach
• Współdzielone sesje: sesje synchronizują się między CLI a rozszerzeniem IDE
• Ta sama autoryzacja: logowanie kontem ChatGPT lub kluczem API

Instalacja z VS Code Marketplace lub sklepów rozszerzeń Cursor/Windsurf.³

4. Codex Cloud [EXPERIMENTAL]

Zadania w chmurze działają asynchronicznie w środowiskach zarządzanych przez OpenAI:

• Fire and forget: kolejkowanie zadań działających niezależnie od lokalnej maszyny
• Wykonywanie równoległe: równoczesne uruchamianie wielu zadań chmurowych
• Tworzenie PR: Codex tworzy pull requests z ukończonej pracy
• Lokalne zastosowanie: pobieranie wyników z chmury do lokalnego repozytorium poleceniem codex apply <TASK_ID>

codex cloud list             # List recent cloud tasks
codex apply <TASK_ID>        # Apply diff from a specific cloud task

Zadania chmurowe są również dostępne pod adresem chatgpt.com/codex.⁴

5. Codex for Chrome [NEW]

Codex jest dostarczany jako rozszerzenie przeglądarki Chrome, dodając piątą powierzchnię obok CLI, aplikacji desktopowej, rozszerzenia IDE i chmury. Rozszerzenie zostało zaprojektowane tak, aby towarzyszyć normalnemu przeglądaniu, a nie je przejmować: Codex pracuje równolegle w kartach w tle, a użytkownik zachowuje kontrolę nad tym, których witryn dotyka.⁹⁰

• Równoległe wykonywanie w kartach: Codex działa w wielu kartach jednocześnie, nie blokując aktywnej karty pierwszoplanowej.
• Kontrola per witryna: użytkownik wskazuje listę dozwolonych witryn, z którymi Codex może wchodzić w interakcję; domyślnie brak dostępu.
• Przeglądarka jako warsztat pracy: rozszerzenie najlepiej sprawdza się w pracy z aplikacjami i witrynami, w których strona jest źródłem prawdy — konsole administracyjne, wewnętrzne dashboardy, interfejsy zarządzania treścią, systemy ticketowe — a nie jako zamiennik CLI przy lokalnych repozytoriach.
• Ten sam mózg: Codex for Chrome wykorzystuje tę samą inteligencję GPT-5.x-Codex co pozostałe powierzchnie, więc konfiguracja AGENTS.md lub skills działająca w CLI wnosi te same konwencje do pracy w przeglądarce.

Instalacja z dokumentacji rozszerzenia Codex Chrome.⁹⁰

Dogłębna analiza systemu konfiguracji

Codex używa formatu TOML do konfiguracji. Zrozumienie hierarchii pierwszeństwa jest kluczowe, ponieważ to ona decyduje, które ustawienia wygrywają w przypadku konfliktu.

Pierwszeństwo (od najwyższego do najniższego)

1. Nadpisania sesji (najwyższy priorytet): flagi CLI (--model, --sandbox, --ask-for-approval, --search, --enable/--disable, --profile) oraz nadpisania -c key=value
2. Konfiguracja projektu (.codex/config.toml, wykrywana od CWD w górę aż do katalogu głównego projektu; wygrywa najbliższy katalog)
3. Konfiguracja użytkownika ($CODEX_HOME/config.toml, domyślnie ~/.codex/config.toml)
4. Konfiguracja systemowa (/etc/codex/config.toml w systemach Unix)
5. Wbudowane wartości domyślne (najniższy priorytet)

requirements.toml działa jako warstwa ograniczeń polityki, która zawęża wartości możliwe do wyboru przez użytkownika po standardowym scaleniu konfiguracji. Patrz Wdrożenie korporacyjne.

Lokalizacje plików konfiguracyjnych

Wskazówka eksperta: Zmienna środowiskowa CODEX_HOME nadpisuje domyślny katalog ~/.codex. Przydatne w konfiguracjach CI/CD lub wielokontowych.

Pełne odniesienie do konfiguracji

# ~/.codex/config.toml — annotated reference

# ─── Model Selection ───────────────────────────────────
model = "gpt-5.5"                      # Recommended model when available
model_provider = "openai"               # Provider (openai, oss, or custom provider id)
model_context_window = 272000           # Token count available to active model (override)
model_auto_compact_token_limit = 200000 # Threshold triggering automatic history compaction
model_reasoning_effort = "medium"       # minimal|low|medium|high|xhigh (model-dependent)
model_reasoning_summary = "auto"        # auto|concise|detailed|none
model_verbosity = "medium"              # low|medium|high
personality = "pragmatic"               # none|friendly|pragmatic
review_model = "gpt-5.5"               # Optional model for /review command
oss_provider = "lmstudio"              # lmstudio|ollama (used with --oss)

# ─── Sandbox & Approval ───────────────────────────────
sandbox_mode = "workspace-write"        # read-only|workspace-write|danger-full-access
approval_policy = "on-request"          # untrusted|on-request|never

[sandbox_workspace_write]
writable_roots = []                     # Additional writable paths
network_access = false                  # Allow outbound network
exclude_tmpdir_env_var = false          # Exclude $TMPDIR from sandbox
exclude_slash_tmp = false               # Exclude /tmp from sandbox

# ─── Web Search ────────────────────────────────────────
web_search = "live"                     # Web search mode (constrained by allowed modes)

# ─── Instructions ──────────────────────────────────────
developer_instructions = ""             # Additional injected instructions
model_instructions_file = ""            # Custom instructions file path
compact_prompt = ""                     # Custom history compaction prompt

# ─── Shell Environment ─────────────────────────────────
allow_login_shell = false               # Allow login shell semantics (loads .profile/.zprofile)

[shell_environment_policy]
inherit = "all"                         # all|core|none
ignore_default_excludes = false         # Set true to keep KEY/SECRET/TOKEN vars
exclude = []                            # Glob patterns to exclude
set = {}                                # Explicit overrides
include_only = []                       # Whitelist patterns

# ─── Authentication ────────────────────────────────────
cli_auth_credentials_store = "file"     # file|keyring|auto
forced_login_method = "chatgpt"         # chatgpt|api
mcp_oauth_callback_port = 0            # Fixed port for MCP OAuth callback (0 = random)
mcp_oauth_credentials_store = "auto"   # auto|file|keyring

# ─── History & Storage ─────────────────────────────────
[history]
persistence = "save-all"                # save-all|none
max_bytes = 0                           # Cap size (0 = unlimited)

tool_output_token_limit = 10000         # Max tokens per tool output
log_dir = ""                            # Custom log directory

# ─── UI & Display ──────────────────────────────────────
file_opener = "vscode"                  # vscode|vscode-insiders|windsurf|cursor|none
hide_agent_reasoning = false
show_raw_agent_reasoning = false
check_for_update_on_startup = true

[tui]
notifications = false                   # Enable notifications
notification_method = "auto"            # auto|osc9|bel
animations = true
show_tooltips = true
alternate_screen = "auto"               # auto|always|never
status_line = ["model", "context-remaining", "git-branch"]

# ─── Project Trust ─────────────────────────────────────
project_doc_max_bytes = 32768           # Max AGENTS.md size (32 KiB)
project_doc_fallback_filenames = []     # Alternative instruction filenames
project_root_markers = [".git"]         # Project root detection

# ─── Feature Flags ─────────────────────────────────────
# Use `codex features list` for current names/stages/defaults.
[features]
shell_tool = true                       # Shell command execution (stable)
collaboration_modes = true              # Plan mode (stable)
personality = true                      # Personality selection (stable)
request_rule = true                     # Smart approvals (stable)
unified_exec = true                     # PTY-backed exec (stable)
shell_snapshot = true                   # Shell env snapshots (stable)
command_attribution = true              # Codex co-author in commits (v0.103.0+)
request_user_input = true               # Allow agent to ask clarifying questions in Default mode (v0.106.0+)
multi_agent = false                     # Enable multi-agent collaboration tools (v0.102.0+)
apply_patch_freeform = false            # Expose freeform apply_patch tool
apps = false                            # ChatGPT Apps/connectors (experimental)
child_agents_md = false                 # AGENTS.md guidance (experimental)
runtime_metrics = false                 # Runtime summary in turns
search_tool = false                     # Enable search_tool_bm25 for Apps discovery

# ─── Multi-Agent Roles (v0.102.0+) ───────────────────
[agents]
max_threads = 4                         # Maximum concurrent agent threads

[agents.explorer]
description = "Read-only codebase navigator"
config_file = "~/.codex/profiles/explorer.toml"

# ─── Notifications ────────────────────────────────────
notify = ["terminal-notifier", "-title", "Codex"]  # Command for notifications

# ─── Per-Project Overrides ────────────────────────────
[projects."/absolute/path/to/repo"]
trust_level = "trusted"                 # Per-project trust override

Profile

Nazwane szablony konfiguracji dla różnych trybów pracy:

# Define profiles in ~/.codex/config.toml

[profiles.fast]
model = "gpt-5.1-codex-mini"
model_reasoning_effort = "low"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
personality = "pragmatic"

[profiles.careful]
model = "gpt-5.4"
model_reasoning_effort = "xhigh"
approval_policy = "untrusted"
sandbox_mode = "read-only"

[profiles.auto]
model = "gpt-5.4"
model_reasoning_effort = "medium"
approval_policy = "never"
sandbox_mode = "workspace-write"

Aktywacja profilu:

codex --profile fast "quick refactor"
codex --profile careful "security audit"
codex -p auto "fix CI"

Wskazówka eksperta: Można ustawić domyślny profil za pomocą profile = "fast" na najwyższym poziomie konfiguracji. Nadpisanie per sesję realizuje się flagą --profile.

Niestandardowi dostawcy modeli

Połączenie z Azure, AWS Bedrock, lokalnymi modelami lub usługami proxy:

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://YOUR_PROJECT.openai.azure.com/openai"
wire_api = "responses"
query_params = { api-version = "2025-04-01-preview" }
env_key = "AZURE_OPENAI_API_KEY"

# Built-in amazon-bedrock provider (v0.123.0+, first-class in v0.124.0+)
# AWS SigV4 signing + credential-based auth; AWS profile selectable via the
# nested `aws.profile` field (NOT a top-level `aws_profile` key).
# v0.130.0+ also accepts credentials from `aws login` (the AWS console-login
# flow) — Codex resolves the cached console-login session for the chosen
# profile if static keys are absent.
[model_providers.amazon-bedrock]
name = "Amazon Bedrock"

[model_providers.amazon-bedrock.aws]
profile = "default"                   # any profile from ~/.aws/credentials
# Region/credential resolution otherwise follows the standard AWS chain;
# v0.130.0 added support for `aws login` console-login profiles in addition
# to static access keys and IAM role assumption.[^168]

[model_providers.ollama]
name = "Ollama (Local)"
base_url = "http://localhost:11434/v1"
wire_api = "chat"

Ostrzeżenie: Wire API chat/completions (wire_api = "chat") został wycofany dla modeli hostowanych przez OpenAI, a OpenAI ogłosiło jego usunięcie w lutym 2026 roku.³⁴ Lokalni dostawcy (Ollama, LM Studio) mogą nadal akceptować ten format. Dla punktów końcowych OpenAI należy zamiast tego używać wire_api = "responses".

Korzystanie z modeli lokalnych za pomocą flagi --oss:

codex --oss "explain this function"               # Uses default OSS provider
codex --oss --local-provider lmstudio "explain"   # Explicit LM Studio
codex --oss --local-provider ollama "explain"      # Explicit Ollama

Lub ustawienie w konfiguracji:

model_provider = "oss"
oss_provider = "lmstudio"   # or "ollama"

Wbudowane nadpisania konfiguracji

Nadpisanie dowolnej wartości konfiguracji z wiersza poleceń:

codex -c model="gpt-5.5" "refactor the API"
codex -c 'sandbox_workspace_write.network_access=true' "install dependencies"
codex -c model_reasoning_effort="xhigh" "debug the race condition"

Który model wybrać?

Dostępne modele (kwiecień 2026)

GPT-5.5 (23 kwietnia 2026) to rekomendowany przez OpenAI wybór do większości zadań Codex: złożonego programowania, obsługi komputera, pracy z wiedzą oraz przepływów badawczych. Dostępny w Codex CLI / web / desktop od 23 kwietnia dla ChatGPT Plus / Pro / Business / Enterprise / Edu / Go; w OpenAI API od 24 kwietnia. Okno kontekstu: 400K w Codex, 1M w API — Codex ogranicza okno do 400K, aby zrównoważyć przepustowość i koszt w różnych poziomach subskrypcji; API udostępnia pełny 1M. Cennik (API): 5 USD wejście / 30 USD wyjście za MTok (2× stawka GPT-5.4; OpenAI podaje ~20% efektywnego wzrostu po usprawnieniach efektywności tokenów). Benchmarki: 82,7% Terminal-Bench 2.0 (aktualny SOTA wśród publicznie dostępnych modeli), 84,9% GDPval (44 zawody), 78,7% OSWorld-Verified, 98,0% Tau2-bench Telecom (bez tuningu promptów). OpenAI wykorzystało GPT-5.5 + Codex wewnętrznie do przepisania infrastruktury serwującej przed premierą — przyniosło to 20% wzrost prędkości generowania tokenów.⁸³

GPT-5.4 pozostaje dostępny na wszystkich powierzchniach Codex (CLI, aplikacja, rozszerzenie IDE, chmura).⁶⁴ Dokładna lista modeli zależy od konta i etapu wdrożenia. Można sprawdzić lokalną pamięć podręczną: ~/.codex/models_cache.json.

Uwaga o wycofaniu (11 marca 2026): Modele GPT-5.1 nie są już dostępne w ChatGPT. Istniejące konwersacje automatycznie kontynuują pracę na GPT-5.3 Instant, GPT-5.4 Thinking lub GPT-5.4 Pro. GPT-5.1-Codex-Mini pozostaje dostępny przez API i CLI do obciążeń wrażliwych na koszty.⁷¹

Uwaga o wersji bezpłatnej (5 maja 2026): GPT-5.5 Instant został wdrożony na bezpłatnym poziomie ChatGPT 5 maja 2026. Poszerza to grono odbiorców rodziny GPT-5.5 poza plany płatne, choć dostęp do Codex CLI nadal wymaga uprawnionej subskrypcji Plus / Pro / Business / Enterprise / Edu / Go lub klucza API.⁹²

GPT-5.4 mini (17 marca 2026): Mniejszy, szybszy wariant GPT-5.4 z kontekstem 400K za 0,75 USD/4,50 USD za MTok — wykorzystuje tylko 30% limitu GPT-5.4. Idealny do delegowania do subagentów: GPT-5.4 może zająć się planowaniem i koordynacją, podczas gdy subagenci GPT-5.4 mini równolegle obsługują węższe podzadania (przeszukiwanie bazy kodu, przegląd plików, przetwarzanie dokumentów).⁷⁶

Schemat wyboru modelu

Is this a quick fix or simple question?
├─ Yes → gpt-5.1-codex-mini (fastest, cheapest)
└─ No
   ├─ Do you need real-time pairing speed?
   │  ├─ Yes → gpt-5.3-codex-spark (near-instant, Pro only)
   │  └─ No
   │     ├─ Subagent or parallel subtask (search, review, processing)?
   │     │  ├─ Yes → gpt-5.4-mini (30% of GPT-5.4 quota, 2x faster)
   │     │  └─ No
   │     │     ├─ Pure coding task (refactor, migration, feature build)?
   │     │     │  ├─ Yes → gpt-5.3-codex (coding specialist, 272K context)
   │     │     │  └─ No → gpt-5.5 (new flagship: 400K context in Codex / 1M in API, 82.7% Terminal-Bench 2.0 SOTA)
   └─ Still unsure? → gpt-5.5

Wysiłek wnioskowania

Można kontrolować, ile model „myśli” przed udzieleniem odpowiedzi:

Obsługiwane poziomy zależą od modelu. minimal jest dostępny tylko dla modeli GPT-5. Nie wszystkie modele obsługują każdy poziom.

codex -c model_reasoning_effort="xhigh" "find the race condition"

Wskazówka eksperta: Wnioskowanie xhigh może zużywać 3-5x więcej tokenów niż medium przy tym samym prompcie. Warto rezerwować je dla rzeczywiście trudnych problemów, w których dodatkowe myślenie się opłaca.

Szybkie sterowanie wnioskowaniem w TUI (v0.124.0+).⁸⁵ W interaktywnej sesji TUI Alt+, obniża wnioskowanie o jeden poziom, a Alt+. podnosi je o jeden poziom — przydatne, gdy trudny problem w trakcie sesji uzasadnia tymczasowe przejście medium → high → xhigh bez użycia /effort lub -c. Po zaakceptowaniu uaktualnienia modelu w trakcie sesji wnioskowanie resetuje się do domyślnej wartości nowego modelu, zamiast przenosić poprzedni poziom.

Przełączanie modeli

Można przełączać modele w trakcie sesji za pomocą polecenia slash /model lub ustawiać per-uruchomienie przez --model / -m:

codex -m gpt-5.3-codex-spark "pair with me on this component"

Ile kosztuje Codex?

Zobacz także Wybór modelu, aby poznać możliwości, oraz Ramy decyzyjne — pomocne przy doborze właściwego modelu do zadania.

Dostęp poprzez plany ChatGPT

Dostępność Codex zależy od planu ChatGPT oraz ustawień organizacji:⁵¹

Aktualizacja cen z kwietnia 2026: Cena roczna Business spadła z $25 do $20 za stanowisko/mies. Stanowiska tylko-Codex z rozliczaniem pay-as-you-go są teraz dostępne dla obszarów roboczych Business i Enterprise — brak stałej opłaty za stanowisko, rozliczanie wg zużycia tokenów.⁷⁹ Promocyjne 2x limity szybkości dla planów płatnych (od premiery Desktop App w lutym 2026) pozostają aktywne.¹⁶

Zwiększenie limitów użycia w maju 2026 (do 31 maja 2026): Codex w planie Plus działa z 25× limitem 5-godzinnym (w porównaniu do standardowego boosta 20×), a poziom $100/miesiąc został podwojony w tym samym okresie. Warto wykorzystać ten czas na dłuższe partie zadań w chmurze lub przepustowe uruchomienia agentów bez uderzania w standardową ścianę 5-godzinną.⁸⁹

Koszty kredytów

Operacje Codex zużywają kredyty z alokacji planu:

Plany Enterprise i Edu skalują kredyty wraz z alokacją w umowie. Aby sprawdzić bieżące zużycie, należy użyć /status w TUI.

Rozliczanie API

W przypadku korzystania z Codex poprzez API, OpenAI rozlicza użycie wg tokenów według standardowych cen API OpenAI dla wybranego modelu (plus ewentualne zniżki za prompt-caching). Aktualne stawki znajdują się na oficjalnej stronie cennika API.²⁰

Strategie optymalizacji kosztów

1. Wykorzystanie profili: Warto utworzyć profil fast z gpt-5.1-codex-mini i model_reasoning_effort = "low" do rutynowych zadań
2. Rezerwowanie wysokiego reasoning: Tryb xhigh należy stosować tylko do naprawdę trudnych problemów, ponieważ kosztuje 3-5x więcej tokenów
3. Stosowanie --ephemeral: Pomijanie utrwalania sesji w CI/CD redukuje narzut
4. Minimalizacja podsumowań reasoning: Należy ustawić model_reasoning_summary = "none", gdy wyjaśnienia nie są potrzebne
5. Batchowanie w trybie exec: codex exec unika narzutu TUI w przepływach automatyzacji
6. Monitorowanie użycia: Należy sprawdzać /status w TUI oraz pulpity rozliczeniowe organizacji

Przykłady kosztów z praktyki

Reprezentatywne koszty API dla typowych zadań (gpt-5.3-codex w cenie standardowej, średni reasoning):

Koszty zmieniają się wraz z reasoning effort, cachowaniem i długością rozmowy. Warto używać gpt-5.1-codex-mini do rutynowych zadań, co redukuje koszty o ~40-60%. Cachowane tokeny wejściowe są rozliczane ze zniżką.

Ukryty narzut tokenów

Każde wywołanie narzędzia dodaje tokeny ponad widoczny prompt:

Wskazówka eksperta: Należy monitorować rzeczywiste użycie poprzez /status w TUI. Liczba tokenów obejmuje cały narzut, nie tylko widoczne wiadomości. Jeśli koszty zaskakują, warto sprawdzić, ile serwerów MCP jest podłączonych — każdy dodaje definicje narzędzi do każdego wywołania API.

Zarządzanie kosztami w zespole

Strategie kontroli kosztów w zespole: - Ustawienie requirements.toml w celu egzekwowania limitów modelu i reasoning effort w skali całej organizacji - Stosowanie gpt-5.1-codex-mini w CI/CD — zautomatyzowane pipeline’y rzadko wymagają maksymalnego reasoning - Budżetowanie oparte na profilach — definiowanie profili ci, review i dev z odpowiednimi pułapami kosztów - Monitorowanie poprzez OpenTelemetry — wdrożenia enterprise mogą eksportować telemetrię użycia do istniejących stosów obserwowalności

Ramy decyzyjne

Kiedy używać poszczególnych powierzchni

Kiedy używać poszczególnych trybów sandbox

Kiedy używać poszczególnych poziomów rozumowania

Plan Mode kontra wykonanie bezpośrednie

Will Codex need to change more than 3 files?
│
├── YES → Use Plan Mode (/plan)
│         Codex designs the approach BEFORE making changes.
│         You review and approve the plan.
│         Best for: refactors, new features, migrations
│
└── NO → Is the change well-defined?
         │
         ├── YES → Direct execution
         │         Just describe the task. Codex executes immediately.
         │         Best for: bug fixes, small features, test additions
         │
         └── NO → Use Plan Mode (/plan)
                  Let Codex explore and propose an approach first.
                  Best for: unfamiliar codebases, ambiguous requirements

Steer Mode: Enter kontra Tab

Zasada ogólna: Enter = „zatrzymaj się, posłuchaj tego teraz.” Tab = „kiedy skończysz, zrób też to.”

Desktop App kontra CLI

How do you prefer to work?
│
├── Terminal-first → Use CLI
│   │
│   ├── Single focused task → codex (interactive TUI)
│   ├── Scripted automation → codex exec (non-interactive)
│   └── Quick one-shot → codex exec "prompt" -o result.txt
│
└── Visual/multi-project → Use Desktop App
    │
    ├── Multiple parallel tasks → Multi-thread with worktree isolation
    ├── Visual diff review → Built-in Git diff viewer
    ├── Scheduled automation → Automations tab
    └── Voice-driven → Ctrl+M for voice dictation

Który profil?

Proszę dopasować zadanie do wstępnie skonfigurowanego profilu:

Konfiguracja config.toml:

# Default profile
profile = "default"

[profiles.fast]
model = "gpt-5.1-codex-mini"
model_reasoning_effort = "low"

[profiles.careful]
model = "gpt-5.3-codex"
model_reasoning_effort = "xhigh"

[profiles.pair]
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "high"

[profiles.ci]
model = "gpt-5.1-codex-mini"
model_reasoning_effort = "low"
sandbox_mode = "workspace-write"

Przełączanie profili dla każdej sesji: codex --profile careful

Jak działa system Sandbox i zatwierdzania?

Codex wykorzystuje dwuwarstwowy model bezpieczeństwa, który oddziela to, co jest technicznie możliwe od tego, kiedy Codex prosi o zatwierdzenie przez człowieka. Podejście to różni się fundamentalnie od systemu uprawnień Claude Code — Codex egzekwuje ograniczenia na poziomie jądra systemu operacyjnego.⁵ Zob. także Enterprise Deployment, gdzie omówiono ograniczenia requirements.toml egzekwowane przez administratorów w całej organizacji.

Warstwa 1: Sandbox (co jest możliwe)

Sandbox kontroluje dostęp do systemu plików i sieci, wykorzystując mechanizmy natywne systemu operacyjnego:

Egzekwowanie zależne od platformy:

• macOS: framework Apple Seatbelt poprzez sandbox-exec z profilami zależnymi od trybu, kompilowanymi w czasie wykonania i egzekwowanymi przez jądro⁶. Począwszy od v0.121.0, profile sandboxa macOS mogą zawierać na liście dozwolonych konkretne gniazda Unix (np. docker.sock, gniazda IPC edytora), a prywatne rozpoznawanie DNS nie jest już domyślnie blokowane.⁸²
• Linux: Landlock dla ograniczeń systemu plików + seccomp dla filtrowania wywołań systemowych. Samodzielny proces pomocniczy (codex-linux-sandbox) zapewnia izolację typu defense-in-depth.⁵ Bubblewrap (bwrap) jest dołączony do projektu i kompilowany jako część buildu Linux (awansowany ze statusu opcjonalnego w v0.100.0)⁷. v0.117.0 poprawiła niezawodność sandboxa na starszych dystrybucjach z legacy konfiguracjami jądra.⁷⁵ v0.129.0 wzmocniła startup sandboxa w Linuksie i podniosła wersję dołączonego Bubblewrap do 0.11.2 z upstreamowymi łatami bezpieczeństwa; v0.130.0 dodała kolejne wzmocnienia startupu.⁸⁹⁹¹
• Windows: natywny sandbox z restricted tokens (awansowany ze statusu eksperymentalnego w v0.100.0). Wspierany jest również WSL (dziedziczy Landlock + seccomp z Linuksa). v0.117.0 zawiera ulepszenia sandboxa z restricted-token zapewniające lepszą izolację procesów.⁷⁵ v0.130.0 nadaje użytkownikom sandboxa dostęp do pamięci podręcznej binariów runtime pulpitu, dzięki czemu sandbox Windows może niezawodnie rozwiązywać binaria runtime dla użytkowników workspace-sandbox.⁹¹

Dlaczego to ma znaczenie: w przeciwieństwie do sandboxingu opartego na kontenerach (Docker), sandboxing na poziomie systemu operacyjnego jest szybszy, lżejszy i trudniejszy do obejścia. Jądro egzekwuje ograniczenia, zanim Codex w ogóle zobaczy wywołanie systemowe.

Poprawki bezpieczeństwa: - Obejście sandboxa przez fork zsh (v0.106.0): naprawiono podatność, w której wykonanie powłoki przez forkowanie zsh mogło obejść ograniczenia sandboxa.⁶⁰ Jeśli korzysta się z wcześniejszej wersji, należy niezwłocznie zaktualizować. - Limit rozmiaru wejścia (v0.106.0): Codex egzekwuje obecnie limit wejścia wynoszący około 1 miliona znaków, aby zapobiec zawieszeniom spowodowanym nadmiernie dużymi payloadami.⁶⁰ - Bezpieczny profil devcontainer (v0.121.0): nowy wzmocniony profil klienta dla devcontainerów Docker wykorzystuje Bubblewrap do sandboxingu wewnątrz kontenera. WSL2 jest wspierany; WSL1 jest jawnie odrzucony (Bubblewrap jest niekompatybilny z shimem jądra WSL1).⁸² - Guardian review + hooks (v0.121.0): hooks są wyłączone podczas sesji Guardian review, aby pre/post-tool hooks nie mogły zakłócać decyzji subagenta Guardian.⁸² Jeśli polega się na hooks dla logowania lub walidacji, należy mieć świadomość, że Guardian review je pomija — w razie potrzeby pełnego śladu audytowego należy oprzeć się na obserwowalności app-server. - System plików /dev w Linuksie (v0.105.0): polecenia działające w sandboxie w Linuksie otrzymują obecnie minimalny system plików /dev, co poprawia kompatybilność z narzędziami oczekującymi węzłów urządzeń.⁶¹

Polityka ReadOnlyAccess (v0.100.0+): konfigurowalny kształt polityki dla granularnej kontroli dostępu do odczytu. Można ją wykorzystać do ograniczenia katalogów, z których Codex może odczytywać, nawet w trybie workspace-write:

[sandbox_workspace_write]
read_only_access = ["/etc", "/usr/local/share"]  # Only these paths readable outside workspace

Warstwa 2: Polityka zatwierdzania (kiedy pytać)

Polityka zatwierdzania określa, kiedy Codex zatrzymuje się, aby poprosić o potwierdzenie przez człowieka:

on-failure nadal pojawia się w niektórych starszych przykładach i ścieżkach kompatybilności, ale aktualna dokumentacja konfiguracyjna OpenAI oznacza ją jako przestarzałą. Dla uruchomień interaktywnych warto preferować on-request, a dla uruchomień nieinteraktywnych, które mają już zewnętrzną granicę bezpieczeństwa — never.⁸⁷

Odrębne ID zatwierdzeń (v0.104.0+)

Codex przypisuje obecnie odrębne ID zatwierdzenia każdemu poleceniu w wieloetapowym wykonaniu powłoki. Oznacza to, że zatwierdzenia są granularne — zatwierdzenie jednego polecenia w sekwencji nie zatwierdza automatycznie kolejnych w tym samym wywołaniu powłoki.⁴⁹

Elastyczne kontrolki zatwierdzania (v0.105.0+)

Przepływ zatwierdzania wspiera obecnie dodatkowe uprawnienia sandboxa oraz granularne odrzucanie:⁶¹

• Dodatkowe uprawnienia sandboxa: gdy polecenie potrzebuje dostępu wykraczającego poza bieżący tryb sandboxa, Codex może zażądać konkretnych dodatkowych uprawnień zamiast wymagać pełnej zmiany trybu
• Granularne odrzucanie: można odrzucić poszczególne wywołania narzędzi wraz z informacją zwrotną, dzięki czemu Codex może dostosować swoje podejście, zamiast po prostu ponawiać to samo polecenie

Żądania uprawnień w czasie wykonania (v0.113.0+)

Codex zawiera obecnie wbudowane narzędzie request_permissions, które umożliwia modelowi żądanie dodatkowych uprawnień w czasie wykonania.⁶⁹ Gdy model napotyka zadanie wymagające podwyższonego dostępu, może formalnie zażądać konkretnych uprawnień (ścieżek systemu plików, dostępu sieciowego itd.) poprzez przepływ zatwierdzania w TUI, zamiast zawodzić cicho lub wymagać od użytkownika ponownego uruchomienia z innymi flagami.

Profile uprawnień (v0.113.0+, rozszerzone w v0.128.0)

Profile uprawnień dzielą polityki sandboxa systemu plików i sieci na nazwane, wielokrotnego użytku sekcje. Należy ustawić default_permissions na wbudowany profil, taki jak :read-only, :workspace lub :danger-no-sandbox, albo wskazać go na niestandardową tabelę [permissions.<name>].⁸⁷

default_permissions = "project-safe"

[permissions.project-safe.filesystem]
"/usr/local" = "read"
glob_scan_max_depth = 3

[permissions.project-safe.filesystem.":project_roots"]
"." = "write"
"**/*.env" = "none"

[permissions.project-safe.network]
enabled = true
mode = "limited"

[permissions.project-safe.network.domains]
"api.github.com" = "allow"
"registry.npmjs.org" = "allow"

Należy używać none dla wrażliwych plików i wzorców glob, które powinny być nieczytelne nawet wtedy, gdy katalog główny projektu jest zapisywalny. Dla jednorazowych wyjątków poleceń lepiej preferować reguły niż szerokie rozszerzanie profilu.⁸⁷

Wskazówki dotyczące przestarzałego --full-auto

Starsze przewodniki opisywały --full-auto jako wygodny alias dla:

codex --sandbox workspace-write --ask-for-approval on-request

W v0.128.0 release notes oznaczają --full-auto jako przestarzały, a aktualna pomoc CLI nie wymienia go już dla uruchomień interaktywnych. Zamiast tego należy używać jawnych flag powyżej lub nazwanego profilu uprawnień.⁸⁶

Niezawodność sandboxa (v0.129.0): wzmocnienie startupu sandboxa w Linuksie redukuje wyścigi na wolnych systemach plików lub checkoutach z linkami symbolicznymi; usprawnienia niezawodności sandboxa w Windows adresują kilka brzegowych awarii podczas długo trwających uruchomień; a dołączony Bubblewrap został podbity do 0.11.2 z upstreamowymi łatami bezpieczeństwa. Nie są wymagane żadne zmiany konfiguracji. Należy uruchomić codex update, aby je pobrać.⁸⁹

Rekomendowane konfiguracje

Codzienny rozwój (bezpieczne ustawienie domyślne):

sandbox_mode = "workspace-write"
approval_policy = "on-request"

Power user (pełny dostęp, human-in-the-loop):

sandbox_mode = "danger-full-access"
approval_policy = "untrusted"

To połączenie jest rekomendowanym przez społeczność „złotym środkiem”: maksymalne możliwości, ale zatwierdzenie wymagane przy każdym poleceniu.⁸

Automatyzacja CI/CD:

sandbox_mode = "workspace-write"
approval_policy = "never"

Smart Approvals z subagentem Guardian (v0.115.0+)

Smart Approvals mogą kierować żądania review przez subagenta guardian zamiast wymagać zatwierdzenia przez człowieka dla każdej akcji. Sesja guardian utrzymuje się pomiędzy zatwierdzeniami, aby ponownie wykorzystać prompt cache i uniknąć narzutu uruchamiania. Każdy review otrzymuje czystą historię (wcześniejsze decyzje nie wyciekają do późniejszych przeglądów).⁷³

Konfigurowanie reviewera w config.toml:

approvals_reviewer = "guardian_subagent"   # "user" (default) or "guardian_subagent"

Jest to szczególnie użyteczne w workflowach CI/CD, gdzie pożądane jest zautomatyzowane review z rozumowaniem zamiast blanket approval_policy = "never".

Włączanie dostępu sieciowego

Codex domyślnie blokuje dostęp do sieci w trybie workspace-write. Należy włączyć go w razie potrzeby:

# Per-run
codex -c 'sandbox_workspace_write.network_access=true' "install the packages"

# In config.toml
[sandbox_workspace_write]
network_access = true
writable_roots = ["/path/to/extra/dir"]   # Additional writable directories
exclude_slash_tmp = false                  # Prevent /tmp from being writable
exclude_tmpdir_env_var = false             # Prevent $TMPDIR from being writable

Wsparcie proxy WebSocket (v0.104.0+)

Dla środowisk korporacyjnych, które kierują ruch WebSocket przez proxy, Codex obsługuje obecnie zmienne środowiskowe WS_PROXY i WSS_PROXY:⁴⁹

export WSS_PROXY="https://proxy.corp.example.com:8443"
codex "update the README"

Uzupełniają one istniejące wsparcie dla HTTPS_PROXY i SOCKS5 proxy (v0.93.0+), pokrywając wszystkie warstwy transportowe.

Testowanie sandboxa

Należy zweryfikować zachowanie sandboxa, zanim mu się zaufa:

codex sandbox macos --permissions-profile :workspace -- ls /etc/passwd   # macOS test
codex sandbox linux --permissions-profile :workspace -- cat /etc/shadow  # Linux test

Jeśli sandbox działa poprawnie, oba polecenia powinny zakończyć się błędem permission denied w profilu o zasięgu workspace. Jeśli któreś z poleceń się powiedzie, konfiguracja sandboxa wymaga zbadania.

Jak działa AGENTS.md?

AGENTS.md to system instrukcji projektowych Codex — otwarty standard⁹, którym obecnie zarządza Agentic AI Foundation należąca do Linux Foundation. Obsługują go Codex, Cursor, Copilot, Amp, Jules (Google), Gemini CLI, Windsurf, Cline, Aider, Zed, Factory, RooCode oraz ponad 60 000 projektów open source. Określa on, jak Codex zachowuje się w konkretnym repozytorium lub katalogu. Zobacz Skills, aby poznać pakiety wiedzy eksperckiej wielokrotnego użytku, które uzupełniają AGENTS.md.

Hierarchia wykrywania

Codex buduje łańcuch instrukcji na początku sesji, przechodząc przez drzewo katalogów:

1. Globalne (~/.codex/): AGENTS.override.md > AGENTS.md
2. Projektowe (od katalogu głównego git do bieżącego katalogu): na każdym poziomie sprawdzane są AGENTS.override.md > AGENTS.md > zapasowe nazwy plików
3. Scalanie: pliki są łączone od katalogu głównego w dół; pliki bliższe bieżącemu katalogowi pojawiają się później w prompt i zastępują wcześniejsze wytyczne

~/.codex/AGENTS.md                     ← Global defaults
  └─ /repo/AGENTS.md                   ← Project-wide rules
      └─ /repo/services/AGENTS.md      ← Service-specific rules
          └─ /repo/services/payments/
               AGENTS.override.md      ← Overrides everything above for this dir

Co wyróżnia świetny AGENTS.md

Na podstawie bezpośrednich wskazówek od samego Codex oraz wzorców społeczności¹⁰:

WARTO: - Pisać konkretnie: "Use rg --files for discovery" działa lepiej niż "search efficiently" - Zdefiniować warunki ukończenia: co oznacza „gotowe”? (testy przechodzą, lint bez błędów itd.) - Uwzględnić polecenia: budowanie, testy, lint, formatowanie (dokładne wywołania) - Organizować według zadań: sekcje dotyczące kodowania, review, release, incydentów/debugowania - Zdefiniować eskalację: co zrobić w razie blokady lub napotkania nieoczekiwanego stanu

NIE NALEŻY: - Wrzucać całych przewodników stylistycznych bez reguł wykonania - Używać niejednoznacznych dyrektyw („zachowaj ostrożność”, „optymalizuj”) - Łączyć sprzecznych priorytetów (szybkość + wyczerpująca weryfikacja + brak budżetu runtime) - Pisać dokumentacji opisowej (AGENTS.md to polityka operacyjna, nie README)

Przykład: produkcyjny AGENTS.md

# Repository Guidelines

## Build, Test, and Development Commands
- Run API (dev): `python3 -m uvicorn main:app --reload`
- Install deps: `pip install -r requirements.txt`
- Lint: `python3 -m ruff check .` (auto-fix: `--fix`)
- Format: `python3 -m ruff format .`
- Tests: `python3 -m pytest -v`
- Coverage: `python3 -m pytest --cov=app --cov-report=term-missing`

## Coding Style & Naming Conventions
- Python 3.11+. Type hints on all functions.
- Ruff enforced: 88-char lines, double quotes, spaces for indent.
- Naming: modules `snake_case.py`, classes `PascalCase`, functions `snake_case`.

## Commit & Pull Request Guidelines
- Conventional Commits: `feat:`, `fix:`, `docs:`, `refactor:`, `chore:`, `test:`
- Commits should be small and focused.
- PRs must include: description, test plan, and screenshots for UI changes.

## Security
- Never commit secrets. Use `.env` for local config.
- Validate all external API calls with proper error handling.

Obsługa sekretów w sesjach agenta

Historię widoczną dla Codex należy traktować jako powierzchnię bezpieczeństwa, a nie tylko kod źródłowy. Release notes Codex dokumentują prace nad snapshotami shell i redakcją zmiennych środowiskowych, a system pamięci skanuje zapisy pamięci pod kątem sekretów, ale te zabezpieczenia nie sprawiają, że dane wyjściowe poleceń, transkrypty sesji, snapshoty shell, lokalne logi czy skrypty pomocnicze stają się bezpiecznymi miejscami do drukowania poświadczeń.³⁷⁵⁵⁹⁵

Zasada działania jest prosta: nie drukować sekretów do inspekcji przez model; przechowywać pomocnicze poświadczenia w konfiguracji wymaganej przez środowisko; podczas audytów oddzielać wykonywalne źródła, dokumentację, wygenerowane cache, transkrypty sesji, snapshoty shell, logi i celowe magazyny sekretów; redagować lokalną historię, gdy pojawia się kształt sekretu o wysokiej pewności; oraz promować hooks prewencyjne dopiero po udowodnieniu ręcznej pętli higieny. Publiczną lekcją jest mapa powierzchni i kryteria akceptacji, nie prywatne wartości tokenów, dokładne ścieżki ani wewnętrzne mechanizmy detektorów.⁹⁵

Mechanizm override

AGENTS.override.md na dowolnym poziomie katalogu zastępuje zwykły AGENTS.md dla danego zakresu. Stosować do:

• Zamrożeń release: „Bez nowych funkcji, tylko poprawki”
• Trybu incydentu: „Wszystkie zmiany muszą zostać sprawdzone przez osobę dyżurną”
• Tymczasowego utwardzania: „Bez aktualizacji zależności w tym sprincie”

Konfiguracja

# Custom fallback filenames (in addition to AGENTS.md)
project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]

# Increase max size for large instruction files
project_doc_max_bytes = 65536    # 64 KiB (default: 32 KiB)

Generowanie szkieletu

codex                           # Launch TUI
/init                           # Generate AGENTS.md scaffold

Lub zweryfikować łańcuch instrukcji:

codex --ask-for-approval never "Summarize your current instructions"

Hooks

Codex wprowadził hooks w v0.99.0 (AfterAgent) i v0.100.0 (AfterToolUse), a następnie dodał eksperymentalny silnik hooks w v0.114.0 ze zdarzeniami SessionStart i Stop.⁷⁰ Od v0.124.0 (23 kwietnia 2026) hooks są stabilne.⁸⁵ Obecnie można je konfigurować inline w config.toml i requirements.toml — nie jest już wymagany osobny plik skryptów hook — i obserwują narzędzia MCP obok apply_patch oraz długotrwałych sesji Bash. System obejmuje teraz cykl życia sesji i automatyzację na poziomie narzędzi, domykając lukę względem modelu hooks w Claude Code.

Dostępne zdarzenia hook

Konfiguracja hook

Hooks konfiguruje się w .codex/config.toml:

[[hooks]]
event = "AfterToolUse"
command = "echo 'Tool completed' >> /tmp/codex-log.txt"

[[hooks]]
event = "SessionStart"
command = "echo 'Current date: $(date +%Y-%m-%d)'"

Stdout hook SessionStart trafia do kontekstu modelu, dzięki czemu świetnie nadaje się do wstrzykiwania dynamicznych informacji (dat, nazw branch, zmiennych środowiskowych) na początku sesji.

Odtwarzanie wzorców hooks z Claude Code

W przypadku migracji z Claude Code podobną automatyzację można uzyskać tak:

Wskazówka ekspercka: Od v0.124.0 (23 kwietnia 2026) silnik hooks jest stabilny. Nowe zdarzenia hook nadal trafiają do kolejnych wydań — proszę sprawdzić Codex changelog.

Przeglądarka hooks w TUI (v0.129.0): Uruchomić /hooks w TUI, aby odkryć dostępne hooks, zobaczyć, które są obecnie aktywne, i przełączać pojedyncze hooks bez edytowania config.toml. Przydatne podczas rozwiązywania problemów ze źle działającym hook dołączonym do plugin lub tymczasowego wyłączania lintera AfterToolUse na czas skupionej sesji edycji.⁸⁹

Czym jest MCP (Model Context Protocol)? [EXPERIMENTAL]

MCP rozszerza możliwości Codex przez połączenie z zewnętrznymi narzędziami i usługami. Grupa poleceń codex mcp jest obecnie oznaczona jako eksperymentalna, a polecenia i format konfiguracji mogą zmieniać się między wydaniami. Codex obsługuje dwa typy transportu: STDIO (procesy lokalne) oraz Streamable HTTP (serwery zdalne).¹¹

Zmiany MCP w v0.121.0: Narzędzia są teraz rejestrowane z namespace, dlatego nazwy narzędzi na listach pojawiają się jako <server>:<tool>, a nie jako same nazwy — należy zaktualizować wszystkie skrypty lub prompty, które używają grep wobec niekwalifikowanych nazw narzędzi. Nowa flaga supports_parallel_tool_calls jest przekazywana do dołączonych MCP, co umożliwia równoległe wykonywanie na serwerach deklarujących takie wsparcie. Metadane stanu sandbox trafiają teraz przez metadane narzędzi MCP, aby serwery mogły dostosować zachowanie (np. ostrzec, jeśli działają w sandboxie read-only). Niestandardowe żądanie codex/sandbox-state zostało usunięte — zamiast niego należy używać ścieżki metadanych. Tutaj trafia faza 3 wdrożenia aplikacji MCP z obsługą wywołań narzędzi; spłaszczone odroczone wywołania narzędzi są teraz obsługiwane dla serwerów korzystających ze wzorca odroczonych wywołań.⁸²

Konfigurowanie serwerów MCP

Serwery STDIO (procesy lokalne):

# In ~/.codex/config.toml or .codex/config.toml

[mcp_servers.context7]
enabled = true
required = true                         # Fail startup if unavailable
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env = { "MY_VAR" = "value" }            # Static env vars
env_vars = ["PATH", "HOME"]             # Forward host env vars
cwd = "/path/to/project"                # Optional working directory
startup_timeout_sec = 10
tool_timeout_sec = 60
enabled_tools = ["search", "summarize"]  # Tool allowlist
disabled_tools = ["slow-tool"]           # Tool denylist

Serwery HTTP (zdalne):

[mcp_servers.figma]
enabled = true
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"
http_headers = { "X-Figma-Region" = "us-east-1" }
env_http_headers = { "X-Org-Id" = "FIGMA_ORG_ID" }  # Headers from env vars
startup_timeout_sec = 10
tool_timeout_sec = 60

Zarządzanie CLI

codex mcp add context7 -- npx -y @upstash/context7-mcp
codex mcp add context7 --env API_KEY=... -- npx -y @upstash/context7-mcp   # With env vars
codex mcp add figma --url https://mcp.figma.com/mcp --bearer-token-env-var FIGMA_OAUTH_TOKEN
codex mcp list                          # List all configured servers
codex mcp list --json                   # JSON output
codex mcp get context7                  # Show server config
codex mcp get context7 --json           # JSON output
codex mcp login <server>                # OAuth flow for HTTP servers
codex mcp logout <server>               # Remove OAuth credentials
codex mcp remove <server>               # Delete server definition

W trakcie sesji: /mcp pokazuje aktywne serwery i dostępne narzędzia. /mcp verbose (v0.123.0+)⁸⁴ zwraca pełną diagnostykę serwera, zasoby i szablony zasobów — przydatne, gdy serwer nie ładuje się poprawnie albo narzędzia nie pojawiają się tam, gdzie powinny. Zwykłe /mcp pozostaje szybkie.

Ładowanie MCP z pluginów (v0.123.0+) akceptuje zarówno standardowy schemat mcpServers, jak i mapy serwerów najwyższego poziomu w .mcp.json, dzięki czemu pluginy przygotowane zgodnie z dowolną z tych konwencji ładują się poprawnie.⁸⁴

Uruchamianie Codex JAKO serwera MCP

Codex może udostępniać samego siebie jako serwer MCP do orkiestracji wielu agentów:¹²

codex mcp-server                        # Start as MCP server (stdio transport)

Serwer udostępnia dwa narzędzia: 1. codex(): Rozpoczęcie nowej sesji z parametrami promptu, sandboxa, modelu i zatwierdzania 2. codex-reply(): Kontynuowanie istniejącej sesji z threadId i promptem

Użycie z Agents SDK (Python):

from agents import Agent, Runner
from agents.mcp import MCPServerStdio

async with MCPServerStdio(
    name="Codex CLI",
    params={"command": "npx", "args": ["-y", "codex", "mcp-server"]},
    client_session_timeout_seconds=360000,
) as codex_mcp_server:
    agent = Agent(name="Developer", mcp_servers=[codex_mcp_server])
    result = await Runner.run(agent, "Fix the failing tests")

Godne uwagi serwery MCP

Praktyczne wzorce

Wzorzec 1: programowanie świadome kontekstu — Warto połączyć Context7 z dokumentacją używanego frameworka, aby Codex zawsze miał aktualne odwołania API:

[mcp_servers.context7]
enabled = true
required = true
command = "npx"
args = ["-y", "@upstash/context7-mcp"]

Wzorzec 2: limity wyjścia — Odpowiedzi narzędzi MCP są domyślnie obcinane przy około 25 tys. znaków. W przypadku narzędzi zwracających duże payloady (zapytania do bazy danych, przechwycone logi) należy użyć enabled_tools, aby ograniczyć zakres do konkretnych narzędzi i utrzymać skupione odpowiedzi.

Wzorzec 2a: multimodalne wyjście narzędzi (v0.107.0) — Narzędzia niestandardowe mogą teraz zwracać multimodalne wyjście (obrazy, treści rozszerzone) obok tekstu. Dzięki temu narzędzia tworzące artefakty wizualne — zrzuty ekranu, diagramy, rendery wykresów — mogą przekazywać je bezpośrednio do modelu do analizy.⁶²

Wzorzec 3: zarządzanie MCP w przedsiębiorstwie — Można ograniczyć serwery MCP, których deweloperzy mogą używać, za pomocą requirements.toml:

# In /etc/codex/requirements.toml — only approved servers allowed
[mcp_servers.approved-internal]
identity = { command = "npx @company/internal-mcp" }

Każdy serwer, który nie pasuje do tożsamości w requirements.toml, zostanie zablokowany przy uruchamianiu. Pełną konfigurację zasad opisano w sekcji wdrażanie w przedsiębiorstwie.

Tryb kodu [EXPERIMENTAL]

Tryb kodu (v0.114.0) zapewnia bardziej izolowane przepływy pracy związane z kodowaniem przez ograniczenie zakresu agenta do operacji skoncentrowanych na kodzie.⁷⁰ Po włączeniu agent skupia się na czytaniu, pisaniu i testowaniu kodu bez szerszych interakcji systemowych.

Ta funkcja jest eksperymentalna. Aktualizacje warto sprawdzać w informacjach o wydaniach.

Środowisko uruchomieniowe REPL JavaScript [REMOVED]

Codex v0.100.0 dodał eksperymentalne środowisko uruchomieniowe REPL JavaScript (js_repl), a v0.106.0 udostępnił je przez powierzchnię /experimental.⁶⁰ Te wskazówki mają teraz charakter historyczny. W v0.128.0 dziennik zmian wydania zawiera wpis „Remove js_repl feature”, a bieżąca lista funkcji oznacza zarówno js_repl, jak i js_repl_tools_only jako usunięte.⁸⁶

Nie należy dodawać features.js_repl = true do nowych konfiguracji. Gdy potrzebna jest powtarzalna logika wykonywalna, należy używać poleceń powłoki, skryptów dodanych do repozytorium, narzędzi MCP albo skill Codex z katalogiem scripts/.

Czym są skills?

Skills to wielokrotnego użytku, zadaniowe pakiety funkcji, które Codex ładuje na żądanie. Są zgodne z otwartym standardem agent skills.¹³

Struktura skill

my-skill/
  SKILL.md           (required: instructions)
  scripts/           (optional: executable scripts)
  references/        (optional: reference docs)
  assets/            (optional: images, icons)
  agents/openai.yaml (optional: metadata, UI, dependencies)

Lokalizacje wykrywania

Codex przechowuje skills zainstalowane przez użytkownika w $CODEX_HOME/skills (domyślnie: ~/.codex/skills), w tym wbudowane systemowe skills w .system/. Codex obsługuje foldery skills połączone dowiązaniami symbolicznymi.

Tworzenie skill

Format SKILL.md:

---
name: security-audit
description: Run a thorough security audit on the codebase.
---

## Security Audit Procedure

1. Scan for hardcoded secrets using `rg -i "(api_key|password|secret|token)\s*=" --type py`
2. Check for SQL injection: look for string interpolation in queries
3. Verify input validation on all API endpoints
4. Check dependency vulnerabilities: `pip audit` or `npm audit`
5. Review authentication and authorization patterns
6. Report findings with severity levels (Critical/High/Medium/Low)

Metadane (agents/openai.yaml):

interface:
  display_name: "Security Audit"
  short_description: "Full codebase security review"
  icon_small: "./assets/shield.svg"
  brand_color: "#DC2626"
  default_prompt: "Run a security audit on this repository"

policy:
  allow_implicit_invocation: false    # Require explicit $skill

dependencies:
  tools:
    - type: "mcp"
      value: "snyk"
      transport: "streamable_http"
      url: "https://mcp.snyk.io/mcp"

Wywoływanie skills

• Jawnie: menu /skills albo wzmianka $skill-name w prompcie
• Niejawnie: Codex automatycznie wykrywa pasujące skills na podstawie opisu zadania (jeśli allow_implicit_invocation: true)
• Creator: użyj $skill-creator, aby interaktywnie utworzyć nowy skill
• Installer: użyj $skill-installer install <name>, aby zainstalować społecznościowe skills

Włączanie/wyłączanie

[[skills.config]]
path = "/path/to/skill/SKILL.md"
enabled = false

Skills a slash commands

Debugowanie skills

Jeśli skill się nie aktywuje:

1. Sprawdź wykrywanie: /skills powinno wyświetlać go w TUI
2. Zweryfikuj ścieżkę: upewnij się, że folder skill znajduje się w rozpoznawanej lokalizacji (~/.codex/skills/, katalog główny projektu albo /etc/codex/skills/)
3. Sprawdź enabled: skills z enabled = false w config.toml nie zostaną załadowane
4. Sprawdź aktywację niejawną: jeśli używane jest automatyczne wykrywanie, upewnij się, że w agents/openai.yaml ustawiono allow_implicit_invocation: true
5. Użyj słów kluczowych: uwzględnij w prompcie terminy z description danego skill, aby poprawić dopasowanie niejawne

Przykład produkcyjny: skill do wdrażania

Kompletny, wieloplikowy skill pokazujący współdziałanie odwołań i skryptów:

deploy-skill/
  SKILL.md
  references/
    runbook.md
    rollback-checklist.md
  scripts/
    pre-deploy-check.sh
    smoke-test.sh
  agents/openai.yaml

SKILL.md:

---
name: deploy
description: Deploy the application to staging or production. Runs pre-flight checks, executes deployment, and verifies with smoke tests.
---

## Deployment Procedure

### Pre-flight
1. Run `scripts/pre-deploy-check.sh` to verify:
   - All tests pass
   - No uncommitted changes
   - Branch is up to date with remote
2. Review the runbook at `references/runbook.md` for environment-specific steps.

### Deploy
3. Execute the deployment command for the target environment.
4. Monitor logs for errors during rollout.

### Verify
5. Run `scripts/smoke-test.sh <environment-url>` to confirm critical paths.
6. If smoke tests fail, follow `references/rollback-checklist.md`.

Wywołanie: $deploy to staging albo $deploy production with canary rollout

Plugins

Plugins łączą skills, wpisy MCP, hooks i app connectors w jeden instalowalny pakiet (v0.110.0+).⁶⁵ Od v0.117.0 plugins są elementami pierwszej klasy: plugins o zakresie produktu synchronizują się automatycznie przy uruchomieniu, a /plugins udostępnia w TUI przeglądarkę do odkrywania i zarządzania.⁷⁵ Wersja v0.128.0 rozszerzyła przepływy pracy plugins o instalację z marketplace, zdalne buforowanie pakietów, zdalne APIs odinstalowywania, hooks dołączone do plugin, stan włączenia hooks oraz import konfiguracji external-agent.⁸⁶ v0.129.0 (7 maja 2026) dodaje udostępnianie przestrzeni roboczej plugin (przekazanie zestawu plugins członkom zespołu bez ponownej publikacji), kontrolę dostępu do udostępniania (włączanie/wyłączanie i cofanie dostępu per odbiorca), filtrowanie źródeł (ograniczenie marketplace, z których pobiera przestrzeń robocza) oraz operacje marketplace, które można wywoływać bezpośrednio z przeglądarki /plugins zamiast z CLI.⁸⁹ v0.130.0 (8 maja 2026) zwiększa przejrzystość pakowania plugin i daje większą kontrolę nad przepływem udostępniania:⁹¹

• Dołączone hooks widoczne w szczegółach plugin. Widok szczegółów /plugins wyświetla teraz każdy lifecycle hook, który zawiera plugin (SessionStart, UserPromptSubmit, Stop itd.). Przed zainstalowaniem plugin można dokładnie zobaczyć, które hooks zostaną zarejestrowane w sesji — bez niespodziewanych skutków ubocznych hooks z plugin, któremu ufa się wyłącznie ze względu na jego narzędzia.
• Metadane udostępniania plugin w shareContext. Gdy plugin jest udostępniany z przestrzeni roboczej, payload linku udostępniania ujawnia teraz metadane linku (twórca, zakres, świeżość), dzięki czemu sesje odbierające mogą pokazać pochodzenie i zdecydować, czy go zaakceptować.
• Kontrola wykrywalności w ustawieniach udostępniania. Ustawienia udostępniania udostępniają przełącznik wykrywalności, aby zespoły mogły publikować plugins do konkretnych przestrzeni roboczych albo list odbiorców bez ogólnego udostępniania ich do listowania w całej organizacji.

Źródła plugin

Wykrywanie plugin

Codex informuje model, które plugins są włączone na początku sesji (v0.111.0), co usprawnia wykrywanie zainstalowanych MCP, apps i skills.⁶⁵ Model może sugerować odpowiednie plugins podczas sesji na podstawie kontekstu zadania. W v0.117.0 plugins o zakresie produktu są synchronizowane przy uruchomieniu, dzięki czemu najnowszy katalog plugins jest dostępny bez ręcznej interwencji.⁷⁵

Wzmianki @plugin (v0.112.0+)

Odwołaj się bezpośrednio na czacie do dowolnego zainstalowanego plugin za pomocą @plugin-name.⁶⁸ Gdy wspomina się plugin, jego kontekst (możliwości, narzędzia, konfiguracja) jest automatycznie dołączany do okna kontekstu modelu — nie trzeba opisywać, co robi plugin.

@deploy push this branch to staging with canary rollout
@linter check for unused imports in src/

Działa to z dowolnym zainstalowanym plugin, w tym z niestandardowymi skills, serwerami MCP i app connectors.

Marketplace plugin (v0.113.0+)

Marketplace plugin obejmuje teraz bogatsze wykrywanie z metadanymi, kategoriami i ocenami.⁶⁹ Kontrole uwierzytelniania podczas instalacji weryfikują, czy plugins wymagające kluczy API albo OAuth mają ważne dane uwierzytelniające przed instalacją. Endpoint odinstalowywania usuwa plugins oraz powiązaną z nimi konfigurację w czysty sposób.

Dodawanie zewnętrznych marketplace (v0.121.0+)

Aktualna dokumentacja OpenAI Codex utrzymuje zarządzanie źródłami marketplace w codex plugin marketplace. Formalizuje to dystrybucję zewnętrznych plugins poza własnym marketplace OpenAI i obsługuje skróty repo GitHub, adresy URL Git HTTP(S), adresy URL SSH oraz lokalne katalogi główne marketplace; użyj --ref, aby przypiąć Git ref, i powtarzaj --sparse PATH tylko dla repozytoriów marketplace opartych na Git.⁹³

# GitHub repository (shorthand)
codex plugin marketplace add owner/repo

# Arbitrary git URL
codex plugin marketplace add https://git.example.com/team/plugins.git

# SSH Git URL
codex plugin marketplace add [email protected]:team/plugins.git

# Local directory
codex plugin marketplace add /path/to/local/marketplace

# Upgrade or remove a configured marketplace
codex plugin marketplace upgrade <marketplace-name>
codex plugin marketplace remove <marketplace-name>

Po dodaniu plugins z danego marketplace pojawiają się w przeglądarce /plugins obok domyślnych. Wywołujący app-server (integracje IDE/desktop) mają równoległy endpoint do programowego rejestrowania marketplace.⁸²

Kwestia bezpieczeństwa: zewnętrzne marketplace uruchamiają dowolny kod plugin z uprawnieniami Codex. Przed dodaniem należy sprawdzić źródła i preferować wykonywanie w sandbox podczas pierwszych uruchomień.

Zarządzanie plugins

codex plugin marketplace add <src>       # Add a marketplace source
codex plugin marketplace upgrade [name]  # Upgrade one marketplace or all
codex plugin marketplace remove <name>   # Remove a configured marketplace

W TUI użyj /plugins (v0.117.0+), aby interaktywnie przeglądać, instalować i usuwać poszczególne plugins bez opuszczania sesji.⁷⁵

Wskazówka ekspercka: plugins konsolidują to, co wcześniej wymagało oddzielnej konfiguracji MCP, instalacji skill i konfiguracji app connector. Jeden plugin może zawierać wszystkie trzy elementy — dzięki czemu wdrażanie zespołu jest szybsze, a konfiguracja bardziej przenośna.

Tryb planowania i współpraca

Tryb planowania pozwala Codex zaprojektować podejście przed wprowadzeniem zmian. Jest włączony domyślnie (od wersji v0.94.0).¹⁴ Zobacz Decision Frameworks dla drzewa decyzyjnego “Plan Mode vs Direct Execution”.

Wejście w tryb planowania

/plan                              # Switch to plan mode
/plan "redesign the API layer"     # Plan mode with initial prompt

W trybie planowania Codex: - Czyta pliki i analizuje bazę kodu - Proponuje plan implementacji - Nie wprowadza zmian do momentu zatwierdzenia - Strumieniuje plan w dedykowanym widoku TUI

Tryb sterowania (Steer Mode)

Tryb sterowania (włączony domyślnie od wersji v0.98.0) umożliwia wstrzykiwanie nowych instrukcji, gdy Codex aktywnie pracuje, bez przerywania bieżącego zadania.¹⁴

Dostępne są dwie metody wstrzykiwania:

Praktyczne przykłady:

# Codex is refactoring the auth module...

[Enter] "Use bcrypt instead of argon2 — we already have it as a dependency"
→ Codex adjusts immediately, mid-turn

[Tab] "Once auth is done, update the migration script too"
→ Codex finishes auth refactor, then starts the migration

Tryb sterowania jest zawsze aktywny w TUI. Jeżeli woli się poczekać, aż Codex skończy, zanim przekaże się instrukcje, wystarczy pisać normalnie po zakończeniu tury — żaden specjalny tryb nie jest potrzebny.

Ulepszenia TUI (v0.105.0–v0.106.0)

Podświetlanie składni (v0.105.0): TUI podświetla teraz składnię w blokach kodu z ogrodzeniami i diffach inline. Można użyć /theme, aby wybrać schemat kolorów.⁶¹

Nowe polecenia TUI (v0.105.0+):⁶¹

Transkrypcja głosowa (v0.105.0, eksperymentalna): Wciśnięcie spacji umożliwia dyktowanie promptów za pomocą transkrypcji głosowej. Funkcja jest eksperymentalna i może wymagać uprawnień do mikrofonu.⁶¹ Od wersji v0.107.0 sesje głosowe w czasie rzeczywistym obsługują wybór urządzeń mikrofonu i głośnika, co pozwala wskazać konkretny sprzęt wejścia/wyjścia audio.⁶²

Inne ulepszenia: - Długie linki pozostają teraz klikalne nawet wtedy, gdy są zawinięte przez wiele linii TUI (v0.105.0)⁶¹ - Linki do plików lokalnych są renderowane z lepszym formatowaniem (v0.106.0)⁶⁰ - Naprawiono obsługę Ctrl+C dla sub-agentów, tak aby poprawnie kończyła procesy potomne (v0.106.0)⁶⁰

System pamięci

Codex posiada trwały system pamięci (v0.100.0+), który przechowuje fakty, preferencje i kontekst projektu pomiędzy sesjami.²⁴

Polecenia pamięci

Wpisy są przechowywane w plikach markdown w katalogu ~/.codex/memory/. Codex ładuje je na początku sesji i używa ich, aby kształtować zachowanie we wszystkich kolejnych sesjach.

Co warto przechowywać

Pamięć sprawdza się najlepiej w przypadku trwałych preferencji i faktów dotyczących projektu:

• Konwencje projektu: “Ten projekt używa tabulatorów, a nie spacji” lub “Odpowiedzi API zawsze zawierają pole meta“
• Preferencje narzędzi: “Należy używać pnpm zamiast npm” lub “Testy uruchamiać poleceniem pytest -x --tb=short“
• Decyzje architektoniczne: “Moduł uwierzytelniania znajduje się w src/core/auth/, a nie w src/middleware/“
• Preferencje przepływu pracy: “Linter należy uruchomić zawsze przed pokazaniem diffa”

Pamięć w pipeline’ach

Podczas uruchamiania codex exec pamięć jest ładowana automatycznie. Oznacza to, że pipeline’y CI/CD oraz skrypty korzystają z tego samego kontekstu co sesje interaktywne — nie ma potrzeby powtarzania instrukcji przy każdym wywołaniu.

Udoskonalenia pamięci (v0.101.0–v0.107.0)

• Sanityzacja sekretów: Pamięć jest automatycznie skanowana pod kątem sekretów przed zapisaniem na dysku
• Świadomość CWD: Pliki pamięci zawierają teraz kontekst katalogu roboczego dla wywoływania pamięci specyficznej dla projektu
• Wykluczenie wiadomości deweloperskich: Wiadomości developer/system są wykluczane z wejścia pamięci fazy 1, co poprawia jakość pamięci dzięki skupieniu się na interakcjach użytkownika
• Zapominanie oparte na diffie (v0.106.0): Pamięć korzysta teraz z mechanizmu zapominania opartego na diffie, aby usuwać przestarzałe fakty, dzięki czemu magazyn pamięci pozostaje zwięzły i adekwatny w czasie⁶⁰
• Selekcja świadoma użycia (v0.106.0): Pobieranie pamięci uwzględnia teraz wykorzystanie, priorytetyzując często używane i niedawno istotne wpisy⁶⁰
• Konfigurowalna pamięć (v0.107.0): Pamięć jest teraz w pełni konfigurowalna. Można użyć codex debug clear-memories, aby zresetować wszystkie zapisane wpisy i zacząć od czystej karty — przydatne przy przełączaniu kontekstu między niezwiązanymi projektami lub gdy stan pamięci uległ rozjechaniu⁶²
• Aktualizacja modelu fazy 2 (v0.121.0): Modelem konsolidacji pamięci fazy 2 jest teraz gpt-5.4 (zastąpił poprzedni domyślny). Pipeline fazy 2 działa pomiędzy sesjami, destylując transkrypcje fazy 1 do trwałych faktów; zmiana modelu poprawia jakość przywoływania przy tym samym koszcie tokenów.⁸²
• Menu pamięci w TUI (v0.121.0): Nowy interfejs w sesji udostępnia tryb pamięci, usuwanie pojedynczych wpisów oraz przycisk resetu. Reset pamięci zachowuje teraz przeszłe rolloutsy zamiast je unieważniać, dzięki czemu czyści przyszłą powierzchnię przywoływania bez psucia odtwarzania sesji.⁸²

Pamięć vs AGENTS.md

Wskazówka: Polecenia /m_update warto używać dla faktów, które powinny utrzymać się bezterminowo. Dla kontekstu specyficznego dla sesji wystarczy poinformować Codex bezpośrednio w rozmowie. Dla kontekstu współdzielonego z zespołem należy stosować AGENTS.md.

Zarządzanie sesjami

Codex utrwala sesje w ~/.codex/sessions/, umożliwiając wznawianie, rozgałęzianie i przepływy wielowątkowe na powierzchniach CLI i desktopowych.

Wznawianie

Można podjąć pracę tam, gdzie się ją zostawiło:

codex resume                          # Interactive picker (sorted by recency)
codex resume <SESSION_ID>             # Resume a specific session
codex exec resume --last "continue"   # Non-interactive: resume most recent

Polecenie ukośnikowe /resume w TUI otwiera ten sam interaktywny wybór z funkcją wyszukiwania.

Rozgałęzianie (Fork)

Można rozgałęzić rozmowę, aby przeanalizować alternatywy bez utraty bieżących postępów:

/fork                              # Fork current conversation
/fork "try a different approach"   # Fork with new prompt

Forki tworzą niezależne wątki dzielące tę samą historię aż do punktu rozgałęzienia. Zmiany w jednym forku nie wpływają na drugi. Jest to przydatne przy porównywaniu podejść (np. “rozgałęź i wypróbuj Redis zamiast Memcached”) lub bezpiecznym eksplorowaniu ryzykownych zmian.

Rozgałęzianie wątków na sub-agentów (v0.107.0): Wątki można teraz rozgałęziać na niezależnych sub-agentów, dzięki czemu rozmowa może uruchamiać równoległe strumienie pracy wykonywane autonomicznie. Rozszerza to istniejący model rozgałęziania — zamiast jedynie rozgałęziać rozmowę, forkowany wątek staje się sub-agentem z własnym kontekstem wykonania.⁶² Od wersji v0.117.0 sub-agenci używają adresów opartych na ścieżce (np. /root/agent_a) ze strukturalną komunikacją międzyagentową, co czyni koordynację wieloagentową bardziej jawną i łatwiejszą do debugowania.⁷⁵

Lista wątków

Wyświetlanie i zarządzanie aktywnymi sesjami:

/status                            # Current session info and token usage
/ps                                # Show background terminals in session

W aplikacji desktopowej wątki są widoczne w panelu bocznym wraz z pełną historią i podglądem diffów.

Cykl życia sesji

Sesje synchronizują się pomiędzy CLI a aplikacją desktopową — można rozpocząć w jednym, kontynuować w drugim.

Tryb nieinteraktywny (codex exec)

codex exec uruchamia Codex w trybie nieinteraktywnym do skryptów, CI/CD i automatyzacji.¹⁵

Podstawowe użycie

codex exec "summarize the repository structure"
codex exec --sandbox workspace-write --ask-for-approval on-request "fix the CI failure"
codex exec --json "triage open bugs" -o result.txt

Domyślnie codex exec zapisuje postęp/zdarzenia do stderr, a końcową wiadomość agenta do stdout. Taka konstrukcja sprawia, że narzędzie można komponować ze standardowymi potokami uniksowymi.

Wyjście w formacie linii JSON

Z opcją --json stdout staje się strumieniem zdarzeń JSONL:

codex exec --json "fix the tests" | jq

Typy zdarzeń: thread.started, turn.started/completed/failed, item.started/completed, error

{"type":"thread.started","thread_id":"019c5c94-..."}
{"type":"turn.started"}
{"type":"item.started","item":{"id":"item_1","type":"command_execution","status":"in_progress"}}
{"type":"item.completed","item":{"id":"item_3","type":"agent_message","text":"..."}}
{"type":"turn.completed","usage":{"input_tokens":24763,"cached_input_tokens":24448,"output_tokens":122}}

Strukturalne wyjście

Można wymusić kształt odpowiedzi za pomocą JSON Schema:

codex exec "Extract project metadata" \
  --output-schema ./schema.json \
  -o ./project-metadata.json

-o / --output-last-message zapisuje końcową wiadomość do pliku.

Wznawianie i przegląd sesji

codex exec resume --last "continue where you left off"
codex exec resume <SESSION_ID> "fix the remaining issues"
codex exec review --base main           # Code review against a branch

Kluczowe flagi

Uwierzytelnianie w CI

codex exec obsługuje CODEX_API_KEY do uwierzytelniania nieinteraktywnego w środowiskach automatyzacji.

Banner startowy codex exec (v0.130.0). Banner startowy codex exec nie zawiera już dotychczasowego sformułowania „research preview”. Jeśli proces CI przetwarza wyjście startowe, tekst bannera jest teraz zwięźlejszy; strukturalne zdarzenia --json pozostają niezmienione.⁹¹

codex remote-control (v0.130.0+)

codex remote-control to polecenie najwyższego poziomu, które uruchamia headless app-server przeznaczony do sterowania przez inny proces — rozszerzenia IDE, niestandardowe orkiestratory lub zdalne płaszczyzny sterowania. Zastępuje wielo-flagowe wywołanie codex app-server, które wielu integratorów składało ręcznie, i daje narzędziom firm trzecich pojedynczy, stabilny punkt wejścia do tego samego środowiska app-server, które dostarczane jest pod powierzchniami desktop i IDE.⁹¹

# Start a headless, remotely controllable app-server
codex remote-control

# Same lifecycle as a TUI session: thread store, hooks, plugins, MCP, sandbox
# all initialize from your normal config.toml.

Warto łączyć codex remote-control z poniższymi APIami paginacji app-server podczas budowania interfejsów użytkownika, które muszą wyliczać duże historie wątków bez jednoczesnego ładowania każdego turnu do pamięci.

Paginacja wątków w App-Server (v0.130.0+)

Klienci app-server mogą teraz stronicować duże wątki za pomocą trzech odrębnych widoków elementów turnu:⁹¹

Paginację warto łączyć z interfejsem ThreadStore wprowadzonym w v0.121.0, aby efektywnie przechodzić długo działające wątki, zwłaszcza we wdrożeniach remote-control, w których orkiestrator może znajdować się na innym komputerze niż pliki rolloutu.⁸²

Live odświeżanie konfiguracji App-Server (v0.130.0+)

Aktywne wątki app-server odbierają teraz zmiany w config.toml bez konieczności restartu — wystarczy zedytować konfigurację, zapisać, a działający wątek odzwierciedli nowe wartości w kolejnym turnie. To bug-fixowy odpowiednik codex remote-control: długo działający headless server można rekonfigurować w miejscu zamiast go zatrzymywać.⁹¹

Codex Cloud i zadania w tle [EXPERIMENTAL]

Status: Codex Cloud to funkcja eksperymentalna. Interfejsy, ceny i dostępność mogą ulec zmianie. OpenAI zarządza środowiskami chmurowymi, a użytkownik nie kontroluje infrastruktury.

Codex Cloud uruchamia zadania asynchronicznie w środowiskach zarządzanych przez OpenAI.⁴ Zob. także GitHub Action & CI/CD w celu integracji Codex z potokiem CI.

Jak to działa

1. Zgłoszenie zadania (przez chatgpt.com/codex, integrację Slack lub CLI)
2. Codex klonuje repozytorium do izolowanego sandboxa w chmurze
3. Agent pracuje samodzielnie: czyta kod, uruchamia testy, wprowadza zmiany
4. Po zakończeniu Codex tworzy PR lub udostępnia diff do przeglądu
5. Zastosowanie wyników lokalnie poleceniem codex apply <TASK_ID>

Dostęp do internetu w chmurze

Internet agenta jest domyślnie wyłączony i konfigurowany per środowisko:

• Off: Brak dostępu agenta do internetu (domyślnie)
• On: Opcjonalna lista dozwolonych domen + ograniczenia metod HTTP

Allowed domains: pypi.org, npmjs.com, github.com
Allowed methods: GET, HEAD, OPTIONS

Skrypty konfiguracyjne mogą nadal korzystać z internetu w celu instalacji zależności, nawet gdy internet agenta jest wyłączony.

Integracja ze Slack

Wzmianka @Codex w kanale lub wątku Slack uruchamia zadanie w chmurze.

Wymagania wstępne: 1. Kwalifikujący się plan ChatGPT (Plus, Pro, Business, Enterprise lub Edu) 2. Połączone konto GitHub 3. Co najmniej jedno skonfigurowane środowisko chmurowe 4. Aplikacja Slack zainstalowana w workspace

Codex odpowiada linkiem do zadania i publikuje wyniki po jego ukończeniu.

Cloud CLI

codex cloud exec --env <ENV_ID> "Fix failing tests"  # Start a cloud task
codex cloud status <TASK_ID>                          # Check task progress
codex cloud diff <TASK_ID>                            # View task diff
codex cloud list                                      # List recent tasks
codex cloud list --json                               # JSON output
codex cloud apply <TASK_ID>                           # Apply from cloud subcommand
codex apply <TASK_ID>                                 # Apply diff (top-level shortcut)

Aplikacja desktopowa Codex

Aplikacja desktopowa Codex (macOS i Windows) udostępnia interfejs graficzny zoptymalizowany pod kątem zarządzania wieloma projektami.¹⁶ Wersja dla systemu Windows została wydana 4 marca 2026 z natywną obsługą PowerShell oraz natywnym sandboxem Windows.⁶⁶

Instalacja

codex app                      # Auto-downloads and installs on first run

Można też pobrać bezpośrednio: Codex.dmg (macOS) | Dostępna w Microsoft Store (Windows)

Kluczowe funkcje

Tryby wątków

Każdy wątek działa w jednym z trzech trybów, wybieranym przy jego utworzeniu:

Mechanika izolacji Worktree:

Po uruchomieniu wątku Worktree aplikacja desktopowa: 1. Tworzy nowy worktree git (git worktree add) w katalogu tymczasowym 2. Pobiera świeżą gałąź z bieżącego HEAD 3. Uruchamia agenta wewnątrz worktree — wszystkie zmiany plików są izolowane 4. Po zakończeniu prezentuje przegląd diff — można wybrać, które zmiany scalić z powrotem

Oznacza to, że wiele wątków Worktree może działać jednocześnie na tym samym repozytorium bez konfliktów. Każdy otrzymuje własną gałąź i katalog roboczy.

Automatyzacje

Automatyzacje działają lokalnie w aplikacji, więc aplikacja musi być uruchomiona, a projekt dostępny na dysku:

• W repozytoriach Git automatyzacje korzystają z dedykowanych worktree w tle (izolowanych od katalogu roboczego)
• W projektach niebędących Git uruchomienia wykonują się bezpośrednio w katalogu projektu
• Automatyzacje używają domyślnych ustawień sandboxa

Konfiguracja automatyzacji: 1. Proszę otworzyć projekt w aplikacji desktopowej 2. Kliknąć kartę Automations w panelu bocznym 3. Zdefiniować wyzwalacz (harmonogram, webhook lub ręczny) 4. Napisać prompt i wybrać tryb wykonania (lokalny lub worktree) 5. Ustawić poziom rozumowania dla uruchomienia automatyzacji (App v26.312)⁷² 6. Automatyzacje uruchamiają się zgodnie z harmonogramem i kolejkują wyniki do przeglądu

Przykładowe zastosowania: - Triaging zgłoszeń: Automatyczna kategoryzacja i priorytetyzacja nowych zgłoszeń - Monitorowanie CI: Obserwowanie błędów buildów i sugerowanie poprawek - Reagowanie na alerty: Reagowanie na alerty monitoringu z analizą diagnostyczną - Aktualizacje zależności: Sprawdzanie i aplikowanie poprawek bezpieczeństwa

Wyniki pojawiają się w kolejce do zatwierdzenia przez człowieka.

Obsługa systemu Windows

Aplikacja desktopowa Codex została wydana na Windows 4 marca 2026 (App v26.304) z natywną obsługą PowerShell, natywnym sandboxem Windows oraz pełną parytetowością funkcji, w tym skills, automatyzacjami i worktree, bez wymagania WSL.⁶⁶

GitHub Action i CI/CD

Oficjalna GitHub Action integruje Codex z potokiem CI/CD.¹⁸

Podstawowe użycie

# .github/workflows/codex.yml
name: Codex
on:
  pull_request:
    types: [opened]

jobs:
  codex:
    runs-on: ubuntu-latest
    outputs:
      final_message: ${{ steps.run_codex.outputs.final-message }}
    steps:
      - uses: actions/checkout@v5
      - name: Run Codex
        id: run_codex
        uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: workspace-write
          safety-strategy: drop-sudo

Opcje konfiguracji

Wyjście: final-message, ostateczny tekst odpowiedzi Codex dla kolejnych kroków/zadań.

Strategie bezpieczeństwa

Kontrola dostępu

with:
  allow-users: "admin,maintainer"     # Limit who can trigger
  allow-bots: false                   # Block bot-triggered runs

Domyślnie: Tylko współpracownicy z dostępem do zapisu mogą wyzwalać przepływy pracy Codex.

Codex SDK

TypeScript SDK osadza możliwości agenta Codex w niestandardowych aplikacjach.¹⁹

Instalacja

npm install @openai/codex-sdk

Podstawowe użycie

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();

// Multi-turn conversation
const turn1 = await thread.run("Diagnose CI failures and propose a fix");
console.log(turn1.finalResponse);

const turn2 = await thread.run("Implement the fix and add tests");
console.log(turn2.items);

// Resume a previous session
const resumed = codex.resumeThread("<thread-id>");
await resumed.run("Continue from previous work");

Zaawansowane funkcje SDK

• runStreamed(...): Asynchroniczny strumień zdarzeń dla aktualizacji pośrednich
• outputSchema: Wymuszenie ostatecznego wyjścia w kształcie JSON
• Wejście multimodalne: Przekazywanie tekstu + obrazów lokalnych ({ type: "local_image", path: "..." })
• Przepływy obrazów (v0.117.0): view_image zwraca URL-e, wygenerowane obrazy można ponownie otwierać, a historia obrazów przetrwa wznowienie sesji⁷⁵
• Wieloośrodowiskowy view_image (v0.130.0): Dla sesji obejmujących wiele środowisk (wprowadzonych w v0.124.0 z wyborem środowiska i katalogu roboczego dla każdej tury, dopracowanych w v0.125.0 dzięki przylepnym środowiskom), view_image rozpoznaje teraz ścieżki plików poprzez wybrane środowisko, a nie lokalny system plików orkiestratora. Obraz dołączony ze zdalnego środowiska jest pobierany względem katalogu roboczego tego środowiska, a nie hosta uruchamiającego SDK.⁹¹

Konfiguracja wątku i klienta

// Custom working directory, skip git check
const thread = codex.startThread({
  workingDirectory: "/path/to/project",
  skipGitRepoCheck: true,
});

// Custom environment and config overrides
const codex = new Codex({
  env: { CODEX_API_KEY: process.env.MY_KEY },
  config: { model: "gpt-5.5" },
});

Sesje są utrwalane w ~/.codex/sessions.

Środowisko uruchomieniowe: Node.js 18+.

Optymalizacja wydajności

Zarządzanie kontekstem

Okna kontekstowe różnią się w zależności od modelu. Stan na kwiecień 2026: GPT-5.5 w Codex oferuje 400K (1M w API). GPT-5.4 / GPT-5.4-mini oferują odpowiednio 1M / 400K (odpowiednik API w Codex). Rodzina GPT-5.3-Codex / GPT-5.2-Codex działa na 272K wejścia + 128K wyjścia (łączny budżet 400K). Wszystkie zapełniają się szybciej, niż można by oczekiwać — warto zarządzać nimi proaktywnie:

1. Regularne używanie /compact: Podsumowuje historię konwersacji, zwalniając tokeny
2. Dostarczanie lokalnej dokumentacji: Wysokiej jakości AGENTS.md i lokalna dokumentacja redukują narzut eksploracji (która zużywa kontekst)
3. Używanie @ do dołączania konkretnych plików: Bezpośrednie odwoływanie się do plików zamiast proszenia Codex o ich znalezienie
4. Skupione prompty: Prompty o wąskim zakresie z dokładnie wskazanymi plikami zużywają mniej kontekstu niż otwarta eksploracja

Wydajność tokenów

Optymalizacja szybkości

1. gpt-5.3-codex-spark: Wariant o niższych opóźnieniach do interaktywnego pair programmingu
2. --profile fast: Wstępnie skonfigurowany model mini z niskim rozumowaniem
3. Równoległe wykonywanie narzędzi: Codex uruchamia niezależne odczyty/sprawdzenia współbieżnie, więc warto strukturyzować prompty, aby to umożliwić
4. Pętle ukierunkowane na rezultat: Zamiast instrukcji krok po kroku warto poprosić o „zaimplementuj, przetestuj, popraw, zatrzymaj się gdy zielone”

Jak debugować problemy?

Typowe problemy i rozwiązania

Słownik komunikatów błędów

Narzędzia diagnostyczne

codex --version                        # Check CLI version
codex login status                     # Verify authentication
codex mcp list                         # Check MCP server status
codex debug app-server --help          # Debug app server issues

Diagnostyka TUI w trakcie sesji:

/status                                # Token/session overview
/config                                # Inspect effective config values and sources
/compact                               # Summarize history to reclaim context

Uwaga: codex --verbose nie jest prawidłową flagą najwyższego poziomu. Należy korzystać z powyższych podpoleceń debug i diagnostyki TUI.

Czysta reinstalacja

npm uninstall -g @openai/codex && npm install -g @openai/codex@latest

Tryb debugowania

codex debug app-server send-message-v2  # Test app-server client

Zgłaszanie problemów

/feedback                              # Send logs to Codex maintainers (in TUI)

Można również zgłaszać problemy pod adresem github.com/openai/codex/issues.¹

Codex Security [PREVIEW]

Codex Security wszedł w fazę research preview 6 marca 2026 r., wprowadzając kontekstową analizę bezpieczeństwa aplikacji do stacku Codex.⁷⁷ Funkcja jest dostępna dla klientów ChatGPT Pro, Enterprise, Business i Edu za pośrednictwem Codex web.

Jak to działa: Codex Security analizuje repozytoria, aby zbudować model zagrożeń specyficzny dla projektu, identyfikuje podatności sklasyfikowane według rzeczywistego wpływu i poddaje ustalenia próbom w środowisku sandboxowym w celu ich walidacji. Agent uwypukla wnioski o wyższej pewności wraz z poprawkami, redukując szum z błahych błędów.

Wydajność: Podczas research preview Codex Security przeskanował 1,2 mln commitów i zidentyfikował 10 561 podatności o wysokiej powadze. Precyzja z czasem rosła — szum zmniejszono o 84%, zawyżone oceny powagi o ponad 90%, a wskaźnik fałszywie pozytywnych wyników obniżono o połowę. System znalazł rzeczywiste podatności w OpenSSH, GnuTLS oraz Chromium, czemu towarzyszyło przypisanie 14 CVE.⁷⁷

Uwaga: Codex Security jest oddzielny od wbudowanego modelu bezpieczeństwa sandboxa CLI. Sandbox chroni maszynę przed Codexem; Codex Security chroni bazę kodu przed podatnościami.

Wdrożenie korporacyjne

Kontrola administratora (requirements.toml)

Administratorzy egzekwują politykę korporacyjną za pomocą pliku requirements.toml — pliku konfiguracyjnego wymuszanego przez administratora, który ogranicza ustawienia o znaczeniu krytycznym dla bezpieczeństwa, niemożliwe do nadpisania przez użytkowników:²¹

# /etc/codex/requirements.toml

# Restrict which approval policies users can select
allowed_approval_policies = ["untrusted", "on-request", "never"]

# Limit available sandbox modes
allowed_sandbox_modes = ["read-only", "workspace-write"]

# Control web search capabilities
allowed_web_search_modes = ["cached"]

# Allowlist MCP servers by identity (both name and identity must match)
[mcp_servers.approved-server]
identity = { command = "npx approved-mcp-server" }

# Admin-enforced command restrictions
[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete is prohibited by IT policy"

[[rules.prefix_rules]]
pattern = [{ token = "sudo" }]
decision = "prompt"
justification = "Elevated commands require explicit approval"

W przeciwieństwie do pliku config.toml na poziomie użytkownika, który ustala preferencje, requirements.toml stanowi twardą warstwę ograniczeń określającą, jakie wartości może wybrać użytkownik — i nie można jej nadpisać. Reguły wymagań administratora mogą jedynie prompt lub forbid (nigdy nie zezwalają w sposób cichy).

Konfiguracja MDM dla macOS

Dystrybucja odbywa się poprzez MDM z wykorzystaniem domeny preferencji com.openai.codex.²¹ Codex honoruje standardowe ładunki MDM systemu macOS (Jamf Pro, Fleet, Kandji itp.). Zakoduj TOML jako base64 bez zawijania wierszy:

Pierwszeństwo (od najwyższego do najniższego):

1. Zarządzane preferencje macOS (MDM)
2. Wymagania pobierane z chmury (ChatGPT Business / Enterprise)
3. /etc/codex/requirements.toml (lokalny system plików)

Wymagania chmurowe wypełniają jedynie nieustawione pola wymagań, więc warstwy zarządzane o wyższym pierwszeństwie zawsze mają przewagę. Wymagania chmurowe działają w trybie best-effort — jeśli pobranie się nie powiedzie lub przekroczy limit czasu, Codex kontynuuje pracę bez warstwy chmurowej.

Integracja z OpenTelemetry

Codex obsługuje propagację kontekstu śledzenia OpenTelemetry ze standardowych zmiennych środowiskowych OTel aż do wywołań OpenAI API. Przed uruchomieniem Codex należy ustawić standardowe zmienne środowiskowe:

# Point Codex at your OTel collector
export OTEL_EXPORTER_OTLP_ENDPOINT="https://otel-collector.internal:4318"
export OTEL_SERVICE_NAME="codex-cli"
export OTEL_RESOURCE_ATTRIBUTES="team=platform,env=production"

# Launch Codex — trace context propagates to all OpenAI API calls
codex

• Standardowe zmienne środowiskowe OTEL_* są respektowane (endpoint, nazwa usługi, atrybuty zasobów)
• Kontekst śledzenia propaguje się przez Codex do wywołań API, umożliwiając obserwowalność end-to-end
• Atrybuty zasobów pozwalają tagować ślady według zespołu, środowiska lub projektu
• Należy mieć na uwadze wymagania dotyczące prywatności przy włączaniu logowania promptów/narzędzi — ślady mogą zawierać fragmenty kodu
• Konfigurowalne metadane śladów OpenTelemetry (v0.130.0+). Poza standardową kopertą OTEL_RESOURCE_ATTRIBUTES, crate codex-otel udostępnia obecnie konfigurowalne metadane śladów, dzięki czemu administratorzy mogą tagować ślady wymiarami specyficznymi dla organizacji (centrum kosztów, identyfikator projektu, numer zgłoszenia) bez konieczności rekonstruowania OTEL_RESOURCE_ATTRIBUTES od podstaw przy każdym wywołaniu. Warto zestawić to z bogatszą analityką recenzji/feedbacku dostarczoną w tym samym wydaniu, co pozwala na ujednolicone debugowanie i triaż w sesjach CLI, app-server oraz remote-control.⁹¹

Dostęp korporacyjny

• ChatGPT Business / Enterprise / Edu: Dostęp kontrolowany przez administratora organizacji, z automatycznym stosowaniem wymagań pobieranych z chmury. Obsługuje SSO przez SAML/OIDC za pośrednictwem dostawcy tożsamości (Okta, Entra ID itp.)
• API: Standardowa autoryzacja API, rozliczenia oraz kontrola na poziomie organizacji/projektu. OpenAI publikuje raporty SOC 2 Type II i SOC 3; dla poziomu Enterprise dostępne jest HIPAA BAA
• Codex SDK: Osadzanie w wewnętrznych narzędziach i procesach
• Egzekwowanie polityki na dużą skalę: Można wykorzystać dystrybuowany przez MDM requirements_toml_base64 lub plik /etc/codex/requirements.toml na poziomie systemu plików

Obsługa danych i zgodność: - Dane wejściowe/wyjściowe API nie są wykorzystywane do trenowania w ramach warunków OpenAI dla Business/Enterprise/API - W kwestii rezydencji danych ruch API OpenAI domyślnie kieruje się przez infrastrukturę zlokalizowaną w USA; w przypadku wymagań dotyczących rezydencji danych w UE należy skonsultować się z zespołem sprzedaży Enterprise OpenAI - Transkrypcje sesji są przechowywane lokalnie; jedynie wywołania API opuszczają maszynę - ChatGPT Enterprise wspiera ramy zgodności obejmujące SOC 2, GDPR oraz CCPA

Strategia wdrożenia

Zalecane fazowe wdrożenie dla organizacji:

1. Pilotaż (faza 1): Wdrożenie u 3–5 starszych inżynierów z plikiem requirements.toml wymuszającym tryb sandbox untrusted oraz wyszukiwanie sieciowe cached. Zbieranie informacji zwrotnych dotyczących wzorców AGENTS.md oraz potrzeb w zakresie serwerów MCP.
2. Rozszerzenie zespołu (faza 2): Wdrożenie w całym zespole. Dystrybucja standardowego dla zespołu pliku config.toml przez MDM lub repozytorium. Włączenie sandboxa workspace-write dla zaufanych repozytoriów.
3. Integracja z CI (faza 3): Dodanie codex-action do potoków CI/CD w celu automatycznego przeglądu PR oraz generowania testów. Wykorzystanie --ephemeral dla utrzymania przewidywalnych kosztów.
4. Skala całej organizacji (faza 4): Wdrożenie przez MDM z plikiem requirements.toml egzekwującym zatwierdzone serwery MCP, polityki sandbox oraz listy dozwolonych modeli.

Wzorce audytowe

Śledzenie wykorzystania Codex i egzekwowanie zgodności:

• Ślady OpenTelemetry: Monitorowanie wolumenu wywołań API, zużycia tokenów oraz opóźnień w podziale na zespoły
• Trwałość sesji: Audyt katalogu ~/.codex/sessions/ na potrzeby przeglądu zgodności (można wyłączyć opcją --ephemeral w kontekstach wrażliwych)
• Egzekwowanie tożsamości MCP: requirements.toml rejestruje zablokowane próby uruchomienia serwerów — warto przeglądać je pod kątem nieautoryzowanego użycia narzędzi
• Ślad audytowy git: Wszystkie zmiany plików dokonywane przez Codex przechodzą przez standardowy git — przegląd dostępny przez historię gałęzi i diffy PR

Najlepsze praktyki i antywzorce

Wzorce promptowania

1. Prompty oparte na ograniczeniach: Zaczynać od granic. „Nie zmieniać kontraktów API. Refaktoryzować wyłącznie wewnętrzną implementację.”
2. Strukturyzowane kroki reprodukcji: Numerowane kroki dają lepsze poprawki błędów niż mgliste opisy
3. Żądania weryfikacji: Zakończyć słowami „Uruchom lint oraz najmniejszy istotny zestaw testów. Zgłoś polecenia i wyniki.”
4. Odwołania do plików: Użyć @filename, aby dołączyć konkretne pliki do kontekstu
5. Pętle zorientowane na wynik: „Zaimplementuj, uruchom testy, napraw błędy, zatrzymaj się dopiero, gdy wszystkie testy przejdą.” Codex iteruje aż do ukończenia

Filozofia testowania

Społeczność zbiega się wokół współpracy z AI opartej na testach:²²

• Definiować testy z wyprzedzeniem jako sygnały ukończenia
• Pozwolić Codex iterować, aż testy przejdą (red → green → refactor)
• Stosować wzorce programistyczne Tiger Style
• Podawać dokładny tekst pliku przy żądaniu poprawek. Codex używa ścisłego dopasowania, a nie rozmytego patchowania opartego na AST

Najlepsze praktyki zarządzania kontekstem

• Dostarczać wysokiej jakości lokalną dokumentację zamiast polegać na wyszukiwaniu w sieci
• Utrzymywać uporządkowany markdown ze spisami treści i plikami postępów („progresywne ujawnianie”)
• Normalizować zakończenia linii (LF vs CRLF) we wszystkich śledzonych plikach, aby zapobiec niepowodzeniom patchowania
• Zachować zwięzłość pliku AGENTS.md, ponieważ długie instrukcje zostają wypchnięte z kontekstu

Workflow Git

• Zawsze tworzyć nową gałąź przed uruchomieniem Codex w nieznanych repozytoriach
• Używać workflow opartego na patchach (git diff / git apply) zamiast bezpośrednich edycji
• Recenzować sugestie Codex jak PR-y w code review
• Używać /diff do weryfikacji zmian przed commitem

Skille i prompty społeczności

Repozytorium feiskyer/codex-settings udostępnia konfiguracje utrzymywane przez społeczność:²³

Wielokrotnego użytku prompty (w ~/.codex/prompts/): - deep-reflector: Wyciąganie wniosków z sesji deweloperskich - github-issue-fixer [issue-number]: Systematyczna analiza błędów i tworzenie PR-ów - github-pr-reviewer [pr-number]: Workflow code review - ui-engineer [requirements]: Rozwój frontendu klasy produkcyjnej

Skille społeczności: - claude-skill: Przekazywanie zadań do Claude Code z trybami uprawnień - autonomous-skill: Automatyzacja zadań wielosesyjnych ze śledzeniem postępu - deep-research: Orkiestracja równoległych podzadań - kiro-skill: Pipeline wymagania → projekt → zadania → wykonanie

Antywzorce

Częste błędy, które marnują tokeny, dają słabe wyniki lub tworzą frustrujące workflow.

Antywzorce kosztowe

Antywzorce kontekstowe

Antywzorce workflow

Antywzorce promptów

Przepisy workflow

Kompleksowe wzorce dla typowych scenariuszy deweloperskich.

Przepis 1: Konfiguracja nowego projektu

mkdir my-app && cd my-app && git init
codex

> Create a FastAPI project with: main.py, requirements.txt, Dockerfile,
  basic health endpoint, and a README. Use async throughout.

> /init

Przejrzeć wygenerowany AGENTS.md, edytować zgodnie z własnymi konwencjami, a następnie:

> Run the health endpoint test and confirm it passes

Przepis 2: Codzienny przepływ deweloperski

cd ~/project && git checkout -b feature/user-auth
codex

> @src/models/user.py @src/api/auth.py
  Add password reset functionality. Requirements:
  1. POST /api/auth/reset-request (email → sends token)
  2. POST /api/auth/reset-confirm (token + new password)
  3. Tests for both endpoints
  Run tests when done.

Przejrzeć z /diff, a następnie zacommitować.

Przepis 3: Złożona refaktoryzacja z trybem planowania

codex

> /plan Migrate the database layer from raw SQL to SQLAlchemy ORM.
  Constraints: don't change any API contracts, keep all existing tests passing.

Przejrzeć plan. Zatwierdzić lub skierować:

[Tab] Also add a migration script using Alembic

Po wykonaniu przez Codex zweryfikować:

> Run the full test suite and report results
> /diff

Przepis 4: Code review PR z codex exec

codex exec --model gpt-5.1-codex-mini \
  "Review the changes in this branch against main. \
   Flag security issues, missed edge cases, and style violations. \
   Format as a markdown checklist." \
  -o review.md

Przepis 5: Debugowanie z Cloud Tasks [EXPERIMENTAL]

codex cloud exec --env my-env "Diagnose why the /api/orders endpoint returns 500 \
  for orders with > 100 line items. Check the serializer, database query, \
  and pagination logic. Propose a fix with tests."

Sprawdzić postęp później:

codex cloud status <TASK_ID>
codex cloud diff <TASK_ID>

Zastosować poprawkę lokalnie po ukończeniu:

codex apply <TASK_ID>

## Przewodnik migracji

### Z Claude Code

| Koncepcja Claude Code | Odpowiednik w Codex |
|---------------------|------------------|
| `CLAUDE.md` | `AGENTS.md` (otwarty standard) |
| `.claude/settings.json` | `.codex/config.toml` (format TOML) |
| flaga `--print` | podpolecenie `codex exec` |
| `--dangerously-skip-permissions` | `--dangerously-bypass-approvals-and-sandbox` |
| Hooks (12+ zdarzeń) | Hooks (SessionStart, Stop, UserPromptSubmit, AfterAgent, AfterToolUse; v0.99.0–v0.116.0) |
| Subagents (narzędzie Task) | Sub-agents (wewnętrzne, maks. 6; brak odpowiednika narzędzia Task widocznego dla użytkownika) |
| `/compact` | `/compact` (identyczne) |
| `/cost` | `/status` (pokazuje zużycie tokenów) |
| Model: Opus/Sonnet/Haiku | Model: gpt-5.5 / gpt-5.4 / gpt-5.4-mini / starsze warianty gpt-5.3-codex (Codex korzysta z rodziny modeli GPT-5.x firmy OpenAI) |
| `claude --resume` | `codex resume` |
| Reguły uprawnień | Tryby sandbox + zasady zatwierdzania |
| Konfiguracja MCP w settings.json | Konfiguracja MCP w config.toml |

**Kluczowe różnice, które warto zrozumieć:**

- **Sandbox działa na poziomie systemu operacyjnego**: Codex wykorzystuje Seatbelt/Landlock, a nie kontenery. Ograniczenia działają na poziomie jądra, poniżej warstwy aplikacji.
- **Hooks są rozszerzane**: Codex obsługuje obecnie 5 zdarzeń hook: `SessionStart`, `Stop` oraz `UserPromptSubmit` (v0.114.0–v0.116.0, eksperymentalne), a także `AfterAgent` (v0.99.0) i `AfterToolUse` (v0.100.0). System obejmuje cykl życia sesji, przechwytywanie promptów oraz automatyzację na poziomie narzędzi, choć ponad 12 zdarzeń cyklu życia w Claude Code wciąż zapewnia szerszy zakres. W przypadku wzorców automatyzacji jeszcze nieobjętych systemem warto skorzystać z instrukcji w AGENTS.md lub ze skills.
- **Sub-agents v2 (v0.117.0)**: Sub-agents korzystają teraz z adresów opartych na ścieżkach (np. `/root/agent_a`) z ustrukturyzowanymi komunikatami między agentami oraz listowaniem agentów.[^80] Rozszerza to istniejący mechanizm (maks. 6 jednoczesnych, zmniejszone z 12 w v0.91.0). Role multi-agent pozostają konfigurowalne (v0.104.0+).[^57] v0.105.0 wprowadziła `spawn_agents_on_csv` do rozdziału pracy między wiersze ze śledzeniem postępu i ETA.[^63] Codexowi nadal brakuje jawnego UX narzędzia Task z Claude Code dla delegowania kierowanego przez użytkownika — w przypadku wzorców delegowania warto skorzystać z zadań chmurowych lub orkiestracji SDK.
- **AGENTS.md działa międzyplatformowo**: Plik AGENTS.md działa w Cursor, Copilot, Amp, Jules, Gemini CLI oraz ponad 60 000 projektów open source. CLAUDE.md jest wyłącznie dla Claude.
- **Profile zastępują ręczne przełączanie**: Zamiast zmieniać flagi przy każdym uruchomieniu, można zdefiniować profile w pliku config.toml.

### Z GitHub Copilot

| Koncepcja Copilot | Odpowiednik w Codex |
|-----------------|------------------|
| Copilot CLI (agentowy terminal) | Interaktywny CLI lub aplikacja desktopowa |
| Wyspecjalizowani agenci (Explore, Plan) | Skills + tryb plan + tryb steer |
| `copilot-instructions.md` / AGENTS.md | `AGENTS.md` (ten sam standard) |
| Obsługa MCP | Obsługa MCP (STDIO + HTTP) |
| ACP (Agent Client Protocol) | Hooks (AfterAgent, AfterToolUse) |
| Copilot SDK | Codex SDK (TypeScript) |
| Przepływy pracy agenta kodującego | Agent Codex z kontrolą sandbox/zatwierdzeń + zadania chmurowe |

**Co zyskujesz:**
- Sandboxing na poziomie systemu operacyjnego (Seatbelt/Landlock — wymuszany przez jądro, a nie oparty na kontenerach)
- Delegowanie zadań chmurowych za pomocą `codex apply`
- Profile konfiguracyjne do przełączania przepływów pracy
- Aplikacja desktopowa z izolacją worktree

### Z Cursor

| Koncepcja Cursor | Odpowiednik w Codex |
|---------------|------------------|
| Reguły projektu (`.cursor/rules`) / `AGENTS.md` | `AGENTS.md` + profile/konfiguracja |
| Przepływy pracy agent chat/composer | Interaktywny CLI lub aplikacja desktopowa |
| Odwołania do plików `@` | Odwołania do plików `@` (identyczne) |
| Apply/edit + przegląd | Wbudowane łatanie i przegląd różnic |

---

## Karta szybkiego odniesienia

```text
╔═══════════════════════════════════════════════════════════════╗
║                    CODEX CLI QUICK REFERENCE                  ║
╠═══════════════════════════════════════════════════════════════╣
║                                                               ║
║  LAUNCH                                                       ║
║  codex                      Interactive TUI                   ║
║  codex "prompt"             TUI with initial prompt           ║
║  codex exec "prompt"        Non-interactive mode              ║
║  codex app                  Desktop app                       ║
║  codex resume               Resume previous session           ║
║  codex fork                 Fork a session                    ║
║                                                               ║
║  FLAGS                                                        ║
║  -m, --model <model>        Select model                      ║
║  -p, --profile <name>       Load config profile               ║
║  -s, --sandbox <mode>       Sandbox mode                      ║
║  -C, --cd <dir>             Working directory                 ║
║  -i, --image <file>         Attach image(s)                   ║
║  -c, --config <key=value>   Override config                   ║
║  --ask-for-approval <p>     Approval policy                   ║
║  --oss                      Use local models (Ollama)         ║
║  --search                   Enable live web search            ║
║                                                               ║
║  SLASH COMMANDS (in TUI)                                      ║
║  /compact      Free tokens   /diff        Git diff            ║
║  /review       Code review   /plan        Plan mode           ║
║  /model        Switch model  /status      Session info        ║
║  /fork         Fork thread   /goal        Persisted goal      ║
║  /vim          Modal Vim     /hooks       Browse/toggle hooks ║
║  /init         AGENTS.md scaffold                             ║
║  /mcp          MCP tools     /skills      Invoke skills       ║
║  /ps           Background    /personality Style               ║
║  /permissions  Approval mode /statusline  Footer config       ║
║  /fast         Toggle fast mode (default: on)                ║
║  /copy         Copy last response to clipboard                ║
║  /clear        Clear screen  /theme       Syntax highlighting ║
║                                                               ║
║  TUI SHORTCUTS                                                ║
║  @              Fuzzy file search                             ║
║  !command       Run shell command                             ║
║  Ctrl+G         External editor                               ║
║  Ctrl+L         Clear screen                                  ║
║  Enter          Inject instructions (while running)           ║
║  Esc Esc        Edit previous messages                        ║
║                                                               ║
║  EXEC MODE (CI/CD)                                            ║
║  codex exec --sandbox workspace-write "task" Sandboxed auto   ║
║  codex exec --json -o out.txt "task"    JSON + file output    ║
║  codex exec --output-schema s.json      Structured output     ║
║  codex exec resume --last "continue"    Resume session        ║
║                                                               ║
║  MCP MANAGEMENT [EXPERIMENTAL]                                ║
║  codex mcp add <name> -- <cmd>    Add STDIO server            ║
║  codex mcp add <name> --url <u>   Add HTTP server             ║
║  codex mcp list                    List servers                ║
║  codex mcp login <name>           OAuth flow                  ║
║  codex mcp remove <name>          Delete server               ║
║                                                               ║
║  PLUGINS                                                      ║
║  codex plugin marketplace add <src>     Add marketplace       ║
║  codex plugin marketplace upgrade       Upgrade marketplaces  ║
║                                                               ║
║  CLOUD [EXPERIMENTAL]                                         ║
║  codex cloud exec --env <ID> Start cloud task                 ║
║  codex cloud status <ID>     Check task progress              ║
║  codex cloud diff <ID>       View task diff                   ║
║  codex cloud list            List tasks                       ║
║  codex apply <TASK_ID>       Apply cloud diff locally         ║
║                                                               ║
║  CONFIG FILES                                                 ║
║  ~/.codex/config.toml        User config                      ║
║  .codex/config.toml          Project config                   ║
║  ~/.codex/AGENTS.md          Global instructions              ║
║  AGENTS.md                   Project instructions             ║
║  requirements.toml           Enterprise policy constraints    ║
║                                                               ║
║  SANDBOX MODES                                                ║
║  read-only          Read files only, no mutations             ║
║  workspace-write    Read/write in workspace + /tmp            ║
║  danger-full-access Full machine access                       ║
║                                                               ║
║  APPROVAL POLICIES                                            ║
║  untrusted     Prompt for all mutations                       ║
║  on-request    Prompt for boundary violations                 ║
║  never         No prompts                                     ║
║                                                               ║
║  MODELS (April 2026)                                          ║
║  gpt-5.5               Recommended default (400K in Codex)   ║
║  gpt-5.5-pro           Highest-effort GPT-5.5 tier            ║
║  gpt-5.4               Prior flagship / fallback              ║
║  gpt-5.4-mini          Subagent work, 2x faster (400K)        ║
║  gpt-5.3-codex         Legacy coding specialist               ║
║                                                               ║
╚═══════════════════════════════════════════════════════════════╝

Dziennik zmian