Codex CLI is OpenAI's coding agent for the terminal: it reads a repository, edits files and runs commands on the developer's machine, with the developer's access. It ships with a sandbox and approval modes that are better than most, and every one of them can be switched off by the developer in one file. This article is two things at once. The first half is a plain account of what Codex CLI is, how it installs, signs in and runs, for anyone deciding whether to use it. The second half is for the security team that has just learned developers already do: what it can reach on a laptop, which settings matter, and the one file a developer cannot override.
What is Codex CLI?
OpenAI describes it as a lightweight coding agent that runs in your terminal (source: the Codex repository). It is open source under the Apache 2.0 licence, and it installs with one line: npm install -g @openai/codex, brew install --cask codex, or the shell installer at chatgpt.com/codex/install.sh. On first run it asks you to sign in with ChatGPT, and OpenAI lists Plus, Pro, Business, Edu and Enterprise as the plans it comes with. The alternative is an API key, billed through the OpenAI Platform account at standard API rates (source: authentication).
Once signed in, you type what you want in a terminal, and Codex inspects code, makes changes and runs commands to get there. It shares one configuration with the ChatGPT desktop app and the Codex IDE extension, so an MCP server added in one appears in the others (source: MCP).
How it differs from the other two agents most companies find on developer laptops: Claude Code is also a terminal agent, but has no sandbox by default and relies on permission rules and hooks. Cursor is an editor with an agent inside it. Codex CLI sits between them: a terminal agent that runs commands inside an operating-system sandbox unless told not to.
Where its configuration lives
Everything a developer can set is in one file, ~/.codex/config.toml, and a project can add its own .codex/config.toml with overrides, which apply only in a project the developer has marked trusted (source: configuration reference). The keys that decide what the agent may do:
approval_policy: when Codex asks before acting.on-requestasks for what the sandbox does not allow,neverstops asking entirely, and a granular form picks which categories ask.sandbox_mode: what it may touch.read-only,workspace-write, ordanger-full-access.[sandbox_workspace_write]: the details of the middle mode, includingwritable_roots, the directories it may write to, andnetwork_access.[mcp_servers.<name>]: one table per MCP server, with acommandfor a local one or aurlfor a remote one, plusargs,envand per-tool approval settings.[features]: toggles, includinghooks.[projects]: which directories aretrusted, which is what lets a project's own config and MCP servers load.
Credentials are separate. Sign-in with ChatGPT or an API key ends up in ~/.codex/auth.json, or in the operating system's credential store when that is available, which is the default (source: authentication).
What each mode runs without asking
The sandbox and the approval policy are two different controls, and it helps to keep them apart. The sandbox is what Codex can do technically: where it can write and whether it can reach the network. The approval policy is when it must ask a person first (source: approvals and security).
The presets combine them:
- Auto, the default in a version-controlled folder:
workspace-writewithon-request. It reads, edits and runs commands inside the workspace without asking. It asks for edits outside the workspace and for network access. - Read-only:
read-onlywithon-request. It reads and runs commands inside the sandbox without asking, and asks for anything beyond it. - Dangerous full access, the
--yoloflag, also spelled--dangerously-bypass-approvals-and-sandbox: no sandbox, no approvals. OpenAI's own page marks it elevated risk and not recommended.
Two details matter for the security reader. Network access is off by default in workspace-write; a developer turns it on with network_access = true under [sandbox_workspace_write]. And even in a writable sandbox, .git, .agents and .codex inside the workspace stay read-only, so the agent cannot quietly rewrite its own configuration or the repository's history.
The sandbox itself is the operating system's. On macOS it is the built-in Seatbelt framework. On Linux and WSL2 it is bubblewrap, which must be installed first, and Codex uses the first bwrap it finds on the path (source: sandboxing). The documentation does not say what happens to a command the user approves that the sandbox would have blocked, so this article does not either.
MCP servers
Codex loads MCP servers from the same config.toml, one [mcp_servers.<name>] table each. codex mcp add writes the table; codex mcp login handles a remote server's OAuth. A project can bring its own servers in .codex/config.toml, but only in a trusted project. Each server has a default_tools_approval_mode, with values including auto, prompt, writes and approve, so whether a tool call asks is set per server (source: MCP).
Everything in the MCP server security post applies here. A server is a process started with the developer's account, or a URL the agent talks to, and the GitHub MCP incident worked the same way on every client: instructions in an issue, read through the server, followed by the agent.
What it can reach on a laptop
The sandbox limits writes and the network. It does not limit reads. In read-only and workspace-write alike, Codex reads what the developer can read, and the default writable root is the folder it was started in, which for many developers is the home directory. When we sat down with one senior developer's machine, the agents on it could read forty-six credentials: .env files across cloned repositories, cloud CLI profiles, SSH keys, registry tokens. Codex was one of the agents. Nothing in its default configuration stops the read; the sandbox only stops the send, and only until a developer sets network_access = true because a build needed it.
The pattern to hold in mind is the one the prompt injection post walks through: injected text in something the agent reads, then a credential read, then a network call. Codex's sandbox breaks the chain at the third step by default. Auto mode with network on, or --yolo, puts it back.
A developer who wanted a build to reach a registry has turned the network on for every session since. Join the launch list and see which of your machines have it on, from the first mail
How a company sets a standard
This is where Codex is ahead of its peers, and the security team should know it. OpenAI documents managed configuration: a system file at /etc/codex/requirements.toml on macOS and Linux, %ProgramData%\OpenAI\Codex\requirements.toml on Windows, that an admin writes and a user cannot override. It can forbid approval policies such as never, forbid sandbox modes such as danger-full-access, allowlist MCP servers, restrict network domains and file read patterns, and turn features off. A second system file, /etc/codex/managed_config.toml, sets defaults a user may change. Precedence runs macOS MDM, then cloud-managed requirements for ChatGPT Business and Enterprise, then the system requirements file, then the user's config, then the project's (source: managed configuration).
So the standard a company wants is three lines in one file that a developer cannot edit: no never, no danger-full-access, and a list of the MCP servers that were reviewed. The platform team deploys it through MDM the same way as Claude Code's managed settings, and the lockdown guide gives the order to do it in.
Hooks are the other control point. They are on by default, read from ~/.codex/hooks.json and a repository's .codex/hooks.json, and a PreToolUse hook can intercept shell commands, file edits made through apply_patch and MCP tool calls. OpenAI's own words: treat tool hooks as a useful guardrail, not a complete enforcement boundary (source: hooks). That is the honest position for every agent's hook, and it is why the requirements file, not the hook, is the control that holds.
A worked example: one laptop
A backend developer installed Codex CLI with npm in June and signed in with ChatGPT. The first week it ran in Auto and asked for the network every time a test suite pulled a package, so the developer set network_access = true and stopped being asked. In August, a repository they cloned for a contractor's review contained a .codex/config.toml with an MCP server pointing at the contractor's internal tool; the developer marked the project trusted to make the review work, and the server has loaded in every session in that folder since. The home directory holds an AWS profile and two .env files with production database URLs.
Read by the security team, that laptop has four issues: a standing network permission that removes the sandbox's one hard stop, an MCP server nobody reviewed, credentials in reach of an agent that can now send, and no system requirements file, so all of it was the developer's call. The fix is one file in /etc/codex and one review. The finding is knowing which laptop it is.
Why one laptop is not the estate
Everything above can be checked on one machine by hand: open ~/.codex/config.toml, read the mode, the network line and the MCP tables, list the trusted projects. It is true for that afternoon. A security team cannot open that file on three hundred machines, cannot know which developer set network_access = true last Tuesday, which repository gained a .codex/config.toml yesterday, or whether the requirements file is actually present on every machine the MDM claims to have reached. And nobody can hand an auditor a dated record of any of it. The standard is set once. Knowing it holds, everywhere, every day, is the other job.
How ZYBE handles this
Codex is one of the agent ecosystems ZYBE reads on every machine, through Codex's own hook mechanism, and the scan lists it beside Claude Code, Cursor and the rest, with its mode, its network setting, its MCP servers and its trusted projects. The issues named in this article are its issues: Agent may run shell commands without asking and Agent acts without asking for a mode or a policy that removes the prompt, Credentials an agent can read for the .env files and profiles in reach, Credential in an MCP configuration where a token was pasted into a server's table, Unreviewed components and MCP server package not pinned to a version for what config.toml loads, and Agent far behind its current release. In block mode the detections act on the call even where a setting allows it: Agent read a credential file, Remote script piped into a shell, Credential used, then the network. The compliance view files the evidence under the frameworks the auditor asks about, and nothing sensitive leaves the machine: names, counts and hashes only.
Frequently asked questions
Is Codex CLI free? The tool itself is open source under the Apache 2.0 licence. Using it needs either a ChatGPT plan, and OpenAI lists Plus, Pro, Business, Edu and Enterprise as the plans it comes with, or an OpenAI API key, which is billed through the OpenAI Platform account at standard API rates. Signed in with ChatGPT, it uses the plan. Signed in with a key, every session costs money, and the key sits in ~/.codex/auth.json unless the OS credential store is used.
Codex CLI vs Claude Code: what is the difference for security? Both run in the terminal with the developer's access. Codex CLI runs commands inside a sandbox by default, Seatbelt on macOS and bubblewrap on Linux, with network off in the default workspace-write mode. Claude Code has no sandbox by default and relies on permission rules and hooks. Both have a mode that removes every check: danger-full-access with --yolo in Codex, bypassPermissions in Claude Code. Both read a system-level file a developer cannot override: /etc/codex/requirements.toml for Codex, managed settings for Claude Code.
Does Codex CLI run commands automatically? In the default Auto preset, yes: it reads, edits and runs commands inside the workspace without asking, and asks only for edits outside the workspace and for network access. In read-only it runs commands inside the sandbox and asks for anything beyond it. With approval_policy set to never it stops asking entirely, though the sandbox still applies. With --yolo there is no sandbox and no asking.
How do I configure Codex CLI? The user file is ~/.codex/config.toml, and a project can add .codex/config.toml, which applies only in a project marked trusted. The keys that matter most are approval_policy, sandbox_mode, the [sandbox_workspace_write] table with network_access and writable_roots, and one [mcp_servers.