Codex runs real commands on your real machine. Two separate settings decide how far that goes, and it is worth knowing which one does what before the first prompt asks you anything.
Two layers
The sandbox is what Codex can technically do when it runs a command: where it can write, and whether it can reach the network. The operating system enforces it — on macOS through Seatbelt, on Linux with bubblewrap and seccomp — so it holds even if the model gets something wrong.
The approval policy is when Codex has to stop and ask you before acting: before it leaves the sandbox, before it uses the network, before a command outside what it is allowed to run on its own.
The sandbox decides what is possible. The approval policy decides what needs your yes.
The default: Auto
When you start codex in a Git repository, Codex recommends the Auto preset. In flag form that is:
codex --sandbox workspace-write --ask-for-approval on-request
In Auto, Codex can:
- read files, edit them and run commands inside the workspace — your project folder, plus temporary folders such as
/tmp— without asking.
It has to ask before it:
- edits anything outside the workspace;
- runs a command that needs network access, which is off by default.
Even inside the workspace some paths stay read-only: the project’s .git folder, and .codex and .agents folders if they exist. Codex can change your code but not your Git history behind your back.
Quick check
In Auto, which of these makes Codex stop and ask?
The other presets
| What you want | How | What it means |
|---|---|---|
| Look and plan, change nothing | --sandbox read-only --ask-for-approval on-request | It reads files and runs commands inside a read-only sandbox |
| A script or CI run that never stops to ask | --sandbox read-only --ask-for-approval never | Read-only, and it never asks for approval |
| No limits at all | --dangerously-bypass-approvals-and-sandbox (alias --yolo) | No sandbox, no approvals; not recommended |
Inside a session you do not need flags: /permissions lets you pick a preset, such as Auto or Read Only, and /status shows which approval policy and writable folders are active right now. In a folder without version control, Codex recommends read-only from the start.
The one setting to leave alone
--yolo reads like a convenience. It is not one. It turns off both layers for every command for the rest of the session, so anything Codex decides to run can write anywhere you can and reach any server. The CLI reference’s advice is to avoid it unless you are inside a dedicated sandbox machine, and to prefer --add-dir when Codex just needs to write to one more folder.
If the approval prompts feel constant, the fix is usually narrower: approve the command you have read, or change the preset for this task with /permissions.
The sandbox is not a review
Auto keeps Codex inside your project, which is exactly where it can still break things. The sandbox stops it reaching the rest of your machine; it does nothing about a wrong edit to your own code. That is what the checkpoint commit and /diff from the last lesson are for.
Try it yourself
Codex reaches the edge of its sandbox and asks.
Is it safe to approve a command Codex asks about?
Read it first. An approval is Codex telling you its next action leaves the space you agreed to, such as reaching the network or writing outside the project. Approve the command you have read and understood; decline and ask why when you have not.
Can I give Codex network access without turning the sandbox off?
Yes. The workspace-write sandbox has a network_access setting in ~/.codex/config.toml, and the docs describe a network proxy feature that limits which domains commands may reach. Both are narrower than --yolo, which removes the sandbox entirely.