Original URL: https://getagenttools.com/blog/codex-dangerously-skip-permissions/ # Codex dangerously skip permissions: --dangerously-bypass-approvals-and-sandbox and the safer pair 20 Oct 2026Marek. - codex - coding-agents - agent-security 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`. ```bash # 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](https://getagenttools.com/blog/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](https://learn.chatgpt.com/docs/agent-approvals-security) says `--ask-for-approval never` "works with all `--sandbox` modes". So you can stop the questions and still keep a boundary. | Codex flag | Approval prompts | Sandbox | | --- | --- | --- | | `--ask-for-approval never` (`-a never`) | None | The one you pick with `-s` | | `--sandbox danger-full-access` | Per your `-a` setting | None | | `--dangerously-bypass-approvals-and-sandbox` (`--yolo`) | None | None | | `--approve-for-me` (`--not-so-yolo`) | A reviewer agent answers them | `workspace-write` | 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](https://learn.chatgpt.com/docs/developer-commands?surface=cli) 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: ```text error: the argument '--sandbox ' 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: ```toml 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](https://learn.chatgpt.com/docs/config-file/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](https://getagenttools.com/blog/claude-code-sandbox/) post. The fix is one table in `config.toml`: ```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](https://getagenttools.com/blog/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](https://learn.chatgpt.com/docs/agent-approvals-security), the [CLI reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli), the [config reference](https://learn.chatgpt.com/docs/config-file/config-reference) and local `codex --help` for `codex-cli 0.163.0`. Code references are from the [openai/codex](https://github.com/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. Put this into practice [See the tool list](https://getagenttools.com/tools/)[Train your team](https://getagenttools.com/#training)