OpenAI Codex CLI: az ügynök, amely a jogosultságokat konfigurációs fájlnak tekinti

Az OpenAI Codex CLI terminálos kódolóügynök: beolvas egy repositoryt, szerkeszt fájlokat, futtatja a projekt saját parancsait, és addig iterál, amíg a feladat kész nincs. Az érdekes rész nem azügynökci hurok, amit több versenytárs is megtesz. Az az, hogy a biztonsági modell két beállításként jelenik meg egy TOML-fájlban, amelyet egy csapat commitolhat, review-zhat és pinelhet, nem pedig promptként vagy a szolgáltató által kikényszerített kontószabályként.

Ez teszi a kategóriájában legjobban kormányozható kódolóügynökké, és egyben azt, amelyben a konfigurációs hibák a legdrágábbak. Egy commitolt sandbox_mode = "danger-full-access" ugyanis olyan döntés, amely review nélkül jut élesbe. A többi arról szól, mennyire bírja ezt a kompromisszum.

Mi ez

A CLI verziózott npm-csomagként érkezik, jelenleg 0.160.1, a repository Apache-2.0 licenc alatt áll Rust maggal. A Codex szélesebb termékének egyik felülete, amelyhez a ChatGPT desktop app, egy IDE-bővítmény és egy felhős futtató is tartozik, de a CLI az a rész, amely a fejlesztő gépén fut, és az egyetlen, amely nyílt forráskódú.

• Apache-2.0 licenc, Rust mag, npm-csomag @openai/codex plusz önálló telepítőszkript.
• A konfiguráció a ~/.codex/config.toml fájlban él, és projektenként szűkíthető a .codex/config.toml útvonalon.
• Két külön bejelentkezési út: ChatGPT-előfizetés vagy API-kulcs, eltérő limitekkel és eltérő számlázással.
• A helyi munka Git-repositoryt igényel; a codex exec ugyanazt a szabályt kényszeríti ki, és kínálja a --skip-git-repo-check kapcsolót.
• Az MCP-szerverek ugyanabban a konfigurációs fájlban vannak, és meg vannak osztva az IDE-bővítménnyel és a desktop appal ugyanazon a hoszton.

Hogyan működik

A menet szerkezete a megszokott: egy prompt plusz repository-kontextus megy a modellhez, a modell tool-hívásokat ad ki, a CLI egy sandboxban futtatja őket, és az eredmények tool outputként térnek vissza a következő menethez. Ami egy shell-wrappertől eltér, az az, hogy a sandbox és a jóváhagyási ellenőrzés két külön kapu, és mindkettő konfigurált, nem interaktívan kérdezett.

A hurok nem a termék, bármilyen érdekes. Amit egy csapat valójában konfigurál, az a körülötte lévő határ, és a dokumentáció szokatlanul egyértelműen hangsúlyozza, hogy a kettő ortogonális. A Full access módban futó menet a gép minden fájlját szerkesztheti és hálózati parancsokat futtathat kérdés nélkül, és a dokumentáció ezt az adatvesztés és kiszivárgás jelentősen megnövelt kockázataként írja le, nem rejti el.

Első lépések

Telepíts, jelentkezz be, indítsd. Az első indítás a Sign in with ChatGPT vagy egy API-kulcs között választ, és ez később számít, mert ez határozza meg a limiteket és azt, melyik elszámolási rendszerben dolgozol.

# Install on macOS or Linux; npm and Homebrew are also supported.
curl -fsSL https://chatgpt.com/codex/install.sh | sh

# Run inside a project directory, then sign in.
codex

# Pin the version in CI instead of tracking latest.
npm install -g @openai/codex@0.160.1

# The first prompt is a good place for /init, which writes AGENTS.md.
# /status, /model, /permissions and /review are the other useful commands.

Az AGENTS.md az állandó utasításfájl. A CLI olvas egy globális ~/.codex/AGENTS.md fájlt, majd a projekt gyökérkönyvtárától halad az aktuális könyvtárig, szintenként egy fájlt véve, ahol az AGENTS.override.md felülmúlja az AGENTS.md-t. Az együttes méretet a project_doc_max_bytes korlátozza, alapértelmezésen 32 KiB. Egy csapat számára ez a legértékesebb dolog, amit meg lehet írni, mert az ügynök viselkedésének az a része, amely code review-n megy át.

Sandbox és jóváhagyások

Ezt érdemes kétszer elolvasni. A sandbox a határ, a jóváhagyási szabály a megállás. Az alapértelmezés, az Ask for approval, sandbox_mode = "workspace-write" értékkel, approval_policy = "on-request" mellett és emberi reviewerrel. A dokumentáció külön kiemeli, hogy a reviewer váltása auto_review-ra nem szélesíti a sandboxot. Ez a helyes tervezés, és egyben az a részlet, amelyet a legtöbb eszköz elront.

# ~/.codex/config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

# Boundary: read-only | workspace-write | danger-full-access
sandbox_mode = "read-only"

# Pausing: on-request | never | granular table
approval_policy = "on-request"

# Reviewer: user | auto_review
approvals_reviewer = "user"

# Extra roots and network, only used when sandbox_mode = workspace-write
[sandbox_workspace_write]
writable_roots = ["~/code"]
network_access = false

A konfigurációs fájl sokkal mélyebbre megy. Van hálózati proxy domainenkénti engedélyezési és tiltási szabályokkal, van shell környezet politika, amely kiszűri a kulcsra vagy tokenre hasonlító nevű változókat, vannak írható gyökerek, és vannak hookok, amelyek egy tool-hívás előtt futnak. Ez nagy felület, és ellen kell állni a késztetésnek, hogy mindet beállítsd. Minden gomb egy döntés, amelyet valaki más helyett kell meghozni.

Automatizálás és codex exec

A nem interaktív mód az, ami miatt ezt a CLI-t egy chatvezérelt ügynöknél jobbnak érdemes választani. A codex exec alapértelmezésen read-only sandboxban fut, a folyamatot a stderrre írja, csak a végső üzenetet nyomtatja a stdoutra, és Git-repositoryn kívül nem indul el. Ez az utolsó szabály fékezőgép egy olyan ügynök ellen, amely átír egy könyvtárat, amelyről nem tud diffet mutatni.

# Progress on stderr, final message on stdout: safe to pipe.
codex exec "summarise the repository structure" | tee summary.md

# Machine-readable: one JSON object per event.
codex exec --json "triage the open bug reports" | jq

# Escalate the sandbox explicitly, never implicitly.
codex exec --sandbox workspace-write "add a regression test and run it"

# Structured final answer against a schema, written to a file.
codex exec "extract project metadata" \
  --output-schema ./schema.json -o ./metadata.json

Két részlet teszi éles formájúvá. A --json kapcsolóval az eseményfolyam hordozza a felhasználást, a gyorsítótárazott bemeneti tokenekkel együtt, így egy pipeline futtatásonként, nem havi szinten tud költséget rendelni. A required = true jelzésű MCP-szerver pedig a start hibájával áll le, ahelyett hogy csendben továbbmenne. Ez a különbség egy törött CI-futtatás és egy alattomosan rossz között.

MCP és projektkontextus

Az MCP-szerverek ugyanabban a konfigurációs fájlban vannak, így megoszlanak a CLI, az IDE-bővítmény és a desktop app között ugyanazon a hoszton. Támogatott a stdio és a streamable HTTP, OAuth-tel, dinamikus kliensregisztrációval együtt.

[mcp_servers.docs]
command = "npx"
args = ["-y", "@upstash/context7-mcp"]
env_vars = ["CONTEXT7_TOKEN"]
required = true          # fail startup instead of running without it
enabled_tools = ["search", "summarize"]
default_tools_approval_mode = "prompt"
tool_timeout_sec = 45

Az MCP kontextusba kerül, és az árlistázási dokumentáció ezt nyíltan ki is mondja: minden szerver növeli az üzenetet, és többet fogyaszt a keretből. Egy jó csapat kettő-három szervert tart aktívan, a többit letiltja, és a szerverlistát a menetenkénti büdzsé részeként kezeli, nem kényelmi listaként.

Költség és limitek

Két elszámolási rendszer osztozik ugyanazon a binárison, és nem hasonlíthatók össze. A ChatGPT-előfizetés ötórás ablakokban számol üzeneteket, és a közzétett számok becslések, nem plafonok: a Plusz csomagnál a közepes modelleknél körülbelül 15 és 160 helyi üzenet öt óránként, a legolcsóbb modellnél 350 és 3.000 között. Az API-kulcs tokeneket számol a közzétett díjak szerint, és ez teszi őt a megfelelő hitelesítéssé az automatizáláshoz.

A gyakorlati tanács rövid. Az előfizetést használd interaktív munkához, ahol van egy ember, aki észreveszi, ha fogy a keret, az API-kulcsot pedig minden felügyelet nélküli dologhoz, mert csak így lesz futtatásonként előre látható tétel. A /status parancs a munkameneten belül mutatja a maradó kapacitást, és a dokumentáció egyértelmű, hogy önmagában a prompt hossza nem megbízható előrejelzője egy feladat fogyasztásának.

Hol marad el

Három probléma, a fontosságuk szerinti sorrendben. Először is: a konfigurációs felület hatalmas egy olyan eszközhöz képest, amelynek magja hétköznapi hurok, és nincs lehetőség szándékosan kis, egyetlen átolvasásból auditálható konfigurációval futtatni. Másodszor: a CLI körüli termék gyorsan változik, a modelleket rögzített dátumon vonják ki, többet egy éven belül nyugtáztak le, és egy commitolt modellnév egy configban vagy CI-szkriptben teherré válik. Harmadszor: a review parancs anélkül jelenti a megállapításokat, hogy módosítaná a munkafát. Ez a helyes viselkedés, és jóval kevésbé hasznos, mint azok a változatok, amelyek meg is javítják, amit találtak.

Az összehasonlítás olyan közel van, hogy a döntő tényező ritkán maga az ügynök. Az, hogy nálatok milyen a jogosultsági történet. Ha a csapatban már van egy commitolt, review-zott ügynök-konfiguráció, a Codex illik hozzá. Ha nincs, a CLI erőssége teher marad, amíg valaki meg nem írja azt a fájlt.

Ítélet

A Codex CLI a legerősebb választás azoknak a csapatoknak, amelyek olyan kódolóügynököt akarnak, amelynek viselkedése review-zható artefaktum. A sandbox és a jóváhagyás szétválasztása jól átgondolt, a read-only alapértelmezés az automatizáláshoz a helyes alapértelmezés, és az Apache-2.0 azt jelenti, hogy a konfiguráció vendorolható és pinelhető. Egyetlen fejlesztőnek, aki政策 megírása előtt kipróbálna egy ügynököt, gyengébb választás.

1. Vedd fel, ha az ügynök jogosultságai olyan fájlban akarnak élni, amely code review-n megy át, és CI-ben pinneld az npm-verziót.
2. Minden felügyelet nélküli dologhoz API-kulcsot használj. Az előfizetésalapú credit elszámolás nem bírja a kapcsolatot egy ütemezett jobbal.
3. Írj AGENTS.md-t, mielőtt bármit mást állítanál. Ez többet változtat a viselkedésen, mint a config.toml bármelyik kapcsolója.
4. Automatizálásnál hagyd a sandbox_mode-ot workspace-write-on, és a danger-full-accesst tartsd egy általad kontrollált konténerre.
5. Hagyd ki, ha egy évre stabil modellazonosító kell. A kivezetési ütem gyorsabb, mint amit a legtöbb csapat elnyel.

Források

1. Codex CLI documentation
2. Codex: configuration
3. Codex: sample configuration
4. Codex: permissions
5. Codex: non-interactive mode
6. Codex: authentication
7. Codex: Model Context Protocol
8. Codex: pricing
9. Codex: open-source components
10. Codex changelog