Cline

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.