Running Cline in CI means switching off the approval gate it ships with

Cline asks for approval on every file edit and every terminal command until you turn on auto-approve ^[11]. In the editor, that gate is the product: edits arrive as reviewable diffs, and checkpoints let you undo the agent's work when a change goes wrong ^[8]. On a build agent there is nobody to click approve. The CLI is documented as running fully headless for scripts and CI/CD ^[3], and the automation example in the dev.to write-up is `git diff origin/main | cline "Review these changes for issues"` ^[19]. Run that with the default gate on and it waits forever. With the gate off, the diffs and the checkpoint history are records someone reads after the fact, if at all.

Portability across the four surfaces holds where the source is specific. Project conventions in `.clinerules` are picked up automatically by the CLI, the VS Code extension and the JetBrains plugin ^[12]. That list covers three of the four things Cline ships ^[2]. The fourth is the SDK, a Node.js package published as `@cline/sdk` ^[4], and what the write-up describes there is custom tools plus lifecycle hooks for logging, auditing and policy enforcement ^[15]. For a CI agent built on the SDK, an approval policy has to live in those hooks, and the hooks are yours to write.

Model routing puts the provider choice, and the spend, on the buyer. You bring your own API key ^[14] and point it at eleven named providers, plus a catch-all for any OpenAI-compatible endpoint ^[13][1]. Two of the eleven are Ollama and LM Studio, which run models locally ^[13]. A team that cannot send source code to a hosted provider still has a path, and it keeps the same `.clinerules` and the same MCP server connections as the hosted setup ^[12][16].

The write-up does not include measured results. 67,000 GitHub stars and 7,000 forks ^[6] are traction for a VS Code extension that began as Claude Dev ^[2]; how a headless run behaves against your test suite is a separate question. For the CI story to transfer in your shop, your tests have to be a strong enough acceptance gate that a wrong patch costs a re-run rather than a bad merge. And pull request review has to stay a human step, because the agent's own error-checking is aimed at linter and compiler output, missing imports and type mismatches ^[7].

Then there is scope. Cline runs build scripts, tests, deploys and database commands, and it keeps watching a long-running process such as a dev server, reacting to new errors as they appear ^[9]. Newer additions coordinate several agents on one task, with a coordinator delegating subtasks and state persisting across sessions, and agents can be put on a cron schedule for work like daily PR summaries ^[17].