Codex CLI Approval & Sandbox Controls

Two mechanisms are involved and they are frequently conflated. The approval policy decides whether you are asked before the agent acts. The sandbox decides what the agent can touch regardless of whether you were asked. Loosening approvals inside a tightly-scoped sandbox is a reasonable trade — you stop confirming every step, and the blast radius is still bounded. Loosening approvals with a broad sandbox removes both safeguards at once, and that is a materially different decision even though it looks like the same setting. /permissions opens a picker for the approval preset and applies it from that point in the session. Being able to change it mid-conversation matters more than it sounds: the natural working pattern is tight approvals while you establish that the agent understands the task, then looser ones once it has demonstrated it does, then tight again for anything touching production configuration. A policy fixed at launch cannot follow that shape. Recent versions also surface custom profiles here if you have defined them in configuration. The -a flag sets the policy for an entire run from the command line, which is how Codex is driven in a script or CI job where nothing can pause for a human. Setting it to never removes every prompt. In that arrangement the sandbox is doing all of the containing, so the scoping needs to be right before the job starts rather than corrected while it runs. /status is the command to run before letting the agent work unattended. It reports the active model, the approval policy in force, which directories are writable, and how much context has been consumed. Every one of those is something people assume rather than check, and the writable-roots line in particular is worth reading whenever a session has been going long enough that you might have granted something and forgotten. --add-dir extends the sandbox beyond the working directory to a path you name at launch, which is necessary when a task genuinely spans repositories or needs to read logs from elsewhere. Grant narrowly. The temptation is to add a parent directory and stop thinking about it, and the cost of that convenience is that the boundary you set up stops meaning anything. Settings applied through slash commands last only for the session. config.toml makes them defaults, and the -c flag overrides a single key inline for one run — which is the sensible way to try a setting before committing to it. Where those layers disagree, /debug-config prints the precedence order, which is the fastest way to resolve the specific confusion of a configured setting that appears to be ignored. The sandbox implementation differs by platform, and the differences are real rather than cosmetic: Seatbelt on macOS, Landlock and seccomp on Linux, restricted tokens and ACLs on Windows under WSL. What each permits is not identical, which is why codex sandbox exists — it runs a command you choose under exactly the restrictions the agent faces, so you can verify what is actually allowed rather than reasoning about it from documentation. On Windows there is also /sandbox-add-read-dir, a platform-specific command with no counterpart elsewhere. A closing point on framing. It is tempting to treat approvals as friction to be eliminated, and for repetitive well-understood work that is a fair judgement. But the prompts are the only moment at which a wrong plan becomes visible before it becomes a diff, and the cost of reading them is small compared with reconstructing what happened to a working tree afterwards. Version control is the safety net that makes the rest of these decisions tolerable, and it is worth being explicit about it. Working in a clean Git tree means /diff tells you exactly what the agent changed and a single command reverses all of it. Working in a tree that already had uncommitted changes means the agent's edits and yours are mixed together in the same diff, and separating them afterwards is genuinely tedious. Committing before a substantial agent task is the cheapest precaution available and it makes every other setting here less consequential. The reverse also holds. Approval prompts do relatively little for you in a repository with no version control and a lot of untracked work, because saying no to one command does not undo the previous five. The controls in this section are best understood as reducing how often you need the safety net, not as replacing it — which is why the recommendation is to set them thoughtfully and still commit first. One more consideration applies specifically to network access. A sandbox that permits outbound connections lets the agent install packages and fetch documentation, which is genuinely useful and also the widest of the doors you can leave open — it is the difference between an agent that can only affect files you can inspect and one that can pull in code you have not read. Whether that trade is right depends entirely on the task. For refactoring within an existing codebase it buys nothing; for setting up a new project it saves a great deal. Deciding deliberately, rather than inheriting whatever the default happened to be, is the point.