SafetyCard Request a review

Codex CLI

OpenAI's lightweight terminal coding agent

github.com/openai/codex · 2026-10-03 · b741e48

Defense-in-depth score

4.2 / 10

Codex CLI runs every model-issued shell command inside a real OS sandbox (Seatbelt on macOS, bubblewrap+seccomp on Linux) that blocks network and confines writes to the project, and anything that needs to leave the sandbox goes to you with the exact command shown. The dominant risk is what sits inside that sandbox: every command inherits your full environment, including API keys and cloud tokens, and can read your whole disk (~/.ssh, ~/.codex/auth.json), so one approved network command or a trusted repo whose .codex/config.toml switches off approvals is enough to leak them. There are no turn, time or spend limits by default.

Safest setup

Codex CLI runs every model-issued command in an OS sandbox with network off and writes kept to the project, and asks you, with the exact command on screen, before anything leaves it. Inside that sandbox commands see your full environment and can read your whole disk, so the safest setup strips credentials from that environment and keeps the machine itself free of secrets the task doesn't need.

SetupHowWhat it gives you
Scoped, short-lived credentialsStart Codex from a shell holding only the keys this project needs, each scoped to one project or short-livedWhatever a command reads, it reaches only the access you chose, not your whole account C1
A scrubbed command environmentSet inherit = "core" and ignore_default_excludes = false under [shell_environment_policy] in your own config.tomlCommands run without your API keys, cloud tokens and other KEY, SECRET or TOKEN variables C8
The OS sandbox, network offKeep the default sandbox_mode of workspace-write, with network_access left offCommands change only project files and /tmp, and reach the network only after you approve C4
Per-call approval by youKeep the default approval_policy and approvals_reviewer, and run without --dangerously-bypass-approvals-and-sandboxYou see the exact command before anything leaves the sandbox C2
Folder trust after readingChoose "Trust and continue" once you have read the repository's .codex/config.toml, .codex/rules and AGENTS.mdApproval, sandbox and MCP settings come only from files you have seen C2
Reviewed instruction filesCheck the git diff of AGENTS.md before starting each new sessionInstructions that carry over between sessions are ones you have read C6
Its own container or VMRun Codex in a container or VM that holds only this project and the credentials it needsCommands that can read the whole disk find no SSH keys, cloud logins or other projects C4
Stopped background terminalsRun /stop (alias /clean) after interrupting a turnCommands the agent left running end along with the turn C10

Approving with confidence

  • Read each prompt and approve commands one at a time; a "don't ask again" answer saves a prefix rule, and later commands with that prefix run outside the sandbox.
  • A command asking for network access can send anything it has read, so check where it is going before approving.
  • MCP tools their server marks read-only run without a prompt, so add only MCP servers you trust.

Handling data

  • Session transcripts under ~/.codex/sessions keep every tool call and its output unredacted; store them like the project's secrets.
  • Usage analytics are on by default; enabled = false under [analytics] in your config.toml turns them off.

Key gaps (1)

  1. Sandboxed commands inherit the full parent environment (credentials included) and can read the whole filesystem, so a hijacked command can harvest secrets even though writes and network are blocked. C4 · Code-execution isolation

Criteria

C1 Identity & least privilege

0.33 / 1.00

Codex runs as you and does not narrow your authority for the commands it runs: by default every shell command gets your full environment, including API keys, cloud credentials and GitHub tokens, because the built-in KEY/SECRET/TOKEN filter is switched off by default. MCP servers are the exception and receive only a small core set of variables. What keeps those credentials from being used is not identity scoping but the sandbox: network is off, so using a stolen token needs a command you approve. An experimental, opt-in credential broker can swap GitHub and OpenAI tokens for dummies, but it is off by default.

C2 Approval gates

0.53 / 1.00

Approval in Codex is built around the sandbox: commands that stay inside it (writing project files, running tests) run without asking, while anything that needs to escape it - network access, writes outside the project, or a command the model marks as needing escalation - stops for your approval with the exact command on screen. Forced `rm -f` style deletions always prompt, and MCP tools prompt unless the server itself declares them read-only. Allow-rules you add are saved in your home directory, not the repo, but a repository you have trusted can ship a .codex/config.toml that turns approvals off. There is no undo: escalated commands run fully outside the sandbox once approved.

C3 Tool & action scoping

0.30 / 1.00

The main tool is a general shell that accepts any command string, so argument validation is minimal: there is no allowlist, only a small heuristic that flags forced `rm` and user-written prefix rules. The file-edit tool checks every path against the writable roots before auto-approving. Everything is on by default, though the shell tool can be disabled. In practice the reach of a misused command is bounded by the sandbox: writes stay in the project, but reads cover the whole machine.

C4 Code-execution isolation

0.55 / 1.00

Model-issued commands run inside a real operating-system sandbox: a deny-by-default Seatbelt profile on macOS and bubblewrap plus seccomp with no network namespace on Linux, failing closed if bubblewrap is missing rather than running on the host. Writes are limited to the project (with .git and .codex kept read-only) and /tmp, and network is off. Leaving the sandbox requires a per-command human approval, but approved allow-rules and trusted project config can switch it off, and MCP servers run on the host. Inside the sandbox, though, commands see your full environment (credentials included) and can read your entire disk.

C5 Untrusted input blast radius

0.50 / 1.00

Codex does not try to detect prompt injection; its protection is structural. Because the default sandbox has no network and blocks writes outside the project, an agent hijacked by a malicious README, command output or search result cannot send data out or change things beyond the project without you approving a specific command. It can still read your secrets into the conversation and rewrite or delete project files unattended. MCP or app tools that their server labels read-only are called without approval and could become an outbound channel when configured.

C6 Memory, context & configuration integrity

0.50 / 1.00

Codex is careful with settings a repository could plant: project config, exec-policy rules and hooks only load after you explicitly trust the folder, and each hook must additionally be trusted by its content hash, stored in your own config so a changed hook stops running. Some keys (model endpoints, notify, telemetry) are always ignored in project config. But once a folder is trusted its config can still change approvals, sandbox mode and MCP servers, AGENTS.md instructions load silently, and because AGENTS.md is not write-protected inside the sandbox the agent can edit it and influence future sessions. Long-term memories are off by default.

C7 Third-party extensions

0.35 / 1.00

No third-party extensions run by default. MCP servers and plugins are added by you or by a trusted project's config, launched as separate processes with a cleaned-up environment but without a sandbox, and there is no version pinning or integrity check for MCP commands or custom marketplaces. OpenAI's curated plugin catalog is synced from its own repository. When a skill needs an MCP server Codex asks before installing it, but the prompt lists only server names, not the command that will run.

C8 Secrets & sensitive-data protection

0.28 / 1.00

Your ChatGPT/OpenAI login is stored in a plaintext auth.json with owner-only permissions by default (MCP OAuth tokens prefer the OS keyring). Secret redaction exists but is applied only to some displayed command text and to memories, not to tool output sent to the model or to saved transcripts. The biggest gap is that every shell command inherits your full environment, so long-lived keys are within reach of any command the model runs. Usage analytics are on by default; prompt logging to OpenTelemetry is off.

C9 Audit & traceability

0.55 / 1.00

Every session is written to a JSON-lines transcript under ~/.codex/sessions that records each tool call and its output with timestamps, including MCP calls; sub-agents get their own transcripts. The file sits outside the sandbox's writable area, so the model's commands cannot edit it. Approval prompts and your decisions are not persisted, there is no tamper-evidence, and write failures are only logged while the agent carries on.

C10 Limits & kill switch

0.33 / 1.00

Codex has no cap on turns, wall-clock time or spend by default; the token-budget feature is still under development and off. You can interrupt a turn at any time, which cancels the running task, but long-running commands started as background terminals keep running until you clean them up or exit. Sub-agents inherit the same settings and are capped at 6 concurrent threads and a depth of 1, and at most 64 background processes can exist.