News · Issue 8

OpenAI Publishes Codex's Security Model: Inside the Sandbox After Agent Scrutiny

How OpenAI actually boxes in its own coding agent, down to the config file, and the bug reports that pushed the details into the open.

12 August 2026 Codex agent inside a sealed sandbox watched by a security console

What happened

OpenAI put its Codex playbook on the table

Codex agent inside a sealed sandbox watched by a security console

On May 8, 2026 OpenAI published Running Codex safely at OpenAI, a post that walks through exactly how its own security team boxes in Codex, the coding agent that runs across CLI, IDE, desktop, and cloud. Days later came a companion piece on the Windows sandbox implementation, sitting on top of an earlier series that unrolls the agent loop internals.

The timing is not an accident. Codex runs real shell commands on real machines, and community bug reports had been poking at whether the sandbox actually holds, including one filed in March 2026 about writes leaking through a supposedly read-only run. What OpenAI published is the config-level answer: the boundaries, the escape hatches, and how they watch for trouble.

Jan 23, 2026 (Agent loop series begins)
Mar 23, 2026 (Sandbox-bypass bug filed (#15524))
May 8, 2026 (Running Codex safely)
May 13, 2026 (Windows sandbox post)

The core idea is that safety is split into two independent layers, and once you see the split the rest of the model reads cleanly.

The two layers

Sandbox is 'can it?'; approval is 'should it ask?'

Inner sandbox boundary wrapped by an outer human-approval gate

The sandbox is the technical boundary: where Codex may write, whether it can reach the network, which paths stay off limits. The approval policy is separate and answers a different question, which is when Codex must stop and ask a human before crossing that boundary. Same task, two knobs.

workspace-write — The default sandbox mode: read anywhere, but write only in the current directory plus declared writable_roots. Writes elsewhere need approval. The other modes are read-only and danger-full-access (no filesystem sandbox at all).

SANDBOX MODE          FILESYSTEM
read-only          →  read, no writes
workspace-write    →  write cwd + writable_roots
danger-full-access →  no filesystem limits

NETWORK   restricted (ask)  |  enabled
APPROVAL  untrusted · on-failure · on-request · never

The knobs Codex reads before it runs a command

These used to live in per-model prompt files and were later moved into a builder that assembles the sandbox, approval, and network instructions dynamically for each request. In the strictest pairing, never approval with danger-full-access, the model is told to never ask and to work around constraints on its own, which is exactly the combination you want reserved for tightly controlled runs.

Enforcement

Three operating systems, three real jails

macOS, Linux and Windows each enforcing the Codex sandbox differently

The abstract modes bottom out in real OS primitives. On macOS the sandbox uses Seatbelt; on Linux it combines Landlock with bubblewrap; and Windows required building a dedicated backend, which is why it got its own engineering post. The repo documents each of these as the actual enforcement layer, not a suggestion the model is asked to respect.

This is also where the scrutiny bit. Issue #15524 reported that codex exec -s read-only could still write to disk when nested under an external sandbox like Docker, because the inner enforcement assumed it owned the boundary. A separate issue tracked Landlock read restrictions not being fully enforced behind a has_full_disk_read_access TODO.

outer sandbox (Docker / bubblewrap)
  └─ codex exec -s read-only
       └─ write to disk still succeeds   ← #15524

  "read-only" was only as strong as
  the layer that actually owned the jail

Why a nested sandbox can quietly widen permissions

Neither report is catastrophic on its own, but together they explain why the public write-up spends so much effort on layering the enforcement rather than trusting any single boundary to hold.

Staying out of the way

An agent that approves the small stuff itself

Auto-approval subagent and a network proxy with allow and deny lanes

Constant approval prompts kill the point of an agent, so Codex adds an auto-review mode. When an action would cross the sandbox boundary, Codex hands the planned action plus recent context to an auto-approval subagent, which can green-light low-risk work silently and escalate the rest to a human.

Codex plans action
   │ crosses sandbox boundary?
   ▼ yes
auto-approval subagent  (reads plan + context)
   ├─ low-risk        → approve silently
   └─ high-risk       → stop and ask human

approvals_reviewer = "auto_review"

On the network side, OpenAI is blunt that it does not give Codex open-ended outbound access internally. A managed policy allows known-good destinations, blocks denied ones, and asks about unfamiliar domains, so a config can pin allowed_domains to things like .openai.com and login.microsoftonline.com while denied_domains slams the door on pastebin.com, a classic exfiltration target. Web fetches can even be forced through OpenAI's cache rather than the live internet.

Rules and the watchers

A rules file up front, an AI triage agent behind

Rules engine filtering commands and a telemetry pipeline feeding an AI triage agent

Not every command carries the same risk, so Codex adds a Starlark rules file that classifies commands by prefix. Read-only inspections get waved through without approval even outside the sandbox, while dangerous commands can be blocked outright.

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "allow",
    justification = "read-only PR inspection",
)
prefix_rule(
    pattern = ["kubectl", "get"],
    decision = "allow",
    justification = "cluster inspection for debugging",
)

default.rules: allow the harmless, gate the rest

Everything then gets logged. Codex exports OpenTelemetry events for prompts, approval decisions, tool results, and network allow/deny calls, and enterprise activity flows into OpenAI's Compliance Platform where it can be centralized into a SIEM. OpenAI says it feeds those logs to an internal AI-powered triage agent that correlates the original request, the tool activity, and the network decisions to separate expected behavior from something worth waking a human for.

How admins lock this down so users can't loosen it

Config is layered: cloud-managed requirements are admin-enforced and non-overridable, sitting above macOS managed preferences and local files, and they apply consistently across desktop, CLI, and IDE. Login can be forced through ChatGPT and pinned to a specific enterprise workspace, with OAuth credentials tucked into the OS keyring rather than a plaintext file.

The takeaway

A blueprint for boxing in your own agents

Why it matters

Coding agents that run arbitrary shell commands are now normal, and the hard question is no longer whether they help but how you keep one from writing where it shouldn't or phoning home to a paste site. By publishing its own config down to the rules file and admitting it never grants Codex open network access, OpenAI turned an internal security posture into a pattern teams can copy. The open bug reports are part of the value here, since they show where a nested sandbox can quietly widen permissions.

The short version

OpenAI's May 8, 2026 post details how it sandboxes Codex, with a Windows sandbox follow-up on May 13.
Safety splits into two layers: the **sandbox** (what's technically allowed) and the **approval policy** (when to ask a human).
Enforcement is real OS jailing: **Seatbelt** on macOS, **Landlock + bubblewrap** on Linux, a custom Windows backend.
An **auto-approval subagent** clears low-risk actions, and OpenAI runs Codex with a locked-down network, never open outbound.
A Starlark rules file plus **OpenTelemetry** logging feed an AI triage agent, and public bug reports (#15524) show the sandbox is still being hardened.