People who come from Claude Code look for --dangerously-skip-permissions in Codex. The Codex CLI does not define it. Its command-line options, in OpenAI's source on GitHub, keep two controls apart, and the flag people mean switches off both.
Codex has two controls, not one
The sandbox decides what a command can touch. --sandbox takes read-only, workspace-write or danger-full-access, and the protocol definitions describe the last one as having no restrictions at all.
Approvals decide when Codex stops to ask you. --ask-for-approval takes on-request, where the model decides when to ask, or never, where a failed command goes straight back to the model and nobody is asked. Projects marked untrusted get untrusted, which asks for any command no rule allows, and there is a granular policy per kind of request.
The two combine. A sandbox with no questions suits unattended work. Questions with no sandbox leave every approved command free to touch anything your account can.
What the flag turns off
--dangerously-bypass-approvals-and-sandbox, alias --yolo, skips every confirmation prompt and runs commands without the sandbox. In the interactive CLI it cannot be combined with --ask-for-approval, since it already decides both.
Intended solely for running in environments that are externally sandboxed.Codex CLI source, shared_options.rs
Without the sandbox, the agent runs as you. It can read ~/.ssh and every other repository in your home folder, write outside the project, and reach any host on the internet. Without approvals, nobody reads the command before it runs.
"The yolo flag just skips the prompts."
Revision 1: it also turns off the sandbox that keeps commands inside the project.What you give up with the sandbox
In workspace-write, commands can write to the working directory, /tmp and your temp folder, plus any folder you add with --add-dir. Outbound network access is off unless you turn it on.
Some folders stay read-only even inside a writable project: .git, including .git/hooks, and .codex, because a change there could widen what the agent is allowed to do. That protection goes away with the sandbox.
On Linux the sandbox is bubblewrap with a seccomp filter, as the Linux sandbox notes describe, and on macOS it is Seatbelt. Know its edge: on Linux it starts from a read-only view of the whole filesystem, so your keys stay readable unless a permissions profile marks them none.
Why people reach for it anyway
Long tasks stall on questions, and after enough of them you approve without reading. The same habit sits behind the question of whether dangerously skip permissions is safe in Claude Code.
There is a better reason too. Bubblewrap needs user namespaces, and some machines and containers do not allow them; Codex warns at startup when it cannot create one, and WSL 1 cannot run it. When a container is already the boundary, the flag is the case its help text describes.
Drop the questions before the sandbox
Keep the sandbox, skip the questions. --sandbox workspace-write --ask-for-approval never runs without stopping, and a command the sandbox blocks fails back to the model instead of reaching your files.
Let a reviewer answer. --approve-for-me, alias --not-so-yolo, routes approval requests to automatic review and keeps the workspace-write sandbox.
Open only what the task needs. Add one folder with --add-dir instead of opening the disk, and mask secret files such as **/*.env in a permissions profile. Our list of AI agent security risks covers the wrong file, the wrong host and the instruction the agent should not have followed.
If you use the flag, put the wall outside
The help text's condition is the whole answer: an external sandbox. A container, a virtual machine or a sandboxed CI runner can be one, if it answers four questions.
What can it read? The project, not your home folder, your keys or your other repositories.
Where can it send? A short list of named hosts, with everything else refused.
What does it hold? As few secrets as the task needs. Anything in its environment can leave through an allowed host.
Who can widen it? A person, not the agent. That short list is what agentic AI security comes down to for us: directories, hosts, keys, and a person who approves more.
A side note on how we do it
We build Fenzi, which starts Codex inside an OpenShell sandbox with a copy of the project, a short host list and a placeholder instead of the real key. Codex's bubblewrap cannot create namespaces there, so it runs in full access while the outer rules apply to every command; the Codex sandbox notes on the agents sheet say why. It is one way to build the outer wall, and a container or a virtual machine can build it too.
So, is it safe?
On a bare laptop, no: the flag removes Codex's questions and its walls together, and the agent keeps your account and your network. Inside a container or virtual machine that limits what it reads, where it sends and what it holds, it is the setup Codex's own help text describes. Keep Codex's sandbox when you can, drop the questions first, and read the Linux sandbox notes in the Codex repository before you decide what to open.