Autonomous coding agent as VS Code extension, CLI and SDK
github.com/cline/cline · 2026-10-03 · 39ff235
Defense-in-depth score
1.4 / 10
As shipped, the Cline CLI auto-approves every tool, so the model runs arbitrary shell commands, edits files and fetches URLs on your machine with your full credentials and no human check. There is no sandbox, and opening a repository silently runs its .cline hook scripts and plugin modules. A prompt injection in a web page or cloned repo can therefore steal secrets and take irreversible actions unattended. Run it with --auto-approve false, only in trusted repos, and preferably inside a container.
As shipped, the Cline CLI approves every tool call itself and runs commands on your machine with your full account, with no sandbox and no time or spend limit. It does include per-call approval, a plan mode and a run timeout, so the safest setup turns those on and puts the rest of the boundary around Cline yourself.
| Setup | How | What it gives you |
|---|---|---|
| A dedicated, low-privilege account | Run Cline as an OS user or in an environment that holds only the keys and logins this task needs, each with a spending limit set at the provider | Every command the model runs reaches only the systems and spend you chose, not your whole account C1 |
| Per-call approval | Start interactive sessions with --tui and --auto-approve false | You see the exact shell command, and the file path of each edit, before it runs C2 |
| Plan mode for reading | Use --plan for tasks that only need to read and investigate | The file editor is off and shell commands go through the plan-mode command check C3 |
| A run timeout | --timeout <seconds> on every run | A session ends after a fixed time instead of running until someone stops it C10 |
| Git checkpoints | Run Cline inside a git repository so the default checkpoints snapshot the working tree | File changes in the workspace can be rolled back after a run C2 |
| Trusted repositories only | Open only repositories you trust, after reading their .cline/hooks, .clinerules/hooks, .cline/plugins, .clinerules and AGENTS.md | Code and instructions that load at session start come only from sources you have checked C6 |
| Its own container or VM | Run Cline in a container or VM that mounts only the project and reaches only the model provider and hosts the task needs | An outer boundary around model-written commands, hooks, plugins and MCP servers, and a narrow path for data to leave C4 |
| A copy of each transcript | Copy the session records under ~/.cline/data/sessions to storage the agent can't write | A record of every tool call and result that the agent's own shell can't alter afterwards C9 |
0.00 / 1.00
Cline's CLI runs with the full authority of the user who launched it and does nothing to narrow it. The shell tool, MCP servers and plugin subprocesses all inherit the complete process environment, so any API keys, cloud credentials, SSH agent or GitHub CLI login available to the user are available to every command the model runs. There is no per-tool identity or authorization layer, so a hijacked session can do anything the user's account can do.
0.25 / 1.00
The CLI ships with tool auto-approval switched on for every tool, including shell commands, file edits and MCP tools, so in the default configuration nothing waits for a human. If a user passes --auto-approve false, a per-call prompt appears that shows the exact shell command but only the path (no diff) for file edits, with no risk tiers. Even then, approval enforcement does not cover every path. Git checkpoints let workspace file changes be undone, but shell side effects such as pushes, deletions outside the repo or network calls cannot be.
0.15 / 1.00
The default act-mode tool set includes an unrestricted shell, file editing, file reading and web fetching, all enabled at once. The shell takes any command string. The editor's path containment is not a complete boundary, file reading has no path restriction, and web fetch only checks the URL scheme, with no block on internal addresses. The plan-mode command blacklist does not apply in the default act mode.
0.00 / 1.00
Commands the model writes run directly on the host as the user, with the full environment and full network access. There is no container, OS sandbox or VM anywhere in the CLI or SDK; the CLI's "sandbox" option only isolates Cline's own data directory. Workspace hook scripts and plugin modules also run as host subprocesses. A destructive or malicious command reaches everything the user can.
0.00 / 1.00
Cline reads web pages, repository files and MCP tool results straight into the model's context with nothing marking them as untrusted and nothing that changes what the agent may do afterwards. Because every tool is auto-approved by default, injected instructions in a fetched page or a cloned repo can make the agent read secrets with read_files or the shell and send them anywhere, or take irreversible actions, without a human seeing it.
0.10 / 1.00
Opening a repository in Cline silently loads its instruction files (AGENTS.md, .clinerules), and also its hook scripts (.cline/hooks, .clinerules/hooks) and plugin modules (.cline/plugins), which are executed with no workspace-trust prompt. All runtime config extensions are on by default. The agent can also write those same files with its auto-approved editor or shell, so a single injection can plant a hook or rule that runs in every later session in that project. Newer Agent Plugin packages are, by contrast, only discovered from the user's home directory.
0.05 / 1.00
Plugin modules placed in a repository's .cline/plugins folder are discovered and executed automatically when a session starts, and hook scripts in the repo run as subprocesses, all without consent. The plugin "sandbox" is a separate Node process that still inherits the full environment. MCP servers are added by the user to a user-scope settings file but are launched unpinned with the full environment. There is no version pinning, integrity check or re-approval on change.
0.20 / 1.00
Provider credentials are stored in a plaintext JSON file with owner-only permissions rather than an OS keychain. The read_files tool has no path restriction and the shell inherits the full environment, so the model can read stored keys or environment secrets in the default auto-approved mode. Git remote URLs have embedded credentials stripped before being put in the prompt, but there is no general redaction of logs, transcripts or tool output. Product telemetry is opt-out and, as far as the event definitions show, content-free.
0.45 / 1.00
Each session's full message history, including every tool call and its arguments and results, is saved under ~/.cline/data/sessions at the end of every agent iteration, so a run can be reconstructed afterwards. Saving is fire-and-forget, so failures are only logged and the agent keeps acting. In the CLI the dedicated hooks.jsonl audit log is skipped for the main session because the CLI installs its own runtime hooks; sub-agent events are still appended there. The records sit in the user's home directory, where the auto-approved shell can edit or delete them.
0.23 / 1.00
The CLI sets no iteration cap, no wall-clock limit (--timeout defaults to 0) and no cost ceiling, so a runaway session can loop and spend indefinitely. Individual shell commands time out after 30 seconds by default, and pressing stop aborts the run and kills the running command's process group. A consecutive-mistake counter stops the loop after repeated errors, but that bounds failures, not damage.
SafetyCard