Cline rules for safe bash command execution

Published 2025-12-28 by Owner

Cline can execute shell commands as part of its agent loop. Most of the time this is useful (running tests, checking git status, etc.). Occasionally Cline runs something you don’t want — destructive commands, network calls, things with side effects.

A few .clinerules lines reduce the risk substantially.

The default risk

Cline by default asks for confirmation on destructive commands. The list of “destructive” is heuristic; some destructive things slip through.

Specifically, Cline may run without explicit confirmation:

rm of files inside the project (sometimes flagged, sometimes not)
git reset --hard (usually flagged but inconsistent)
npm install of packages (not flagged)
Curl/wget calls (sometimes not flagged)

The inconsistency is the problem. Users get used to “Cline asks before destructive things”; the cases that slip through cause surprises.

The rules

Add to .clinerules:

# Shell command rules

Before running any shell command:

1. Never run rm, mv, or cp without explicit confirmation, even within the
   project directory.

2. Never run git commands that modify history (reset, rebase, push --force,
   amend) without confirmation.

3. Never run curl, wget, or other network commands without explaining what
   you're fetching and why.

4. Never run commands that install software (npm install, pip install,
   apt install) without confirmation. Even if a dependency seems missing,
   ask before installing.

5. For commands that take more than 30 seconds (builds, tests on large
   suites), confirm before running. The user may want to know it'll take
   a while.

6. Never run commands that touch /etc, /var, ~/.ssh, ~/.aws/, or other
   system/credential directories.

7. Never run commands that include >> or > redirects to files outside the
   project directory.

8. For commands that depend on environment variables, verify the variable
   is set before running. Don't assume.

When in doubt, ask before running.

This is verbose but each line addresses a specific failure mode I’ve seen.

What this changes

After these rules, Cline’s behavior:

Asks before running rm, even in the project
Explains network calls before making them
Confirms package installations
Avoids touching credential paths

The friction is real — more confirmations, more “ask before X.” For most users, the friction is worth it.

The auto-approval setting

Cline 3.x has an “auto-approve up to $X per task” setting. Default is conservative.

Pair the rules with reasonable auto-approval:

Auto-approve limit: $1.00 per task
Max requests per task: 30

These limit how much Cline can run before checking with you. Low enough that a runaway loop is bounded; high enough that normal tasks don’t hit the limit.

A specific incident I prevent

A real example. Pre-rules, I asked Cline to “make sure the build works.” Cline:

Ran npm run build (fine)
Got an error about a missing dependency
Ran npm install some-package (without asking)
Ran build again (now passing)
Reported success

The package install was a problem. The “missing dependency” was actually a typo in an import, not a missing package. The package Cline installed was unrelated.

My package.json now had a useless dependency. I noticed days later in a git diff.

After the rules above, this scenario plays out differently:

Cline runs npm run build
Sees the error
Asks me before running npm install
I notice the typo, fix it, and we don’t add the dependency

The rule about confirming installs is doing real work.

Combining with sandboxing

For especially sensitive work, run Cline in a Docker container:

docker run -it -v $(pwd):/workspace -w /workspace mcr.microsoft.com/devcontainers/typescript-node bash

Inside the container, Cline can do whatever; the host is protected. Some integrations require dev container setup but the principle works.

This is overkill for most work. For work involving sensitive paths, working with credentials, or experimental tasks, the sandbox is appropriate.

What I avoid

A few patterns I don’t use:

Ultra-permissive rules (“trust Cline with everything”). The default risk is real; relaxing it removes a safety net.

Ultra-restrictive rules (“ask before every command”). Friction hurts the agent loop. Routine commands don’t need confirmation.

The middle ground above (specific destructive things require confirmation, routine things don’t) is the right balance for most users.

Worth setting up

The rules take 5 minutes to write. They prevent a category of “Cline did something I didn’t want” incidents.

For Cline users who haven’t customized rules: this is one of the highest-leverage rule sets to add. The cost is minimal; the protection is real.

The default safety in Cline is good but not perfect. A few extra lines close the gap.