Blog
Qwen Code yolo mode: five approval modes, and the one most people want instead
Qwen Code started as a fork of Gemini CLI and kept its yolo flag. It then added something Gemini never had: a mode where a model decides which commands need you.
In Qwen Code, --yolo, -y or --approval-mode yolo approves every tool call. It does not touch either of Qwen Code's sandboxes, both of which are off by default, so a bare yolo session runs with your user's full access. The mode below it, auto, has a classifier approve or block each shell, network or out-of-workspace action, which is closer to what most people want. Forkbench adds the credential half: a key used through Vault never enters Qwen Code's environment.
The five modes
Qwen Code's approval mode takes five values, and Shift+Tab cycles through them in a session.
- plan. Reads and proposes, edits nothing, runs nothing.
- default. Asks before edits and commands.
- auto-edit. Applies file edits without asking, still asks before shell commands.
- auto. A classifier reviews each shell, network or out-of-workspace action and approves or blocks it, added in version 0.16.0.
- yolo. Approves everything.
Yolo removes the human, not a boundary
Qwen Code's documentation says it directly: approval and yolo do not expand the filesystem or network policy. If a sandbox is on, it stays on.
The catch is that both sandboxes start off. The whole-process sandbox, Docker, Podman or Seatbelt on macOS, is enabled with --sandbox. The newer per-command sandbox is Linux-only. On a Mac with neither switched on, yolo means commands run as you, with your network, and nothing between them and your home folder.
Yolo does widen two smaller things. It drops the non-interactive behaviour of refusing anything not on the allow list, and it approves gated MCP servers without asking.
What still stops a yolo session
Three checks survive. permissions.deny is evaluated first and holds in every mode. Leaving plan mode still asks. And an untrusted folder forces approval mode back to default whatever you passed, which surprises people running yolo on a freshly cloned repository and wondering why it keeps asking.
How this works in Forkbench
Forkbench is a desktop app for running coding agents. Qwen Code runs in it as the qwen command you installed, with your .qwen/settings.json intact, and reaches the Thread's notes and board through the fb command on its PATH.
On a Mac, the useful addition is a boundary that is on without you remembering to switch it on. A Thread can be locked to a set of folders by the kernel, inherited by every process Qwen Code starts. And a key in Vault is used by the command that needs it without the value entering Qwen Code's environment, so neither yolo nor a classifier in auto mode is ever deciding whether a command may use a token it is holding.
The limit: a folder lock is about files, not network requests. The key not being in the process is what covers the rest.
Related: Yolo mode in every coding agent, compared, Gemini CLI yolo mode, the fork's parent, Claude Code: what --dangerously-skip-permissions actually skips
Frequently asked
How do I enable yolo mode in Qwen Code?
Start with --yolo, -y or --approval-mode yolo, or switch with /approval-mode yolo in a session. Add --project or --user to that command to save it, and Shift+Tab cycles through all five modes.
What is auto mode in Qwen Code?
A mode where a classifier reviews each shell, network or out-of-workspace action and approves or blocks it, instead of asking you. It sits between auto-edit and yolo, and arrived in version 0.16.0.
Does Qwen Code yolo mode disable the sandbox?
No. Qwen Code's documentation states that approval modes do not expand the filesystem or network policy. Both sandboxes are off by default, though, so unless you enabled one, yolo runs commands directly on your machine.
Why does Qwen Code ignore --yolo?
Usually because the folder is not trusted. Qwen Code resets the approval mode to default in an untrusted folder, whatever flag you passed.