Codex CLI: kompleksowa dokumentacja techniczna

W skrócie: Codex to wielopowierzchniowy agent programistyczny, który czyta bazę kodu, uruchamia polecenia w piaskownicy na poziomie systemu operacyjnego, modyfikuje pliki i deleguje zadania do chmury. Wystarczy opanować pięć głównych systemów (config.toml, model piaskownicy i zatwierdzeń, AGENTS.md, MCP oraz skills), a Codex stanie się mnożnikiem produktywności. Warto korzystać z profili do przełączania kontekstu, /compact do zarządzania budżetem kontekstu oraz AGENTS.md jako międzynarzędziowych instrukcji projektowych, które działają w Codex, Cursor, Amp i innych narzędziach. GPT-5.4 jest teraz zalecanym modelem z oknami kontekstu o pojemności 1M tokenów.

Codex działa jako wielopowierzchniowy agent programistyczny, a nie chatbot generujący kod. CLI czyta bazę kodu, wykonuje polecenia w piaskownicy, modyfikuje pliki, łączy się z usługami zewnętrznymi przez MCP i deleguje długotrwałe zadania do chmury. Działa lokalnie, ale myśli globalnie — ta sama inteligencja zasila cztery odrębne powierzchnie, w zależności od stylu pracy.

Różnica między zwykłym a efektywnym korzystaniem z Codex sprowadza się do pięciu głównych systemów. Opanowanie ich sprawia, że Codex staje się mnożnikiem produktywności:

1. System konfiguracji: steruje zachowaniem za pomocą config.toml
2. Model piaskownicy i zatwierdzeń: kontroluje, co Codex może wykonać
3. AGENTS.md: definiuje kontrakty operacyjne na poziomie projektu
4. Protokół MCP: rozszerza możliwości o usługi zewnętrzne
5. System skills: pakuje wielokrotnie używaną wiedzę domenową

Przez wiele miesięcy korzystałem z Codex równolegle z Claude Code w produkcyjnych bazach kodu, pipeline’ach CI/CD i zespołowych przepływach pracy. Niniejszy przewodnik to destylat tego doświadczenia — kompletna dokumentacja referencyjna, jakiej brakowało mi na początku. Każda funkcja zawiera rzeczywistą składnię, praktyczne przykłady konfiguracji oraz przypadki brzegowe, na których potykają się nawet doświadczeni użytkownicy.

Uwaga dotycząca stabilności: Funkcje oznaczone [EXPERIMENTAL] mogą ulec zmianie między wydaniami. Codex Cloud, grupa poleceń MCP, code mode oraz hooks engine mają status eksperymentalny w wersji v0.117.0. Rdzeń CLI, piaskownica, AGENTS.md, config.toml, Skills oraz system wtyczek są stabilne.

Kluczowe wnioski

• Cztery interfejsy, jeden umysł: CLI, aplikacja desktopowa, rozszerzenie IDE i zadania w chmurze — wszystkie korzystają z tej samej inteligencji GPT-5.x-Codex, więc warto wybrać interfejs najlepiej pasujący do własnego sposobu pracy.
• Sandboxing na poziomie systemu operacyjnego: Codex wymusza ograniczenia systemu plików i sieci na poziomie jądra (Seatbelt na macOS, Landlock + seccomp na Linuksie), 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 i ponad 60 000 projektów open source. Wystarczy napisać raz i używać wszędzie.
• Profile eliminują narzut przełączania kontekstu: Można zdefiniować nazwane zestawy konfiguracji (fast, careful, auto) i przełączać się między nimi za pomocą --profile.
• Zarządzanie kontekstem ma znaczenie: GPT-5.4 oferuje 1M kontekstu; GPT-5.3-Codex zapewnia 272K na wejściu. W obu przypadkach warto korzystać z /compact, precyzyjnych promptów i odwołań @file, aby proaktywnie zarządzać budżetem tokenów.

Jak korzystać z tego przewodnika

To ponad 2500 linii materiału referencyjnego — najlepiej zacząć od sekcji odpowiadającej poziomowi doświadczenia:

Karta szybkiego dostępu na końcu zawiera zwięzłe podsumowanie wszystkich głównych poleceń.

Jak działa Codex: model mentalny

Zanim przejdziemy do funkcji, warto zrozumieć, w jaki sposób architektura Codex kształtuje wszystko, co można z nim zrobić. System działa na czterech interfejsach wspieranych przez 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: Rodzina modeli GPT-5.x-Codex napędza wszystko. Od wersji v0.111.0 zalecanym modelem jest gpt-5.4 — flagowy model frontier OpenAI łączący możliwości kodowania GPT-5.3-Codex z silniejszym rozumowaniem, natywną obsługą komputera i oknami kontekstu o rozmiarze 1M.⁶⁶ Odczytuje pliki, pisze łatki, wykonuje polecenia powłoki i analizuje bazę kodu. Gdy kontekst się zapełnia, Codex kompaktuje konwersację, aby zwolnić miejsce. Ta warstwa zużywa tokeny.

Warstwa bezpieczeństwa: Każde polecenie wykonywane przez Codex przechodzi przez sandbox na poziomie systemu operacyjnego. Na macOS framework Seatbelt firmy Apple wymusza ograniczenia na poziomie jądra. Na Linuksie Landlock + seccomp filtrują dostęp do systemu plików i wywołania systemowe. Sandbox działa na poziomie jądra, a nie wewnątrz kontenerów. Polityka zatwierdzania decyduje następnie o tym, kiedy wymagać potwierdzenia od użytkownika.

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

Warstwa interfejsów: CLI dla zaawansowanych użytkowników terminala i automatyzacji. Aplikacja desktopowa do wielowątkowego zarządzania projektem. Rozszerzenie IDE do cykli edycja-kompilacja-testy. Chmura do asynchronicznych zadań działających niezależnie.

Kluczowy wniosek: Większość użytkowników korzysta tylko z jednego interfejsu. Zaawansowani użytkownicy wykorzystują wszystkie cztery: chmurę do długotrwałych zadań, CLI do deterministycznych operacji na repozytorium, rozszerzenie IDE do szybkich cykli kodowania i aplikację desktopową do planowania i koordynacji.

Spis treści

1. Jak zainstalować Codex?
2. Szybki start: pierwsza sesja
3. Główne interfejsy interakcji
4. Szczegółowy opis systemu konfiguracji
5. Jaki model wybrać?
6. Ile kosztuje Codex?
7. Ramy decyzyjne
8. Jak działa sandbox i system zatwierdzania?
9. Jak działa AGENTS.md?
10. Hooks
11. Czym jest MCP (Model Context Protocol)?
12. Code Mode
13. JavaScript REPL Runtime
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 enterprise
27. Najlepsze praktyki i antywzorce
28. Przepisy na workflow
29. Przewodnik migracji
30. Karta szybkiego dostępu
31. Historia zmian
32. Źródła

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

Skrypt bezpośredniej instalacji (v0.106.0+)

Dla macOS i Linuksa dostępny jest jednolinijkowy skrypt instalacyjny jako zasób wydania na GitHub:⁶²

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

Skrypt automatycznie wykrywa platformę i architekturę, pobiera odpowiedni plik binarny i umieszcza go w PATH.

Pobieranie plików binarnych

W środowiskach bez npm lub Homebrew można pobrać pliki binarne dla konkretnej platformy ze strony 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 tokenami ograniczonymi (awansowany z wersji eksperymentalnej w v0.100.0). Obsługiwany również 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

Dwie ścieżki uwierzytelniania:

1. Konto ChatGPT (zalecane): Logowanie za pomocą 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 eksperta: Sposób przechowywania poświadczeń można skonfigurować za pomocą cli_auth_credentials_store w config.toml. Opcje: file (domyślnie), keyring (pęk kluczy systemu operacyjnego) lub auto (keyring, jeśli dostępny, w przeciwnym razie plik).

Uzupełnianie poleceń 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 v0.104.0

Szybki start: pierwsza sesja

Przejście od zera do produktywności 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 strukturę bazy kodu. W domyślnym trybie suggest żadne zmiany nie są wprowadzane.

5. Wprowadzenie zmiany:

> Add input validation to the login endpoint

Codex proponuje edycje w formie diffu. Można je zatwierdzić klawiszem y lub odrzucić klawiszem n.

6. Użycie slash commands:

> /plan Refactor the database layer to use connection pooling

Codex tworzy plan bez jego wykonywania. Po przejrzeniu planu można go zatwierdzić, aby rozpocząć realizację.

7. Sprawdzenie wprowadzonych zmian:

> /diff

Wyświetlenie wszystkich zmian wprowadzonych przez Codex w bieżącej sesji.

Co dalej: - Konfiguracja AGENTS.md z instrukcjami projektu (zob. Jak działa AGENTS.md?) - Konfiguracja profilu pod własny przepływ pracy (zob. Profile) - Wypróbowanie 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 inny wzorzec pracy.

1. Interaktywny CLI (Terminal UI)

codex                        # Launch TUI
codex "fix the failing tests" # Launch with initial prompt
codex -m gpt-5.3-codex      # Specify model
codex --full-auto            # Workspace-write sandbox + on-request approval

Terminal UI to pełnoekranowa aplikacja z następującymi elementami:

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

Kluczowe skróty TUI:

Slash commands dostępne w TUI:

2. Codex Desktop App (macOS + Windows)

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

Aplikacja desktopowa oferuje możliwości niedostępne w CLI:

• Wielozadaniowość: równoległe uruchamianie wielu agentów w różnych projektach jednocześnie
• Izolacja za pomocą worktrees git: każdy wątek pracuje na izolowanej kopii repozytorium
• Wbudowany podgląd diffów: stagowanie, cofanie i commitowanie zmian bez opuszczania aplikacji
• Zintegrowany terminal: terminal przypisany do każdego wątku do uruchamiania poleceń
• Rozgałęzianie rozmów: tworzenie odgałęzień rozmów w celu eksploracji alternatyw
• Odpinane okna: odłączanie rozmów do przenośnych okien
• Automatyzacje: planowanie cyklicznych zadań (triage zgłoszeń, monitorowanie CI, reagowanie na alerty)

Kiedy używać aplikacji desktopowej, a kiedy CLI: Aplikacja desktopowa sprawdza się przy koordynowaniu wielu strumieni pracy lub gdy potrzebny jest wizualny podgląd diffów. CLI warto wybrać, gdy zależy nam na kompozycji terminalowej, skryptowaniu lub integracji z CI/CD.

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

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

• Tryb agenta domyślnie: odczytywanie plików, wprowadzanie edycji, uruchamianie poleceń
• Edycje inline: sugestie uwzględniające kontekst w aktywnych plikach
• Sesje współdzielone: sesje synchronizowane między CLI a rozszerzeniem IDE
• Wspólne uwierzytelnienie: logowanie kontem ChatGPT lub kluczem API

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

4. Codex Cloud [EKSPERYMENTALNY]

Zadania w chmurze wykonują się asynchronicznie w środowiskach zarządzanych przez OpenAI:

• Wystrzel i zapomnij: kolejkowanie zadań działających niezależnie od maszyny lokalnej
• Równoległe wykonywanie: jednoczesne uruchamianie wielu zadań w chmurze
• Tworzenie PR: Codex tworzy pull requesty z ukończonej pracy
• Lokalne zastosowanie: pobieranie wyników z chmury do lokalnego repozytorium za pomocą codex apply <TASK_ID>

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

Zadania w chmurze są również dostępne z poziomu chatgpt.com/codex.⁴

Szczegółowy opis systemu konfiguracji

Codex używa formatu TOML do konfiguracji. Zrozumienie hierarchii pierwszeństwa jest kluczowe, ponieważ określa ona, które ustawienia mają priorytet w przypadku konfliktów.

Kolejność pierwszeństwa (od najwyższego do najniższego)

1. Nadpisania sesji (najwyższe): flagi CLI (--model, --sandbox, --ask-for-approval, --search, --enable/--disable, --profile) oraz nadpisania -c key=value
2. Konfiguracja projektu (.codex/config.toml, wyszukiwana od bieżącego katalogu w górę 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ższe)

requirements.toml działa jako warstwa ograniczeń polityki, która ogranicza wartości dostępne dla użytkowników po standardowym scalaniu konfiguracji. Zobacz Enterprise Deployment.

Lokalizacje plików konfiguracyjnych

Wskazówka ekspercka: Zmienna środowiskowa CODEX_HOME nadpisuje domyślny katalog ~/.codex. Przydatne w środowiskach CI/CD lub konfiguracjach z wieloma kontami.

Kompletna dokumentacja konfiguracji

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

# ─── Model Selection ───────────────────────────────────
model = "gpt-5.3-codex"                # Default model (272K input context)
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.2-codex"         # 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-failure|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 zestawy 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 ekspercka: Można ustawić domyślny profil za pomocą profile = "fast" na najwyższym poziomie konfiguracji. Nadpisanie dla sesji odbywa się przez --profile.

Niestandardowi dostawcy modeli

Łączenie z Azure, 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"

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

Uwaga: Format chat/completions wire API (wire_api = "chat") został wycofany dla modeli hostowanych przez OpenAI — OpenAI ogłosiło usunięcie w lutym 2026.³⁶ Lokalni dostawcy (Ollama, LM Studio) mogą nadal akceptować ten format. Dla endpointów OpenAI należy używać wire_api = "responses".

Użycie lokalnych modeli z flagą --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"

Nadpisania konfiguracji z linii poleceń

Nadpisywanie dowolnej wartości konfiguracyjnej z poziomu wiersza poleceń:

codex -c model="gpt-5.2-codex" "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 (marzec 2026)

GPT-5.4 jest 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.

Informacja o wycofaniu (11 marca 2026): Modele GPT-5.1 nie są już dostępne w ChatGPT. Istniejące konwersacje automatycznie kontynuują 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 dla obciążeń wrażliwych na koszty.⁷³

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
   │     ├─ Pure coding task (refactor, migration, feature build)?
   │     │  ├─ Yes → gpt-5.3-codex (coding specialist, 272K context)
   │     │  └─ No → gpt-5.4 (recommended: coding + reasoning + computer use, 1M context)
   └─ Still unsure? → gpt-5.4

Poziom rozumowania

Kontrola tego, jak intensywnie model „myśli” przed udzieleniem odpowiedzi:

Dostępne 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 ekspercka: Rozumowanie xhigh może zużywać 3–5× więcej tokenów niż medium dla tego samego promptu. Należy je stosować wyłącznie do naprawdę trudnych problemów, w których dodatkowe myślenie się opłaca.

Zmiana modelu

Można zmienić model w trakcie sesji za pomocą slash commands /model lub ustawić go per uruchomienie przez --model / -m:

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

Ile kosztuje Codex?

Patrz również Wybór modelu dla informacji o możliwościach oraz Ramy decyzyjne do wyboru odpowiedniego modelu dla danego zadania.

Dostęp przez plany ChatGPT

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

Ceny promocyjne: Dostęp Free/Go i 2× limity dla płatnych planów zbiegły się z premierą Codex Desktop App (luty 2026). Te wyższe limity obowiązują na wszystkich powierzchniach — aplikacja, CLI, IDE i chmura. OpenAI nie ogłosiło daty zakończenia promocji.¹⁷

Koszty kredytów

Operacje Codex zużywają kredyty z przydziału planu:

Plany Enterprise i Edu skalują kredyty zgodnie z przydziałem kontraktowym. Można sprawdzić bieżące zużycie przez /status w TUI.

Rozliczenia API

Podczas korzystania z Codex przez API OpenAI rozlicza zużycie per token zgodnie ze standardowym cennikiem OpenAI API dla wybranego modelu (plus ewentualne zniżki za buforowanie promptów). Aktualne stawki można sprawdzić na oficjalnej stronie cenowej API.²¹

Strategie optymalizacji kosztów

1. Używanie profili: Można utworzyć profil fast z gpt-5.1-codex-mini i model_reasoning_effort = "low" dla rutynowych zadań
2. Oszczędzanie wysokiego rozumowania: xhigh należy stosować tylko do naprawdę trudnych problemów, ponieważ kosztuje 3–5× więcej tokenów
3. Używanie --ephemeral: Pomijanie utrwalania sesji w CI/CD w celu zmniejszenia narzutu
4. Minimalizacja podsumowań rozumowania: Ustawienie model_reasoning_summary = "none", gdy wyjaśnienia nie są potrzebne
5. Tryb wsadowy exec: codex exec eliminuje narzut TUI w procesach automatyzacji
6. Monitorowanie zużycia: Sprawdzanie /status w TUI i pulpitów rozliczeniowych organizacji

Przykłady kosztów z praktyki

Reprezentatywne koszty API dla typowych zadań (gpt-5.3-codex w standardowym cenniku, rozumowanie medium):

Koszty różnią się w zależności od poziomu rozumowania, buforowania i długości konwersacji. Do rutynowych zadań warto używać gpt-5.1-codex-mini, co zmniejsza koszty o ~40–60%. Buforowane tokeny wejściowe są rozliczane ze zniżką.

Ukryty narzut tokenów

Każde wywołanie narzędzia dodaje tokeny poza widocznym promptem:

Wskazówka ekspercka: Warto monitorować rzeczywiste zużycie przez /status w TUI. Liczba tokenów obejmuje cały narzut, nie tylko widoczne wiadomości. Jeśli koszty zaskakują, należy sprawdzić liczbę podłączonych serwerów MCP — każdy dodaje definicje narzędzi do każdego wywołania API.

Zarządzanie kosztami zespołu

Strategie kontroli kosztów zespołu: - Ustawienie requirements.toml w celu wymuszenia limitów modeli i poziomu rozumowania w całej organizacji - Używanie gpt-5.1-codex-mini w CI/CD — zautomatyzowane potoki rzadko potrzebują maksymalnego rozumowania - Budżetowanie oparte na profilach — definiowanie profili ci, review i dev z odpowiednimi pułapami kosztów - Monitorowanie przez OpenTelemetry — wdrożenia korporacyjne mogą eksportować telemetrię zużycia do istniejących stosów obserwowalności

Ramki decyzyjne

Kiedy używać poszczególnych interfejsów

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

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

Tryb planowania a bezpośrednie wykonanie

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

Tryb sterowania: Enter vs Tab

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

Desktop App vs 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?

Dopasuj 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 na sesję: codex --profile careful

Jak działa system sandbox i zatwierdzeń?

Codex wykorzystuje dwuwarstwowy model bezpieczeństwa, który oddziela to, co jest technicznie możliwe od momentu, w którym Codex prosi o zatwierdzenie przez człowieka. Podejście to różni się fundamentalnie od systemu uprawnień Claude Code — Codex wymusza ograniczenia na poziomie jądra systemu operacyjnego.⁵ Warto również zapoznać się z rozdziałem Enterprise Deployment dotyczącym ograniczeń w requirements.toml, które administratorzy egzekwują w całej organizacji.

Warstwa 1: Sandbox (co jest możliwe)

Sandbox kontroluje dostęp do systemu plików i sieci za pomocą natywnych mechanizmów systemu operacyjnego:

Egzekwowanie zależne od platformy:

• macOS: Framework Seatbelt firmy Apple poprzez sandbox-exec z profilami specyficznymi dla trybu, kompilowanymi w czasie wykonywania i egzekwowanymi przez jądro⁶
• Linux: Landlock do ograniczeń systemu plików + seccomp do filtrowania wywołań systemowych. Samodzielny proces pomocniczy (codex-linux-sandbox) zapewnia izolację w modelu obrony wielowarstwowej.⁵ Bubblewrap (bwrap) jest dołączony i kompilowany jako część buildu linuksowego (awansowany z opcjonalnego w v0.100.0)⁷. Wersja v0.117.0 poprawiła niezawodność sandbox na starszych dystrybucjach z przestarzałymi konfiguracjami jądra.⁷⁷
• Windows: Natywny sandbox z tokenami ograniczonymi (awansowany z eksperymentalnego w v0.100.0). WSL również obsługiwany (dziedziczy Landlock + seccomp z Linuksa). Wersja v0.117.0 zawiera ulepszenia sandbox z tokenami ograniczonymi dla lepszej izolacji procesów.⁷⁷

Dlaczego to ma znaczenie: W odróżnieniu od 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 sandbox przez fork zsh (v0.106.0): Naprawiono lukę, w której wykonanie powłoki przez forkowanie zsh mogło ominąć ograniczenia sandbox.⁶² W przypadku korzystania z wcześniejszej wersji należy natychmiast zaktualizować. - Limit rozmiaru danych wejściowych (v0.106.0): Codex wymusza teraz limit około 1 miliona znaków na dane wejściowe, aby zapobiec zawieszaniu się przy nadmiernie dużych ładunkach.⁶² - System plików /dev w Linuksie (v0.105.0): Polecenia uruchamiane w sandbox na Linuksie otrzymują teraz minimalny system plików /dev, co poprawia kompatybilność z narzędziami oczekującymi węzłów urządzeń.⁶³

Polityka ReadOnlyAccess (v0.100.0+): Konfigurowalna struktura polityki do szczegółowej kontroli dostępu do odczytu. Umożliwia ograniczenie katalogów, z których Codex może czytać, nawet w trybie workspace-write:

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

Warstwa 2: Polityka zatwierdzeń (kiedy pytać)

Polityka zatwierdzeń określa, kiedy Codex wstrzymuje się i prosi o potwierdzenie przez człowieka:

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

Codex przypisuje teraz odrębne identyfikatory zatwierdzeń do każdego polecenia w ramach wieloetapowego wykonywania powłoki. Oznacza to, że zatwierdzenia są szczegółowe — zatwierdzenie jednego polecenia w sekwencji nie powoduje automatycznego zatwierdzenia kolejnych w tej samej sesji powłoki.⁵¹

Elastyczne mechanizmy zatwierdzeń (v0.105.0+)

Proces zatwierdzania obsługuje teraz dodatkowe uprawnienia sandbox i szczegółowe odrzucanie:⁶³

• Dodatkowe uprawnienia sandbox: Gdy polecenie wymaga dostępu wykraczającego poza bieżący tryb sandbox, Codex może zażądać konkretnych dodatkowych uprawnień zamiast wymagać pełnej zmiany trybu
• Szczegółowe odrzucanie: Można odrzucić poszczególne wywołania narzędzi z informacją zwrotną, aby Codex mógł dostosować swoje podejście zamiast po prostu ponownie próbować tego samego polecenia

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

Codex zawiera teraz wbudowane narzędzie request_permissions, które pozwala modelowi żądać dodatkowych uprawnień w czasie wykonywania.⁷¹ Gdy model natrafi na zadanie wymagające podwyższonego dostępu, może formalnie zażądać konkretnych uprawnień (ścieżki systemu plików, dostęp do sieci itp.) poprzez proces zatwierdzania w TUI, zamiast cichego niepowodzenia lub konieczności ponownego uruchomienia z innymi flagami.

Język konfiguracji profili uprawnień (v0.113.0+)

Nowy język konfiguracji profili uprawnień dzieli polityki sandbox systemu plików i sieci na oddzielne, komponowalne sekcje:⁷¹

[permission_profile.filesystem]
read = ["~/Projects", "/usr/local"]
write = ["~/Projects/my-app"]

[permission_profile.network]
allow = ["api.github.com", "registry.npmjs.org"]
deny = ["*"]   # Global wildcard domains now rejected (hardened in v0.113.0)

Zastępuje to monolityczny tryb sandbox szczegółowymi politykami per zasób. Wykonywalne profile uprawnień integrują się również z polityką sandbox per turę do wykonywania skills (v0.112.0).⁷⁰

Flaga --full-auto

--full-auto to wygodny alias dla:

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

Krytyczna uwaga: --full-auto nadpisuje każdą jawnie podaną wartość --sandbox. Przekazanie --full-auto --sandbox read-only da w rezultacie workspace-write, ponieważ --full-auto ma pierwszeństwo.⁸

Zalecane konfiguracje

Codzienna praca programistyczna (bezpieczne ustawienie domyślne):

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

Zaawansowany użytkownik (pełny dostęp, człowiek w pętli):

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

Ta kombinacja jest rekomendowanym przez społeczność „złotym środkiem”: maksymalne możliwości, ale zatwierdzenie wymagane dla każdego polecenia.⁹

Automatyzacja CI/CD:

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

Inteligentne zatwierdzenia z Guardian Subagent (v0.115.0+)

Smart Approvals mogą kierować żądania przeglądu do guardian subagent zamiast wymagać ludzkiego zatwierdzenia dla każdej akcji. Sesja guardian utrzymuje się między zatwierdzeniami, aby wykorzystywać pamięć podręczną promptów i unikać narzutu uruchamiania. Każdy przegląd otrzymuje czystą historię (wcześniejsze decyzje nie przenikają do późniejszych przeglądów).⁷⁵

Konfiguracja reviewera w config.toml:

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

Jest to szczególnie przydatne w procesach CI/CD, gdzie potrzebny jest automatyczny przegląd z uzasadnieniem zamiast ogólnikowego approval_policy = "never".

Włączanie dostępu do sieci

Codex domyślnie blokuje dostęp do sieci w trybie workspace-write. Można go włączyć 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

Obsługa proxy WebSocket (v0.104.0+)

W środowiskach korporacyjnych kierujących ruch WebSocket przez proxy, Codex obsługuje teraz zmienne środowiskowe WS_PROXY i WSS_PROXY:⁵¹

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

Uzupełniają one istniejącą obsługę proxy HTTPS_PROXY i SOCKS5 (v0.93.0+), pokrywając wszystkie warstwy transportowe.

Testowanie sandbox

Warto zweryfikować zachowanie sandbox przed poleganiem na nim:

codex sandbox macos --full-auto -- ls /etc/passwd   # macOS test
codex sandbox linux --full-auto -- cat /etc/shadow   # Linux test

Jeśli sandbox działa poprawnie, oba polecenia powinny zakończyć się błędem odmowy dostępu — sandbox uniemożliwia odczyt wrażliwych plików systemowych nawet w trybie --full-auto. Jeśli którekolwiek polecenie zakończy się sukcesem, konfiguracja sandbox wymaga zbadania.

Jak działa AGENTS.md?

AGENTS.md to system instrukcji projektowych Codex — otwarty standard¹⁰ zarządzany obecnie przez Agentic AI Foundation w ramach Linux Foundation. Obsługiwany przez Codex, Cursor, Copilot, Amp, Jules (Google), Gemini CLI, Windsurf, Cline, Aider, Zed, Factory, RooCode oraz ponad 60 000 projektów open source. Definiuje sposób działania Codex w ramach konkretnego repozytorium lub katalogu. Więcej o pakietach wielokrotnego użytku uzupełniających AGENTS.md w sekcji Skills.

Hierarchia odnajdywania

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

1. Globalne (~/.codex/): AGENTS.override.md > AGENTS.md
2. Projektowe (od korzenia repozytorium git do bieżącego katalogu): Na każdym poziomie sprawdzane są AGENTS.override.md > AGENTS.md > nazwy zapasowe
3. Scalanie: Pliki są konkatenowane od korzenia w dół; pliki bliższe bieżącemu katalogowi pojawiają się później w prompcie i nadpisują 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 składa się na dobry AGENTS.md

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

TAK: - Konkretność: "Use rg --files for discovery" jest lepsze niż "search efficiently" - Zdefiniowanie zakończenia: Co oznacza „gotowe”? (testy przechodzą, lint czysty itp.) - Dołączenie poleceń: Build, test, lint, format (dokładne wywołania) - Organizacja według zadań: Sekcje dla kodowania, review, wydań, debugowania/incydentów - Zdefiniowanie eskalacji: Co robić w przypadku zablokowania lub nieoczekiwanego stanu

NIE: - Wrzucanie całych przewodników stylu bez reguł wykonawczych - Używanie niejednoznacznych dyrektyw („bądź ostrożny”, „zoptymalizuj”) - Mieszanie sprzecznych priorytetów (szybkość + wyczerpująca weryfikacja + brak budżetu na runtime) - Pisanie dokumentacji prozą (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.

Mechanizm nadpisywania

AGENTS.override.md na dowolnym poziomie katalogu zastępuje standardowy AGENTS.md w danym zakresie. Zastosowania:

• Zamrożenie wydania: „Żadnych nowych funkcji, tylko poprawki”
• Tryb incydentowy: „Wszystkie zmiany muszą być zrecenzowane przez dyżurnego”
• Tymczasowe utwardzenie: „Żadnych 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

Można też zweryfikować łańcuch instrukcji:

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

Hooks

Codex wprowadził hooks w wersji v0.99.0 (AfterAgent) i v0.100.0 (AfterToolUse), a następnie dodał eksperymentalny silnik hooks w v0.114.0 z obsługą zdarzeń SessionStart i Stop.⁷² System obejmuje obecnie cykl życia sesji oraz automatyzację na poziomie narzędzi, wyrównując możliwości z modelem hooks w Claude Code.

Dostępne zdarzenia hooks

Konfiguracja hooks

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 hooka SessionStart trafia do kontekstu modelu, co czyni go idealnym do wstrzykiwania dynamicznych informacji (daty, nazwy gałęzi, zmienne środowiskowe) przy starcie sesji.

Odtwarzanie wzorców hooks z Claude Code

Przy migracji z Claude Code można uzyskać podobną automatyzację w następujący sposób:

Wskazówka ekspercka: Silnik hooks jest eksperymentalny i aktywnie rozwijany. Warto sprawdzać changelog Codex pod kątem nowych zdarzeń hooks w każdym wydaniu.

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

MCP rozszerza możliwości Codex, umożliwiając 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ą ulec zmianie między wydaniami. Codex obsługuje dwa typy transportu: STDIO (procesy lokalne) oraz Streamable HTTP (serwery zdalne).¹²

Konfiguracja 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 wyświetla aktywne serwery i dostępne narzędzia.

Uruchamianie Codex jako serwera MCP

Codex może udostępniać się jako serwer MCP na potrzeby orkiestracji wieloagentowej:¹³

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

Serwer udostępnia dwa narzędzia: 1. codex(): Rozpoczyna nową sesję z parametrami prompt, sandbox, model i approval 2. codex-reply(): Kontynuuje istniejącą sesję za pomocą threadId i prompt

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")

Popularne serwery MCP

Praktyczne wzorce

Wzorzec 1: Programowanie z uwzględnieniem kontekstu — Połączenie Context7 z dokumentacją frameworka zapewnia Codex stały dostęp do aktualnych referencji 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 do ~25 tys. znaków. W przypadku narzędzi zwracających duże dane (zapytania do baz danych, logi), warto użyć enabled_tools, aby ograniczyć zakres do konkretnych narzędzi i utrzymać zwięzłość odpowiedzi.

Wzorzec 2a: Multimodalne dane wyjściowe narzędzi (v0.107.0) — Niestandardowe narzędzia mogą teraz zwracać multimodalne dane wyjściowe (obrazy, rich content) obok tekstu. Umożliwia to narzędziom generującym artefakty wizualne — zrzuty ekranu, diagramy, wykresy — bezpośrednie przekazywanie ich do modelu w celu analizy.⁶⁴

Wzorzec 3: Korporacyjne zarządzanie MCP — Kontrola dostępnych serwerów MCP 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 zdefiniowanej w requirements.toml, zostanie zablokowany przy uruchomieniu. Szczegóły w sekcji Enterprise Deployment dotyczącej pełnej konfiguracji polityk.

Tryb Code [EXPERIMENTAL]

Tryb Code (v0.114.0) zapewnia bardziej izolowane przepływy pracy programistycznej, ograniczając zakres działania agenta do operacji skoncentrowanych na kodzie.⁷² Po włączeniu agent skupia się na odczytywaniu, zapisywaniu i testowaniu kodu bez szerszych interakcji z systemem.

Ta funkcja jest eksperymentalna. Warto sprawdzać informacje o wydaniach, aby śledzić zmiany.

Środowisko uruchomieniowe JavaScript REPL [EXPERIMENTAL]

W wersji Codex v0.100.0 dodano eksperymentalne środowisko uruchomieniowe JavaScript REPL (js_repl), które zachowuje stan między wywołaniami narzędzi. W wersji v0.106.0 REPL został przeniesiony do polecenia /experimental z kontrolą kompatybilności przy uruchomieniu — wymaga Node.js 22.22.0 lub nowszego.⁶²

Włączanie JS REPL:

# In config.toml
[features]
js_repl = true

Można go również aktywować w trakcie sesji za pomocą /experimental w TUI.

Przykład użycia: Po włączeniu Codex może zachowywać stan między wywołaniami narzędzi w ramach sesji:

// Codex can accumulate data across multiple tool calls
const results = await fetchTestResults();
const failures = results.filter(r => r.status === "failed");
console.log(`${failures.length} failures out of ${results.length} tests`);
// Variable 'failures' persists and is available in subsequent tool calls

Wymagania: Node.js 22.22.0+ (kontrola kompatybilności przy uruchomieniu). W wersji v0.105.0 dodano ulepszone raportowanie błędów i odzyskiwanie po awariach REPL.⁶³

Ta funkcja jest eksperymentalna. Interfejs może ulec zmianie między wydaniami.

Czym są skills?

Skills to wielokrotnego użytku, wyspecjalizowane pakiety funkcjonalności, które Codex ładuje na żądanie. Są zgodne z otwartym standardem agent skills.¹⁴

Struktura skills

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 wyszukiwania

Codex przechowuje zainstalowane przez użytkownika skills w katalogu $CODEX_HOME/skills (domyślnie: ~/.codex/skills), w tym wbudowane skills systemowe w podkatalogu .system/. Codex obsługuje dowiązania symboliczne do folderów skills.

Tworzenie skills

Format SKILL.md:

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

## Procedura audytu bezpieczeństwa

1. Przeskanuj kod w poszukiwaniu zakodowanych na stałe sekretów za pomocą `rg -i "(api_key|password|secret|token)\s*=" --type py`
2. Sprawdź podatność na SQL injection: szukaj interpolacji ciągów znaków w zapytaniach
3. Zweryfikuj walidację danych wejściowych na wszystkich endpointach API
4. Sprawdź podatności zależności: `pip audit` lub `npm audit`
5. Przejrzyj wzorce uwierzytelniania i autoryzacji
6. Przedstaw wyniki z poziomami krytyczności (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

• Jawne: menu /skills lub wzmianka $skill-name w prompcie
• Niejawne: Codex automatycznie wykrywa pasujące skills na podstawie opisu zadania (jeśli allow_implicit_invocation: true)
• Kreator: użyj $skill-creator, aby interaktywnie stworzyć nowy skill
• Instalator: użyj $skill-installer install <name>, aby zainstalować skills społeczności

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świetlić go w TUI
2. Zweryfikuj ścieżkę: upewnij się, że folder skill znajduje się w rozpoznawanej lokalizacji (~/.codex/skills/, katalog główny projektu lub /etc/codex/skills/)
3. Sprawdź enabled: skills z enabled = false w config.toml nie zostaną załadowane
4. Sprawdź niejawną aktywację: jeśli polegasz na automatycznym wykrywaniu, upewnij się, że allow_implicit_invocation: true w agents/openai.yaml
5. Użyj słów kluczowych: umieść terminy z description danego skill w prompcie, aby poprawić niejawne dopasowanie

Przykład produkcyjny: skill wdrożenia

Kompletny wieloplikowy skill pokazujący współdziałanie referencji 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 za pomocą: $deploy to staging lub $deploy production with canary rollout

Plugins

Plugins łączą skills, wpisy MCP i konektory aplikacji w jeden instalowalny pakiet (v0.110.0+).⁶⁷ Od wersji v0.117.0 plugins są pełnoprawnymi elementami systemu: plugins o zakresie produktowym synchronizują się automatycznie przy starcie, /plugins udostępnia przeglądarkę w TUI do wyszukiwania i zarządzania, a operacje instalacji/usuwania działają zarówno z CLI, jak i TUI.⁷⁷

Źródła plugins

Wykrywanie plugins

Codex informuje model o włączonych plugins na początku sesji (v0.111.0), co poprawia wykrywalność zainstalowanych serwerów MCP, aplikacji i skills.⁶⁷ Model może sugerować odpowiednie plugins podczas sesji na podstawie kontekstu zadania. W wersji v0.117.0 plugins o zakresie produktowym synchronizują się przy starcie, zapewniając dostępność najnowszego katalogu plugins bez ręcznej interwencji.⁷⁷

Wzmianki @plugin (v0.112.0+)

Można odwoływać się do dowolnego zainstalowanego pluginu bezpośrednio w czacie za pomocą @plugin-name.⁷⁰ Gdy wspomni się o pluginie, jego kontekst (możliwości, narzędzia, konfiguracja) jest automatycznie dołączany do okna kontekstowego modelu — nie trzeba opisywać, co plugin robi.

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

Działa to z każdym zainstalowanym pluginem, w tym niestandardowymi skills, serwerami MCP i konektorami aplikacji.

Marketplace plugins (v0.113.0+)

Marketplace plugins oferuje teraz bogatsze możliwości wyszukiwania z metadanymi, kategoriami i ocenami.⁷¹ Weryfikacja uwierzytelniania podczas instalacji sprawdza, czy plugins wymagające kluczy API lub OAuth posiadają prawidłowe poświadczenia przed instalacją. Endpoint dezinstalacji czysto usuwa plugins wraz z powiązaną konfiguracją.

Zarządzanie plugins

codex plugin list              # Show installed plugins
codex plugin install <name>    # Install from marketplace
codex plugin uninstall <name>  # Remove plugin and config (v0.113.0+)

W TUI należy użyć /plugins (v0.117.0+), aby przeglądać, instalować i usuwać plugins interaktywnie bez opuszczania sesji.⁷⁷

Wskazówka ekspercka: Plugins konsolidują to, co wcześniej wymagało osobnej konfiguracji MCP, instalacji skills i ustawień konektorów aplikacji. Pojedynczy plugin może łączyć wszystkie trzy elementy — przyspieszając wdrażanie zespołu i zwiększając przenośność konfiguracji.

Tryb planowania i współpraca

Tryb planowania pozwala Codex zaprojektować podejście przed wprowadzeniem zmian. Jest domyślnie włączony (od v0.94.0).¹⁵ Zapoznaj się z sekcją Ramy decyzyjne, aby poznać drzewo decyzyjne „Tryb planowania a bezpośrednie wykonanie”.

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, dopóki nie zostaną zatwierdzone - Strumieniuje plan w dedykowanym widoku TUI

Tryb sterowania

Tryb sterowania (domyślnie włączony od v0.98.0) umożliwia wstrzykiwanie nowych instrukcji podczas aktywnej pracy Codex, 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śli wolisz poczekać, aż Codex zakończy pracę, zanim wydasz instrukcje, wystarczy pisać normalnie po zakończeniu tury — nie jest wymagany żaden specjalny tryb.

Ulepszenia TUI (v0.105.0–v0.106.0)

Podświetlanie składni (v0.105.0): TUI wyświetla teraz podświetlone składniowo bloki kodu i różnice (diffy) inline. Użyj /theme, aby wybrać schemat kolorów.⁶³

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

Transkrypcja głosowa (v0.105.0, eksperymentalna): Naciśnij spację, aby dyktować prompty za pomocą transkrypcji głosowej. Ta 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ądzenia mikrofonu i głośnika, umożliwiając wybór konkretnego sprzętu audio wejściowego/wyjściowego.⁶⁴

Inne usprawnienia: - Długie linki pozostają teraz klikalne nawet gdy zawijają się w liniach TUI (v0.105.0)⁶³ - Linki do plików lokalnych wyświetlane są z ulepszonym formatowaniem (v0.106.0)⁶² - Obsługa Ctrl+C dla sub-agentów naprawiona — prawidłowe kończenie procesów potomnych (v0.106.0)⁶²

System pamięci

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

Polecenia pamięci

Wspomnienia są przechowywane w plikach markdown w katalogu ~/.codex/memory/. Codex wczytuje je na początku sesji i wykorzystuje do kształtowania zachowania we wszystkich przyszłych sesjach.

Co warto przechowywać

System pamięci sprawdza się najlepiej w przypadku trwałych preferencji i faktów dotyczących projektu:

• Konwencje projektowe: „Ten projekt używa tabulatorów, nie spacji” lub „Odpowiedzi API zawsze zawierają pole meta“
• Preferencje narzędzi: „Używaj pnpm zamiast npm” lub „Uruchamiaj testy za pomocą pytest -x --tb=short“
• Decyzje architektoniczne: „Moduł uwierzytelniania znajduje się w src/core/auth/, a nie w src/middleware/“
• Preferencje przepływu pracy: „Zawsze uruchom linter przed pokazaniem mi diffa”

Pamięć w potokach automatyzacji

Podczas uruchamiania codex exec wspomnienia są ładowane automatycznie. Oznacza to, że potoki CI/CD i skrypty korzystają z tego samego kontekstu co sesje interaktywne — nie ma potrzeby powtarzania instrukcji przy każdym wywołaniu.

Ulepszenia systemu pamięci (v0.101.0–v0.107.0)

• Sanityzacja sekretów: Wspomnienia są automatycznie skanowane pod kątem sekretów przed zapisem na dysk
• Świadomość katalogu roboczego: Pliki pamięci zawierają teraz kontekst katalogu roboczego, umożliwiając przywoływanie informacji specyficznych dla projektu
• Wykluczenie wiadomości deweloperskich: Wiadomości deweloperskie/systemowe są wykluczane z wejścia pamięci fazy 1, co poprawia jakość pamięci poprzez skupienie się na interakcjach użytkownika
• Zapominanie oparte na diffach (v0.106.0): System pamięci wykorzystuje teraz zapominanie oparte na diffach w celu usuwania nieaktualnych faktów, utrzymując bazę pamięci zwięzłą i trafną⁶²
• Selekcja uwzględniająca użycie (v0.106.0): Pobieranie wspomnień uwzględnia teraz częstotliwość dostępu, priorytetyzując często używane i ostatnio istotne wspomnienia⁶²
• Konfigurowalna pamięć (v0.107.0): Wspomnienia są teraz w pełni konfigurowalne. Polecenie codex debug clear-memories pozwala zresetować wszystkie zapisane wspomnienia i zacząć od nowa — przydatne przy przełączaniu się między niepowiązanymi projektami lub gdy stan pamięci uległ dezaktualizacji⁶⁴

Pamięć a AGENTS.md

Wskazówka: /m_update służy do zapisywania faktów, które powinny być trwałe. Dla kontekstu specyficznego dla sesji wystarczy powiedzieć Codex bezpośrednio w rozmowie. Dla współdzielonego kontekstu zespołowego należy użyć AGENTS.md.

Zarządzanie sesjami

Codex przechowuje sesje w katalogu ~/.codex/sessions/, umożliwiając wznawianie, rozgałęzianie i wielowątkowe przepływy pracy zarówno w CLI, jak i w aplikacji desktopowej.

Wznawianie

Kontynuacja od miejsca, w którym skończono:

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 /resume w TUI otwiera ten sam interaktywny selektor z wyszukiwaniem.

Rozgałęzianie

Rozgałęzienie rozmowy w celu eksploracji alternatyw bez utraty bieżącego postępu:

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

Rozgałęzienia tworzą niezależne wątki współdzielące tę samą historię aż do punktu rozgałęzienia. Zmiany w jednym rozgałęzieniu nie wpływają na drugie. Jest to przydatne przy porównywaniu podejść (np. „rozgałęź i spróbuj Redis zamiast Memcached”) lub bezpiecznym eksperymentowaniu z ryzykownymi zmianami.

Rozgałęzianie wątków w podagenty (v0.107.0): Wątki można teraz rozgałęziać w niezależne podagenty, umożliwiając rozmowie tworzenie równoległych strumieni pracy, które działają autonomicznie. Rozszerza to istniejący model rozgałęzień — zamiast jedynie rozgałęziać rozmowę, rozgałęziony wątek staje się podagentem z własnym kontekstem wykonawczym.⁶⁴ Od wersji v0.117.0 podagenty wykorzystują adresy oparte na ścieżkach (np. /root/agent_a) ze strukturalną komunikacją międzyagentową, co czyni koordynację wieloagentową bardziej jawną i łatwiejszą do debugowania.⁷⁷

Lista wątków

Przeglądanie 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 na pasku bocznym z pełną historią i podglądem diffów.

Cykl życia sesji

Sesje synchronizują się między CLI a aplikacją desktopową — można rozpocząć w jednym narzędziu i kontynuować w drugim.

Tryb nieinteraktywny (codex exec)

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

Podstawowe użycie

codex exec "summarize the repository structure"
codex exec --full-auto "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 architektura umożliwia kompozycję ze standardowymi potokami Unix.

Wyjście w formacie JSON Lines

Z flagą --json strumień 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}}

Strukturyzowane wyjście

Wymuszenie kształtu 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 sesji i przegląd kodu

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 nieinteraktywnego uwierzytelniania w środowiskach automatyzacji.

Codex Cloud i zadania w tle [EKSPERYMENTALNE]

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

Codex Cloud uruchamia zadania asynchronicznie w środowiskach zarządzanych przez OpenAI.⁴ Zob. także GitHub Action i CI/CD, aby dowiedzieć się, jak zintegrować Codex z potokiem CI.

Jak to działa

1. Przesłanie zadania (przez chatgpt.com/codex, integrację Slack lub CLI)
2. Codex klonuje repozytorium do izolowanego sandboxa w chmurze
3. Agent pracuje niezależnie: 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 za pomocą codex apply <TASK_ID>

Dostęp do internetu w chmurze

Dostęp agenta do internetu jest domyślnie wyłączony i konfigurowany na poziomie środowiska:

• Wyłączony: Brak dostępu agenta do internetu (domyślnie)
• Włączony: 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 do instalacji zależności, nawet gdy dostęp agenta do internetu jest wyłączony.

Integracja ze Slack

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

Wymagania wstępne: 1. Odpowiedni 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 przestrzeni roboczej

Codex odpowiada linkiem do zadania i publikuje wyniki po zakoń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 Codex Desktop App

Aplikacja Codex Desktop App (macOS i Windows) zapewnia interfejs graficzny zoptymalizowany pod kątem zarządzania wieloma projektami.[^17] Wersja dla Windows została wydana 4 marca 2026 roku z natywną obsługą PowerShell oraz natywnym sandboxem Windows.[^68]

### Instalacja

```bash
codex app                      # Auto-downloads and installs on first run

Lub pobierz 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 podczas tworzenia:

Mechanizm izolacji Worktree:

Po uruchomieniu wątku Worktree aplikacja desktopowa: 1. Tworzy nowy git worktree (git worktree add) w katalogu tymczasowym 2. Przełącza się na nową gałąź utworzoną z bieżącego HEAD 3. Uruchamia agenta wewnątrz worktree — wszystkie zmiany plików są izolowane 4. Po zakończeniu prezentuje przegląd diffów — użytkownik decyduje, które zmiany scalić

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 używają dedykowanych worktree w tle (odizolowanych od katalogu roboczego)
• W projektach bez Git zadania wykonywane są bezpośrednio w katalogu projektu
• Automatyzacje korzystają z domyślnych ustawień sandboxa

Konfiguracja automatyzacji: 1. Otwórz projekt w aplikacji desktopowej 2. Kliknij zakładkę Automatyzacje na pasku bocznym 3. Zdefiniuj wyzwalacz (harmonogram, webhook lub ręczny) 4. Napisz prompt i wybierz tryb wykonania (local lub worktree) 5. Ustaw poziom rozumowania dla uruchomienia automatyzacji (App v26.312)⁷⁴ 6. Automatyzacje uruchamiają się zgodnie z harmonogramem, a wyniki trafiają do kolejki recenzji

Przykłady zastosowań: - Triage zgłoszeń: Automatyczna kategoryzacja i priorytetyzacja nowych zgłoszeń - Monitorowanie CI: Śledzenie niepowodzeń buildów i sugerowanie poprawek - Reakcja na alerty: Reagowanie na alerty monitoringu z analizą diagnostyczną - Aktualizacje zależności: Sprawdzanie i stosowanie poprawek bezpieczeństwa

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

Obsługa systemu Windows

Aplikacja Codex Desktop App została wydana na Windows 4 marca 2026 roku (App v26.304) z natywną obsługą PowerShell, natywnym sandboxem Windows oraz pełną zgodnością funkcji, w tym skills, automatyzacje i worktrees, bez konieczności korzystania z 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 — końcowy tekst odpowiedzi Codex do wykorzystania w kolejnych krokach/zadaniach.

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 uprawnieniami do zapisu mogą wyzwalać przepływy Codex.

Codex SDK

TypeScript SDK umożliwia osadzenie 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ń z aktualizacjami pośrednimi
• outputSchema: Wymuszanie wyjścia w formacie JSON
• Wejście multimodalne: Przekazywanie tekstu i lokalnych obrazów ({ type: "local_image", path: "..." })
• Przepływy pracy z obrazami (v0.117.0): view_image zwraca URL-e, wygenerowane obrazy można ponownie otwierać, a historia obrazów przetrwa wznowienie sesji⁷⁷

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.2-codex" },
});

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

Środowisko uruchomieniowe: Node.js 18+.

Optymalizacja wydajności

Zarządzanie kontekstem

Flagowe modele mają okna wejściowe o pojemności 272K tokenów (128K wyjściowych, łączny budżet 400K), ale zapełniają się szybciej, niż można się spodziewać. Warto zarządzać tym proaktywnie:

1. Regularne używanie /compact: Podsumowuje historię konwersacji, zwalniając tokeny
2. Lokalna dokumentacja: Wysokiej jakości AGENTS.md i lokalna dokumentacja zmniejszają narzut eksploracji (który zużywa kontekst)
3. Dołączanie konkretnych plików za pomocą @: Bezpośrednie odwoływanie się do plików zamiast proszenia Codex o ich wyszukiwanie
4. Skupione prompty: Precyzyjne prompty z konkretnymi plikami zużywają mniej kontekstu niż otwarta eksploracja

Efektywność tokenów

Optymalizacja szybkości

1. gpt-5.3-codex-spark: Wariant o niższym opóźnieniu do interaktywnego parowania
2. --profile fast: Wstępnie skonfigurowany model mini z niskim poziomem rozumowania
3. Równoległe wykonywanie narzędzi: Codex uruchamia niezależne odczyty/sprawdzenia jednocześnie — warto formułować prompty tak, aby to umożliwiać
4. Pętle zorientowane na wynik: Lepiej poprosić o „zaimplementuj, przetestuj, napraw, zakończ gdy zielone” zamiast instrukcji krok po kroku

Jak debugować problemy?

Typowe problemy i rozwiązania

Referencja komunikatów o błędach

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 oraz diagnostyki TUI.

Czysta reinstalacja

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

Tryb debug

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 na github.com/openai/codex/issues.¹

Wdrożenie w przedsiębiorstwie

Kontrola administracyjna (requirements.toml)

Administratorzy wymuszają politykę korporacyjną za pomocą pliku requirements.toml — konfiguracji wymuszanej przez administratora, która ogranicza ustawienia wrażliwe z punktu widzenia bezpieczeństwa i nie może być nadpisana przez użytkowników:²²

# /etc/codex/requirements.toml

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

# 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 odróżnieniu od pliku config.toml na poziomie użytkownika, który określa preferencje, requirements.toml stanowi twardą warstwę ograniczeń definiującą dopuszczalne wartości — użytkownicy nie mogą go nadpisać. Reguły administracyjne mogą jedynie wymagać potwierdzenia (prompt) lub zabraniać (forbid) — nigdy nie zezwalają cicho.

Konfiguracja macOS MDM

Dystrybucja odbywa się przez MDM z wykorzystaniem domeny preferencji com.openai.codex.²² Codex obsługuje standardowe payloady macOS MDM (Jamf Pro, Fleet, Kandji itp.). TOML należy zakodować w base64 bez zawijania linii:

Kolejność priorytetów (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 uzupełniają jedynie nieustawione pola, więc warstwy zarządzane o wyższym priorytecie zawsze mają pierwszeństwo. Wymagania chmurowe działają na zasadzie best-effort — w przypadku niepowodzenia lub przekroczenia limitu czasu pobierania Codex kontynuuje pracę bez warstwy chmurowej.

Integracja z OpenTelemetry

Codex obsługuje propagację kontekstu śledzenia OpenTelemetry ze standardowych zmiennych środowiskowych OTel do wywołań API OpenAI. 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 przez Codex do wywołań API, umożliwiając pełną obserwowalność end-to-end
• Atrybuty zasobów pozwalają tagować ślady według zespołu, środowiska lub projektu
• Przy włączaniu logowania promptów i narzędzi warto pamiętać o wymaganiach dotyczących prywatności — ślady mogą zawierać fragmenty kodu

Dostęp korporacyjny

• ChatGPT Business / Enterprise / Edu: Dostęp kontrolowany przez administratora organizacji z automatycznie stosowanymi wymaganiami pobieranymi z chmury. Obsługa SSO przez SAML/OIDC za pośrednictwem dostawcy tożsamości (Okta, Entra ID itp.)
• API: Standardowa autoryzacja API, rozliczenia oraz kontrola organizacji/projektów. OpenAI publikuje raporty SOC 2 Type II i SOC 3; HIPAA BAA dostępne dla poziomu Enterprise
• Codex SDK: Osadzanie w wewnętrznych narzędziach i przepływach pracy
• Wymuszanie polityk na dużą skalę: Wykorzystanie requirements_toml_base64 dystrybuowanego przez MDM lub /etc/codex/requirements.toml na poziomie systemu plików

Obsługa danych i zgodność z regulacjami: - Dane wejściowe/wyjściowe API nie są wykorzystywane do trenowania zgodnie z warunkami OpenAI Business/Enterprise/API - W kwestii rezydencji danych — ruch API OpenAI jest domyślnie kierowany przez infrastrukturę w USA; w przypadku wymagań dotyczących rezydencji danych w UE należy skontaktować się z zespołem sprzedaży Enterprise OpenAI - Transkrypcje sesji są przechowywane lokalnie; jedynie wywołania API opuszczają maszynę - ChatGPT Enterprise obsługuje ramy zgodności obejmujące SOC 2, RODO i CCPA

Strategia wdrożenia

Rekomendowane wdrożenie fazowe dla organizacji:

1. Pilotaż (tydzień 1–2): Wdrożenie dla 3–5 doświadczonych inżynierów z requirements.toml wymuszającym tryb sandbox untrusted oraz wyszukiwanie cached. Zbieranie opinii na temat wzorców AGENTS.md i potrzeb dotyczących serwerów MCP.
2. Rozszerzenie na zespół (tydzień 3–4): Wdrożenie dla całego zespołu. Dystrybucja standardowego config.toml zespołu przez MDM lub repozytorium. Włączenie sandbox workspace-write dla zaufanych repozytoriów.
3. Integracja z CI (tydzień 5–6): Dodanie codex-action do pipeline’ów CI/CD w celu automatycznej recenzji PR i generowania testów. Użycie --ephemeral dla przewidywalnych kosztów.
4. Cała organizacja (miesiąc 2+): Wdrożenie przez MDM z requirements.toml wymuszającym zatwierdzone serwery MCP, polityki sandbox i dozwolone modele.

Wzorce audytu

Śledzenie wykorzystania Codex i zapewnianie zgodności:

• Ślady OpenTelemetry: Monitorowanie wolumenu wywołań API, zużycia tokenów i opóźnień w podziale na zespoły
• Trwałość sesji: Audyt ~/.codex/sessions/ w celu przeglądu zgodności (wyłączenie za pomocą --ephemeral w kontekstach wrażliwych)
• Wymuszanie tożsamości MCP: requirements.toml loguje zablokowane próby uruchomienia serwerów — przegląd w celu wykrycia nieautoryzowanego użycia narzędzi
• Ścieżka audytu Git: Wszystkie zmiany plików dokonane przez Codex przechodzą przez standardowy git — przegląd za pomocą historii gałęzi i diffów PR

Najlepsze praktyki i antywzorce

Wzorce promptowania

1. Prompty oparte na ograniczeniach: Należy zaczynać od granic. „NIE ZMIENIAJ kontraktów API. Refaktoryzuj jedynie wewnętrzną implementację.”
2. Ustrukturyzowane kroki reprodukcji: Ponumerowane kroki dają lepsze poprawki błędów niż niejasne opisy
3. Żądania weryfikacji: Należy kończyć zdaniem „Uruchom lint + najmniejszy odpowiedni zestaw testów. Podaj polecenia i wyniki.”
4. Odwołania do plików: Można 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 przechodzą.” Codex iteruje do zakończenia

Filozofia testowania

Społeczność zbliża się do konsensusu w sprawie współpracy z AI opartej na testach:²³

• Warto definiować testy z góry jako sygnały ukończenia
• Należy pozwolić Codex iterować, aż testy przejdą (red → green → refactor)
• Warto przyjąć wzorce programowania Tiger Style
• Należy podawać dokładny tekst pliku przy żądaniu łatek. Codex stosuje ścisłe dopasowanie, a nie rozmyte łatanie oparte na AST

Najlepsze praktyki zarządzania kontekstem

• Warto dostarczać wysokiej jakości lokalną dokumentację zamiast polegać na wyszukiwaniu w sieci
• Należy utrzymywać ustrukturyzowany markdown ze spisami treści i plikami postępu („progresywne ujawnianie”)
• Warto normalizować zakończenia linii (LF vs CRLF) w śledzonych plikach, aby zapobiec błędom łatek
• Należy utrzymywać AGENTS.md w zwięzłej formie, ponieważ długie instrukcje są wypychane poza kontekst

Przepływ pracy z Git

• Należy zawsze tworzyć nową gałąź przed uruchomieniem Codex na nieznanych repozytoriach
• Warto stosować przepływy oparte na łatkach (git diff / git apply) zamiast bezpośrednich edycji
• Sugestie Codex należy przeglądać jak review kodu w PR-ach
• Warto użyć /diff, aby zweryfikować zmiany przed zatwierdzeniem

Umiejętności i prompty społeczności

Repozytorium feiskyer/codex-settings dostarcza konfiguracje utrzymywane przez społeczność:²⁴

Prompty wielokrotnego użytku (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 - github-pr-reviewer [pr-number]: Przepływy pracy przeglądu kodu - ui-engineer [requirements]: Produkcyjne tworzenie frontendu

Umiejętności społeczności: - claude-skill: Przekazywanie zadań do Claude Code z trybami uprawnień - autonomous-skill: Wielosesyjna automatyzacja zadań ze śledzeniem postępu - deep-research: Równoległa orkiestracja podzadań - kiro-skill: Pipeline wymagania → projekt → zadania → wykonanie

Antywzorce

Typowe błędy, które marnują tokeny, dają słabe wyniki lub tworzą frustrujące przepływy pracy.

Antywzorce kosztowe

Antywzorce kontekstowe

Antywzorce przepływu pracy

Antywzorce promptowania

Receptury przepływów pracy

Kompletne wzorce dla typowych scenariuszy deweloperskich.

Receptura 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

Należy przejrzeć wygenerowany AGENTS.md, dostosować do własnych konwencji, a następnie:

> Run the health endpoint test and confirm it passes

Receptura 2: Codzienny przepływ pracy deweloperskiej

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.

Przegląd za pomocą /diff, a następnie zatwierdzenie.

Receptura 3: Złożony refaktor 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.

Należy przejrzeć plan. Zatwierdzić lub skorygować:

[Tab] Also add a migration script using Alembic

Po wykonaniu przez Codex, weryfikacja:

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

Receptura 4: Przegląd PR za pomocą 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

Receptura 5: Debugowanie z zadaniami w chmurze [EKSPERYMENTALNE]

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."

Sprawdzenie postępu później:

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

Zastosowanie poprawki lokalnie po zakończeniu:

codex apply <TASK_ID>

Przewodnik migracji

Z Claude Code

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

• Sandbox działa na poziomie systemu operacyjnego: Codex używa Seatbelt/Landlock, a nie kontenerów. Ograniczenia działają na poziomie jądra systemu, poniżej warstwy aplikacji.
• Hooks są rozbudowywane: Codex obsługuje obecnie 5 zdarzeń hook: SessionStart, Stop i UserPromptSubmit (v0.114.0–v0.116.0, eksperymentalne) oraz AfterAgent (v0.99.0) i AfterToolUse (v0.100.0). System obejmuje cykl życia sesji, przechwytywanie promptów i automatyzację na poziomie narzędzi, choć 12+ zdarzeń cyklu życia w Claude Code wciąż oferuje szerszy zakres. W przypadku wzorców automatyzacji, które nie są jeszcze obsługiwane, należy korzystać z instrukcji AGENTS.md lub skills.
• Sub-agenty v2 (v0.117.0): Sub-agenty używają teraz adresów opartych na ścieżkach (np. /root/agent_a) ze strukturalną komunikacją międzyagentową i listowaniem agentów.⁷⁷ Rozszerza to istniejący mechanizm (maks. 6 równoległych, zmniejszone z 12 w v0.91.0). Role w systemie wieloagentowym pozostają konfigurowalne przez config (v0.104.0+).⁴⁹ Wersja v0.105.0 dodała spawn_agents_on_csv do rozgałęziania zadań po wierszach ze śledzeniem postępu i szacowanym czasem ukończenia.⁶³ Codex wciąż nie posiada odpowiednika jawnego interfejsu narzędzia Task z Claude Code do delegowania zadań przez użytkownika — do wzorców delegowania należy używać zadań w chmurze lub orkiestracji SDK.
• AGENTS.md jest międzynarzędziowy: 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 config.toml.

Z GitHub Copilot

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

Z Cursor

Karta szybkiego odniesienia

╔═══════════════════════════════════════════════════════════════╗
║                    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                   ║
║  --full-auto                workspace-write + on-request      ║
║  --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   /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 ║
║  /experimental Toggle experimental features (js_repl)        ║
║                                                               ║
║  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 --full-auto "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 list              List installed plugins        ║
║  codex plugin install <name>    Install from marketplace      ║
║                                                               ║
║  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-failure    Auto-run until failure                         ║
║  on-request    Prompt for boundary violations                 ║
║  never         No prompts                                     ║
║                                                               ║
║  MODELS (March 2026, v0.116.0)                                ║
║  gpt-5.4               Recommended flagship (1M context)     ║
║  gpt-5.3-codex         Coding specialist (272K in / 400K)    ║
║  gpt-5.3-codex-spark   Interactive, lower latency (128K)     ║
║  gpt-5.2-codex         Long-horizon refactors (272K / 400K)  ║
║  gpt-5.1-codex-mini    Quick tasks, cost-efficient (272K/400K)║
║                                                               ║
╚═══════════════════════════════════════════════════════════════╝

Historia zmian

Źródła

Uwaga dotycząca URL-i blogów OpenAI: Źródła ¹⁷, ²⁶–³¹, ³⁴, ⁶⁶, ⁶⁸ i ⁶⁹ prowadzą do wpisów na openai.com/index/, które zwracają HTTP 403 przy automatycznym dostępie z powodu ochrony Cloudflare przed botami. Te URL-e są dostępne poprzez standardową przeglądarkę internetową.