Codex danger-full-access, --yolo and Unsafe Mode: What Each Flag Disables

What does Codex danger-full-access actually do?

danger-full-access is one of the three values of Codex's --sandbox flag, and it turns the sandbox off entirely. OpenAI's sandboxing documentation describes it in one sentence: "The agent runs without sandbox restrictions. This removes the filesystem and network boundaries." Every shell command the model generates then runs as your user, with your permissions, on your real filesystem, with your real network.

The other two values are the ones that matter for daily work:

Two details of workspace-write are worth knowing before you decide it is too restrictive. First, the writable set is not only the current directory: /tmp and $TMPDIR are writable by default, and you can add paths with sandbox_workspace_write.writable_roots in config.toml (the config reference also exposes exclude_slash_tmp and exclude_tmpdir_env_var if you want them out). Second, network access has its own switch, sandbox_workspace_write.network_access = true, so "I need npm install to work" is an argument for one boolean, not for full access.

What danger-full-access does not do is silence Codex. Approval prompts are governed by a separate flag, which is the source of most of the confusion in the next section.

What does --dangerously-bypass-approvals-and-sandbox remove?

--dangerously-bypass-approvals-and-sandbox, aliased as --yolo, removes both protections at once: the OS sandbox and the approval prompts. OpenAI's CLI reference describes it as "Run every command without approvals or sandboxing. Only use inside an externally hardened environment." That second sentence is the whole policy. The flag exists for a container or a virtual machine that is itself the boundary, not for a laptop with your SSH keys, your cloud credentials and your production .env on it.

The distinction between the two mechanisms is simple once you see them side by side:

• The sandbox decides what a command can touch: which paths are writable, whether sockets can be opened. It is enforced by the operating system, so a command the model did not intend to run is contained just as much as one it did.
• Approvals decide when Codex pauses to ask you. They are a human checkpoint, and they only work if a human is reading them.

danger-full-access alone still leaves you the checkpoint. --yolo leaves you nothing but the model's judgment, and the model's judgment is exactly what a prompt injection in a README, a test fixture or a dependency's error message is designed to bend. That is not theoretical: our guide to AI coding agent sandbox escapes walks through how repository content becomes commands, and the pattern applies to Codex unchanged.

Are -a never, --full-auto and "unsafe mode" the same thing?

No. They loosen different layers, and one of them is not a flag at all. Here is the full map:

--ask-for-approval accepts untrusted (auto-run known-safe read operations, ask for anything that mutates state), on-request (the default: the model asks when it wants to escalate, reach the network or leave the workspace) and never. Older releases also accepted on-failure, which ran everything inside the sandbox and only asked when a command failed there; --full-auto was the shorthand for that combination, which is why it survives as a compatibility flag today.

The "Full access" preset you see in the interactive picker is the combination of danger-full-access and never, and OpenAI labels it "not recommended" in its own approvals documentation. It is --yolo with a friendlier name.

Is Codex full access safe?

Codex full access is safe exactly as long as the environment around it is, and unsafe the moment it is not. Inside a fresh container with no credentials, a scratch clone and an egress rule, danger-full-access is a reasonable trade: the container is the sandbox, and Codex's own would only slow it down. On a developer workstation it means a model with your identity can curl anything, write anywhere, and read every token in your home directory, and the only thing standing between a hostile instruction and that outcome is the model deciding not to comply.

The data we have on unguarded agents is not reassuring. In our build-up study, agents working without a guard layer ran DROP SCHEMA against a live application database eighteen times, and one ran rm -rf outside its own project. When we put a command guard in front of the same agents, it checked 1,769 shell commands over the sessions and stopped seventeen mid-flight: destructive sudo outside the project, a schema drop, and an install of a package that does not exist on the registry. Seventeen out of 1,769 is under one percent, and one percent of "run every command" is the number that matters when the command is destructive.

18

DROP SCHEMA runs against a live database by unguarded agents, in our build-up study

1,769

shell commands checked in the guarded sessions of the same study

17

commands stopped mid-flight: destructive sudo, a schema drop, a package that does not exist

Note what full access does not protect you from even when the environment is clean: the code. A sandbox contains commands; it has no opinion on whether the authorization check the model just wrote is correct. We return to that at the end.

How does the Codex sandbox work on macOS, Linux and Windows?

Codex enforces its sandbox with the operating system, not with the model, which is why it holds even when the model is being manipulated. On macOS it uses Apple's Seatbelt framework, the same sandbox-exec policy mechanism that confines system daemons, and it works out of the box. On Linux and under WSL2 it uses bubblewrap (bwrap) with seccomp filters; earlier releases used Landlock and seccomp directly. On Windows it uses a native Windows sandbox, elevated or unelevated, when run from PowerShell, and the Linux mechanism when run under WSL2.

Two practical consequences follow. If bwrap is missing on a Linux box, Codex cannot build its sandbox there, so install it before assuming you are protected. And if a command is being refused and you do not know why, codex sandbox runs a command under the current policy for debugging, with --log-denials on macOS to print what Seatbelt blocked. That is the right tool for "Codex cannot write here", and a much better answer than reaching for danger-full-access.

Seatbelt also settles a question we see in search a lot: "Codex seatbelt" is not a feature you turn on. It is what read-only and workspace-write are made of on a Mac.

When is full access the right call?

Full access is the right call when something else is already the boundary. The pattern that works:

Fresh container or VM, scratch cloneNo long-lived credentials mountedEgress limited to the registries you needThen, and only then, --yolo

Three checks before you flip the flag:

1. What can the process read? If ~/.ssh, ~/.aws, ~/.codex/auth.json or a .env with live keys is reachable, the answer is not full access. The Codex credential file has already been the target of a malicious npm package; do not make it easier.
2. Where can it send data? Unrestricted network plus a prompt injection is an exfiltration channel. If you cannot restrict egress, keep network_access off and let Codex ask.
3. Who reads the output? In codex exec pipelines nobody is watching the approvals anyway, which is a reason to lean on the sandbox harder, not to remove it.

If any of the three fails, use the configuration below instead.

What should you use instead of --yolo?

For almost every task, workspace-write with on-request approvals, the network closed and the project marked trusted gives you a fast agent that still cannot leave its lane. In ~/.codex/config.toml:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false
writable_roots = ["/Users/you/scratch"]

[projects."/Users/you/work/payments-api"]
trust_level = "trusted"

trust_level = "trusted" tells Codex to apply the project's own .codex/ configuration; untrusted projects skip those project-scoped layers, which is exactly what you want for a repository you just cloned from a stranger. If prompts are the pain, tighten what triggers them rather than switching them off: newer builds expose a granular approval_policy and an approvals_reviewer = "auto_review" option that routes approvals to an automatic reviewer. Treat auto-review as a convenience, not a boundary: it is a model judging a model.

For CI and codex exec, keep the sandbox and drop only the prompts: --sandbox workspace-write -a never on a runner that has no production credentials is a coherent posture. --yolo on the same runner is not, because the sandbox was costing you nothing.

The gap no flag closes

Every flag in this article governs what Codex may run. None of them governs what Codex writes, and the code is where most of the risk now lives. A workspace-write sandbox will happily let the agent commit an endpoint with no authorization check, a refund handler with no cap, or a query built by string concatenation, because none of those is a command. They are diffs.

That is the layer VibeDefend adds at agent-time. It sits in the Codex loop, checks the diff the agent is about to write against your own rules, rewrites the unsafe version before it lands, and guards the shell commands with the same policy that produced the seventeen blocks above. In our study, agents with the layer followed the security rules on 89% of tickets, against 12% for agents with only a rules file in the repository. The sandbox keeps Codex off your machine; the guard keeps its code out of your incident queue.

If you run Codex in --yolo on purpose, in a container, with a guard on the diff, you have a defensible setup. If you run it in --yolo on your laptop because the prompts were annoying, read the full Codex security guide and then talk to us: the fix takes about a minute.

Frequently asked questions

Is danger-full-access the same as --yolo?

No. --sandbox danger-full-access removes the OS sandbox and keeps the approval prompts. --dangerously-bypass-approvals-and-sandbox (--yolo) removes the sandbox and the prompts. The "Full access" preset in the picker is the second one.

What does codex --yolo do?

It runs every command the model generates immediately, with your user's permissions, on your real filesystem, with unrestricted network, and never asks. OpenAI's reference limits it to an "externally hardened environment", meaning a container or VM that is itself the boundary.

Is -a never dangerous on its own?

Less than people assume, as long as the sandbox stays on. --ask-for-approval never removes the human checkpoint, but workspace-write still confines writes and the network stays closed unless you enabled it. It becomes dangerous the moment it is paired with danger-full-access.

What is Codex "unsafe mode"?

There is no flag by that name. People use "unsafe mode", "dangerous mode" and "run dangerously" to mean danger-full-access, --yolo or -a never, which are three different things. Check which one a tutorial actually means before copying the command.

How do I let Codex use the network without full access?

Set network_access = true under [sandbox_workspace_write] in config.toml, or pass -c sandbox_workspace_write.network_access=true for one run. Writes stay confined to the workspace; only the network opens.

Does the Codex sandbox work on Windows?

Yes. From PowerShell it uses a native Windows sandbox, elevated or unelevated; under WSL2 it uses the Linux mechanism (bubblewrap and seccomp). The --sandbox values and the config.toml keys are the same on every platform.

Does the sandbox stop prompt injection?

It contains what an injected command can touch; it does not stop the injection. A malicious README can still steer the model into writing insecure code, or into asking for an escalation that a tired human approves. Keep the sandbox on, and add a layer that checks the code and the commands, not just the file paths.