# Approvals and the sandbox

Course: Codex from Zero — https://zero2vibecode.com/learn/codex
Canonical URL: https://zero2vibecode.com/learn/codex/0-4-approvals-and-sandbox
Verified against: Codex CLI v0.163.0 (2026-10-22)
Last updated: 2026-10-22

Two settings decide what Codex can do on your machine: the sandbox says what it is technically able to touch, and the approval policy says when it must stop and ask. The default lets it work inside your project and asks before it reaches beyond it.

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:

```bash
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.

## 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.