Cline auto-approve settings: what each toggle allows, and who decides what is safe

The short answer

Cline’s auto-approve is a list of toggles, one per kind of action: reading files, editing files, running commands, using the browser and using MCP servers, each with a workspace-only and an everywhere version.¹ The safest useful setup is the one Cline’s docs suggest: turn on Read project files and leave edits, commands, browser and MCP off until you have a reason.¹ The toggle to understand before you turn it on is Execute safe commands. Cline doesn’t use a fixed allowlist; the model marks each command with a requires_approval flag, so “safe” means the model thought it was safe.¹ YOLO mode approves everything.¹

The toggles

Cline checks auto-approve per tool call, against the category of the call.¹

Source: Cline’s Auto Approve docs.¹

Two details from the docs matter in practice. The “all files” and “all commands” options only extend their base toggle, so they do nothing on their own. And notifications fire when an auto-approved command has been running for 30 seconds, which is a useful nudge to look at a command you didn’t approve by hand.¹

Notice what the MCP toggle is: one switch for every tool on every server you’ve connected. Turning it on approves a read-only search tool and a tool that drops tables in the same click. If you connect a database MCP server, that one toggle decides whether its write tools need you. Our post on requiring approval for MCP tool calls covers how to split tools by risk at the server instead.

Safe commands are the model’s call

This is the part people miss. Other agents decide what runs unattended from a list you wrote:

Cline’s docs give examples of what is commonly treated as safe (npm run build, npm test, git status, ls -la) and what commonly needs approval (npm install, rm -rf, mv, sed -i), and they say plainly these are examples, not promises.¹

The flag is reasonable for honest mistakes. A model that knows rm -rf is dangerous will usually flag it. The weakness shows up when the model’s judgment is the thing under attack. A README, an issue comment or a web page the agent reads can carry instructions; if they persuade the model a command is routine, the same model sets the flag. The lethal trifecta post explains why private data, untrusted content and a way to act are a bad combination. Execute safe commands puts the “way to act” under the same judgment that read the untrusted content.

There is also a subtler gap: a command that looks harmless can call something that isn’t. npm test runs whatever the test script says. make runs the Makefile. If the agent edited that script earlier in the session, with Edit project files on, “safe” covers the new contents.

None of this makes the toggle useless. It means: turn it on in projects where the worst command is a lost build, not where a database client and production credentials are in reach.

YOLO mode

YOLO mode is one checkbox in Cline Settings, under Features. With it on, Cline auto-approves file operations anywhere on your system, every terminal command including destructive ones, browser actions, MCP tools, and the switch from Plan mode to Act mode.¹ Cline’s own docs call it dangerous and list what could go wrong: deleting important files, changing system settings, installing packages, pushing to version control.¹

The mode switch deserves a sentence. Plan mode is where Cline proposes and you review. In YOLO mode the transition to Act is approved too, so the review step you might be counting on is gone.¹

For teams, Cline Enterprise can turn YOLO off for everyone. Setting "yoloModeAllowed": false in remote configuration disables the toggle, and members can’t enable it in local settings.² Cline recommends most organisations disable it by default.² If you run Cline Enterprise, this is the first policy to set.

Checkpoints cover files only

Cline’s checkpoints are a good safety net for edits. After each tool use, including commands, Cline commits your project files to a shadow Git repository separate from your own history, and it captures files Git doesn’t track.⁵ You can restore files, the conversation, or both.

What a checkpoint holds is a snapshot of files in your project. It doesn’t hold the rows a command deleted from a database, a message an MCP tool sent, a package published to a registry, or a file outside the workspace. Our post on Cursor’s checkpoints walks through the same limit for Cursor; it applies to every file-based undo. If an auto-approved command reached a database, the checkpoint can’t bring the data back. A backup, point-in-time recovery or a record of the exact rows changed can.

If you build on the Cline SDK

Cline also ships an SDK for building agents on its harness, and its defaults are worth checking. Tool names you don’t list in toolPolicies default to enabled and auto-approved.³ So an SDK agent that adds a new tool approves it unless you set a policy.

Code Program code, for developers. The text around it says what it does.

const toolPolicies = {
  read_files: { autoApprove: true },
  search_codebase: { autoApprove: true },
  editor: { autoApprove: false },
  run_commands: { autoApprove: false },
};

Plugins can add a beforeTool hook that returns skip with a reason to block a call, or { policy: { autoApprove: false } } to require approval.⁴ Each hook call has a 3-second timeout, and under the default hookErrorMode of "ignore", a hook that throws or times out is recorded and the run continues as if the hook said nothing.⁴ If your hook is a safety check, set hookErrorMode to "throw" so a broken check stops the run instead of waving calls through.

A setup we would start from

1. Read project files: on.
2. Edit project files: on only with checkpoints and a clean Git tree.
3. Execute safe commands: off in any project with database clients, cloud CLIs or production credentials in the environment. On in throwaway projects.
4. Execute all commands: off.
5. Use MCP servers: off unless every tool on every connected server is read-only.
6. Browser: off unless the task needs it.
7. YOLO: off; on Enterprise, set "yoloModeAllowed": false.²
8. Notifications: on, so long-running auto-approved commands get your attention.¹
9. Database access: give the agent a role that can’t drop or bulk-delete, so a wrongly “safe” command is a limited one.

Approvals work only if you read them. If the toggles leave you clicking approve forty times an hour, you’ll stop reading; our alert fatigue post looks at what the research says about that. Fewer, better prompts beat more prompts.

To try approvals and a read-back on a real database without installing anything, open the playground. To grade what agents on your machine can reach, including the MCP servers Cline is connected to, run npx deedglass scan (the grade, explained).

Questions people ask

Does Cline have a command allowlist?

Not for its auto-approve toggles. The docs say Cline doesn’t use a fixed allowlist; the model marks each command with requires_approval.¹

Can I auto-approve some MCP tools but not others?

The toggle covers MCP tools and resources as one category.¹ To split them, limit the tools a server exposes, or run write tools behind a gate that asks.

Do checkpoints undo terminal commands?

They snapshot project files after each tool use, commands included.⁵ Effects outside those files, such as database rows or remote systems, aren’t in the snapshot.

Written with AI assistance and checked against our claims register.