Coding agents
Codex
Codex CLI is the local coding agent from OpenAI for the terminal: an OS-enforced sandbox, its own approval policy and a non-interactive mode for CI.
Codex is the coding agent from OpenAI that runs locally, started from the terminal. It is neither a web surface nor an editor extension, but a process on your machine that reads files, edits them and runs commands inside a repository. Codex Web is the separate cloud product.
It is installed with an installer script on macOS and Linux, a PowerShell command on Windows, an npm package, a Homebrew cask, or a binary from GitHub Releases.
Sandbox and approvals: two separate dials
Sandbox mode decides what a command can technically do once it runs; the operating system enforces it. Approval policy decides when Codex stops and asks. Sandbox values are read-only, workspace-write and danger-full-access, approvals accept on-request and never, and the retired untrusted value should be removed from existing configuration because it can prevent the client from starting.
The sandbox covers spawned commands, not just built-in file operations: whatever Codex launches, including git, package managers and test runners, inherits the same boundaries. workspace-write keeps network access off by default, enabled with the network_access key under [sandbox_workspace_write], and extra directories go into writable_roots.
Enforcement is platform-native: Seatbelt on macOS, bubblewrap on Linux and WSL2, the native Windows sandbox on Windows. Install bubblewrap on Linux first, because the fallback path needs unprivileged user namespaces. The network_proxy feature adds destination rules where deny wins over allow, and its DNS rebinding check reduces risk without removing it. danger-full-access with never is what the docs call full access, so we pair it with isolation outside Codex.
Signing in and daily use
With a ChatGPT account the sign-in flow opens a browser and usage follows your workspace permissions and data settings. With an API key, usage follows your API organisation’s settings instead, and some features that rely on workspace access or cloud services are limited or unavailable. Credentials land in ~/.codex/auth.json or the system credential store, controlled by cli_auth_credentials_store, so file-based storage should be treated like a password.
The CLI is more than an interactive loop. codex exec is the non-interactive entry point for scripts and CI pipelines, where nobody answers an approval prompt, so the sandbox limits must be fixed up front. Other commands review uncommitted changes or a base branch without touching the working tree, resume a saved chat, and connect MCP servers. config.toml under ~/.codex holds the model choice and per-project overrides.
What to watch
- Model names move. Older models retire on a schedule, so pinned names need maintenance.
- Network access is off by default. Installing dependencies or calling an external API must be enabled deliberately, with scoped rules.
- Spawned commands share the sandbox. A test or build step fails if it writes outside the writable roots.
- Bubblewrap is a prerequisite on Linux. Without it the fallback path is weaker and warns at startup.
- Monitoring replaces nothing. If a task is paused, the CLI has no full findings and resume flow.
Where it fits in our stack
Codex is our tool for deeper analysis and a second opinion, where an OS-enforced sandbox matters more than convenience: reviewing an unfamiliar repository in read-only mode, or an unattended CI run with limits fixed in advance. The process is steered from Hermes Agent, and tools are wired through MCP servers; where the sandbox alone is not enough, the task runs in a container under Docker.
CyberElectro works the same way: Codex runs inside boundaries we set in advance, so the result stays reviewable.
Further reading
- openai/codex - source repository and install options.
- Codex CLI - the official CLI documentation.
- Agent approvals & security - sandbox, approvals and network rules.