OpenAI Codex CLI: autonomiczny agent w terminalu.

Codex nie jest przywiązany do jednego modelu. Domyślnie bierze rekomendowany wariant, a Ty przełączasz się między modelami w locie komendą /model albo wybierasz go przy starcie flagą -m. Stan na koniec września 2026, przy logowaniu kontem ChatGPT:

• GPT-6.1 Sol (gpt-6.1-sol): domyślny od 29.09.2026. Wynikami zbliża się do Astry, a kosztuje mniej, więc pasuje do długiej, powtarzalnej pracy nad kodem.
• GPT-6 Astra (gpt-6-astra): najmocniejszy model, na zadania, które wymagają długiego rozumowania i pracy z wieloma narzędziami.
• GPT-6 Luna (gpt-6-luna): najoszczędniejszy, do konkretnych, powtarzalnych zadań: ekstrakcji, przekształceń, drobnych poprawek.
• GPT-6 Sol oraz GPT-5.6 Sol, Terra i Luna: nadal dostępne w okresie przejściowym.

Z Codeksa zalogowanego kontem ChatGPT wycofano GPT-5.4 i GPT-5.4-mini (31.08.2026) oraz GPT-5.3-Codex-Spark (14.09.2026). Linia „-codex" (gpt-5.3-codex, gpt-5.2) zniknęła z listy już w maju 2026, podobnie jak codex-mini-latest i o3-mini. GPT-5.5 odchodzi 14.10.2026, więc jeśli siedzi w Twoim config.toml, skryptach albo wywołaniach codex exec -m, podmień go już teraz. Przy logowaniu własnym kluczem API te wycofania Cię nie dotyczą, bo dostępność modeli wynika wtedy z klucza.

Głębokość myślenia ustawiasz sam. W /model wybierasz wysiłek rozumowania, a w części modeli także Max (więcej czasu na jedno zadanie) i Ultra (praca rozdzielona na subagentów). Na co dzień wystarcza ustawienie domyślne; wyższe poziomy zużywają więcej tokenów.

Plik konfiguracyjny: ~/.codex/config.toml.

1. Domyślny model

model = "gpt-6.1-sol"  # lub gpt-6-astra, gpt-6-luna

Jeśli klucza model nie ustawisz, Codex sam dobiera rekomendowany wariant. Model ustawia się kluczem najwyższego poziomu, bez tabeli [model].

2. Tryby zatwierdzania i sandbox

approval_policy = "on-request"   # "on-request", "never" albo { granular = { ... } }
sandbox_mode = "workspace-write" # "read-only", "workspace-write", "danger-full-access"

Po przepisaniu CLI na Rust polityka zatwierdzania i sandbox to dwa osobne klucze. Stare tryby suggest/auto-edit/full-auto są legacy.

• approval_policy — kiedy Codex pyta o zgodę: on-request (pyta przed wyjściem poza sandbox) do pracy interaktywnej, never do CI. Wariant granular pozwala osobno przepuszczać albo automatycznie odrzucać poszczególne kategorie próśb.
• sandbox_mode — zakres działań: read-only, workspace-write (zapis w katalogu projektu), danger-full-access.

3. Serwery MCP

Każdy serwer to osobna tabela [mcp_servers.NAZWA], nie tablica [[...]]. Serwer lokalny (stdio) opisujesz przez command i args, zdalny przez url:

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

[mcp_servers.figma]
url = "https://mcp.figma.com/mcp"
bearer_token_env_var = "FIGMA_OAUTH_TOKEN"

Czym jest Model Context Protocol i jak działa, opisujemy w szkoleniu Serwery MCP. ChromeDevTools MCP daje Codeksowi pełną kontrolę nad przeglądarką Chrome: nawigację, wypełnianie formularzy, testowanie UI, screenshoty, debugowanie i wykonywanie JavaScript.

Instalacja MCP

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

Konfiguracja zapisze się w ~/.codex/config.toml. Alternatywnie dodaj ją ręcznie:

[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest"]

Po instalacji możesz dawać komendy w języku naturalnym, np.:

Otworz localhost:3000, sprawdz czy sa bledy w konsoli i napraw je w kodzie