Cline (Open-Source VS Code Extension) (AI IDE Platform Market Research)

1. Introduction

Cline represents the "open-source + human-in-the-loop" route within this group. It began as a VS Code extension and has since grown into an open-source agent runtime covering an editor extension, a terminal CLI, an SDK, and a multi-agent Kanban board (officially described as "One open source agent runtime"), released under the Apache 2.0 license and supporting 30+ model providers and any OpenAI-compatible endpoint.

Cline's design bet can be summarized in one sentence from its upstream documentation: the autonomous loop is trustworthy precisely because a human sits inside the loop, not after it. Every file edit and every terminal command requires human approval by default — when the user stops approving, the loop stops, and there is no autonomous path around a rejected action. Under this group's Harness six-layer framework, this means Cline elevates L6 (governance and security) from an "add-on mechanism of the platform" to the "mode of existence of the product": it has neither Cursor's sandbox system nor Claude Code's managed policies, but its per-gate approval model forces any privilege-escalating action to pass through a human decision point that cannot be persuaded by the model. This is both why it has been adopted by many individual developers and small teams (transparent, controllable, model-agnostic) and why its ceiling is limited in unattended scenarios.

1.1. Developer and Product History

1.2. Positioning and Latest Version

Cline's official positioning is an "open-source coding agent runtime": the same engine drives four hosts — IDE extension, CLI, Kanban, and SDK — "running in your editor, your terminal, or your own product." Its key differences from commercial IDEs are threefold: model-agnostic (Claude, GPT, Gemini, local Ollama / LM Studio, any OpenAI-compatible endpoint, BYOK or BYO weights); per-approval human-in-the-loop; and fully open-source and auditable (including the shadow Git repository used for checkpoints).

The latest version is the v3.8x series (third-party 2026 figure: v3.81); the exact current version is recorded as [To be filled].

1.3. Business Model and Pricing

Cline itself is completely free with no subscription tier (official FAQ: "there is no Cline Pro subscription — the model is open source + pay-per-use"):

Engineering implication of the billing structure: cost and risk both fall back between the user and the model providers, and the Cline platform itself introduces no additional credit abstraction; the tradeoff is that "cost predictability" depends on the user's understanding of each provider's pricing, and organization-level cost governance tooling does not exist in the open-source edition.

2. Terminology

3. Feature Overview

3.1. In-Editor Capabilities

3.2. Multi-Form Product Line

• VS Code extension: the primary form; a side-panel agent UI.
• JetBrains plugin: the same experience covers IntelliJ IDEA, PyCharm, WebStorm, GoLand, and more.
• CLI: npm i -g cline, for interactive sessions or fully headless mode, suitable for cron, CI / CD, and scripts; cline auth authorizes via browser; cline mcp manages MCP servers. macOS / Linux preview; Windows is on the roadmap.
• SDK: npm install @cline/sdk to programmatically build agents and integrations, registering custom tools, multi-agent teams, connectors, and scheduled automation.
• Kanban: npm i -g kanban; a web-based multi-agent task board where each card has its own worktree, auto-commit, and dependency chain, allowing multiple agents to run in parallel.
• Collaboration and automation integration: converse with agents in Slack, Discord, Telegram, and Linear; run headless in pipelines such as GitHub Actions and GitLab.
• ACP: integrates with Zed and Neovim as an ACP-compatible agent.

3.3. Model Integration

The official FAQ recommends Claude Sonnet 4.6, GPT-5.3 Codex, and Gemini Pro 3.1 as the priority for coding scenarios (2026-09 official figures). This model-agnosticism makes Cline a common open-source base for integrating domestic models into AI coding workflows — in contrast with the domestic-model track of entry 07, CodeBuddy, in this group, forming an "open-source BYOK" vs. "commercial integration" comparison.

4. Platform Architecture

图 4-1｜Cline 平台总体架构：同一核心驱动六种宿主，逐门禁审批贯穿全程

数据来源：基于本文分析绘制的示意图。

4.1. Overall Architecture

4.2. Agent Loop and Tool Registry

Cline's loop is a dual-mode ReAct: a user task enters Plan mode (read-only toolset: read_file, list_files, search_files, list_code_definition_names, plan_mode_respond) to produce a strategy and clarifying questions; the user manually switches to Act mode (full toolset: write_to_file, replace_in_file, apply_patch, execute_command, browser_action, MCP tools), where each mutating action passes through the approval gate, is executed, observed, and fixed, finally submitting results via attempt_completion. Three structural facts are worth emphasizing:

1. Mode switching is a human action: there is no autonomous model exit from Plan to Act, which upgrades "align first, then act" from a prompt convention to a state-machine constraint.
2. Condensing is a tool: condense and summarize_task are members of the default tool enumeration, so condensing history is an action the agent can see and proactively execute — context management is brought into the agent's action space rather than being a purely host-side behavior.
3. Rejection terminates: since every mutating action passes through the approval gate, stopping approval physically stops the loop; the system prompt is assembled per tool in modules (one source file per tool), so approval semantics and prompt semantics share the same origin.

5. Harness Design

5.1. L1 Context Engineering Layer

• .clinerules: project-level rules supporting single-file or directory forms, covering coding standards, architecture conventions, deployment flows, and testing requirements; auto-picked up by the CLI, the VS Code extension, and the JetBrains plugin, and versioned with and shared across the team. This is Cline's primary L1 contract — this group's tasks define .clinerules as a "project-level contract," whose precise meaning is: here the rules file is not an option but a prerequisite for the workflow, and carrying rules in the repo is the officially recommended project-initialization action.
• Skills: rule sets loaded on demand, so rules need not all live permanently in context.
• @ file references: explicitly specify editing targets via @index.js or relative paths.
• Focus Chain: a to-do list maintained across long tasks to counter direction drift in long sessions.
• Two-track condensing: condense / summarize_task as tools (which the model can actively call) plus host-side history management, giving the model an extra layer of initiative over most platforms' "purely background condensing."
• Gap: no repo-wide vector index / semantic retrieval mechanism (codebase understanding relies mainly on exploratory tools expanding layer by layer), so cold-start context efficiency on large monorepos is lower than Cursor / Windsurf's indexing systems; marked as an information gap.

5.2. L2 Tools and Execution Layer

• File tools: three edit formats (whole-file / targeted replace / patch) coexist, all presented as diffs for approval; linter and compiler errors are automatically monitored and fed back as fixes.
• Execution tools: execute_command runs commands in the integrated terminal, reads streams in real time, and keeps reacting to long-running processes.
• Browser tools: browser_action drives a real browser, and is one of the few VS Code plugin-style agents that build browser capability in as a standard tool.
• MCP: managed via Marketplace + the cline mcp CLI; community servers can cover databases, APIs, and cloud infrastructure; "have Cline write a custom tool on the spot" is an officially supported workflow.
• Sandbox: no built-in OS-level sandbox. Execution isolation relies entirely on: (a) the approval gate (the default tier); (b) disposable containers / VMs provided by the user (both official and community advice for full-auto mode points to "disposable environments only"). This is a notable gap versus Codex CLI (with native Seatbelt / Landlock binding).

5.3. L3 Orchestration and Control Layer

• Plan / Act dual modes are Cline's orchestration signature: it turns "planning" into a read-only, sandboxed dialogue phase and "execution" into a per-approval sequence of actions, with the boundary between them controlled by the human.
• Task derivation: the new_task tool derives new tasks; use_subagents dispatches sub-agents (read-only category); use_skill loads skills.
• Multi-agent teams: the orchestrator decomposes tasks and dispatches them to specialist agents with independent tools and context; team state persists across sessions.
• Kanban: card-level worktree isolation + auto-commit + dependency chains, turning parallel multi-agents into a visual task board.
• Headless orchestration: CLI headless mode + cron + CI (GitHub Actions / GitLab) + Slack / Linear triggers form a scheduled and event-driven orchestration surface. Notably: in headless scenarios "per-approval" degenerates into "auto-approve + preset whitelist," so orchestration capability and governance constraints must be explicitly reconfigured.

5.4. L4 Memory and State Layer

The checkpoint system is Cline's L4 core and the most "engineered" tier in this group:

• Implementation mechanism: a shadow Git repository running in parallel with the user's Git repo, auto-committing workspace snapshots at tool-call granularity (rather than per prompt turn); file writes, terminal commands, and browser actions each form a checkpoint.
• Capability surface: restore to any checkpoint (rolling back both workspace and task state); diff between any two checkpoints (CompareCheckpointResult); the restore action itself is recorded into history as metadata (createRestoredCheckpointMetadata).
• Key property: fully parallel to the user's commit history with no cross-pollution; the shadow repo itself is auditable (open source, so its behavior can be inspected).
• Design significance: the approval model is responsible for "pre-action interception" and checkpoints for "post-action recovery" — together they downgrade "what if the Agent broke something" from an incident to a single rollback operation. This is a typical sample of L6 and L4 cooperation: a permissive execution environment (no sandbox) is viable because the state layer provides complete undo capability.
• Remaining state: task history is saved across sessions and supports recovery; team state is persistent; .clinerules and knowledge files serve as cross-session file-based memory. There is no independent automatic long-term memory (auto memory) mechanism, marked "no result."

5.5. L5 Evaluation and Observability Layer

• Trajectory is the interaction stream: every model call, tool call, approval decision, and result is visible to the user as a dialogue stream — Cline has no separate trace panel, but the readability of its trajectory is among the best in its class, because the approval interaction itself is the item-by-item display of the trajectory.
• Mechanical feedback loop: linter / compiler errors are automatically monitored and fixed, and a test-fix loop is built in.
• Cost observability: third-party figures put a single task around $0.01~$0.10 (); Cline Provider side has credit metering; in BYOK scenarios, cost observability depends on each provider's console.
• Gap: no built-in benchmark evaluation, no regression suite, no trajectory export API (the SDK layer has an event system), so organization-level quality measurement requires external CI and evaluation tools; marked "no result."

5.6. L6 Governance and Security Layer

L6 is where Cline's identity lives; let's break it down mechanism by mechanism:

A structural weakness that must be honestly recorded (third-party security-analysis scope): the approval model is advisory, not enforceable — faced with a carefully crafted prompt injection, the model may reinterpret or bypass permission rules; the approval gate runs inside the extension process with no OS-level isolation as a fallback. Third-party analyses therefore consistently recommend that high-security environments layer the approval gate with OS-level sandboxing (the Codex CLI model) or cloud isolation (disposable containers). This is consistent with this group's README security-baseline judgment: approval is one of the guardrails; it cannot be the only guardrail. Compared with the Amazon Q incident (2025-08-11), Cline's approve-everything default is the most conservative default against the prompt-injection surface among similar tools, but the exposure after "enabling auto-approve" is identical to any platform without a sandbox.

No unattended tier: Cline has no official one-click bypass-all tier (the third-party yoloMode is a community-configuration naming); full automation must be achieved by checking off per-category auto-approve, and official best practice explicitly recommends keeping edit categories disabled. This "friction-by-design" is a direct expression of the product's values.

5.7. Six-Layer Capability Summary

6. Real-World Cases

This retrieval did not obtain official enterprise adoption cases with quantified metrics released by Cline, honestly recorded as "no public quantitative data found." Available alternative evidence:

1. Adoption scale (official scope, 2026-09 retrieval): 8.0M+ cross-platform installs, 67.5k GitHub stars, 250+ contributors. Third-party 2026 figures (5M+ installs, 61.2k stars) show a steep growth curve.
2. Scenario-based use cases (official site and docs): cooperative refactoring of large codebases (keeping imports and types consistent), CLI scheduled tasks and CI checks, async task handling integrated with Slack / Linear, SDK embedding into one's own product, and Kanban multi-agent parallel development.
3. Security research reference: Cline's approval and checkpoint mechanisms are frequently cited samples in third-party coding-agent security analyses (such as security comparison matrix studies) — as a typical implementation of the "human-in-the-loop guard" route, compared side by side with Codex CLI's "OS sandbox" route and Warp's "cloud isolation" route. That it is repeatedly cited itself speaks to the research value of this route.

The scenario-based use cases above are descriptive uses of product capabilities, not independently verified effectiveness data; when citing them, avoid presenting them as quantified outcomes.

7. Summary

Strengths:

1. L6's conservative defaults are a genuine differentiator: approve-everything by default + a mode state machine + human verification of completion make the "privilege-escalation risk under default configuration" the lowest in its class; it suits developers and teams with a strong demand to "see every change the AI makes with their own eyes."
2. The checkpoint system is complete: tool-call-granularity shadow Git snapshots + arbitrary rollback + two-point diffs downgrade execution risk from irreversible to reversible; together with the approval gate, they form a two-layer "pre-action + post-action" defense.
3. Complete model and data autonomy: 30+ providers + local models + Apache 2.0 auditable make it one of the lowest-friction open-source bases for integrating domestic models, intranet deployment, and compliance-audit scenarios.
4. Complete form spectrum: IDE, CLI, SDK, Kanban, and ACP cover a continuous spectrum from interactive to unattended, all sharing the same core.

Limits:

1. No sandbox as a fallback: approval is an advisory line of defense, so against prompt injection and full-auto configuration the exposure equals an non-isolated platform; high-security environments must add containers / VMs themselves.
2. Limited throughput ceiling: the per-approval default rhythm produces significant interaction overhead in long tasks (this is precisely its design goal, but for throughput-sensitive teams it is a real cost); no repo-wide index makes cold-start slower on large repos.
3. L5 gap: no benchmark, no regression, no trajectory export; effectiveness evaluation is entirely external.
4. Weak organizational capabilities: the open-source edition has no RBAC, audit export, or centralized billing, and Enterprise capabilities and pricing are not public ([To be filled]).

Applicability boundary and selection advice: for individual developers and teams of 3~20, BYOK access to any model (especially domestic models), and scenarios that want agent capability in an existing VS Code / JetBrains environment at minimal cost, Cline is currently one of the best open-source choices; for compliance-culture teams that require explicit approval for every AI action (financial, medical internal R&D tool evaluation phases), its defaults happen to match the requirement. For unattended batch tasks and scenarios requiring OS-level sandboxing and organizational governance, Codex CLI (sandboxing + orthogonal approval) or the Enterprise tier of commercial platforms fits better; fully-managed teams pursuing editor experience and repo-wide indexing will find Cursor / Windsurf more mature. For rollout, follow its official best practice: auto-approve only project-file reads, set the max request count to 10~20, keep edits and commands under manual approval, and relax progressively once trust is established — this "trust gradual curve" is itself an executable L6 strategy.

Information Gap Statement

1. Current version number: the latest stable version is not public on official retrieval pages (third-party 2026 figure: v3.81), marked [To be filled].
2. Scale-figure scope: the 8.0M+ installs / 67.5k stars are the official site's 2026-09 scope, which differs in retrieval time from the third-party mid-2026 figures (5M+ / 61.2k); note the retrieval date when citing.
3. Single-task cost: the typical $0.01~$0.10 is a third-party figure, marked [To be verified].
4. Advanced configs such as yoloMode: from third-party analysis, not an official recommended configuration, marked [To be verified].
5. Enterprise capabilities and pricing: the official site has an Enterprise entry but no public feature list or pricing, marked [To be filled].
6. SDK event system: whether the SDK layer provides a trajectory export API has not been verified item by item, marked [To be verified].
7. Quantified enterprise cases: no independently verified effectiveness data found; recorded as "no result."
8. JetBrains plugin open-source scope: the official README states the JetBrains plugin is currently not open source, differing from the open-source scope of the other forms; confirm the licensing boundary before use.

8. References

1. Cline official site — Cline Bot Inc., 2026. https://cline.bot/
2. Cline GitHub repository — Cline Bot Inc., 2024–2026. https://github.com/cline/cline
3. Cline Frequently Asked Questions — Cline official FAQ, 2026. https://cline.bot/faq
4. Cline official documentation — Cline Bot Inc., 2025–2026. https://docs.cline.bot/
5. Cline for VS Code: Free AI Coding Agent Setup Guide — DeployHQ, 2026 (third party). https://www.deployhq.com/guides/cline
6. Safety and Control — DeepWiki's structured analysis of cline/cline, 2026 (third party). https://deepwiki.com/cline/cline/10-safety-and-control
7. Cline Field Guide — Chimera project's code-level analysis of Cline's loop and tool registry, 2026 (third party). https://0bserver07.github.io/chimera/field-guide/cline
8. Part 2: Hooks, MCP & Security (coding-agent security comparison study) — maxpool.dev, 2026 (third party). http://maxpool.dev/research-papers/coding_agents_extensions.html
9. Cline — Visual Studio Marketplace (extension ID: saoudrizwan.claude-dev), 2024–2026. https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev
10. cline — npm, 2025–2026. https://www.npmjs.com/package/cline