Guide · Cline

How do I use Cline auto-approve and YOLO mode safely?

Updated 2026-10-31

Turn on only Cline's Read project files auto-approval at first, leave Read all files, Edit all files and Execute all commands off, and turn on notifications so Cline tells you when it is waiting. Keep Checkpoints and git for rollback. Use YOLO mode, which Cline's documentation says disables all safety checks, only in an isolated or throwaway environment, such as a VM that sees one project folder and reaches only your model provider.

01Steps

Start with Read project files only. Cline's documentation recommends enabling Read project files and keeping the other permissions off until you have a specific need.
Add Edit project files when you review diffs. Edit project files covers only your workspace. If you enable edits, Cline recommends using Checkpoints so you can roll changes back. Leave Edit all files off: it reaches outside the workspace.
Allow safe commands, not all commands. Execute safe commands runs terminal commands marked safe. Execute all commands also runs commands that would require approval, which is where deletes, pushes and installs live.
Turn on notifications. Cline then sends an OS-level notification when approval is required, and when an auto-approved terminal command has run for 30 seconds.
Work on a branch you can throw away. Commit first and give the task its own branch, so git can undo what Checkpoints miss.
terminal
```
git switch -c cline/task
git add -A && git commit -m "before cline"
```
For YOLO or the CLI's auto-approve, isolate the run. The Cline CLI's --auto-approve flag approves tool use globally, and its docs list the default as true. Run it inside a sealed VM instead of on your laptop: save the kit below as cline.yaml (the next section explains it), check the plan with --dry-run, then run it. Arguments after the kit go to Cline.
terminal
```
npm view [email protected] dist.integrity
kosa8 agent run --dry-run ./cline.yaml
kosa8 agent run ./cline.yaml --auto-approve true "run tests and fix failures"
```

02Which Cline auto-approve settings are risky?

The ones that reach past your project or past review: Read all files and Edit all files, which work outside your workspace; Execute all commands, which runs commands that would otherwise need approval; and Use the browser and Use MCP servers, which reach web pages and external tools. Read project files is the low-risk starting point.

Toggle	What it allows	Suggested
Read project files	Read, list and search the workspace	On
Read all files	Read outside the workspace, such as `~/.ssh`	Off
Edit project files	Create and edit workspace files	On with Checkpoints
Edit all files	Edit outside the workspace	Off
Execute safe commands	Terminal commands marked safe	Your call
Execute all commands	Commands that would need approval	Off, or only in a VM
Use the browser / MCP servers	Web fetches and MCP tools	Per task

03What does Cline YOLO mode do?

YOLO mode auto-approves everything: file changes, terminal commands, browser actions, MCP tools and the switch from Plan to Act. Cline's documentation says it disables all safety checks and recommends starting in isolated or throwaway environments, with specific requests, the output watched and version control available.

It is turned on under Cline Settings, Features, with no confirmation dialog. Cline's docs list the risks plainly: deleting files, changing system settings, and committing or pushing to version control.

04Does kosa8 work with Cline?

Not as a built-in. kosa8 ships kits for Claude Code, Codex, Gemini CLI, OpenCode and the GitHub Copilot CLI, not Cline, and running Cline under kosa8 is not separately documented or tested. You can write your own kit for the Cline CLI using kosa8's general kit format; the VS Code extension itself runs in your editor, outside any kosa8 sandbox.

cline.yaml

name: cline
image: node:22-alpine
packages:
  - name: cline
    version: X.Y.Z          # the exact version you checked
    integrity: sha512-...   # from npm view, below
command: [cline]
egress_allow: [api.anthropic.com]   # your model provider only
secrets: [ANTHROPIC_API_KEY]        # copied in: the agent can read it

Pinned install. Each package names one exact version and its sha512 integrity; kosa8 checks the digest before installing.
One folder. The sandbox sees the folder you run from (or -w DIR) at /work, and nothing else on your computer.
One host. egress_allow is the only list of hosts it can reach; everything else is refused on your side.
The key is inside. secrets copies the real value in, and kosa8 says so on every run. Name the variable your Cline provider setup reads. Brokering the key needs a tool that accepts a different API address, which kosa8 has not checked for Cline.
Undo. Add --keep --name cline-run to keep the machine for kosa8 checkpoint and kosa8 rewind. A rewind does not roll back the shared folder: that is git's job.

05How do I stop Cline running up a large bill?

Cline's auto-approve documentation does not describe a spending cap. Set a spending limit with your model provider, keep each request narrow, leave notifications on, and watch long runs, because every auto-approved step can be another paid API request.

When the CLI runs in a kept kosa8 sandbox, kosa8 sandbox egress cline-run shows the enforced policy and the counts of passed and refused traffic.

06Other options

Cline's own controls alone fit interactive work: project-only toggles, Checkpoints and git.
A dev container keeps the VS Code extension's commands in a container that sees only the project; containers share the host kernel.
Docker Sandboxes runs coding agents in isolated microVM sandboxes from Docker's tooling.
A full VM in UTM or Lima fits when you want the whole editor in a throwaway Linux machine.
Hosted sandboxes such as E2B, Daytona or Modal fit when the agent should run in the cloud.