How Codex keeps itself in a box
Every autonomous coding agent carries the same uncomfortable question: what happens when it runs a command you never read? OpenAI's answer in Codex is unusually structural. Instead of trusting the model's judgment, Codex assumes the model will eventually do something dumb. It builds the walls so that dumb stays survivable.
The containment story has three layers, and the details matter because they tell you what you are actually trusting. As of this writing, the stack looks like this.
The box, layer by layer
- Kernel-enforced sandboxing locally. On macOS, Codex rides the system's Seatbelt sandbox; on Linux it leans on Landlock and seccomp-style confinement. This is not a system prompt asking the model to behave. It's the operating system refusing the syscall.
- Write scope. The default autonomous posture confines writes to your workspace and its temp directories; a read-only mode exists for pure exploration. The full-trust escape hatch literally has the word danger in its name: the name is the documentation.
- Cloud containers. Every cloud task runs in its own ephemeral container against its own copy of the repo. When the task ends, the environment evaporates. What survives is the diff.
Approval prompts sit on top of all this, but they are the weakest layer. Approval fatigue is real, and you will eventually click yes on autopilot. Approval modes decide how often Codex asks. The sandbox decides what happens when it stops asking.
Network-off is the load-bearing wall
Here is the choice doing the real security work: in Codex's autonomous modes, network access is disabled by default. A local sandboxed session gets no outbound network unless you explicitly opt in; cloud tasks front-load dependency installation during environment setup, then cut the agent off before it starts reasoning.
Prompt injection is why this matters more than any file permission. An agent that reads a poisoned README, a malicious issue comment, or a compromised dependency can be talked into nearly anything, including bundling up your source or your environment variables and sending them somewhere helpful. With the network off, that entire attack class dead-ends. The agent can be thoroughly compromised in spirit and still have nowhere to deliver the loot.
An agent that can read your secrets but cannot phone home is an incident. An agent that can do both is a breach.
The cost is real friction. No network mid-task means package installs fail, documentation fetches fail, and a whole class of tasks needs dependencies declared up front. Codex's bet (the right one, I think) is that this friction belongs at environment-setup time, not smeared across the run as a hundred small trust decisions. The general argument for that trade is laid out in sandboxing coding agents.
What the box does not protect
The sandbox protects your machine from the workspace, not the workspace from the agent. Everything you mounted in is legitimately, by-design readable: the .env file at the repo root, the API token you exported before launching, the cloud credentials sitting in checked-in config. If it is inside the box, it is in scope: readable, quotable into summaries and logs, and fair game for anything a prompt injection manages to install.
- Keep secrets out of the workspace. The agent needs your code, not your production keys.
- Scope what you must mount. Short-lived tokens with narrow permissions; a database seeded with synthetic data.
- Red-team your own setup. Plant a hostile instruction in a test fixture and watch what your configuration does with it. The methodology in LLM red-teaming applies to your own repo, not just your product.
Codex's containment is the most opinionated among the mainstream agents, and I think it is mostly right: default-deny networking, enforced below the model rather than by it. Trust it for what it is: a blast-radius limiter, not absolution. The day you flip the network on and mount real credentials because one task needed them, you have quietly stepped outside the box, and no warning dialog marks the exit.