Codex --yolo: what --dangerously-bypass-approvals-and-sandbox turns off

Two settings, one flag

Codex keeps two dials separate everywhere else. approval_policy decides how often it stops to ask you. sandbox_mode decides what it can reach whether or not you are asked.

--dangerously-bypass-approvals-and-sandbox turns both to their widest setting at once. In OpenAI's own source the flag is declared with the alias yolo, and its help text reads "Skip all confirmation prompts and execute commands without sandboxing. EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed." The config equivalent is approval_policy = "never" with sandbox_mode = "danger-full-access" in ~/.codex/config.toml.

That is the difference from Claude Code worth knowing. Claude Code's flag removes a review step and leaves reach exactly where it was. Codex's flag removes the review step and the walls, because Codex had walls to begin with.

What the sandbox was doing for you

On macOS, Codex applies a Seatbelt profile to every command it runs. Under workspace-write the agent can change the project and temporary directories and nothing else, and network access is a separate switch that stays off unless you enable it.

So a normal Codex session has two quiet protections that most people never think about. A command that tries to write outside the repository fails. A command that tries to reach the internet fails. Neither one asked you anything, which is exactly why nobody misses them until they are gone.

--yolo removes both. A cleanup script that is correct inside the repository and wrong one directory up now runs to completion. A dependency install that pulls a hostile postinstall script now has the network and your whole home folder.

The flags people confuse with it

Most people reaching for --yolo wanted one of these instead.

• --approve-for-me, alias --not-so-yolo. Despite the name, this is the safe one, and the one built for unattended work: approval requests are routed to a second model acting as reviewer, and the sandbox stays at workspace-write. Codex refuses to combine it with --yolo or with -s.
• -s / --sandbox on its own. Sets the sandbox mode without touching approvals, if you want a wider or narrower boundary and the same number of questions.
• --worktree. Starts the session in a new managed git worktree, so whatever the agent does to files lands on a branch you can throw away. It combines with any of the above.

When --yolo is the right call

There is a legitimate case. Codex's own sandbox cannot be applied inside another sandbox on macOS, because Seatbelt profiles do not nest, so if Codex is already running inside a container, a VM or a boundary you set up yourself, its sandbox has nothing to add and will fail with Operation not permitted. In that one situation, --yolo is how you tell Codex the boundary lives somewhere else.

OpenAI's TUI agrees about the risk in its own way: the keyboard shortcut that cycles permission presets deliberately skips full access, so you cannot slide into it by tapping a key once too often. You have to ask for it by name.

How this works in Forkbench

Forkbench is a desktop app for running coding agents, and it runs the codex binary you installed with your flags and your config.toml untouched. It does not stop you passing --yolo.

What it changes is what --yolo can reach. A Thread can be locked to a set of folders, applied by the kernel as each shell starts and inherited by everything Codex spawns. That outer boundary is exactly what the section above described: with --yolo, Codex has no sandbox of its own to conflict with it, so the folder lock is the wall. And a key in Vault is used by the command that needs it without the value ever entering Codex's environment, so danger-full-access has no token in reach to send anywhere.

The limit, stated plainly: a folder lock is about files, not the network, so a command Codex runs can still make requests. What it cannot do is carry out a credential that was never in the process.