Cline ships five clients from one repository, and one of them is closed

Three products, three version numbers, one release day

The release list is the first thing to read, because the numbers have nothing to do with each other. All three newest tags are dated 2026-09-30: the extension at v4.1.22, the SDK at v0.0.88, and the desktop app at v0.0.39. The last push to main was on 2026-09-25.

So one repository, one commit history, three products, and three version lines with completely different magnitudes. A v4 in the extension says nothing about a v0 in the SDK, and the SDK is the part you would build your own agent on. A dashboard that surfaces the extension's number tells you nothing about whether the SDK you depend on is settled, and a zero-major version is the honest signal there. Nothing in the project publishes a compatibility matrix between the clients, so pinning a Cline dependency means picking which of the three lines you mean.

The VS Code extension is the repository root, and it is moving

There is an index in the README that maps each product to a directory, and one row is unusual. The SDK is at `sdk/`, the CLI at `apps/cli/`, the desktop app at `apps/examples/desktop-app/`, the docs site at `docs/`. The VS Code extension is listed at `/`, the repository root, with the note WIP migrating.

That means the extension has not finished moving into the `apps/` tree, so the root you clone is the extension's source rather than a neutral monorepo. The manifest at that root is named `@cline/packages` and marked private, with a workspace list covering `sdk/packages/*`, `apps/*`, two separate VS Code subpaths and three example globs. Anyone looking for the extension's package metadata finds a monorepo manifest and a migration in progress. Anyone scripting against this layout has to know that `apps/*` is the future home and the root is the present one.

The JetBrains plugin is the one client you cannot read

Four of the five clients are in the repository. The fifth has a single sentence: currently we are not open-sourcing JetBrains plugins. The index gives that row no directory and no changelog, where every other row has both.

The gap matters more than a missing file usually would, because the project still makes promises about that client. Rules files are described as picked up automatically by the CLI, the VS Code extension and the JetBrains plugin, and the diff and checkpoint behaviour is described for VS Code and JetBrains together. So behaviour is promised for a binary you cannot inspect, and an audit of what the plugin does with your code stops exactly at the boundary where the core engine ends. If your team standardises on the JetBrains family, that sentence is the whole disclosure you get.

The desktop app ships out of the examples directory

The index describes the desktop app as a native macOS and Windows application, a Tauri shell with a Bun sidecar and a Next.js interface, and places it at `apps/examples/desktop-app/`. The product section of the same document offers it as a download for macOS and Windows. The root manifest's workspace list includes `apps/examples/*` and `apps/examples/vscode/src/webview`.

So the path says example and the page says download. It is a small thing until you build tooling against this repository: a script that walks `apps/` for real products will include the desktop app, and a script that skips `examples/` will skip the app people install. The second client-level detail is quieter and matters more, because the desktop app is absent from the list of clients that pick up rules files.

Diffs and checkpoints are scoped to the IDE clients

The review surface is described precisely, and the precision is the problem. Every edit shows up as a diff you can review, modify or revert, and all changes are tracked with checkpoints, but that sentence is introduced with in VS Code and JetBrains. Separately, the CLI is described as an interactive chat or fully headless for CI/CD and scripting, and Plan and Act mode says every file edit and terminal command requires your approval, with an auto-approve toggle to remove it.

Put those together and the headless case has no described review surface. The README does not say what a headless run prints, whether checkpoints exist there, or what the audit record is, and the only stated control is the toggle that disables approval. The plugin section is where the gap is acknowledged by implication, since it says you register lifecycle hooks through the SDK for logging, auditing and policy enforcement. In other words, the record of what the agent did is something you write.

Rules are picked up by three clients, and the fourth is unnamed

Project-specific behaviour goes in a file called `.clinerules`, spelled with no extension, covering coding standards, architecture conventions, deployment procedures and testing requirements. Skills are the second mechanism, letting the model load particular rules when it needs them. The sentence that says these are picked up automatically names the CLI, the VS Code extension and the JetBrains plugin.

The desktop app is not in that list, and it is the client the project markets most recently. A team that writes its deployment procedure into a rules file and then runs sessions from the desktop app has no stated guarantee the file is read, and no error either, since nothing describes what happens when a rules file is ignored. The repository keeps its own `.clinerules/` directory at the root, so the convention is real, it is just applied per client and the list is three long.

Bun builds it, npm installs it, and the tests have two front doors

Consumers install with npm.

npm i -g cline

npm install @cline/sdk

The project itself is built with Bun, and the root manifest shows how much of the pipeline that covers.

        "build": "bun run clean && bun install && bun run build:sdk && bun -F @cline/cli build",
        "build:sdk": "bun --production -F './sdk/packages/*' build",
        "build:apps": "bun -F './apps/**' --production build",
        "build:models": "bun -F @cline/llms generate:models && bun format --write",

So a user needs Node and a contributor needs Bun, which is a small tax most contributors pay knowingly. Two details are worth more attention. The model list is generated and then reformatted as part of the build, so the provider table in the README is generated output rather than something anyone maintains by hand. And the unit tests have two entry points, one using Bun's own parallelism and filters, the other a hand-written shell script that starts six package test runs in the background and waits on each exit code separately.

Editorial conclusion

Cline fits a developer who wants one agent engine across a terminal, a desktop app and an editor, and who reads the diff before approving a command. It does not fit an auditor: the JetBrains plugin is not open sourced, and the diff and checkpoint surfaces the README describes are named for the IDE clients rather than for the headless CLI you would put in a pipeline. Before adopting it, check which of your own clients you run, because .clinerules is picked up by three of the five, and check which model provider you point it at, because that choice decides what executes your commands.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes