Codex YOLO Mode: Run Without Approvals Safely

Codex YOLO Mode: What It Actually Changes

Codex YOLO (You Only Live Once) mode is the risky way to run the Codex CLI when you want the agent to keep working without approval prompts. YOLO means “You Only Live Once” here, not a safer product mode. It’s shorthand for a setup where the agent has broad local access and doesn’t stop to ask before running commands.

The command is:

codex --sandbox danger-full-access --ask-for-approval never

That combination matters because Codex has two separate controls. The sandbox mode controls what commands can access. The approval policy controls when Codex must pause and ask before acting. Codex danger full access via --sandbox danger-full-access removes the usual sandbox boundary. Codex ask for approval never via --ask-for-approval never tells Codex not to stop for approval prompts.

OpenAI also documents a shortcut flag, --yolo, also named --dangerously-bypass-approvals-and-sandbox, for running every command without approvals or sandboxing. The official CLI reference says to use it only inside an externally hardened environment. Treat that as the baseline: if you’re not already inside a disposable or tightly controlled environment, this mode is probably too permissive.

The Visual Cue In The Codex YOLO Mode Screenshot

The screenshot below shows the Codex terminal after launch. The key line is permissions: YOLO mode, the visible indicator that the dangerous/no-approval mode is active.

The command at the top shows the exact launch form: codex --sandbox danger-full-access --ask-for-approval never. If you see permissions: YOLO mode, assume Codex can act quickly and broadly until you stop it.

Who Should Use Codex YOLO Mode

Use Codex YOLO mode only if you are an experienced user who understands the project, the shell, the current working directory, and the credentials available to the process. This is not a good default for learning Codex, looking at an unfamiliar repository, reviewing untrusted code, or working near production infrastructure.

You should know what package-manager scripts do in the repo, which cloud CLIs are installed and authenticated, and whether .env files, SSH keys, API tokens, database credentials, or deployment config are reachable from the session. You should also be comfortable reading git diff carefully after the agent works.

Dangerous Things Codex Can Do In This Mode

In Codex CLI dangerous mode, Codex can do much more damage than in a normal workspace-write session with approvals. The exact blast radius depends on your machine and config, but the risk categories are clear:

• Modify, overwrite, or delete files in places available to the process.
• Run shell commands without pausing for confirmation.
• Execute package-manager scripts such as npm, pnpm, pip, bundle, cargo, or project-specific scripts.
• Rewrite git history if asked, or if a command it runs does so.
• Touch additional directories exposed by the current user or by Codex configuration.
• Use network access if this mode or the environment allows it.
• Read secrets available through environment variables, local config, credential files, or mounted directories.
• Run destructive database, deployment, cloud, or infrastructure commands if those tools are installed and authenticated.
• Follow malicious instructions embedded in untrusted project files, docs, webpages, or tool output.
• Make many changes before a human notices the direction is wrong.

That last point is underrated. Approval prompts aren’t only a security feature; they’re also pacing. They force you to notice when the agent is crossing a boundary. YOLO mode removes that pacing.

Safer Alternatives To Codex YOLO Mode

For most local development, use the normal automatic mode instead:

codex --sandbox workspace-write --ask-for-approval on-request

That lets Codex edit and run routine commands inside the workspace, while still asking when it needs to cross the boundary. If you want planning without changes, use read-only permissions. If you want automation, isolate it.

A safer pattern looks like this:

1. Create a throwaway branch.
2. Run in a disposable VM, dev container, or sandboxed machine.
3. Remove production credentials from the environment.
4. Avoid exposing your home directory or unrelated repositories.
5. Keep cloud CLIs logged out unless the task needs them.
6. Let Codex work on a narrow task, then inspect git diff before continuing.
7. Run tests yourself before merging or deploying.

YOLO mode can be useful in a hardened environment where the agent runs many commands without friction. It is a poor fit for a normal laptop session with broad credentials and a messy working tree.

How To Think About AI Coding Agent Permissions

The right mental model is not “Codex is trusted now.” The right model is “I moved the trust boundary outside Codex.” If you run codex danger full access with codex ask for approval never, your safety has to come from the surrounding environment: container limits, VM snapshots, branch isolation, credential isolation, network policy, and human review after the run.

If the environment is not hardened, do not compensate with hope. Use safer AI coding agent permissions and keep approval prompts interactive.

Related

Claude Code has a similar YOLO-style workflow through claude --dangerously-skip-permissions. See the companion article: Claude Code YOLO Mode: Using —dangerously-skip-permissions.

For official reference, see OpenAI’s Codex agent approvals and security documentation.

Frequently Asked Questions

What is the difference between Codex's sandbox mode and its approval policy?

They are two separate controls that govern different things. The sandbox mode (--sandbox) decides what commands are allowed to access, while the approval policy (--ask-for-approval) decides when Codex must pause and ask before acting. YOLO mode is the combination of danger-full-access and never, which removes both the access boundary and the pacing of approval prompts at the same time.

Is the --yolo flag the same as the longer command?

Functionally yes. OpenAI documents --yolo (also written as --dangerously-bypass-approvals-and-sandbox) as a shortcut that runs every command without approvals or sandboxing, which matches what the longer --sandbox danger-full-access --ask-for-approval never form achieves. The official CLI reference says to use the shortcut only inside an externally hardened environment, so treat it with the same caution as the full command.

How can I tell that YOLO mode is actually active?

Look for the line permissions: YOLO mode in the Codex terminal after launch. That indicator confirms the dangerous, no-approval mode is running, and the command shown at the top of the screen reveals the exact launch form used. If you see it, assume Codex can act quickly and broadly until you stop it.

What is the safest alternative for everyday local development?

Use the normal automatic mode: codex --sandbox workspace-write --ask-for-approval on-request. This lets Codex edit files and run routine commands inside the workspace while still pausing to ask when it needs to cross a boundary. If you only want planning without changes, switch to read-only permissions instead.

Can Codex read my secrets and credentials in this mode?

Yes, if they are reachable from the session. In danger-full-access mode Codex can read environment variables, local config, credential files, and mounted directories, which may include .env files, SSH keys, API tokens, and database credentials. It can also run destructive cloud, deployment, or database commands when those tools are installed and authenticated, so remove production credentials before running.

Why do approval prompts matter beyond security?

Approval prompts also act as pacing. They force you to notice when the agent crosses a boundary and give you a chance to catch a wrong direction before many changes pile up. YOLO mode removes that friction entirely, so an agent can make a large number of changes before a human realizes something is off.

If I trust the environment, do I still need to review Codex's work?

Yes. The correct mental model is that you have moved the trust boundary outside Codex, not that Codex itself is now trusted. Safety comes from container or VM limits, branch and credential isolation, network policy, and human review after the run. Always inspect git diff carefully and run tests yourself before merging or deploying.