Cline auto-approve: what to enable and what not to

Published 2026-05-11 by Owner

Cline can interrupt you for confirmation on almost every action it takes: reading a file, editing a file, running a terminal command, opening a browser. By default, it asks. Most people eventually start approving everything reflexively and wonder why they bothered with the confirmation loop at all.

The settings exist for a reason, though. The right answer is not “approve all” or “approve nothing” — it’s a deliberate per-category decision, because each category has a different blast radius when something goes wrong.

The four categories and their blast radius

Cline splits auto-approve into four distinct categories. They’re not equivalent. Treating them as a single toggle is the mistake most people make in the first week.

Read (file reads)

The safest category by a considerable margin. A file read cannot modify state. The agent reading package.json or src/db/schema.ts cannot break your database or delete your history. The only realistic concern is information exposure if you’re working with secrets or credentials in plain files — and even then, the agent already has filesystem access by definition.

There is also a subtle concern around read volume: in a long session, Cline may read hundreds of files. With manual approval you’d be clicking through dozens of confirmations for reads that contain no risk. That’s the worst of both worlds — friction without protection.

The interruption cost of manual approval is high (constant context switching), and there’s no plausible damage path. Read auto-approve should be on.

Edit (file writes and modifications)

This is where the blast radius starts to matter. Edits to new files are low risk — the worst case is the agent creates a file with wrong content, which you delete or overwrite. Edits to existing files are higher risk, because the agent can corrupt working code or alter configuration that takes time to debug.

The difference between “new file” and “existing file” is material enough that most experienced Cline users apply a different mental model to each. The setting itself doesn’t make this distinction — it’s one toggle for all edits. The practical workaround is to calibrate it by task: auto-approve edits for sessions where Cline is generating new files from scratch, and turn it off when the task is modifying existing code.

A session that starts as greenfield (“add a new reports/ module”) can drift into edits of existing files as the agent discovers dependencies it needs to touch. Watch for that drift. A task that began as low-risk edit territory can become high-risk mid-session without the agent signaling the transition.

A concrete example of this: starting a session with “create the new UserSettings component” sounds like new-file territory. But as Cline builds out the component, it may decide to update the router to include the new route, modify the sidebar nav to add a link, and patch the authentication guard to allow the new path. All three of those are edits to existing files that carry real risk — a bad edit to the router breaks navigation for the entire app. If edit auto-approve is on from the start, all of that happens without a checkpoint.

Terminal commands

This is the highest-risk category, and the one that causes the most actual incidents. A terminal command can install packages, modify the filesystem outside the project directory, delete files, make network requests, or — in the worst case — interact with infrastructure if the shell environment has production credentials loaded.

The confirmation cost is low (commands are less frequent than reads or edits). The damage potential is orders of magnitude higher. This is the right trade for ask-by-default.

There’s also a compounding concern with terminal commands. A single auto-approved command might be benign. A sequence of them — install a package, then run a migration, then start a dev server — creates a situation where the session has moved far from the original intent without any review point. Manual approval on terminal commands is the natural cadence reset that forces a brief review of what the agent has decided to do next.

Browser (web browsing)

The browser category matters if you’re running tasks that involve Cline looking up documentation, testing a URL, or interacting with a web interface. Unconstrained browser access is primarily a privacy and API-cost concern rather than a safety one — the agent can make requests on your behalf, interact with web interfaces if it has session cookies, or burn rate-limit quota on a third-party service.

Leave this on ask unless the task explicitly involves browsing as its primary work. When it does, approve specifically for that session rather than as a global setting.

The one scenario where blanket browser auto-approve makes sense: tasks where Cline is doing research-heavy work like collecting documentation, checking API specs, or pulling version information. In that context, every action is a read-only HTTP request and the interruption from manual approval breaks the flow without adding meaningful protection. Know the task before adjusting the setting.

Operations to never auto-approve

A few classes of terminal commands deserve explicit discussion regardless of what the broader auto-approve setting is configured to do.

This is not a complete list — it’s the categories where the cost of a mistake is high enough that the review step is worth having every single time, with no exceptions carved out for familiar tasks or trusted sessions.

rm -rf with any non-trivial path. The agent sometimes reaches for deletion instead of moving a file aside. You want to see the exact path before it executes. The cost of reading one confirmation dialog is much lower than the cost of recovering deleted files from a backup (or discovering there is no backup).

Related: find . -delete and similar commands that delete multiple files based on a pattern. The pattern might be tighter than you expect, or it might be looser.

Database mutations without a WHERE clause. DELETE FROM, UPDATE, TRUNCATE — if the agent is scaffolding a migration or seeding a database, having it run mutations against your production connection string because that happened to be in the environment is a data-loss scenario. This is not a hypothetical; it is a documented failure mode.

git push --force. Force-pushes rewrite remote history. If the agent is doing cleanup work on a branch and decides to tidy up commits, a force-push without your awareness is difficult to recover from depending on whether other people have pulled the branch.

git reset --hard also falls in this category. A hard reset silently discards uncommitted changes. If the agent resets to clean up a mistake it made, it may be discarding work you wanted to keep.

npm install <package> when the package name is unfamiliar. The agent might install a real package or it might install a package with a name close to a well-known one. The typosquatting risk in the npm ecosystem is real enough that you should read the exact package name before it installs. This is a 3-second review; do it.

Anything connecting to a service using credentials from environment variables. AWS CLI, gcloud, kubectl, any database CLI. The agent has access to your shell environment, which may include production credentials loaded from .env or a credential manager.

The incident that reset my defaults

For about two weeks, terminal auto-approve was enabled on a project that had several npm packages in active development. The task was straightforward: scaffold a new feature module, install its dependencies, run the tests.

Cline ran npm install canvas as part of setting up a charting component the prompt had mentioned in passing. The package installed cleanly. The problem: canvas has a native module that required a system-level dependency (libcairo) that was not present on the CI machine. The build passed locally and failed in CI. It took 40 minutes to trace the failure back to the new dependency — partly because Cline had installed it mid-session without any visible confirmation, partly because the error appeared in a native compilation log that wasn’t the obvious place to look.

The 40 minutes is roughly 20x the time it would have taken to read the npm install canvas confirmation dialog and ask “wait, do we need this?” Auto-approve on terminal commands removed the one checkpoint where I would have noticed an unfamiliar package name and verified intent.

This is the pattern with blast-radius failures. The cost is rarely catastrophic data loss; it’s unexpected investigation work that happens because something changed quietly. The confirmation loop is annoying until it’s the only thing standing between you and an hour of debugging.

A few observations from that incident that generalize:

First, the bad action was not the first action. Cline had read several files, created a new module, and done entirely reasonable work before deciding to pull in canvas. If terminal auto-approve had triggered a concern on the first command, I would have noticed and turned it off. The problem with auto-approve is that it habituates you to the agent doing the right thing, so you’re not watching when it does the wrong thing.

Second, the wrong action looked right in isolation. npm install canvas for a charting component is plausible. The problem wasn’t that the command was obviously bad — it was that I hadn’t agreed to include a charting component, and if I had been asked, I would have asked what prompted the decision. Auto-approve skipped that conversation.

Third, recovery from this class of mistake is slower than it looks. Removing an installed package (npm uninstall canvas) takes 10 seconds. Diagnosing why the CI build is failing when you don’t know a native module was added takes 40 minutes. The recovery time scales with how much you know about the change, not the change itself.

The middle ground: approve once for this session

Cline’s “approve once” behavior — approving a single instance of an action without enabling the global auto-approve toggle — is underused. It’s available on every confirmation prompt. You can approve an action for the current instance only and leave the global setting unchanged.

This is the right mode for tasks where you trust the specific action but don’t want to change your configuration. A few scenarios:

Running a data migration against a staging environment. You trust the specific psql command Cline generated, you’ve read it, and it matches what you wanted. Approve this instance. Don’t approve all terminal commands globally just to avoid the next confirmation.

Cline is editing a file you’ve already reviewed and agreed matches the plan. Approve this edit. Enabling edit auto-approve globally would cover files you haven’t reviewed and may not want modified.

The agent needs to run npm test repeatedly while iterating on a fix. npm test is low-risk and will run many times. Approving the test runner for this session is reasonable. Approving all terminal commands because you want npm test to be frictionless is not.

Approve-once is also the right response when you’re uncertain. If you’re not sure whether a command is safe but the specific instance looks correct, approve once and observe. If you were wrong, you’ve contained the blast radius to one command rather than everything that follows.

There’s a discipline aspect to this that matters: approve-once requires you to actually read the confirmation before clicking. That reading is the protection. If you’re approving without reading — just hitting the button reflexively — you’ve recreated the same risk profile as auto-approve, but more slowly. The point of the confirmation is the pause it creates, not the button itself.

Safe defaults for most sessions

After working through the above, the defaults that generate the least cleanup work:

These aren’t permanent settings. The right configuration for a three-hour greenfield session differs from the right configuration for a production hotfix. The defaults above are starting points to adjust once you understand the specific task, not rules that apply in all cases.

One pattern that works: at the start of a session, spend 30 seconds thinking about which categories this task will actually use heavily, and enable auto-approve only for those. A documentation task where the agent is mostly reading files and generating new MDX is different from a refactor task where the agent will be modifying dozens of existing files.

Another useful frame: auto-approve is a speed knob, not a safety knob. Turning it up speeds the session; it doesn’t make the agent more careful. The agent’s error rate doesn’t change because you removed confirmations — it just means errors complete without a pause. The knob should be set based on your tolerance for cleanup work on this particular session, not on a fixed philosophy about autonomy or control.

That also means auto-approve settings can legitimately change mid-session. If you started with edit auto-approve on and the session is now touching files you care about, turn it off. Cline doesn’t reset any state when you toggle the setting — subsequent actions just require confirmation from that point forward. Adjusting mid-session is a normal and sensible thing to do.

The settings panel in Cline is always accessible during a session. It’s worth checking current settings at session start if you work across multiple machines or profiles. It’s easy to leave auto-approve in a permissive state from a previous session where that was appropriate and carry it into a session where it’s not.

What to check before starting a sensitive session

Before any session that involves production data, deployment steps, infrastructure configuration, or files you’d be upset to lose, a quick pre-flight:

1. Open Cline settings and verify auto-approve state for each category.
2. Confirm terminal auto-approve is off.
3. If edit auto-approve is on, confirm this task is new-file work, not modification work.
4. Note whether your shell environment has any production credentials loaded — echo $AWS_PROFILE or env | grep DATABASE_URL takes five seconds.

None of this needs to be elaborate. The goal is to not discover mid-session that you’ve been auto-approving commands in an environment you didn’t intend to use. Five seconds of setup avoids the more expensive version of that discovery.

The thread that runs through all of this: auto-approve saves you from interruptions, but interruptions are also the mechanism by which you stay in the loop on what the agent is actually doing. The goal is not zero interruptions — it’s interruptions at the decision points that actually matter. Read confirmations almost never matter. Terminal command confirmations almost always do.