Codex Security: Sandbox, Approvals, and Controls for OpenAI Codex CLI
OpenAI ships a real sandbox and a real approval model with Codex. It also published two CVEs in which that sandbox was the thing that broke. Both facts belong in the same evaluation.
Direct answer
Codex security rests on two independent settings that people often confuse. The sandbox mode decides what the agent can touch: read-only, workspace-write, or danger-full-access. The approval policy decides when it has to stop and ask: untrusted, on-request, or never. OpenAI documents the middle option of each as the sensible default, and it ships one control most rivals do not, which is that network access is off unless you turn it on. In OpenAI's own words, "the agent runs with network access turned off." Codex cloud goes further with a two-phase runtime, where "secrets configured for cloud environments are available only during setup and are removed before the agent phase starts." The honest limits are also OpenAI's own. Its documentation warns to "use caution when enabling network access or web search in Codex. Prompt injection can cause the agent to fetch and follow untrusted instructions." And the sandbox boundary itself has failed in production: CVE-2025-59532 let Codex CLI treat a model-generated working directory as the writable root, escaping the workspace on every version from 0.2.0 through 0.38.0. Every one of these settings is per developer, per repository, in a config file the developer owns. AgentShield sits outside the Codex process and adds the layer none of them provide: one policy that applies whether or not an engineer configured it, and one audit trail across every Codex agent you run.
Try it live
Watch Agentshield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
Codex arrived through ChatGPT seats your team already had, so nobody ran a rollout. It is now in nine repositories, two CI pipelines and a nightly job. Each has its own config.toml, written by whoever set it up, and at least one of them has approval_policy set to never because the prompts were slowing someone down. Security has been asked to sign off. The first question nobody can answer is which of those agents can currently reach the network, and the second is what any of them did last month.
How Agentshield handles it
Start with the setting that has the widest blast radius, which is network access rather than file writes. Inventory every config.toml and every managed configuration profile, and find the ones running approval_policy never with sandbox_mode danger-full-access. Pin the CLI above 0.39.0 and the IDE extension above 0.4.12 so the known sandbox escape is closed. Then move the decision off the laptop: AgentShield sits in the request and action path, so Codex keeps working exactly as configured while untrusted content coming back from a fetched page, a repository file, a tool result or an MCP server is inspected before the agent acts on it. Tool calls are checked against a permission scope attached to the agent rather than to the developer who launched it, irreversible actions are held for a human, and every call lands in one append-only record, including the ones that were denied.
The controls
The controls that secure OpenAI Codex CLI, IDE and cloud agents, and the credentials they run with.
What each Codex security control covers, and where OpenAI says it stops
OpenAI documents the edges of its own controls more precisely than most vendors in this category, which makes an honest table possible. Everything in the third column below is OpenAI documentation or a published advisory, not our characterization.
| Control | What it covers | Where OpenAI documentation says it stops |
|---|---|---|
| Sandbox mode | Three levels. Verbatim, workspace-write means "Codex can read files, make edits, and run commands in the workspace. Codex requires approval to edit outside the workspace or to access network." | The boundary is enforced by code that has been wrong. CVE-2025-59532 describes a bug where "Codex CLI could treat a model-generated cwd as the sandbox's writable root, including paths outside of the folder where the user started their session." Affected 0.2.0 through 0.38.0 |
| Approval policy | Independent of the sandbox. Verbatim, untrusted means "Codex runs only known-safe read operations automatically. Commands that can mutate state or trigger external execution paths require approval" | It is a prompt shown to the person at the keyboard. In CI, in a scheduled job, or with approval_policy set to never, there is nobody to show it to and the sandbox becomes the only control |
| Network off by default | The strongest default Codex ships. In OpenAI's words, "the agent runs with network access turned off," with allowlist-first domain control available through the network proxy settings | OpenAI warns directly: "Use caution when enabling network access or web search in Codex. Prompt injection can cause the agent to fetch and follow untrusted instructions." The moment you allowlist a domain to make installs work, the exfiltration path reopens |
| Cloud two-phase runtime | Genuinely good design. Setup "runs before the agent phase and can access the network to install specified dependencies, then the agent phase runs offline by default," and "secrets configured for cloud environments are available only during setup and are removed before the agent phase starts" | Applies to Codex cloud, not to the CLI on a developer laptop or in your own CI runner, which is where most teams actually run it |
| Managed configuration | Administrators can set workspace-wide requirements and approval reviewer settings from the admin console rather than leaving it per repository | Availability follows the plan. The full enterprise control set, including SCIM, RBAC, audit logs and the Compliance API, sits on Enterprise, not on the ChatGPT seats most Codex usage started on |
Read the table as a whole and a pattern shows up. The controls that are strong are the ones OpenAI turns on for you, and the controls that are weak are the ones a developer has to choose. That is not a criticism of Codex specifically, it is the shape of every agent runtime we have looked at, including Claude agent security and Kiro security.
Codex sandbox modes and approval policies compared
These are two separate settings, and almost every misconfiguration we see comes from treating them as one. The sandbox decides capability. The approval policy decides interruption. You pick one from each column, and the combination is what your agent can actually do.
| Setting | Value | What it means | Reasonable use |
|---|---|---|---|
| sandbox_mode | read-only | Verbatim: "Codex can read files and answer questions. Codex requires approval to make edits, run commands, or access network" | Code review, exploration, anything touching a repository you did not write |
| sandbox_mode | workspace-write | Edits and commands inside the workspace. Approval needed to write outside it or reach the network | The default for day to day work, and the right answer for most repositories |
| sandbox_mode | danger-full-access | OpenAI's own label: "No sandbox; no approvals (not recommended)" | A disposable container you can destroy. Not a laptop holding production credentials |
| approval_policy | untrusted | Only known-safe read operations run automatically. Anything that mutates state or triggers external execution asks first | Unfamiliar repositories, contractor machines, anything you would not run blind |
| approval_policy | on-request / never | on-request is the default and asks when Codex needs to escalate past the sandbox. never disables prompts entirely | on-request for interactive work. never only in CI, and only paired with a genuine sandbox |
The combination worth auditing for is approval_policy never together with danger-full-access, sometimes reached through the bypass flag OpenAI named "--dangerously-bypass-approvals-and-sandbox" precisely so that nobody could claim they did not know. On a laptop with a cloud credential file and an SSH agent, that combination is not a coding agent, it is a shell with a language model attached.
The second thing worth auditing is quieter. approval_policy never is completely reasonable inside a locked-down CI container, and completely unreasonable on a workstation, yet it is the same line in the same file format. Nothing in Codex knows which machine it is on. Deciding that centrally rather than per repository is an AI agent access control problem, and it is the point where per-repo config stops scaling.
The two Codex CVEs, and what they change about trusting the sandbox
Two published vulnerabilities in the Codex CLI are worth knowing before you write a policy that leans on the sandbox. Both are in the GitHub Advisory Database and both are fixed, so this is not a reason to avoid Codex. It is a reason to be precise about what the sandbox is load-bearing for.
| Advisory | Severity | Affected | What happened |
|---|---|---|---|
| CVE-2025-61260 (GHSA-xrxf-jgv3-qmrm) | Critical, CVSS 9.8 | @openai/codex 0.23.0 and earlier | Code execution through malicious MCP configuration. Verbatim: "Codex automatically loads project-local .env and .codex/config.toml files without requiring user confirmation, allowing attackers to embed arbitrary commands that execute immediately" |
| CVE-2025-59532 (GHSA-w5fx-fh39-j5rw) | High | 0.2.0 through 0.38.0. Fixed in CLI 0.39.0 and IDE extension 0.4.12 | Sandbox bypass. Codex CLI "could treat a model-generated cwd as the sandbox's writable root," enabling writes and command execution outside the workspace |
The first one is the more instructive of the two for anyone running Codex across many repositories. The attack needed no clever prompt and no model failure. It needed a developer to check out a repository and type codex inside it. Cloning untrusted code is a thing engineers do dozens of times a week without considering it a security decision, and for years it mostly was not one. An agent that reads project-local config on startup quietly turns every clone into an execution event.
The second one carries the more useful lesson, and it is in a single clause of the advisory: the escape "did not impact the network-disabled sandbox restriction." The filesystem boundary failed and the network boundary held, so the blast radius was local writes rather than exfiltration. That is defense in depth doing exactly what it is supposed to do, and it is the strongest available argument against relying on any single control, including ours. If your Codex policy has one enforcement point, a bug in that point is a bug in your whole program. The general form of this argument is on AI runtime security, and the sandboxing tradeoffs specifically are on AI agent sandboxing.
The practical takeaway is short. Pin the version, because both fixes are version fixes and neither helps a team still on 0.38.0. Then assume the boundary can fail and make sure something outside the process would notice if it did.
Codex vs Claude Code vs Kiro: what each coding agent enforces by default
Most teams are not choosing between a coding agent and nothing. They are choosing which one to standardize on, or discovering they already run three. Defaults matter more than feature lists here, because the default is what an engineer who never opened the settings will get.
| Default behavior | OpenAI Codex | Claude Code | Amazon Kiro |
|---|---|---|---|
| Network access out of the box | Off. The clearest single advantage Codex has | Allowed, with web fetches isolated in a separate context window | Allowed |
| File writes out of the box | Workspace only, approval to leave it | Read-only until you approve a write | Approval required before running any command |
| Command matching | Sandbox policy plus an approval prompt | Parses commands into a syntax tree and matches rules against it | Kiro documents that it "uses simple string prefix matching" |
| Isolation claim | A real OS-level sandbox, and one published escape from it | An OS-level bash sandbox, described by Anthropic as a permission gate rather than a sandbox | Kiro states supervised mode "is a code review workflow, not a security control" |
| Scope of any of the above | Per repository config file | Per repository settings file | Per workspace configuration |
On defaults alone Codex wins the first row outright, and the first row is the one that decides whether a prompt injection can send anything anywhere. Claude Code wins on command matching, because syntax tree parsing is genuinely harder to trick than prefix matching, and Anthropic is unusually blunt about calling its own gate a gate. Kiro is the most candid of the three about what its review workflow is not. Any of the three is a defensible choice, and we would not try to talk a team out of one on security grounds.
The last row is the one that should decide your architecture, because it is identical across all three. Every control listed above is configured in a file, per repository, by the engineer who owns that repository and whose velocity it costs. That works fine for one team. It stops working at the point where a security owner has to answer a question about all of them at once, which is the argument on securing AI coding agents. The per-vendor detail is on Claude agent security, Kiro security, Cursor AI security, GitHub Copilot security and Gemini CLI security.
Where AgentShield fits for Codex, and where it does not
We would rather lose an evaluation than win it dishonestly, so here is the split as we see it. Three of the rows below tell you to buy nothing from us.
| What you need | Codex built in | AgentShield | Who should own it |
|---|---|---|---|
| Stop the agent reaching the internet by default | Yes, network is off unless enabled | No | Codex. This is solved better here than in any comparable tool and we add nothing |
| Keep cloud secrets away from the agent phase | Yes, secrets are removed before the agent phase starts | No | Codex cloud. Good design, use it as shipped |
| Keep your code out of model training | Yes on Business and Enterprise, by default | No | OpenAI. If this is your only concern, buy the plan and stop reading |
| One policy across many agents and tools, not one config file per repo | Managed configuration within the OpenAI workspace only | Yes, one policy applied at the gateway every agent calls through | Us, once more than one vendor is in play |
| Evidence for an auditor of what an agent did, including what was denied | Audit logs on Enterprise, scoped to OpenAI products | Yes, an immutable record outside the tool being audited | Us, if the auditor will not accept the vendor auditing itself |
The first three rows are why a lot of readers should close this page. A single team running Codex on an Enterprise plan with workspace-write, on-request approvals and network off has a genuinely good security posture, and adding a gateway to that is buying a control you already have.
The last two rows are where an external layer earns its place, and the trigger is plurality rather than paranoia. One team on Codex is a configuration problem, and configuration problems are cheap to fix. Four teams on Codex, Claude Code, Cursor and a couple of MCP servers is a governance problem, and governance problems do not get solved by another config file. The moment your answer to "what can our agents reach" requires opening more than one vendor console, the enforcement point needs to be somewhere all of them already pass through. That is the case laid out on enterprise AI agent security, and if you are surveying the category rather than shopping for us specifically, our writeup of the AI agent security vendor landscape covers who does what.
FAQ
Common questions about codex security.
What is OpenAI Codex security?
It is the combination of two independent settings plus your plan. sandbox_mode decides what Codex can touch: read-only, workspace-write, or danger-full-access. approval_policy decides when it must stop and ask: untrusted, on-request, or never. On top of those, network access is off by default, and admin controls such as SCIM, RBAC and audit logs follow the ChatGPT plan you are on.
Is Codex secure?
For most teams, yes, and its network-off default is the strongest starting position of any mainstream coding agent. The caveats are OpenAI's own. It warns that enabling network access or web search exposes the agent to prompt injection, and the sandbox boundary itself was bypassable in CVE-2025-59532 across versions 0.2.0 to 0.38.0. Pin above 0.39.0 and treat the sandbox as one layer, not the whole program.
What are OpenAI Codex security risks?
Four, in order of how often we see them. A repository config that sets approval_policy to never on a workstation. Allowlisting a domain for package installs, which reopens the exfiltration path OpenAI warns about. Running a version below 0.39.0, which is still exposed to the sandbox escape. And MCP servers added by individual developers, which run third-party code with your credentials.
Does Codex use my data for training?
It depends on the plan. Business and Enterprise plans do not train on business data by default, and Enterprise adds data residency controls plus a Compliance API. Consumer plans follow the standard ChatGPT data controls, which is why teams that started on individual seats should move to a workspace before the code volume matters rather than after.
What is Codex sandbox mode?
It is the setting that decides the agent capability, separate from approvals. read-only lets Codex read files and answer questions but requires approval to edit, run commands or reach the network. workspace-write allows edits and commands inside the workspace, with approval needed to leave it. danger-full-access is labeled by OpenAI as no sandbox and no approvals, and is marked not recommended.
How do Codex sandbox permissions work?
The sandbox sets a writable root and a network switch, then the approval policy decides whether escalating past that root prompts a human. Both live in config.toml, which Codex reads per project. That per-project design is convenient and is also the reason a security owner cannot answer what every agent in the company is permitted to do without reading every repository.
Does Codex run offline?
By default, yes, in the sense that matters. OpenAI states that the agent runs with network access turned off, and Codex cloud uses a two-phase model where setup can reach the network to install dependencies and the agent phase then runs offline by default. The model inference itself still calls OpenAI, so offline here means the agent cannot fetch or send, not that nothing leaves the machine.
Is Codex better than Claude Code?
On security defaults they win different rows and neither wins overall. Codex is the only one of the two that starts with network access off, which is the single most valuable default. Claude Code parses bash commands into a syntax tree rather than matching prefixes, which is harder to trick. Both configure everything per repository, so at more than one or two teams the difference between them matters less than the gap they share.
Are Codex MCP servers safe to install?
Treat every one as third-party code running with your credentials. This is not theoretical for Codex specifically: CVE-2025-61260 was a critical, CVSS 9.8 flaw in which malicious MCP configuration in a checked-out repository executed immediately because Codex loaded project-local config without confirmation. Pin the version, review the server source, and scope what it can reach rather than trusting the description.
What are OpenAI Codex best practices?
Five, in order of impact. Keep network access off and allowlist single domains rather than enabling it wholesale. Set sandbox and approval defaults per repository risk instead of per developer preference. Pin the CLI above 0.39.0 and the IDE extension above 0.4.12. Never pair approval_policy never with danger-full-access outside a disposable container. Review MCP servers before they land.
Is Codex open source?
The Codex CLI is published as an npm package, @openai/codex, which is how its vulnerabilities get tracked in the GitHub Advisory Database with normal CVE identifiers. The models behind it are not open. For a security review this distinction matters in a useful way: you can pin, audit and diff the client, and you have to treat the model as a vendor dependency.
Do I need third-party security tooling for Codex?
Usually not for one team on a Business or Enterprise plan with network off and sensible approval defaults. It starts earning its place when you run more than one agent vendor, when agents run unattended in CI where no approval prompt can be shown, or when an auditor declines to accept logs produced by the same vendor being audited. Below that bar, configure Codex properly and spend the budget elsewhere.
More use cases