TL;DR
-
codex --yolois a short alias of--dangerously-bypass-approvals-and-sandbox. It sets approvals toneverand the sandbox todanger-full-access. - That second part is unusual. Claude Code's and Gemini CLI's YOLO modes skip prompts but leave sandboxing alone. Codex's removes both.
- The two knobs are orthogonal:
-a never -s workspace-writegives you "never ask, but stay fenced", which is what most people actually want. - The sandbox is real OS isolation: Seatbelt (
sandbox-exec) on macOS, bubblewrap + seccomp on Linux/WSL2, a native sandbox on Windows, and nothing on WSL1. -
codex execnever asks for approval, so in CI the sandbox is the only knob that matters.
Every flag below was checked against openai/codex at commit 72c9595 (release 0.161.0), @agentclientprotocol/codex-acp 2.1.1 and OpenAI's Codex docs on October 7, 2026.
What are the two knobs?
Codex models safety as two independent dimensions:
| Knob | Config key | CLI flag | Values |
|---|---|---|---|
| When to ask you | approval_policy |
-a / --ask-for-approval
|
on-request (default), never, or a granular table |
| What a command can reach | sandbox_mode |
-s / --sandbox
|
read-only, workspace-write, danger-full-access
|
on-request means the model may stop and ask whenever it wants to do something the sandbox would block. The sandbox then decides, at the OS level, which files are writable and whether there's network.
Because the knobs are independent, you get a 2×3 grid of behaviours. The interesting cells:
codex -a never -s danger-full-access # == codex --yolo
codex -a never -s workspace-write # never asks, still fenced
codex -a on-request -s danger-full-access # no fence, may still ask (rarely does)
The middle one has a lovely failure mode: when a command needs more than the sandbox allows, it simply fails, and the error goes back to the model to work around. No human in the loop, but no escape either.
On the CLI, -a only accepts on-request and never. Combining flags that both set a knob is rejected: --yolo can't be combined with -a, and --approve-for-me can't be combined with -a, -s or --yolo.
Why does Codex's YOLO also drop the sandbox?
Because the flag's own help text says it's meant for environments that are already sandboxed from the outside (it calls itself "EXTREMELY DANGEROUS"). The design assumption is: if you're telling Codex "never ask", you're probably in a container, VM or CI runner where an inner sandbox is just friction. That assumption is great in CI and terrible on your laptop.
Here's what danger-full-access actually means. Not "the project". Everything your user account can reach:
- Every file you can read or write:
~/.ssh,~/.aws,~/.config/gcloud, browser profiles, other repos, dotfiles. - Unrestricted network: download-and-run, call APIs with any token it finds, exfiltrate anything.
- Your git identity:
.gitis no longer protected, so history rewrites andgit push --forcego out as you. - Every exported env var in the shell that started Codex.
Now add prompt injection. A malicious instruction in a README, an issue, or a fetched web page can steer the model, and with YOLO on nothing pauses to ask you.
How is the sandbox actually built?
| Platform | Mechanism | Notes |
|---|---|---|
| macOS | Seatbelt via sandbox-exec
|
Built into the OS, nothing to install |
| Linux | bubblewrap + a seccomp network filter | Uses bwrap from PATH or a bundled copy. The old Landlock backend is legacy and refused for filesystem-restricted policies |
| WSL2 | Same as Linux | |
| WSL1 | None | WSL1 can't create the user namespaces bubblewrap needs, so Codex refuses sandboxed commands |
| Native Windows | Codex's own sandbox | Unelevated and elevated variants; /setup-default-sandbox sets up the elevated one |
The Linux one is the gotcha. bubblewrap needs unprivileged user namespaces. Inside an unprivileged container they're often unavailable, you get a startup warning, and the sandbox can't start. That's the one situation where running --yolo inside a container is the normal setup rather than a shortcut: the container is the sandbox.
Even in workspace-write, Codex keeps .git, .codex and .agents read-only, so it can't rewrite history or its own config without asking. That's a neat detail: the agent's own control plane is outside its write fence.
How do I get most of YOLO without dropping the fence?
Most YOLO cravings come from two workspace-write limits: no network, and no writes outside the project. Open them individually:
sandbox_mode = "workspace-write"
approval_policy = "never"
[sandbox_workspace_write]
network_access = true
writable_roots = ["/Users/me/.cache/pip"]
network_access makes npm install/pip install work. writable_roots (or --add-dir <DIR> per run) adds folders. exclude_tmpdir_env_var and exclude_slash_tmp remove $TMPDIR and /tmp from the writable set if you want it tighter.
How does config precedence work, and where does project trust fit?
Codex reads ~/.codex/config.toml (or $CODEX_HOME/config.toml). The YOLO default is just:
approval_policy = "never"
sandbox_mode = "danger-full-access"
A few precedence rules worth knowing:
-
-c key=valueoverrides any key for one run. -
Permission profiles:
default_permissions = ":danger-full-access"(also:workspace,:read-only) is the newer form, and wins oversandbox_modewhen set. -
Profiles:
codex -p yololayers~/.codex/yolo.config.tomlon top of your normal config. Keeping YOLO in a profile means it's opt-in per launch. (Old[profiles.yolo]tables still load, but-pnow means the separate file.) -
Managed
requirements.toml: an admin can forbidneverordanger-full-access, and Codex falls back to the allowed default. -
Retired value:
approval_policy = "untrusted"is now a hard error at startup.on-failureis still accepted as another name foron-request.
Project trust is how Codex handles the "random cloned repo" problem. The first time you open a folder, Codex asks whether you trust it and records trust_level = "trusted" under [projects."/path"] in your config. A trusted, version-controlled project starts in workspace-write + on-request; anything untrusted or not under version control starts read-only. Trust only sets the default: an explicit --yolo or config key still wins. The point is that the decision lives in your home directory, not in the repo.
How does the in-session switch work?
/permissions opens a picker with three presets:
| Preset | Approvals | Sandbox |
|---|---|---|
| Read Only | on-request | read-only |
| Default | on-request | workspace-write |
| Full Access | never |
danger-full-access (the YOLO preset) |
With the Auto-review experiment on, there's also an Auto-review mode that routes approvals to an automatic reviewer (the CLI equivalent is --approve-for-me, hidden alias --not-so-yolo, which pairs that reviewer with workspace-write). /approvals is gone; /approve only retries one action the reviewer rejected. There's no keyboard shortcut to Full Access, which is deliberate friction.
Gotcha: config is read at session start. Edit config.toml mid-session and nothing changes until you restart or use /permissions.
What changes in CI with codex exec?
codex exec runs one task non-interactively. There's nobody to ask, so it never asks and has no -a flag. The sandbox is the only knob, and it defaults to read-only:
codex exec "summarize the open TODOs" # read-only
codex exec --sandbox workspace-write "fix the failing tests"
codex exec --yolo "run the full release script" # no sandbox
exec refuses to run outside a git repo unless you pass --skip-git-repo-check (or --yolo, which skips it too). --json streams JSON Lines events; -o <file> writes the final message. Use CODEX_API_KEY scoped to that one step, not job-wide, if the workflow checks out untrusted code.
On GitHub, openai/codex-action@v1 keeps the key behind a proxy, drops sudo by default (safety-strategy: drop-sudo), and takes permission-profile: ":workspace". A hosted runner is exactly the "outer sandbox" --yolo assumes, but the workspace profile is usually enough.
Two more things YOLO does not skip: hooks still need to be trusted once (--dangerously-bypass-hook-trust exists for automation that vets them), and --full-auto is simply gone (use -s workspace-write).
How does YOLO map over ACP?
Codex doesn't speak the Agent Client Protocol natively. @agentclientprotocol/codex-acp is a stdio adapter that starts the Codex App Server and translates both ways. Over ACP there are no flags, just four session modes:
| ACP mode | Approvals | Sandbox | CLI equivalent |
|---|---|---|---|
read-only |
asks you | read-only | -s read-only |
workspace-write |
asks you | workspace-write |
/permissions Default |
agent (default) |
automatic reviewer | workspace-write | --approve-for-me |
agent-full-access |
never | danger-full-access | --yolo |
Note the default is agent, so Codex over ACP doesn't ask you about most things even before YOLO. INITIAL_AGENT_MODE=agent-full-access starts it in YOLO; CODEX_CONFIG merges a JSON object into session config.
How do I turn on YOLO per task or per workspace with AgentRQ?
Every Codex switch above is session-scoped. If you want YOLO for one job and approvals for everything else, move the decision out of Codex and into a task.
1. Connect Codex through the ACP Gateway (Codex CLI ACP setup guide):
npx @agentrq/acp-gateway@latest --login --agent codex-acp # once
npx @agentrq/acp-gateway@latest --agent codex-acp
The gateway moves each new session out of any self-approving mode (Auto review, Full access) and into read-only, so every edit and command comes to you as a permission request in the AgentRQ task, on the web, your phone or Slack. You answer:
- Allow Once: this call only.
- Always Allow: adds the tool to the workspace's auto-approved list.
- Deny: Codex gets the rejection; you can reply with what to do instead.
If nobody answers within 30 minutes, the gateway cancels the turn instead of guessing (--permission-timeout changes it).
2a. Per task. Flip the YOLO toggle on a task, or set it at creation. Every permission request in that task is auto-approved; every other task still asks. Scheduled tasks, event triggers and workflow steps have the same switch. The per-task flag persists across agent disconnects and reconnects.
2b. Per workspace. Workspace settings has YOLO Mode (Execute All) (UI warning: "Agent will not ask for permission"). Under the hood it's a default, not a global override: the approval check reads the task's own YOLO flag, and the workspace switch decides what that flag starts as. New tasks you create in the web form open with the YOLO toggle already on (you can still switch it off per task), and tasks the agent creates for itself over the workspace MCP server inherit it. Flipping the switch doesn't rewrite tasks that already exist.
Or let a model approve and deny for you, from plain-English rules. Between "ask me every time" and "approve everything" there's a third option: an AgentRQ desktop extension that reviews each permission request before it reaches you. Extensions are trusted Node modules loaded by the AgentRQ desktop app. One registers a reviewer with ctx.hooks.add({ id, review(request) { ... } }) and is handed the pending call: the tool name, the argument preview the harness sent, and the workspace. It answers { behavior: 'deny', reason }, { behavior: 'allow' }, or nothing at all to abstain. Point review() at an external decision API such as TypeSafe's Jev, a "System One" model that returns a typed choice with calibrated probabilities and a confidence in milliseconds instead of generating text. Send the tool call as the state, and your workspace's rules in plain English ("git push is fine on feature branches, never on main", "never read anything under ~/.aws") as a Choice question over allow / deny / ask me. Then threshold it: approve only on a high-confidence allow, refuse on a confident deny, and abstain on everything else so the request lands on your phone as usual. The rules can live on a per-workspace settings tab the extension draws itself; the bundled guardrail example does exactly that with literal patterns.
The review contract is built on one asymmetry: refusing costs a tool call, approving costs whatever the tool call does. So one refusal settles a request; silence (an abstain, an exception, or a reviewer that misses its 5-second deadline) is never an allow, the request just stays in front of you; and an extension needs the decide consent level to approve, while deny consent can only refuse. The install screen starts every extension at none. Reviews only happen while the desktop app is open and signed in, so treat this as a fast first pass, not a security boundary.
The trade-off. Workspace-wide is AgentRQ's version of putting approval_policy = "never" in your global config: zero friction, but it outlives the job you trusted. Per-task YOLO scopes it to one unit of work. Crucially, YOLO in AgentRQ only removes the questions: Codex keeps the sandbox of the mode it's in, so it never turns into danger-full-access. Concrete example: task A ("upgrade test deps and fix what breaks", YOLO on) runs to the end unattended; task B ("clean up the staging deploy script", YOLO off) pings your phone for ./deploy.sh --dry-run (Allow Once) and later git push --force origin staging (Deny, "open a PR instead"). Same Codex, same gateway. Start YOLO tasks from a clean git tree and check the tool call history afterwards. More in the YOLO mode feature page.
FAQ
Is --yolo the same as --dangerously-bypass-approvals-and-sandbox? Yes, identical.
How do I get no prompts but keep the sandbox? codex -a never -s workspace-write.
Why "unexpected argument '--yolo'"? Your Codex predates the alias. npm install -g @openai/codex@latest or brew upgrade --cask codex.
Why does Codex still ask in YOLO? Config changed mid-session, only one of the two keys is set, an admin requirements.toml forbids it, a hook awaits trust, or you're on ACP where the client picks the mode.
Does Codex sandbox work in WSL1? No. Use WSL2.
Is --full-auto YOLO? It never was, and it's removed. Use --sandbox workspace-write.
Comparing agents? Here's YOLO mode in every coding agent, side by side.
Where do you land: --yolo only inside containers, or -a never -s workspace-write with network_access = true everywhere? And has anyone hit the bubblewrap user-namespace wall in their CI? Tell me in the comments.
Originally published on AgentRQ.
Top comments (1)
tr.ee/dev-to