Bee
afab86dcbd
* fix(core): stop concurrent Hub installs from retiring each other Two Cline installations on different builds would shut each other's Hub daemon down in a loop, and every session died with an abnormal socket close (code=1006) as its daemon was killed mid-handshake. The retire decision was a one-sided predicate: each client independently asked "may I reuse this Hub?", and two clients on differing builds both answered no. #13177 added build-epoch ordering to break the tie, but left every unordered case - missing epoch, missing build id - retiring as before, so any pair involving a build from before epochs were embedded still looped. Derive the decision from a total order instead. compareHubBuilds orders two builds by embedded epoch, then core release version, then build id, and is antisymmetric by construction, so at most one side of a pair can ever decide to retire. A Hub that is newer or cannot be ordered is attached over the compatible wire protocol and left to the build-mismatch watcher to prompt about. Genuine protocol incompatibility still replaces. Identity is now read from the same fields on both sides. Filling in a coreVersion locally that the wire record omits made a build's identity depend on which role it was playing, and the two directions of a pair were then decided by different tiers with both concluding they were newer - a second, independent way to produce the loop. Also: - Scope the development Hub owner by build id, so differing dev builds run their own daemon side by side instead of contending for one record. Production keeps its singleton. - Break the circuit after repeated retirements of the same URL, bounding any future ordering bug to a stale-build prompt rather than an unusable Hub. - Report `cline doctor fix` honestly: separate processes that survived a kill from ones that appeared while the fix ran, name the live parent respawning a daemon, and mark a startup lock held by a running process as held rather than leaked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(cli): only blame a live parent for processes seen during doctor fix The advice printed under "started during fix" asserted that every such process was respawned by a live parent, and told the user to go stop it. A process can also start on its own mid-repair - someone opening a new session - and then the instruction points at an unrelated process, or at none at all. Derive the wording from whether a live parent actually exists: name it when every process has one, state the facts when none do, and split the list when it is mixed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * test(core): order the builds in the stale-discovery hub server case The case stubbed two build ids and expected the second to replace the first, but supplied nothing that says which came first: no epochs, and both servers report the same core version. Ordering therefore fell to the build-id tiebreak, where "new-build" sorts before "old-build" and the replacement was judged the older of the two. Give the case the epochs its name implies, and add the missing sibling for an unorderable pair, which is attached to rather than retired - the behavior that keeps two installations from shutting each other down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Cline
The open source coding agent in your IDE and terminal.
CLIRun Cline in your terminal. Interactive chat or fully headless for CI/CD and scripting. |
KanbanRun many agents in parallel from a web-based task board. Each card gets its own worktree, auto-commit, and dependency chains. |
VS Code ExtensionAI coding assistant in your editor. Create files, run commands, browse the web, and use tools with human-in-the-loop approval. |
JetBrains PluginThe same Cline experience in IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest of the JetBrains family. |
SDKBuild your own AI agents and integrations powered by the same engine that runs the CLI, Kanban, VS Code extension, and JetBrains plugin. Custom tools, multi-agent teams, connectors, scheduled automations, and more. |
Index
| Product | Description | Location | CHANGELOG |
|---|---|---|---|
| SDK | Node.js programmatic agent API and extension exports. | sdk/ |
CHANGELOG.md |
| CLI | Terminal UI, headless mode, shell commands, and CLI-specific flows. | apps/cli/ |
CHANGELOG.md |
| VS Code Extension | The Marketplace extension and extension host integration. | / (WIP migrating) |
CHANGELOG.md |
| JetBrains Plugin | JetBrains-hosted client that talks to the shared agent core. | Currently we are not open-sourcing JetBrains plugins | - |
| Kanban | Web-based multi-agent task board. | cline/kanban |
CHANGELOG.md |
| Docs site | Public documentation pages. | docs/ |
- |
Edits Code Across Your Project
Cline reads your project structure, understands the relationships between files, and makes coordinated changes across your codebase. It monitors linter and compiler errors as it works, fixing issues like missing imports, type mismatches, and syntax errors before you even see them. In VS Code and JetBrains, every edit shows up as a diff you can review, modify, or revert. All changes are tracked with checkpoints, so you can easily undo the agent's work.
Runs Bash Commands
Cline executes commands directly in your terminal and watches the output in real time. Install packages, run build scripts, execute tests, deploy applications, manage databases. For long-running processes like dev servers, Cline continues working in the background and reacts to new output as it appears, catching compile errors, test failures, and server crashes as they happen.
Plan and Act
Toggle between Plan mode and Act mode. In Plan mode, Cline explores your codebase, asks clarifying questions, and lays out a strategy. Once you're aligned, switch to Act mode and Cline executes the plan. Every file edit and terminal command requires your approval, so you stay in control of what actually changes. Or toggle auto-approve and let Cline run autonomously.
Rules and Skills
Define project-specific rules in .clinerules files that guide how Cline works in your codebase: coding standards, architecture conventions, deployment procedures, testing requirements. Rules are picked up automatically by the CLI, VS Code extension, and JetBrains plugin. Use skills to let the model load specific rules when needed.
Works With Every Model
Cline is not locked to a single AI provider. Use whichever model fits your workflow:
| Provider | Models |
|---|---|
| Anthropic | Claude Opus, Sonnet, Haiku |
| OpenAI | GPT series models |
| Gemini series models | |
| OpenRouter | 200+ models from any provider |
| Vercel AI Gateway | Route to many providers through one gateway |
| AWS Bedrock | Claude, Llama, and more |
| Azure / GCP Vertex | All hosted models |
| Cerebras / Groq | Fast inference models |
| Ollama / LM Studio | Run local models on your machine |
| Any OpenAI-compatible API | Self-hosted or third-party endpoints |
Extend With Plugins or MCP Servers
Extend Cline's capabilities with plugins. Using the SDK, register tools and lifecycle hooks programmatically through the plugin system for logging, auditing, policy enforcement, or adding domain-specific capabilities. Simple plugin example below.
import { Agent, createTool } from "@cline/sdk"
const deployTool = createTool({
name: "deploy",
description: "Deploy the current branch to staging.",
inputSchema: { type: "object", properties: { env: { type: "string" } }, required: ["env"] },
execute: async (input) => {
// your deployment logic
},
})
const agent = new Agent({ tools: [deployTool], /* ... */ })
...or use MCP servers to connect to databases, query APIs, manage cloud infrastructure, and interact with external systems. Use community-built servers or ask Cline to create custom tools on the fly. In the CLI, manage servers with cline mcp.
Multi-Agent Teams
Coordinate multiple agents working together on complex tasks. A coordinator agent breaks the work into subtasks and delegates to specialist agents, each with their own tools and context. Team state persists across sessions so you can pick up where you left off.
cline --team-name auth-sprint "Plan and implement user authentication with tests"
Scheduled Agents
Run agents on cron schedules for recurring automations. Daily PR summaries, weekly dependency checks, codebase health reports. Schedules persist across restarts and run independently of any terminal session.
cline schedule create "PR summary" \
--cron "0 9 * * MON-FRI" \
--prompt "List all open PRs and their review status" \
--workspace /path/to/repo
Connect to Slack, Telegram, Discord, and More
Chat with your agent from any messaging platform: Telegram, Slack, Discord, Google Chat, WhatsApp, and Linear. Each conversation thread maps to an agent session with full context. Set up access control to restrict who can interact with your agent.
# Connect to Telegram
cline connect telegram -k $BOT_TOKEN
# Connect to Slack through webhook
cline connect slack --bot-token $SLACK_TOKEN --signing-secret $SECRET --base-url $URL
# Connect to Slack using socket mode
cline connect slack --bot-token $SLACK_TOKEN --app-token $SLACK_APP_TOKEN
Headless CLI for CI/CD
Run Cline with zero interaction for scripting and automation. Pipe input, get JSON output, chain commands, integrate into CI/CD pipelines.
cline "Run tests and fix any failures"
git diff origin/main | cline "Review these changes for issues"
cline --json "List all TODO comments" | jq -r 'select(.type == "agent_event" and .event.text) | .event.text'
Contributing
Start with the Contributing Guide. Join our Discord and head to the #contributors channel to connect with other contributors. Check our careers page for full-time roles.