Cline’s .clinerules Has No Enforcement — The Model Decides What to Obey

What you expect

Cline’s .clinerules file functions as a governance layer: write rules into a project file and the agent follows them. Combined with configurable permission modes and the ability to auto-approve only “safe” commands, the expectation is that a team can define boundaries and trust the agent to stay inside them. The 58,000-star user base signals that practitioners believe this.

What actually happens

.clinerules is injected into the system prompt as text. It has no enforcement mechanism. The LLM reads the rules and decides whether to honor them. Across independently filed issues in Cline’s issue tracker, that decision fails on destructive operations:

Issue	What happened
#7572	rm -rf ~/ executed without a permission prompt — model classified destructive command as safe
#7682	git push --force overwrote the remote despite a .clinerules prohibition
#8347	kubectl apply auto-approved under “execute safe commands” — infrastructure mutation misclassified
#9357	Global auto-approve overrides per-tool permission settings entirely

There are no built-in cost controls. Cline has no token budget, no cost warning, and no circuit breaker. Issue #8027 documents a $300 bill for a simple HTML task. Issue #5870 documents a $7 single API call for reading a 68K-line file — Cline has no LSP integration and loads entire files through the context window rather than using the editor’s symbol navigation.

v3.8.5 expanded the exposure. A global “auto-approve all” toggle was added for MCP servers. When enabled, every tool call from every configured MCP server executes without a confirmation prompt. The same release added support for remote MCP endpoints via HTTP/SSE URLs, which bypass local sandbox controls and have unrestricted outbound access by default.

What this means for you

The failure mode is architectural, not configurable. Cline delegates safety classification to the model, making the model both the agent deciding what to do and the guard deciding whether it should. Those roles cannot be filled by the same system reliably.

Any operation the model believes is safe will execute — regardless of .clinerules. That includes irreversible operations in repos where .clinerules explicitly prohibits them. The issue trail shows this is not a rare edge case; it is the default behavior when the model’s classification diverges from the written rule.

For teams running Cline on repos that contain production infrastructure config, secrets, or remote state (Terraform, kubectl, git remotes), this is a pre-condition for data loss and unauthorized mutation.

What to do

1. Do not treat .clinerules as an enforcement boundary. It is a soft hint to the model. Treat any operation it is meant to prohibit as unenforced by default.
2. Enforce destructive command prevention at the OS and remote layer — file system permissions, protected branches on the remote, Kubernetes RBAC. These are mechanisms the model cannot override by classifying the command as safe.
3. Disable the global MCP auto-approve toggle (autoApproveAll: false in Cline extension settings). Audit per-server autoApprove settings. Any remote MCP server (HTTP/SSE URL in config) should require manual confirmation.
4. Set a spending limit at the API provider level. Cline has no built-in cost controls. Most LLM provider consoles support per-key or per-project spend caps that halt requests rather than accumulating charges.
5. If runtime enforcement is a hard requirement, evaluate agents that enforce at the process level. Claude Code’s PreToolUse hooks run external validators that block execution before the shell receives a command — bypassing the model’s intent rather than relying on it.

Falsification criterion: This finding would be disproved by Cline shipping a configurable allowlist/blocklist that intercepts Bash commands at the process level before execution — making the block independent of the model’s safety classification.

Evidence

Tool	Version	Evidence	Result
Cline	v3.x (up to v3.81.0, Apr 2026)	source-reviewed	rm -rf ~/ executed without consent (#7572); git push --force overrode .clinerules (#7682); kubectl apply auto-approved (#8347)
Cline	v3.8.5 changelog	source-reviewed	Global MCP auto-approve-all toggle added; remote SSE endpoints bypass local sandbox (changelog)
Cline	v3.x	source-reviewed	$300 API bill for HTML task (#8027); $7 single call for 68K-line file read (#5870)

Confidence: empirical — 6 independently filed issues across at least 5 distinct reporters. Core incidents (#7572, #7682, #8347) are independent filings, not variations of the same report.

Strongest case against: Cline v3.76.0 shipped native repeated tool call loop detection — described as the first IDE agent to do so. If Cline continues adding enforcement-layer capabilities, the permission model may be partially addressable. The architectural constraint (VS Code extension model vs. shell-level process hooks) remains. Issue #7572 (the rm -rf ~/ incident) predates v3.76.0; that release addresses tool-call repetition loops (#7262), not permission bypass.

Open questions: Does the v3.76.0 loop detection cover parse-failure infinite loops (#7262) or only repeated tool-call patterns? Does the Roo Code standalone CLI (v0.1.16) enable shell-level enforcement that the VS Code extension model does not support?

Seen different? Contribute your evidence — share a repro or counter-example and we’ll review it against this finding. Reader evidence is what keeps these findings accurate.