OpenAI Codex explained: how a terminal coding agent works inside a real repository
A technical account of the Rust workspace, tool loop, app-server protocol, native sandboxes, approval model, installation paths, and operating limits of Codex CLI.
Position and current signal
Codex CLI is a coding agent that runs in a local terminal. It can inspect a repository, edit files, execute commands, and continue from the resulting output. GitHub showed 100,198 stars at capture time, about 755 commits on the default branch during the prior 30 days, and rust-v0.144.6 as the latest release. The important change is operational: model responses, real tools, and operating-system permissions now sit in one development loop.
Primary use cases and capabilities
Useful assignments include repository orientation, bug fixes, test additions, cross-file refactors, build diagnosis, and repeatable script work. Interactive sessions let a developer examine the plan and patch as work proceeds, while non-interactive execution can support bounded automation with recorded output. The app-server exposes a shared protocol to other interfaces, and MCP can add tools. Each additional tool expands the data and permission boundary that the operator must govern.
Architecture and execution model
The main implementation is a Rust workspace. codex-core owns session behavior, model responses, and tool orchestration; the CLI and TUI provide terminal entry points; the protocol crate defines types shared by core, the TUI, and app-server clients. A task normally repeats a cycle of reading context, requesting a model response, invoking a tool, collecting output, and deciding the next action. Completion, interruption, denied approval, or an unrecoverable error stops the loop.
Technology stack and system boundaries
The core is written in Rust and selects a different execution boundary on each supported operating system. macOS uses Seatbelt through sandbox-exec, Linux prefers bubblewrap with documented compatibility paths, and Windows uses restricted-token and platform sandbox mechanisms. Separating the protocol from user interfaces lets terminals, desktop clients, and external integrations reuse core behavior. It also makes configuration, permissions, and client-version compatibility part of the same operational problem.