How Codex CLI Flags Actually Work (Full-Auto, Sandbox, and Bypass)

If you use the Codex CLI, you’ve probably seen a few flags that look like they do the same thing: --full-auto, --sandbox, and --dangerously-bypass-approvals-and-sandbox. They’re related, but they are not interchangeable.

1) --sandbox <mode>

Controls the filesystem + network sandbox policy for model-generated commands. Common modes:

• read-only — commands can read files but not write.
• workspace-write — commands can write inside the current repo and temp dirs.
• danger-full-access — commands can write anywhere (use with caution).

2) --full-auto

A convenience flag that makes Codex run without asking for approvals and forces the sandbox to workspace-write.

Think of it as:

--full-auto  ≈  auto-approve + sandbox=workspace-write

3) --dangerously-bypass-approvals-and-sandbox

Skips all approvals and disables sandboxing entirely. This is intended only for environments that already have a strong external sandbox.

Full-Auto overrides Sandbox

If you pass --full-auto, it overrides any --sandbox flag you specify.

So this:

codex exec --full-auto --sandbox read-only "..."

…still runs with workspace-write, because --full-auto forces that mode.

In other words:

--full-auto  >  --sandbox

Examples

Example A: Safe inside the repo

Use --full-auto and do not pass --sandbox:

codex exec --full-auto "..."

You’ll get auto‑approval and a workspace‑write sandbox. In practice that means model‑generated commands can write inside the current repo (and temp dirs), but writes outside the workspace are blocked. Reads still work broadly, and network access follows your Codex config.

Example B: You want strict read-only

Do not use --full-auto, and set the sandbox explicitly:

codex exec --sandbox read-only "..."

Now the sandbox is truly read‑only: model‑generated commands can read files but cannot write anywhere (including /tmp). Approval behavior comes from your configured approval policy (since --full-auto is not used).

Example C: You want full disk access

Again, omit --full-auto and set the sandbox:

codex exec --sandbox danger-full-access "..."

This gives the model full write access to the filesystem and removes sandbox restrictions. It’s powerful and should only be used when you’re comfortable with unrestricted file writes.

Example D: You want no sandbox at all

Only use this when you already run in a hardened environment:

codex exec --dangerously-bypass-approvals-and-sandbox "..."

This disables approvals and disables sandboxing entirely. Commands run directly with the same permissions as your user, so only use it inside a trusted external sandbox (container/VM) where you already enforce limits.

What is the sandbox anyway?

When Codex runs a command, it can optionally run it inside a restricted execution environment (the sandbox). The sandbox limits what the command can touch on your system, mainly files and network. Think of it like a safety fence around the model’s shell access.

At a high level, the sandbox decides:

• Where writes are allowed (nowhere in read‑only, only the repo in workspace‑write, anywhere in danger‑full‑access).
• Whether network access is allowed (controlled by the sandbox policy + your config).
• Whether dangerous paths should be protected (e.g., config folders or repo metadata).

The key takeaway: the sandbox is the boundary that lets you use Codex safely without handing it unlimited system access. When you remove or bypass it, you're trusting the model with the same permissions you have.

Under the hood on Linux, that boundary is enforced by Landlock (plus related OS primitives). Landlock is a kernel feature that lets a process voluntarily restrict itself to a set of allowed file paths and actions. So when you pick a sandbox mode, Codex builds a Landlock ruleset that matches it and then runs model‑generated commands inside that restricted context.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com