Codex CLI sandbox and approval modes: what each one allows, tested on macOS

The short answer

Codex CLI has two separate controls. The sandbox mode (read-only, workspace-write or danger-full-access) limits what commands can touch; the approval policy decides when Codex stops to ask you. The current docs’ default for a version-controlled folder is Auto, which is --sandbox workspace-write --ask-for-approval on-request: edits and commands run in the working directory, network is off, and Codex asks when it needs to go beyond that.¹ --dangerously-bypass-approvals-and-sandbox, alias --yolo, means no sandbox and no approvals, and the docs mark it not recommended.¹

When we ran Codex’s macOS sandbox, it refused a write to the home folder and blocked network, and allowed writes in the project. It also let us write to .git, which the current docs say is protected, because our installed version was older than the docs. Check yours.

Two settings, not one

The sandbox is the stronger of the two, because it doesn’t depend on recognising a dangerous command. A command can be anything; if it tries to write outside the writable roots, the OS refuses.

The sandbox modes

From the current docs:¹

Two more details: inside a writable root, .git is protected as read-only, and .codex is too when it exists as a directory.¹ Writable roots can be extended with sandbox_workspace_write.writable_roots without removing the sandbox.² Network for workspace-write is turned on with network_access = true under [sandbox_workspace_write] in config.toml.¹

Folders that aren’t version-controlled start in read-only. Codex may also start read-only until you trust the working directory.¹

The approval policies

From the current docs:¹

• on-request: commands the sandbox allows run without approval; Codex asks when it needs to go beyond the boundary.²
• never: no approval prompts. Under never, Codex doesn’t stop to ask even when a task needs to go past the sandbox.²
• untrusted: the docs say it is no longer supported.

And the shortcut: --yolo is --dangerously-bypass-approvals-and-sandbox.¹ It turns off both controls at once.

Approval policy and hooks are separate again. Codex CLI reads hooks from ~/.codex/hooks.json and the repository’s .codex/hooks.json, and runs a non-managed hook only after it’s reviewed and trusted.³ Codex parses a hook’s ask decision but doesn’t support it yet: it marks the hook failed and runs the command.³ So a hook that wants to stop a command must deny.

What the sandbox blocked when we ran it

Codex ships a codex sandbox macos command that runs any command under its Seatbelt profile. We used it in an empty git repository, with --full-auto (in our version, a network-disabled sandbox that can write to the working directory and the temporary folder):

Code Commands typed in a terminal. The text around it says what happens.

codex sandbox macos --full-auto -- sh -c 'echo hi > inside.txt && echo ok'
codex sandbox macos --full-auto -- sh -c 'echo hi > ~/codex-sandbox-test.txt && echo ok'
codex sandbox macos --full-auto -- sh -c 'echo x > .git/test && echo ok'
codex sandbox macos --full-auto -- sh -c 'curl -s -m 5 -o /dev/null -w "%{http_code}" https://example.com || echo "curl failed"'
codex sandbox macos -- sh -c 'echo hi > inside2.txt && echo ok'

Tests 2 and 4 are the ones that matter for safety: a command trying to change files outside the project, or to send data out, failed at the OS level, whatever the command was. That’s the protection that would have mattered in the incidents where agents deleted things outside their folder.

Version drift: check yours

Test 3 surprised us. The current docs say .git inside a writable root is read-only.¹ Our installed codex-cli 0.46.0 let the write through. Its --help also still lists on-failure as an approval policy and describes --full-auto as -a on-failure --sandbox workspace-write, while the current docs describe the Auto preset as on-request.

Nothing is wrong with the docs; our binary was old. The lesson is general: sandbox behaviour is a property of the version you run, not of the documentation you read. Run codex --version, update, and repeat the five tests above on your own machine. They take a minute.

A setup we would use

For day-to-day work in a repository:

Code A settings file: the rules a tool reads before it acts.

# ~/.codex/config.toml
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

Then:

1. Keep network off by default. Turn it on per task, or add only the folders and access a task needs.
2. Never use --yolo on your own machine. If you want hands-off runs, run Codex in a container or VM with only the project inside, and accept danger-full-access there.
3. Keep secrets out of the writable root. The sandbox stops writes and network, but a command can still read files. Our post on .env files and agents covers that.
4. Add a deny hook for destructive commands you know about; our hooks post has the file locations.
5. Commit before long runs, so the git history is your undo.

The blast radius of a bad command under this setup is the working tree you just committed. Compare with Gemini CLI’s equivalent settings in our yolo mode post.

To see which destructive commands an agent on your machine could run without a prompt, paste its config into the check page or run npx deedglass scan (how the grade works); to try tool-call rules in your browser, open the playground.

Questions people ask

What does Codex –full-auto do?

In current docs, the hands-off-but-sandboxed preset is Auto: workspace-write with on-request approvals.¹ Older CLI versions describe --full-auto as on-failure with workspace-write; check codex --help on yours.

Is Codex –yolo safe?

It disables both the sandbox and approvals; the docs mark it not recommended.¹ Use it only inside an environment that is already isolated.

Does the Codex sandbox block network access?

In workspace-write, network is off unless you enable it in configuration.¹ In our test, curl failed under the sandbox.

Written with AI assistance and checked against our claims register.