Blog
Cline CLI --yolo: auto-approve is already on, so here is what --yolo adds
If you installed Cline's CLI expecting the extension's caution, the default will surprise you: a bare cline command already runs without asking.
Cline's standalone CLI auto-approves tool calls by default; --auto-approve false is how you get review back. --yolo, or -y, goes further: it skips approval prompts, exits when the turn finishes, and turns off spawning sub-agents by default. The CLI has no command allow list of its own, so blocking a command means a PreToolUse hook. Forkbench adds the credential half: a key used through Vault never enters Cline's environment.
The default is already unprompted
The CLI's README says it in one line: tool calls are auto-approved by default. Run cline with a task and it edits and executes without stopping.
That is the reverse of the VS Code extension's history, where approval was something you opted out of piece by piece. The two share the same core, and they do not share a default. --auto-approve false restores review for the CLI.
What --yolo adds
If approvals are already off, --yolo is less about permissions and more about running unattended. Per the CLI reference, it skips approval prompts, enables submit_and_exit so the process ends when the turn does, and disables spawn and team tools by default, so a one-shot run does not fan out into sub-agents.
--retries, three by default, stops a run after repeated tool-call mistakes, and it applies in yolo mode too. It is a guard against a run going in circles, not against a run going somewhere it should not.
The extension's old YOLO Mode checkbox was removed in version 4.1.8, and Cline's changelog is candid about why: it was cosmetic, and nothing in the approval path read it.
Blocking commands means writing a hook
The CLI has no allow or deny list for shell commands. Its README points to a PreToolUse hook for that: a script that sees each tool call before it runs and can refuse it. That is a capable mechanism, and it is the only one, so in a default install nothing refuses anything.
--worktree runs the task in a git worktree, which keeps edits off your working copy. It is isolation for files in the repository, not a security boundary. Setting CLINE_SANDBOX or --data-dir enables a sandbox mode, off by default and independent of --yolo.
How this works in Forkbench
Forkbench is a desktop app for running coding agents. Cline's CLI runs in it as the cline command you installed, and reaches the Thread's notes and board through the fb command on its PATH.
With approval off by default, what is in reach is what decides the outcome. A key in Vault is used by the command that needs it without the value entering Cline's environment, so neither the default nor --yolo puts a token in front of a command. A Thread can be locked to a set of folders by the kernel, inherited by every process Cline starts, which is a wall that does not depend on writing a hook.
The limit: a folder lock bounds files, not network traffic. Keeping the key out of the process covers what it does not.
Related: Yolo mode in every coding agent, compared, Claude Code: what --dangerously-skip-permissions actually skips, Git worktrees, explained
Frequently asked
Does Cline CLI auto-approve by default?
Yes. The CLI's README states that tool calls are auto-approved by default, and --auto-approve false turns review back on.
What does cline --yolo do?
It skips approval prompts, enables submit_and_exit so the process exits when the turn ends, and disables spawn and team tools by default. It is built for one-shot, unattended runs.
How do I block a command in Cline CLI?
With a PreToolUse hook, a script that inspects each tool call before it runs and can refuse it. The CLI itself has no allow or deny list for shell commands.
Where did the YOLO Mode setting go in the Cline extension?
It was removed in version 4.1.8 and folded into the Auto Approve menu. Cline's changelog notes that the checkbox was cosmetic, because nothing in the approval path read it.