The cline package pulls a prebuilt binary for your platform through optional dependencies - built for macOS, Linux and Windows on arm64 and x64. Neither Node, Bun nor Zig is required at install time: npm here is just the delivery mechanism.

Then authentication. The provider can be chosen interactively or set outright:

The behaviour for browser-login providers is called out separately: they do not launch a browser on a normal startup, so you have to authenticate in advance. In a non-interactive run, if no saved credentials exist, the command fails fast with an authentication message rather than starting a hidden login flow.

Five Ways to Run It

The same tool behaves differently depending on how it was called.

Input can be piped in, which opens the usual command-line habits:

Zen: Fire It Off and Walk Away

A mode the neighbours usually lack, and a carefully built one.

--zen submits the task to a background daemon and exits the CLI immediately. It does not stream output and does not stay attached to the session - you fire it off and leave.

Since there is no human in the loop once the CLI exits, such sessions run with full tool auto-approval. Spawning subagents and teams is disabled by default - precisely for safety.

If the menubar app is running, it subscribes to the events and raises a notification when the task finishes. If it is not running, there is no live view at all: the result has to be found later through session history.

Combining --zen with an isolated data directory or with the terminal UI is not allowed, and the documentation explains why.

Auto-Approval Is On by Default

This is the most important passage in the article, and here the project contradicts itself.

The main README describes the work like this: every file edit and terminal command requires your approval, so you stay in control of what actually changes.

The CLI README says the opposite, verbatim: tool calls are auto-approved by default, use --auto-approve false to require review before tool execution.

There is probably no real contradiction - these are different products: in the editor approval really is asked for, in the terminal it is not. But someone who reads the front page and installs the CLI gets behaviour other than the one they expect.

When approval is on, the question comes with "no" as the default: anything other than y or yes counts as a rejection. And if stdin and stdout are not a terminal, calls requiring approval are simply denied.

Plan and Act

The toggle between two modes is something Cline introduced earlier than most.

In plan mode the agent explores the code, asks clarifying questions and lays out a strategy. Once you agree, you switch to act mode and it executes. In the CLI, plan mode is the -p flag; act is the default.

Providers

There is no lock-in to a single vendor.

Signing in through a ChatGPT subscription is a separate option - no API key, through the openai-codex provider.

Rules and Skills

Project rules are set in .clinerules files: coding standards, architecture conventions, deployment procedures, testing requirements.

The important property: rules are picked up automatically by all three clients - the CLI, the VS Code extension and the JetBrains plugin. So the project's conventions are written once and work regardless of which one a person uses.

Skills on top of that let the model load specific rules when they are needed, rather than keeping everything in context permanently.

Teams, Schedules and Messengers

Three capabilities that take the agent beyond a single session.

Agent teams: a coordinator breaks the work into subtasks and delegates them to specialists, each with their own tools and context. Team state survives a restart.

Schedules: cron-driven runs for recurring work - a daily pull-request summary, a weekly dependency check, a codebase health report. Schedules survive restarts and run independently of any terminal session.

Messengers: talking to the agent from Telegram, Slack, Discord, Google Chat, WhatsApp and Linear. Each conversation thread maps to an agent session with full context, and access control for who may interact at all is provided.

The SDK and Plugins

The same engine is available as a library.

A custom tool is described by a schema and a function, then handed to the agent:

Four packages are published: @cline/shared with low-level contracts, @cline/llms with provider integrations, @cline/agents with the agent loop itself, and @cline/core with runtime assembly, sessions and settings. The enterprise package is marked internal and is not published.

Plugins are loaded with a check: the set of capabilities is declared in package.json and verified by the loader before the module is imported.

What to Know in Advance

It builds on Bun only. The repository's agent instructions state it without alternatives: the toolchain is Bun 1.3.13 as package manager and task runner, Node 22 or newer as the runtime, and verbatim - do not use npm, yarn or pnpm. That is about developing Cline itself; installing it still goes through npm.

Context compaction for older sessions is best-effort. The architecture document admits it outright: sessions persisted with compacted messages before the current storage model are best-effort, because the omitted part of the original transcript cannot be recovered from the compacted artifact. Now the full history is stored separately and the compacted state in its own file, with a hash checked on resume.

There are more than a thousand open issues. As of 25 August 2026 there are 1,089. For a project of this size and pace that says more about load than about quality, but it is worth knowing.

The JetBrains plugin is closed. Every other part is open, that one is not, and the product table says so.

The thinking level is a flag. From none to xhigh, defaulting to medium when the flag is given with no level; without the flag, thinking is off.

First-Encounter Mistakes

Assuming the terminal will ask permission. It will not: auto-approval is on by default and is turned off with --auto-approve false.

Carrying the main README's promises over to the CLI. The front page describes the editor extension's behaviour.

Running --zen and waiting for output. It shows nothing: the task goes to the background and the result is found through history.

Looking for a single project version. There are four: the extension, the CLI, the SDK and the desktop app all carry their own numbers.

Trying to build the repository with npm. The toolchain is Bun, and that is stated as a prohibition.

Expecting a browser-login provider to open a browser itself. It will not; authenticate in advance with a separate command.

Counting on old compacted sessions being restored. The project warns honestly that this is best-effort.

Looking for the JetBrains plugin's sources. They are not published.

To put it in one sentence: Cline is interesting not because it is an agent but because it is one engine with five faces - and the rules you write once work in the editor, in the terminal and in a background schedule alike.

Sources

This article was checked against the cline/cline repository (branch main) on 25 August 2026: the README, AGENTS.md, apps/cli/README.md, sdk/README.md and sdk/ARCHITECTURE.md. Stars, forks, the open-issue count and the versions of all four lines were taken the same day through the GitHub API and the npm registry. The project ships several releases a day across different lines, so version numbers go stale almost immediately.

• GitHub: cline/cline
• Cline documentation
• The command line
• CLI overview
• The SDK
• Engine architecture
• Instructions for the project's own developers
• The Kanban board
• The extension on the VS Code Marketplace
• The plugin on the JetBrains Marketplace