Codex dangerously skip permissions: --dangerously-bypass-approvals-and-sandbox and the safer pair

No. Codex CLI has no --dangerously-skip-permissions. Its nearest flag is --dangerously-bypass-approvals-and-sandbox. The docs give it a short alias, --yolo. It drops the prompts. It drops the sandbox too. Want only the prompts gone? Pass --ask-for-approval never and pick a sandbox. In config.toml the keys are approval_policy and sandbox_mode.

# Claude Code
claude --dangerously-skip-permissions

# Codex: no prompts, no sandbox
codex --dangerously-bypass-approvals-and-sandbox

# Codex: no prompts, sandbox kept
codex --ask-for-approval never --sandbox workspace-write

• Codex has two knobs. -a sets approvals. -s sets the sandbox. Claude Code keeps its sandbox in a separate setting.
• Full bypass. The help text for it says "EXTREMELY DANGEROUS".
• Reviewer mode. --approve-for-me lets an agent answer approvals. Next to --sandbox it will not start.
• Config file. approval_policy and sandbox_mode do the same job in config.toml.
• Network. In the default sandbox my git clone died on port 443.

What the Claude Code flag skips, and what still stops it, is in my --dangerously-skip-permissions post. This one is the Codex side.

What is the Codex version of --dangerously-skip-permissions?

Depends what you want gone. Codex has one flag for approvals and one for the sandbox. The approvals and security page says --ask-for-approval never "works with all --sandbox modes". So you can stop the questions and still keep a boundary.

The table lists the documented flags. The docs file the full bypass under "Elevated Risk". They say: no sandbox, no approvals, not recommended. The CLI reference tells you to avoid it "unless you are inside a dedicated sandbox VM".

My laptop has codex-cli 0.163.0. Its --help shows the long flag. No --yolo in there. The docs still list it. The source explains the gap. In shared_options.rs the long flag carries alias = "yolo", a hidden alias in the CLI parser. I have not launched either one.

What does --approve-for-me do in Codex?

A second agent answers the approval requests. The sandbox stays at workspace-write. The local help says it routes "approval requests through automatic review using the workspace-write sandbox". The docs add that the reviewer only sees actions that already need approval. It denies critical-risk actions. A failed review does not run the action.

This flag bit me on 9 October 2026. A long-running Codex session would not start from my launcher. The launcher passed --approve-for-me and --sandbox together. Codex 0.162.0 stopped with this line:

error: the argument '--sandbox <SANDBOX_MODE>' cannot be used with '--approve-for-me'

The fix was to delete --sandbox. With --approve-for-me alone the session came up in about four seconds. The current CLI reference spells the rule out. The flag "conflicts with --sandbox and --yolo". The interactive CLI also rejects --ask-for-approval next to it.

So pick one. You set -a and -s by hand. Or --approve-for-me sets them for you.

How do I set approval_policy and sandbox_mode in config.toml?

Put two keys at the top of ~/.codex/config.toml, above any [section]. This is the file-based version of the full bypass:

approval_policy = "never"
sandbox_mode = "danger-full-access"

Each key matches a flag. approval_policy is the file form of -a. sandbox_mode is the file form of -s. The difference is reach. A flag covers one launch. The file covers every new session on that machine. So this pair in the file means no question and no boundary, every time. Do it only where nothing the agent can reach would hurt.

The config reference lists the accepted values. approval_policy takes on-request, never or a granular table. untrusted is unsupported there. on-failure is deprecated. sandbox_mode takes read-only, workspace-write or danger-full-access.

For a git repo, the default pair is milder. on-request with workspace-write is what the docs call Auto. Codex works inside the project and asks before it leaves.

Why does Codex block the network in workspace-write?

The default preset asks before network access. The docs describe it as "workspace write + on-request approvals". In that preset Codex "requires approval to edit outside the workspace or to access network".

I ran into this on 18 September 2026. A git clone inside Codex failed with Failed to connect to github.com port 443. Then Codex asked to run the command outside the sandbox. The machine itself had network. The sandbox with default settings was blocking it. The longer story is in my Claude Code sandbox post. The fix is one table in config.toml:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

That keeps file writes inside the workspace. It opens outbound network for commands. It is a much smaller step than danger-full-access.

Saved approvals in Codex skip the sandbox

The quiet risk is not one flag. It is the list of things you already said yes to. In Codex, "Yes, and don't ask again" saves an allow rule to ~/.codex/rules/default.rules. Those rules keep working under -a never.

They do more than skip a prompt. In the Codex source, exec_policy.rs handles a command whose every part matches an allow rule. It skips approval and sets bypass_sandbox. So that command runs outside the sandbox. -a never with workspace-write is only as tight as your rules file.

If you have allow rules, read them before you trust the sandbox. opencode 1.x lets an "always" approval expire with the session; see opencode --dangerously-skip-permissions. For a run that should not load them, codex exec has --ignore-rules. Claude Code saves clicks the same way. There, under --dangerously-skip-permissions, allow rules decide nothing. In Codex they still decide what leaves the sandbox.

Which Codex setting should I use?

The CLI reference has a line for this. Unattended local work gets --sandbox workspace-write. CI in the approvals table gets read-only plus never. Scripts use codex exec. I checked its help on 0.163.0. There is --sandbox. There is --approve-for-me. No --ask-for-approval.

What I would start with today is -a never plus workspace-write. If a task needs the network, open it in config. --approve-for-me suits a session that runs while nobody watches. The full bypass belongs in a container I can delete afterwards.

Frequently asked questions

Does Codex have a --dangerously-skip-permissions flag?

Not by that name. You want --dangerously-bypass-approvals-and-sandbox. Short form in the docs: --yolo. The help skips it, as the source declares it a hidden alias.

Is -a never safer than --yolo?

Yes, if you pair it with a real sandbox. -a never only silences the questions. A command that needs more than workspace-write allows then fails, and the model sees the error. The exception is a command that matches an allow rule in default.rules. That one skips the sandbox. --yolo lets every command run.

Why does Codex say --sandbox cannot be used with --approve-for-me?

The reviewer flag sets its own sandbox, workspace-write. The CLI reference calls the pair a conflict. Drop --sandbox from the launch line. That was my whole fix on 9 October.

Where does approval_policy go in config.toml?

First lines of ~/.codex/config.toml. Above every [table]. Put it under a header and TOML files it under that table.

Sources, read on 17 October 2026: the Codex approvals and security page, the CLI reference, the config reference and local codex --help for codex-cli 0.163.0. Code references are from the openai/codex repository: codex-rs/core/src/exec_policy.rs and codex-rs/utils/cli/src/shared_options.rs. The error and the clone failure come from my own notes.