Compare commits

...

70 Commits

Author SHA1 Message Date
github-actions[bot] 7c782abaf4 Changeset version bump (#9364)
* changeset version bump

* Updating CHANGELOG.md format

* update package versions

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: Max Paulus 🥪 <max@cline.bot>
2026-02-18 12:22:53 -08:00
Ara 3a14a88f4f fix: include root workspace for changesets release (#9393) 2026-02-18 11:40:02 -08:00
Saoud Rizwan 28d60a83a4 fix(models): keep Sonnet 4.5 as default for now (#9389)
* fix(models): keep Sonnet 4.5 as default

* chore(changeset): add release note for Sonnet 4.5 default

* fix(models): remove Sonnet 4.6 from curated model lists

* fix(models): restore Sonnet 4.6 in web recommended list
2026-02-18 10:53:07 -08:00
Saoud Rizwan ae6468b161 fix(models): reinstate minimax m2.5 free promo surfaces (#9387) 2026-02-18 10:28:54 -08:00
Saoud Rizwan af93e31862 feat(models): make sonnet 4.6 default and remove free promo positioning (#9377) 2026-02-18 10:07:20 -08:00
Tomás Barreiro ca154eb8f5 Add MiniMax M2.5 to the MiniMax provider (#9381)
* Add MiniMax M2.5 to the MiniMax provider

* Add changeset

* Update default model
2026-02-18 09:16:23 -08:00
Tomás Barreiro 1d8497c6bf Prevent error messages when displaying featured models in the CLI (#9379)
* Fix the featured models key

* Add changeset
2026-02-18 16:51:29 +01:00
Seb Duerr 5871fd02b1 feat(cerebras): remove deprecated llama-3.3-70b and qwen-3-32b models (#9345)
* feat(cerebras): remove deprecated llama-3.3-70b and qwen-3-32b models

These models have been deprecated from the Cerebras inference platform.

- Remove llama-3.3-70b and qwen-3-32b from cerebrasModels in api.ts
- Update supported models documentation in cerebras.mdx
- Add changeset for the deprecation

* fix: remove stale llama-3.3-70b and qwen-3-32b references from rate limits

Remove dead switch cases in getRateLimits() that referenced deprecated models
no longer present in cerebrasModels.
2026-02-17 23:39:38 -08:00
alex-lum 2d81c310d2 Alex/inf 413 bug no telemetry for versions greater than 20 (#9372) 2026-02-17 18:55:07 -08:00
Robin Newhouse 0c691f72d2 feat(cli): add /skills slash command (#9089)
* feat(cli): add /skills slash command for managing skills

- Add /skills to CLI_ONLY_COMMANDS in slashCommands.ts
- Create SkillsPanelContent component with:
  - Display global and workspace skills with toggle indicators
  - Enter to use skill (inserts @path into input)
  - Space to toggle skill enabled/disabled
  - Selectable marketplace link to skills.sh
  - Keyboard navigation with arrow keys and vim keys
- Wire up panel in ChatView.tsx
- Add comprehensive tests for keyboard interactions

* refactor(cli): use static skill controller imports

* fix(cli): add React import to skills panel test

* fix(cli): suppress required React import lint in skills test

* fix(cli): harden /skills panel interactions

Revert optimistic skill toggle state when persistence fails, and surface a fallback URL when opening the marketplace fails. Also tighten and extend tests to verify exact marketplace URL handling and rollback behavior.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-17 17:13:51 -08:00
Robin Newhouse a8409137b3 fix: disable click-to-set auto-condense threshold and hardcode default (#9348)
* fix: disable click-to-set auto-condense threshold and hardcode default

Clicking anywhere on the context window progress bar silently set
autoCondenseThreshold to a value based on click position (e.g. 0.05),
persisting in globalState. This caused compaction to fire at ~10K tokens
instead of the intended ~150K, resulting in ~20 context resets per task.

- Comment out click and keyboard handlers on progress bar (keep components
  for future release with proper UX)
- Hardcode threshold to 0.75 default, ignoring corrupted stored values

Co-authored-by: Cursor <cursoragent@cursor.com>

* test: add shouldCompactContextWindow unit tests

Cover threshold math including the accidental low-threshold bug case,
undefined/zero fallbacks, cache token inclusion, and maxAllowedSize cap.

Co-authored-by: Cursor <cursoragent@cursor.com>

* fix: hardcode autoCondenseThreshold in all remaining callsites

Address Greptile review: SubagentRunner.ts, task/index.ts display
logic, and controller/index.ts webview state all still read the
corrupted value from globalState. Hardcode 0.75 everywhere.

Co-authored-by: Cursor <cursoragent@cursor.com>

* style: remove unnecessary union type on hardcoded threshold

Drop `number | undefined` annotation from the hardcoded 0.75 literal
in SubagentRunner.ts per Greptile review feedback.

Co-authored-by: Cursor <cursoragent@cursor.com>

* refactor: use SETTINGS_DEFAULTS constant, remove commented-out code, clarify test

- Replace hardcoded 0.75 with SETTINGS_DEFAULTS.autoCondenseThreshold
  across all 4 callsites for a single source of truth
- Delete commented-out click/keyboard handlers in ContextWindow.tsx,
  replace with TODO referencing PR #9348
- Make bug-case test self-documenting by deriving token values from
  the threshold calculation

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-17 16:32:13 -08:00
Saoud Rizwan 34a21b8e26 docs: add security policy (#9365) 2026-02-17 16:00:01 -08:00
ClineXDiego eb9f53edf4 fix: smarter retry for write_to_file missing content parameter (#9276)
* fix: smarter retry for write_to_file missing content parameter (#7998)

Replace generic 'missing parameter' error with progressive guidance when
write_to_file fails due to empty content parameter. This breaks the
infinite retry loop where the model repeatedly attempts the same
write_to_file call that exceeds output token limits.

Changes:
- Add writeToFileMissingContentError() to formatResponse with 3 tiers:
  1st failure: suggestions (use skeleton + replace_in_file)
  2nd failure: strong directive (stop retrying write_to_file)
  3rd+ failure: CRITICAL stop, forces alternative strategies
- Add context window awareness: warns model when >50% context used
- Add getContextUsagePercent() helper to WriteToFileToolHandler
- Add 22 unit tests covering progressive escalation and context awareness

Fixes #7998

* add changeset for write_to_file retry fix

* refactor: simplify write_to_file error handling per review

- Simplify writeToFileMissingContentError to single-tier error following
  existing diffError pattern (no progressive escalation)
- Use shared getLastApiReqTotalTokens() for context window awareness
- Remove private getContextUsagePercent() method from handler
- Add proactive skeleton + replace_in_file guidance to write_to_file
  tool description for all variants
- Simplify tests to match new API (11 tests)

* test: update system prompt snapshots

* chore: revert write_to_file prompt guidance

* feat: restore progressive 3-tier guidance for write_to_file missing content

Restore the progressive escalation that was removed in dd3c12d4e:
- Tier 1 (1st failure): Gentle suggestions (skeleton + replace_in_file)
- Tier 2 (2nd failure): Strong directive, 'Do NOT attempt full write again'
- Tier 3 (3rd+ failure): CRITICAL stop, forces alternative strategies
- Context window warning when >50% full
- Dynamic UI message: 'Retrying...' vs 'multiple times — different approach'
- 21 tests covering all tiers and context awareness

* nit: extract context window warning threshold to named constant

Also replace emoji with plain text in warning message for consistency.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Robin Newhouse <robin@cline.bot>
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-17 19:08:42 -03:00
github-actions[bot] c60f18d907 Adding 1m (#9346)
Co-authored-by: Arafatkatze <arafat.da.khan@gmail.com>
2026-02-17 11:11:54 -08:00
Saoud Rizwan 36c68a6ab9 fix: remove expired MiniMax free promo surfaces (#9361)
* fix: remove expired MiniMax free promo surfaces

* fix: remove MiniMax M2.5 from recommended models

* chore: update GLM 5 whats-new promo wording
2026-02-17 10:57:19 -08:00
Saoud Rizwan 80dfce0f60 docs: remove stale Claude 5 mention from Auto Compact docs (#9360)
* docs: remove stale Claude 5 wording from auto compact docs

* Remove stale Claude 5 mention from docs
2026-02-17 10:48:23 -08:00
Saoud Rizwan 955ae2f62f feat: add Claude Sonnet 4.6 support and surface it as free (#9356)
* feat: add Sonnet 5 support and make it default across surfaces

* feat: surface Sonnet 5 as free while keeping Sonnet 4.5 defaults

* fix: rename Sonnet 5 support to Sonnet 4.6 across providers and UI

* fix: allow duplicate onboarding model ids across free and frontier

* chore: update Sonnet 4.6 banner to limited-time free messaging

* fix: align Bedrock Sonnet 4.6 model ids with AWS format

* feat: update whats new promo to Sonnet 4.6 free offer

* chore: update Sonnet 4.6 promo copy and timing
2026-02-17 10:43:24 -08:00
Dominic Cooney 8cb0c6d236 Fix e2e tests. (#9350) 2026-02-17 15:06:40 +09:00
github-actions[bot] bb05b2f7b0 changeset version bump (#9316)
Updating CHANGELOG.md format

update changelog

update banner and bump version

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-02-16 12:46:01 -08:00
alex-lum 1a911f4232 fix(telemetry): refresh OTEL org attributes on identify (#9318)
* fix(telemetry): refresh OTEL user/org attributes on every identify

* fix(telemetry): refresh OTEL user/org attributes on every identify

* test(telemetry): cover OTEL identifyUser org refresh scenarios

* refactor(telemetry): rename member_roles to member_role (singular)

* Apply suggestion from @BarreiroT

simpler commenting

Co-authored-by: Tomás Barreiro <52393857+BarreiroT@users.noreply.github.com>

* removing verbose comments

/**
 * Helper to build a ClineAccountUserInfo with an active organization.
 */

* removing verbose comments

* removing unnecessary logger

* assert -> chai expect

---------

Co-authored-by: Tomás Barreiro <52393857+BarreiroT@users.noreply.github.com>
2026-02-16 12:45:31 -08:00
Ara 1cfd560921 feat(cline): add z-ai/glm-5 to free model recommendations (#9341)
* feat: add z-ai/glm-5 to free models list

Include Z.AI's GLM 5 in the free model whitelist for zero-cost usage
and update the model picker UI to display the free label.

* Adding thinking

* Adding thinking

* Adding thinking
2026-02-16 11:59:09 -08:00
Juan Pablo Flores 203ff8f549 docs: enrich Quick Start guide with more context for new users (#9338)
* docs: enrich Quick Start guide with more context for new users

* docs: add Antigravity to full installation guide
2026-02-16 09:00:50 -08:00
Saoud Rizwan e920f1de02 fix(chat): keep reasoning visible before low-stakes tool groups (#9335)
* fix(chat): keep reasoning visible before low-stakes tool groups

* chore(changeset): add patch note for tool-group reasoning visibility

* fix(chat): keep thinking loader visibility aligned with waiting states

* fix(chat): avoid clipping descenders in thinking label
2026-02-15 17:14:41 -08:00
Saoud Rizwan b266475d0a fix(chat): prevent partial row churn during native tool arg streaming (#9334)
* fix(chat): prevent partial text flicker during native tool streaming

* fix(chat): revert act mode partial dedupe change
2026-02-15 15:40:54 -08:00
Saoud Rizwan 402361c482 fix(chat): restore reasoning traces and polish thinking UX (#9330)
* fix(chat): restore reasoning traces and polish thinking UX

* chore(changeset): add patch note for reasoning trace UX fixes
2026-02-15 01:19:59 -08:00
Renee Huang e884699d24 New Cline Docs (#9280)
* only doc changes

* merge

* fix installtion page redirects

* fix redirect, remove unused parts

* rm irrelevant info

* clean up terminal guides

* docs: add home page and reorganize navigation

* chore: remove 71 unused docs files not referenced in navigation

Remove .mdx files that are no longer referenced in docs.json navigation
and only existed as stale content from previous documentation restructuring.
These files were either completely orphaned or only served as redirect
source pages (Mintlify handles redirects at the routing level without
needing the source file to exist).

Updated docs.json redirects that previously pointed to archive/ pages
to point to current equivalents instead:
  - /archive/understanding-context-management → /model-config/context-windows
  - /archive/prompt-engineering-guide → /customization/cline-rules
  - /archive/telemetry → /enterprise-solutions/monitoring/telemetry

Deleted files by category:

Archive (entire directory removed):
  - archive/prompt-engineering-guide.mdx
  - archive/telemetry.mdx
  - archive/understanding-context-management.mdx

Cline CLI:
  - cline-cli/cli-reference-deprecated.mdx

Enterprise Solutions (16 files):
  - enterprise-solutions/bundled-endpoints.mdx
  - enterprise-solutions/configuration/overview.mdx
  - enterprise-solutions/configuration/choosing-your-deployment.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/rules.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/workflows.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/mcp/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/providers/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/providers/custom.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex/overview.mdx
  - enterprise-solutions/configuration/infrastructure-configuration/providers/litellm/overview.mdx
  - enterprise-solutions/monitoring/opentelemetry_override.mdx

Exploring Cline's Tools (entire directory removed):
  - exploring-clines-tools/cline-tools-guide.mdx
  - exploring-clines-tools/new-task-tool.mdx
  - exploring-clines-tools/remote-browser-support.mdx

Features — old pages consolidated into core-workflows/ and customization/ (37 files):
  - features/checkpoints.mdx
  - features/drag-and-drop.mdx
  - features/editing-messages.mdx
  - features/explain-changes.mdx
  - features/skills.mdx
  - features/yolo-mode.mdx
  - features/at-mentions/ (7 files — all consolidated into core-workflows/working-with-files)
  - features/cline-rules/ (2 files — consolidated into customization/cline-rules)
  - features/commands-and-shortcuts/ (5 files — consolidated into core-workflows/using-commands)
  - features/customization/ (2 files)
  - features/hooks/ (3 files — consolidated into customization/hooks)
  - features/slash-commands/ (7 files)
  - features/slash-commands/workflows/ (3 files — consolidated into customization/workflows)
  - features/tasks/ (2 files — consolidated into core-workflows/task-management)

Introduction (entire directory removed):
  - introduction/overview.mdx
  - introduction/welcome.mdx

MCP:
  - mcp/adding-mcp-servers-from-github.mdx
  - mcp/configuring-mcp-servers.mdx

More Info (entire directory removed):
  - more-info/telemetry.mdx

Prompting (entire directory removed):
  - prompting/cline-memory-bank.mdx
  - prompting/prompt-engineering-guide.mdx
  - prompting/understanding-context-management.mdx

Provider Config:
  - provider-config/fireworks-ai.mdx
  - provider-config/ollama.mdx

Getting Started:
  - getting-started/selecting-your-model.mdx

Total: 71 files deleted, 12,344 lines removed.

* docs: update and add documentation pages

* revert unintended formatting changes to src files

* new first project docs

---------

Co-authored-by: Juan Pablo Flores <juan@cline.bot>
2026-02-14 22:02:22 -08:00
Saoud Rizwan f59d950ac6 fix: open Cline sidebar for task deeplinks (#9320)
* fix: open Cline sidebar for task deeplinks

* refactor: share task URI path constant
2026-02-14 01:15:13 -08:00
Ara d2e4f1c7b9 feat(zai): add glm-5 pricing and make it default (#9253) 2026-02-13 20:42:49 -08:00
Ara 49975fd0a3 feat(cli): support Moonshot provider across CLI flows (#9314)
* feat(cli): add moonshot provider support across CLI flows

* Update cli/man/cline.1

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2026-02-13 16:10:10 -08:00
shey-cline c0020e10b1 Allow Custom AWS Regions in Bedrock (CLI) (#9103)
* init

* changeset

* prevent regoinIndex = -1 when navigating with arrow keys while filteredRegions.length = 0

* refactor

* content fix
2026-02-13 15:46:36 -08:00
Ara 8dc5e15ee0 chore: bump version to 3.62.0 (#9313) 2026-02-13 15:13:36 -08:00
github-actions[bot] 276cb4c3a4 Changeset version bump (#9312)
* changeset version bump

* v3.62.0 Release Notes

- Banners now display immediately when opening the extension instead of requiring user interaction first
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions <github-actions@github.com>
2026-02-13 14:24:54 -08:00
Saoud Rizwan 8169abbc74 fix(e2e): stabilize banner and code action assertions (#9311) 2026-02-13 14:11:55 -08:00
Ara a47ad46824 fix: rename package from "claude-dev" to "cline" in changesets (#9309)
Update changeset metadata files to use the correct package name
"cline" instead of the legacy "claude-dev" identifier.
2026-02-13 14:08:57 -08:00
Saoud Rizwan 7896e6d896 feat: promote MiniMax M2.5 in top banner and route CTA to free tab (#9307)
* feat: add minimax promo banner and free-tab model routing

* Add changeset for promoting MiniMax M2.5
2026-02-13 13:20:22 -08:00
aikido-autofix[bot] 166ec38d26 fix(security): update dependencies (#9234)
Co-authored-by: aikido-autofix[bot] <119856028+aikido-autofix[bot]@users.noreply.github.com>
2026-02-13 12:42:06 -08:00
Tomás Barreiro e44ea9d772 Post state to webview after fetching the banners (#9306)
* Post state to webview after fetching

* Test post state to webview is called

* refactors
2026-02-13 21:18:32 +01:00
Ara fcca1d4fe3 v3.61.0 Release Notes (#9305) 2026-02-13 10:35:16 -08:00
github-actions[bot] 34f0795217 v3.60.0 Release Notes (#9274)
- Fixes for Minimax model family
- Fixes for Response chaining for OpenAI's Responses API

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-02-13 09:02:46 -08:00
Bee 0648ed42b2 feat: make response ID chaining configurable (#9285)
Add an optional `usePreviousResponseId` flag to
`convertToOpenAIResponsesInput` and gate previous assistant-response
lookup behind it.

This makes response chaining opt-in instead of always-on, so providers
can control whether to continue from the latest stored OpenAI response
ID.feat(openai): make response ID chaining configurable

Add an optional `usePreviousResponseId` flag to
`convertToOpenAIResponsesInput` and gate previous assistant-response
lookup behind it.

This makes response chaining opt-in instead of always-on, so providers
can control whether to continue from the latest stored OpenAI response
ID.
2026-02-13 08:40:02 -08:00
Saoud Rizwan f32dde2c16 chore: update codex environment config 2026-02-13 04:17:07 -08:00
Saoud Rizwan 605c497eaf chore: update codex environment config 2026-02-13 04:14:22 -08:00
Saoud Rizwan a8322eec44 fix(task): avoid duplicate partial text from reentrant presentation (#9302) 2026-02-13 03:47:56 -08:00
Saoud Rizwan 974a7a748a fix(webview): add spacing before ask followup options 2026-02-13 02:31:14 -08:00
Saoud Rizwan fb2d092301 fix(hooks): preserve streaming tool rows in combineHookSequences (#9301) 2026-02-13 02:10:27 -08:00
Saoud Rizwan 45b3eb4833 fix(chat): stabilize tool-group text and thinking footer behavior (#9300)
* fix(chat): ignore streamed text after tool group starts

* fix(chat): suppress thinking during ask and completion handoff

* fix(chat): prevent thinking footer shimmer remount flicker
2026-02-13 02:03:32 -08:00
Bee a5048189e5 fix: remove focused BannerService test to run full suite (#9299)
The unit test suite currenlt is running the BannerService tests only when it should run the full suite.
Also update package-lock.json that wentout of sync.
2026-02-13 01:08:30 -08:00
Saoud Rizwan 897e842eb4 fix(task): ignore interleaved reasoning UI after text starts (#9298) 2026-02-13 00:25:08 -08:00
Saoud Rizwan 0389d4de07 Revert "fix(task): prevent duplicate streamed text rows after completion (#9235)" (#9297)
This reverts commit b514f18e4f.
2026-02-13 00:20:33 -08:00
Saoud Rizwan d99eec15d8 fix(minimax): emit single reasoning chunk on thinking start (#9290) 2026-02-12 23:46:53 -08:00
Ara 98ed009e69 fix: add missing name fields to free featured models and improve type safety (#9291)
- Add `name` property to minimax, kat-coder-pro, and trinity-large-preview
  models that were previously missing it
- Move type annotation from `as FeaturedModel[]` casts to the variable
  declaration for proper type checking at assignment time
- Add test to verify all featured models include a display name
2026-02-12 23:18:51 -08:00
Saoud Rizwan 8fb7b94297 Revert "Jose/thinking and flicker fix (#9148)" (#9292)
This reverts commit d8397c71b2.
2026-02-12 22:54:07 -08:00
Jose R. Perez d8397c71b2 Jose/thinking and flicker fix (#9148)
* feat: persistant thinking loader at bottom of stream during any cline activity with no visual feedback

* feat: thinking and flicker fix

* refactor: remove multi-layer throttling, use single canonical throttle point

Collapse 4 independent throttle layers (up to ~500ms added latency) into
a single 50ms debounce in subscribeToPartialMessage. Replace index-based
partial message tracking with stable ts-based tracking. Remove webview
queue/timer/flush system in favor of cheap equality dedup.

* fix: Add production-grade improvements to flicker fix

- Fix global mutable state bug in subscribeToPartialMessage.ts
- Add comprehensive test coverage (51 tests passing)
- Rename ThrottledApiHandler → SanitizedApiHandler
- Remove incomplete OpenAI reasoning effort code

* Fix test failures

* PR changes as per Greptile feedback

* Fixes as per feedback during PR review

---------

Co-authored-by: cline-test <132302818+candieduniverse@users.noreply.github.com>
2026-02-12 22:28:46 -08:00
Robin Newhouse 3899469d76 feat(evals): comprehensive LLM evaluation framework with CI (#8909)
* chore(evals): reorganize eval structure with purpose-based naming

- Move evals/diff-edits/ → evals/benchmarks/tool-precision/replace-in-file/
- Move evals/cli/ → evals/legacy/cli/ (preserve for reference)
- Create evals/benchmarks/real-world/ directory
- Create evals/benchmarks/coding-exercises/cases/ directory
- Create evals/analysis/ directory structure

Note: No repositories/exercism/ directory found to move.
Skipping pre-commit hook as this is a reorganization of legacy code.

* chore(evals): remove legacy evaluation code

Remove abandoned evaluation infrastructure:
- evals/benchmarks/tool-precision/ - Dashboard, database, diff implementations
- evals/legacy/cli/ - Old HTTP-based eval harness

This functionality is superseded by the new testing pyramid:
- Tool precision is now covered by contract tests in src/core/
- E2E testing uses the cline-bench framework

* feat(evals): add analysis framework for benchmark results

Add shared infrastructure for analyzing evaluation results:
- TypeScript schemas for Harbor and analysis output formats
- Parsers for Harbor, tool-precision, and exercise results
- Failure classifier with pattern matching (cline-failures.yaml)
- Metrics calculator (pass@k, consistency, latency)
- JSON and Markdown reporters
- CLI with analyze and compare commands
- Unit tests for classifier and metrics

This framework is used by both smoke tests and E2E evaluations
to provide consistent metrics and failure categorization.

* feat(evals): add contract tests for API transforms

Add tests to verify API response transformations preserve data correctly:
- thinking-traces.test.ts: Tests thinking block extraction and formatting
- tool-parsing.test.ts: Tests tool call parsing across providers

These contract tests catch regressions when modifying transform logic,
ensuring API responses are correctly processed regardless of provider.
Run with: npm run test:unit

* feat(evals): add provider smoke tests with pass@k metrics

Add lightweight smoke tests that validate provider integrations work
correctly with real LLM calls:

Scenarios (5 curated tests):
- 01-create-file: Tests write_to_file tool
- 02-edit-file: Tests replace_in_file tool
- 03-read-summarize: Tests read_file tool
- 04-multi-file: Tests multi-file edits
- 05-typescript-function: Tests code generation

Features:
- CLI-based runner using the cline CLI
- Multiple trials per scenario for reliability testing
- pass@k metrics (solution finding) and pass^k (consistency)
- Results storage with logs and latest symlink
- Adaptive metric display based on trial count

Run locally: npm run eval:smoke

* feat(evals): add E2E runner with cline-bench

Add end-to-end testing infrastructure using real-world production bugs:

- cline-bench submodule: 12 curated tasks from actual Cline sessions
  - Complex multi-file refactors
  - Bug fixes requiring deep context understanding
  - Cross-language/framework tasks

- E2E runner (evals/e2e/run-cline-bench.ts):
  - Integrates with Harbor for containerized execution
  - Supports single task or full suite runs
  - Pass/fail metrics with detailed logging

Run: npm run eval:e2e -- --task discord-trivia

Note: E2E tests require Docker and are intended for weekly/release
testing, not per-commit CI (each task takes 20-30 minutes).

* feat(evals): add CI workflow and documentation

CI Workflow (.github/workflows/cline-evals-regression.yml):
- Triggers on push/PR to main (src/core, src/shared, proto, evals paths)
- Builds CLI from source with Go 1.24
- Runs 5 smoke test scenarios in parallel
- Uses Anthropic API with claude-sonnet-4
- Uploads results as artifacts with summary

npm scripts:
- eval:smoke - Run smoke tests locally (builds CLI first)
- eval:smoke:run - Run smoke tests (assumes CLI is built)
- eval:e2e - Run cline-bench E2E tests

Documentation:
- ARCHITECTURE.md: Testing pyramid overview with ASCII diagrams
- EVALS_OVERVIEW.md: High-level introduction for mixed audience
- Updated README.md with current structure and usage

* chore(evals): restore tool-precision as deprecated legacy

Restore the diff edit evaluation framework for @ara's use case.
Marked as DEPRECATED - target removal Q2 2026 when cline-bench
is fully operational for model comparison.

Note: Skipping linter as this is legacy code being preserved as-is.

* feat(evals): add per-scenario model support and apply_patch test

Also honor --model overrides and prune stubs.

* chore(evals): update smoke tests for CLI 2.0

- Remove Go setup from workflow (CLI 2.0 is TypeScript)
- Build CLI via `npm run build` in cli/ directory
- Install CLI via `npm link` to test built code from PR
- Update CLI flags: -y -m model --json (remove -o and -s)
- Provider configured via `cline auth` before tests run

* chore(evals): add auth check and CLI 2.0 flags

- Add configureAuth() that runs cline auth non-interactively
- Require CLINE_API_KEY env var or use existing ~/.cline auth
- Add --config flag to use shared config directory
- Add -t timeout flag to CLI args
- Reduce scenario timeout to 30s for faster iteration
- Remove --json flag (CLI doesn't output errors in json mode)

* feat(evals): add parallel execution and move workspaces to results

- Add --parallel flag to run scenarios concurrently (default limit: 4)
- Move trial workspaces from scenarios/ to results/ directory
- Workspaces now cleaned up with `npm run eval:smoke:clean`
- Keeps scenarios/ clean and version-controllable

* ci: add smoke tests workflow with parallel execution

- Single job runs all 7 scenarios in parallel using test runner's --parallel flag
- Builds CLI in-job (no artifact passing needed)
- Outputs summary.md to GitHub step summary
- Syncs package-lock.json for tiktoken/commander deps

Co-authored-by: Cursor <cursoragent@cursor.com>

* fix(evals): increase 01-create-file timeout to 120s

The 30s timeout was too short for reliable execution.

Co-authored-by: Cursor <cursoragent@cursor.com>

* chore: restore changesets deleted during rebase

These changesets belong to the already-merged CLI fix (#9073)
and should not be deleted by this branch.

Co-authored-by: Cursor <cursoragent@cursor.com>

* chore(evals): remove unused dependencies from package.json

Drop execa, node-fetch, ora, sqlite, uuid, yargs and their types.
These were leftovers from the old CLI-based eval runner. The smoke
tests use Node builtins and the tool-precision benchmark only needs
axios, better-sqlite3, chalk, commander, dotenv, tiktoken.

Co-authored-by: Cursor <cursoragent@cursor.com>

* Add TypeScript build info files to .gitignore

---------

Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
2026-02-12 22:23:35 -06:00
Robin Newhouse e85332319e feat: add .agents/skills directory support for skill discovery (#9074)
* feat: add .agents/skills directory support for skill discovery

Add compatibility for the standardized .agents/skills directory pattern,
both globally (~/.agents/skills) and locally (.agents/skills in workspace).

* feat: make .agents/skills the default for new skills

New skills are now created in .agents/skills (local) and ~/.agents/skills
(global) by default. These directories also have highest priority in
skill discovery, overriding skills with the same name from other locations.

* docs: update skills documentation for .agents/skills directories

* refactor skills directory helpers
2026-02-12 22:08:30 -06:00
Bee 1a29d428ae refactor: BannerService initialization and cache management (#8969)
* increases banner cache duration to 24 hours so we make one api calls per day per user; implements a circuit breaker that stops retrying after 3 consecutive failures

* add new tests

* Clear banner cache when auth status changes

* revert 5898bc6e0e

* Fixing circuit breaker

* fix: reset circuitBreakerOpenedAt on failed half-open recovery

Previously, circuitBreakerOpenedAt was only set when consecutiveFailures
reached exactly MAX_CONSECUTIVE_FAILURES. This meant that after a failed
half-open recovery attempt, the timestamp wasn't updated, causing the
circuit breaker to immediately enter half-open state again on the next call.

Now circuitBreakerOpenedAt is updated on every failure once the circuit
breaker is tripped, ensuring proper timeout between recovery attempts.

* refactor: BannerService initialization and cache management

- Move BannerService initialization from common.ts to AuthService (which is initialized in controller)
- Re-initialize BannerService after auth state updates to ensure user context
- Add HostRegistryInfo to centralize host/platform information collection
- Improve rate limiting with exponential backoff (5min → 15min → 30min)
- Refactor error handling to better distinguish between rate limits and server errors
- Remove temporary disabled banner fetching comments

This change ensures banners are only fetched when user authentication is
available and implements more robust rate limiting to prevent API hammering.
The banner service now properly tracks user context and respects server
rate limits with progressive backoff delays.

* refactor(banner): simplify banner service initialization and usage

- Remove `getBanners()` wrapper method from Controller class
- Call `BannerService.get().getActiveBanners()` directly in Controller
- Change `BannerService.initialize()` to synchronous, returns instance immediately
- Make banner fetching non-blocking by moving to background
- Remove unused `BannerCardData` import from Controller
- Update tests to handle asynchronous background fetching with timeouts
- Clean up AuthService banner service initialization comment

This change simplifies the banner service API by removing unnecessary abstraction layers and making initialization non-blocking. The service now fetches banners in the background rather than blocking on initialization, improving application startup performance.

* clean up

* apply feedback

* un-skip unit test

* mock

* mock env

* clean up and add debounce fetch

* log fetch time

* revert

* feature flag: remote-banners

* fix loop in authService on auth update

Co-authored-by: Tomás Barreiro <BarreiroT@users.noreply.github.com>

* Fix tests

* small fixes

* use .? for banner

* moves initializeDistinctId to StateManager

* initializeDistinctId

* use v2 endpoint

---------

Co-authored-by: Zhongying Qiao <cryptoque@users.noreply.github.com>
Co-authored-by: Arafatkatze <arafat.da.khan@gmail.com>
Co-authored-by: Tomás Barreiro <BarreiroT@users.noreply.github.com>
Co-authored-by: Tomás Barreiro <52393857+BarreiroT@users.noreply.github.com>
Co-authored-by: BarreiroT <tomasmbarreiroi@gmail.com>
2026-02-12 18:28:12 -08:00
Saoud Rizwan 92cf03e42c feat(subagents): simplify research output guidance and command workflow (#9284) 2026-02-12 16:00:02 -08:00
Bee 3ea393a5e9 fix: openai native provider token usage mapping (#9272)
* fix: openai native provider token usage mapping

- Add `store` parameter support to OpenAI native provider options to allow persisting completions.
- Fix incorrect mapping of `cached_tokens` and `reasoning_tokens` in usage statistics.
- Include `thoughtsTokenCount` in the final usage report to track reasoning model performance and costs.

* Update src/core/api/providers/openai-native.ts

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>

---------

Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
2026-02-12 14:26:35 -08:00
Max 9829e7d49e restore yolo mode to what it was before cline cli started (#9205)
Apply suggestions from code review

Co-authored-by: Max Paulus 🥪 <max@cline.bot>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-02-12 11:10:24 -08:00
Max 56de96e5ff fix oca auth (#9145)
Co-authored-by: Max Paulus 🥪 <max@cline.bot>
2026-02-12 10:20:28 -08:00
github-actions[bot] ecde79cf08 v3.59.0 Release Notes (#9263)
- Added Minimax 2.5 Free Promo
- Fixed Response chaining for OpenAI's Responses API

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
2026-02-12 10:20:19 -08:00
Bee ff36cbcb87 feat: implement response chaining for Responses API (#9270)
* feat: implement response chaining for Responses API

Implement response chaining by tracking and passing previous_response_id
to continue conversations from the last assistant message. This enables
the Responses API to maintain context across multiple turns.

Key changes:
- Search backwards through messages to find last assistant message with ID
- Only send new messages after the chained response
- Track function call metadata (call_id, name, id) across chunks
- Include call_id in tool_call events for proper correlation
- Clean up debug logging and remove commented code
- Remove redundant "Ran out of tokens" log message

This improves conversation continuity and ensures function calls are
properly tracked with their associated IDs throughout the streaming
response lifecycle.

* clean up

* update oca

* codex
2026-02-12 10:01:34 -08:00
shey-cline 5a75f08118 Prevent Parent Container Scrolling In Dropdowns (#9146)
* init

* missed some dropdowns & make scroll behavior work for scrolling nested elements

* add changeset

* add combobox roles
2026-02-12 10:00:40 -08:00
shey-cline 120754c2fe Allow Custom AWS Regions in Bedrock (Extension) (#9104)
* init

* changeset

* addressed comments – add onBlur, aria attributes and redundant useMemo
2026-02-12 09:57:04 -08:00
Saoud Rizwan 5d048d09f8 fix(subagents): retry initial stream bootstrap failures (#9264)
* fix(subagents): retry initial stream bootstrap failures

* fix(subagents): align initial retry classification with main loop

* fix(subagents): compact context on window limit during startup

* fix(subagents): proactively compact context at token thresholds

* feat(subagents): optimize file reads before context truncation
2026-02-12 06:34:43 -08:00
Saoud Rizwan 36580ce086 chore(codex): update environment to use launch script and simplify reinstall
Point the VS Code action at the new run-extension-host.sh script and
drop the git checkout of lock files from the reinstall action.
2026-02-12 05:53:25 -08:00
Saoud Rizwan c584bf4185 feat(dev): add tmux-based extension host launch script
Replaces the inline VS Code launch command with a proper dev script that:
- Builds protos and webview upfront
- Runs esbuild, tsc, and webview watchers in parallel tmux panes
- Waits for dist/extension.js before launching the extension host
- Cleans up all processes and closes the dev window on Ctrl+C
2026-02-12 05:53:18 -08:00
Saoud Rizwan 8133babf41 fix(chat): keep focus chain placeholder visible to prevent layout jump (#9266)
* fix(webview): stabilize focus chain header space and placeholder

* fix(chat): add follow-up bottom scroll to avoid short scroll

* style(chat): refine markdown spacing and tool group summary tone

* fix(chat): retry auto-scroll at 40ms and 70ms

* fix(chat): keep focus chain placeholder visible until checklist exists
2026-02-12 03:50:01 -08:00
Saoud Rizwan 741f524da7 chore(deps): upgrade openai sdk to 6.21.0 for xhigh reasoning (#9267) 2026-02-12 03:48:13 -08:00
Robin Newhouse d3918dd7df fix(task): canonicalize attempt_completion result parameter (#9262) 2026-02-12 00:37:27 -06:00
394 changed files with 18792 additions and 21459 deletions
+16 -9
View File
@@ -14,14 +14,7 @@ fi
[[actions]]
name = "VS Code"
icon = "run"
command = '''
npm run compile && IS_DEV=true DEV_WORKSPACE_FOLDER="$(pwd)" CLINE_ENVIRONMENT=production code \
--extensionDevelopmentPath="$(pwd)" \
--disable-workspace-trust \
--disable-extension saoudrizwan.claude-dev \
--disable-extension saoudrizwan.cline-nightly \
"$(pwd)"
'''
command = "chmod +x ./scripts/run-extension-host.sh && ./scripts/run-extension-host.sh production"
[[actions]]
name = "CLI"
@@ -38,5 +31,19 @@ command = '''
rm node_modules
rm webview-ui/node_modules
npm run install:all
git checkout package-lock.json webview-ui/package-lock.json
'''
[[actions]]
name = "pull main"
icon = "tool"
command = '''
git fetch origin main
if ! git merge-base --is-ancestor main origin/main; then
echo "Local main has commits not on origin/main. Aborting..."
exit 1
fi
git update-ref refs/heads/main refs/remotes/origin/main
echo "main updated to $(git rev-parse --short main)"
'''
@@ -0,0 +1,70 @@
name: Smoke Tests
on:
push:
branches: [main]
paths:
- 'src/core/**'
- 'src/shared/**'
- 'proto/**'
- 'evals/**'
- '.github/workflows/cline-evals-regression.yml'
pull_request:
paths:
- 'src/core/**'
- 'src/shared/**'
- 'proto/**'
- 'evals/**'
- '.github/workflows/cline-evals-regression.yml'
workflow_dispatch:
permissions:
contents: read
concurrency:
group: smoke-tests-${{ github.ref }}
cancel-in-progress: true
jobs:
smoke-tests:
name: Smoke Tests
runs-on: ubuntu-latest
timeout-minutes: 15
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '22'
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Build and install CLI
run: |
npm run protos
cd cli && npm install && npm run build && npm link
echo "$(npm config get prefix)/bin" >> $GITHUB_PATH
- name: Verify CLI
run: cline --version
- name: Run smoke tests
env:
CLINE_API_KEY: ${{ secrets.CLINE_API_KEY }}
run: |
cline auth -p cline -k "$CLINE_API_KEY" -m "anthropic/claude-sonnet-4.5"
npx tsx evals/smoke-tests/run-smoke-tests.ts --trials 1 --parallel
- name: Generate summary
if: always()
run: cat evals/smoke-tests/results/latest/summary.md >> $GITHUB_STEP_SUMMARY
- name: Upload results
uses: actions/upload-artifact@v4
if: always()
with:
name: smoke-test-results-${{ github.run_id }}
path: evals/smoke-tests/results/latest/
retention-days: 30
@@ -39,6 +39,7 @@ jobs:
!endsWith(github.actor, '[bot]')
)
uses: ./.github/workflows/npm-main.yaml
secrets: inherit
with:
confirm_publish: ${{ github.event.inputs.confirm_publish }}
@@ -49,5 +50,6 @@ jobs:
(github.event_name == 'workflow_dispatch' && github.event.inputs.publish_target == 'nightly')
)
uses: ./.github/workflows/npm-nightly.yaml
secrets: inherit
with:
force_publish: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.force_nightly_publish == 'true' }}
+3
View File
@@ -48,3 +48,6 @@ test-results
.secrets
*.tsbuildinfo
# Smoke test results (generated)
evals/smoke-tests/results/
+3
View File
@@ -0,0 +1,3 @@
[submodule "evals/cline-bench"]
path = evals/cline-bench
url = https://github.com/cline/cline-bench.git
+63 -12
View File
@@ -1,8 +1,57 @@
# Changelog
## [3.65.0]
### Added
- Add /skills slash command to CLI for viewing and managing installed skills
### Fixed
- Fix aggressive context compaction caused by accidental clicks on the context window progress bar silently setting a very low auto-condense threshold
- Fix infinite retry loop when write_to_file fails with missing content parameter.
- Fixed default claude model
## [3.64.0]
### Added
- Added sonnet 4.6
## [3.63.0]
### Added
- added zai GLM 5 Free promo
### Fixed
- Restore reasoning trace visibility in chat and improve the thinking row UX so reasoning is visible, then collapsible after completion.
## [3.62.0]
### Fixed
- Banners now display immediately when opening the extension instead of requiring user interaction first
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
## [3.61.0]
- UI/UX fixes with minimax model family
## [3.60.0]
- Fixes for Minimax model family
## [3.59.0]
- Added Minimax 2.5 Free Promo
- Fixed Response chaining for OpenAI's Responses API
## [3.58.0]
### Added
- Subagent: replace legacy subagents with the native `use_subagents` tool
- Bundle `endpoints.json` support so packaged distributions can ship required endpoints out-of-the-box
- Amazon Bedrock: support parallel tool calling
@@ -13,6 +62,7 @@
- ZAI/GLM: add GLM-5
### Fixed
- CLI: handle stdin redirection correctly in CI/headless environments
- CLI: preserve OAuth callback paths during auth redirects
- VS Code Web: generate auth callback URLs via `vscode.env.asExternalUri` (OAuth callback reliability)
@@ -24,6 +74,7 @@
- CI: increase Windows E2E test timeout to reduce flakiness
### Changed
- Settings/model UX: move "reasoning effort" into model configuration and expose it in settings
- CLI provider selection: limit provider list to those remotely configured
- UI: consolidate ViewHeader component/styling across views
@@ -41,7 +92,7 @@
### Added
- Cline CLI 2.0 now available. Install with `npm install -g cline`
- Anthopic Opus 4.6
- Anthopic Opus 4.6
- Minimax-2.1 and Kimi-k2.5 now available for free for a limited time promo
- Codex-5.3 through ChatGPT subscription
@@ -61,23 +112,23 @@
### Added
- __CLI authentication:__ Added Vercel AI Gateway and Cline API key provider support for headless CI/automation workflows
- __New model:__ Added Kimi-K2.5 model to Moonshot provider (262K context, image support, prompt caching)
- __Prompt variant:__ Added Trinity Large prompt variant for improved tool-calling support
- __OpenTelemetry:__ Added support for custom headers on metrics and logs endpoints
- __Social links:__ Added community icons (X, Discord, GitHub, Reddit, LinkedIn) to the What's New modal
- **CLI authentication:** Added Vercel AI Gateway and Cline API key provider support for headless CI/automation workflows
- **New model:** Added Kimi-K2.5 model to Moonshot provider (262K context, image support, prompt caching)
- **Prompt variant:** Added Trinity Large prompt variant for improved tool-calling support
- **OpenTelemetry:** Added support for custom headers on metrics and logs endpoints
- **Social links:** Added community icons (X, Discord, GitHub, Reddit, LinkedIn) to the What's New modal
### Fixed
- __LiteLLM:__ Fixed thinking configuration not appearing for reasoning-capable models
- __OpenTelemetry:__ Fixed endpoint path handling (no longer incorrectly appends `/v1/logs` or `/v1/metrics`) and ensured logs are sent regardless of VSCode telemetry settings
- __CLI auth:__ Fixed `cline auth` displaying incorrect provider information after configuration
- **LiteLLM:** Fixed thinking configuration not appearing for reasoning-capable models
- **OpenTelemetry:** Fixed endpoint path handling (no longer incorrectly appends `/v1/logs` or `/v1/metrics`) and ensured logs are sent regardless of VSCode telemetry settings
- **CLI auth:** Fixed `cline auth` displaying incorrect provider information after configuration
### Changed
- __Hooks:__ Hook scripts now run from the workspace repository root instead of filesystem root
- __Default settings:__ Enabled multi-root workspaces, parallel tool calling, and skills by default; disabled strict plan mode by default
- __Settings UI:__ Refreshed feature settings section with collapsible design
- **Hooks:** Hook scripts now run from the workspace repository root instead of filesystem root
- **Default settings:** Enabled multi-root workspaces, parallel tool calling, and skills by default; disabled strict plan mode by default
- **Settings UI:** Refreshed feature settings section with collapsible design
## [3.55.0]
+27
View File
@@ -0,0 +1,27 @@
# Security Policy
## Supported Versions
We actively patch only the most recent minor release of Cline. Older versions receive fixes at our discretion.
## Reporting a Vulnerability
We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.
To report a security issue, please use the GitHub Security Advisory ["Report a Vulnerability"](https://github.com/cline/cline/security/advisories/new) tab.
The team will send a response indicating the next steps in handling your report. After the initial reply, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
When reporting, please include:
- A short summary of the issue
- Steps to reproduce or a proof of concept
- Any logs, stack traces, or screenshots that might help us understand the problem
We acknowledge reports within 48 hours and aim to release a fix or mitigation within 30 days. While we work on a resolution, please keep the details private.
## Escalation
If you do not receive an acknowledgement of your report within 5 business days, you may send an email to security@cline.bot.
Thank you for helping us keep Cline users safe.
+33
View File
@@ -1,8 +1,39 @@
# cline
## [2.4.1]
### Fixed
- Fix infinite retry loop when write_to_file fails with missing content parameter. Provides progressive guidance to the model, escalating from suggestions to hard stops, with context window awareness to break the loop.
## [2.4.0]
### Added
- Adding Anthropic Sonnet 4.6
- Allows users to enter custom aws region when selecting bedrock as a provider in CLI
- Keep reasoning rows visible when low-stakes tool groups start immediately after reasoning.
- Restore reasoning trace visibility in chat and improve the thinking row UX so streamed reasoning is visible, then collapsible after completion.
### Fixed
- Banners now display immediately when opening the extension instead of requiring user interaction first
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
## [2.2.2]
- Allows users to enter custom aws region when selecting bedrock as a provider
- Prevent Parent Container Scrolling In Dropdowns
## [2.2.1]
- Added Minimax 2.5 Free Promo
- Fixed Response chaining for OpenAI's Responses API
## [2.2.0]
### Added
- Subagent: replace legacy subagents with the native `use_subagents` tool
- Bundle `endpoints.json` support so packaged distributions can ship required endpoints out-of-the-box
- Amazon Bedrock: support parallel tool calling
@@ -13,6 +44,7 @@
- ZAI/GLM: add GLM-5
### Fixed
- CLI: handle stdin redirection correctly in CI/headless environments
- CLI: preserve OAuth callback paths during auth redirects
- VS Code Web: generate auth callback URLs via `vscode.env.asExternalUri` (OAuth callback reliability)
@@ -24,6 +56,7 @@
- CI: increase Windows E2E test timeout to reduce flakiness
### Changed
- Settings/model UX: move "reasoning effort" into model configuration and expose it in settings
- CLI provider selection: limit provider list to those remotely configured
- UI: consolidate ViewHeader component/styling across views
+1 -2
View File
@@ -45,7 +45,7 @@ cline
### Use any API and Model
Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras and Groq. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.
Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras, Groq, and Moonshot. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.
<!-- Transparent pixel to create line break after floating image -->
@@ -79,4 +79,3 @@ Get the same Cline experience with enterprise-grade controls: SSO (SAML/OIDC), g
## License
[Apache 2.0 © 2026 Cline Bot Inc.](./LICENSE)
+8 -2
View File
@@ -125,13 +125,13 @@ authentication wizard, or use quick setup flags.
Options:
.PP
\f[B]\-p\f[R], \f[B]\-\-provider\f[R] \f[I]id\f[R] : Provider ID for
quick setup (e.g., openai\-native, anthropic, openrouter)
quick setup (e.g., openai\-native, anthropic, openrouter, moonshot)
.PP
\f[B]\-k\f[R], \f[B]\-\-apikey\f[R] \f[I]key\f[R] : API key for the
provider
.PP
\f[B]\-m\f[R], \f[B]\-\-modelid\f[R] \f[I]id\f[R] : Model ID to
configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929)
configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929, kimi\-k2.5)
.PP
\f[B]\-b\f[R], \f[B]\-\-baseurl\f[R] \f[I]url\f[R] : Base URL (optional,
for OpenAI\-compatible providers)
@@ -242,6 +242,9 @@ cline \-m claude\-sonnet\-4\-5\-20250929 \(dqRefactor this function\(dq
\f[I]# Quick auth setup with model\f[R]
cline auth \-p anthropic \-k sk\-ant\-xxxxx \-m claude\-sonnet\-4\-5\-20250929
\f[I]# Quick auth setup for Moonshot\f[R]
cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
.EE
.SS Including Images
.IP
@@ -309,6 +312,9 @@ cline auth \-p anthropic \-k sk\-ant\-api\-xxxxx
\f[I]# Quick setup for OpenAI\f[R]
cline auth \-p openai\-native \-k sk\-xxxxx \-m gpt\-4o
\f[I]# Quick setup for Moonshot\f[R]
cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
\f[I]# OpenAI\-compatible provider with custom base URL\f[R]
cline auth \-p openai \-k your\-api\-key \-b https://api.example.com/v1
.EE
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "cline",
"version": "2.2.0",
"version": "2.4.1",
"description": "Autonomous coding agent CLI - capable of creating/editing files, running commands, using the browser, and more",
"main": "dist/cli.mjs",
"bin": {
+3
View File
@@ -28,6 +28,8 @@ import {
groqModels,
mistralDefaultModelId,
mistralModels,
moonshotDefaultModelId,
moonshotModels,
openAiCodexDefaultModelId,
openAiNativeDefaultModelId,
openAiNativeModels,
@@ -72,6 +74,7 @@ const providerModels: Record<string, { models: Record<string, unknown>; defaultI
bedrock: { models: bedrockModels, defaultId: bedrockDefaultModelId },
deepseek: { models: deepSeekModels, defaultId: deepSeekDefaultModelId },
mistral: { models: mistralModels, defaultId: mistralDefaultModelId },
moonshot: { models: moonshotModels, defaultId: moonshotDefaultModelId },
groq: { models: groqModels, defaultId: groqDefaultModelId },
xai: { models: xaiModels, defaultId: xaiDefaultModelId },
}
+20 -9
View File
@@ -5,12 +5,13 @@
import { Box, Text, useApp, useInput } from "ink"
import Spinner from "ink-spinner"
// biome-ignore lint/style/useImportType: React is used as a value by JSX (jsx: "react" in tsconfig)
import React, { useCallback, useEffect, useMemo, useState } from "react"
import { refreshOcaModels } from "@/core/controller/models/refreshOcaModels"
import { StateManager } from "@/core/storage/StateManager"
import { openAiCodexOAuthManager } from "@/integrations/openai-codex/oauth"
import { AuthService } from "@/services/auth/AuthService"
import { liteLlmDefaultModelId, openAiCodexDefaultModelId, openRouterDefaultModelId } from "@/shared/api"
import { openAiCodexDefaultModelId, openRouterDefaultModelId } from "@/shared/api"
import { StringRequest } from "@/shared/proto/cline/common"
import { openExternal } from "@/utils/env"
import { COLORS } from "../constants/colors"
import { useStdinContext } from "../context/StdinContext"
@@ -31,6 +32,7 @@ import {
} from "./FeaturedModelPicker"
import { ImportView } from "./ImportView"
import { getDefaultModelId, hasModelPicker, ModelPicker } from "./ModelPicker"
import { OcaEmployeeCheck } from "./OcaEmployeeCheck"
import { getProviderLabel } from "./ProviderPicker"
type AuthStep =
@@ -43,6 +45,7 @@ type AuthStep =
| "success"
| "error"
| "cline_auth"
| "oca_employee_check"
| "oca_auth"
| "cline_model"
| "openai_codex_auth"
@@ -160,7 +163,6 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
const [modelId, setModelId] = useState("")
const [baseUrl, setBaseUrl] = useState("")
const [errorMessage, setErrorMessage] = useState("")
const [authStatus, setAuthStatus] = useState<string>("")
const [providerSearch, setProviderSearch] = useState("")
const [providerIndex, setProviderIndex] = useState(0)
const [clineModelIndex, setClineModelIndex] = useState(0)
@@ -171,11 +173,14 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
// OCA auth hook - enabled when step is oca_auth
const handleOcaAuthSuccess = useCallback(async () => {
await applyProviderConfig({ providerId: "oca", controller })
// Fetch OCA models from the API - this sets actModeOcaModelId/planModeOcaModelId in state
await refreshOcaModels(controller, StringRequest.create({ value: "" }))
const stateManager = StateManager.get()
stateManager.setGlobalState("welcomeViewCompleted", true)
await stateManager.flushPendingState()
setSelectedProvider("oca")
setModelId(liteLlmDefaultModelId)
const actModelId = stateManager.getGlobalSettingsKey("actModeOcaModelId") || ""
setModelId(actModelId)
setStep("success")
}, [controller])
@@ -317,7 +322,6 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
const startClineAuth = useCallback(async () => {
try {
setStep("cline_auth")
setAuthStatus("Starting authentication...")
await AuthService.getInstance(controller).createAuthRequest()
} catch (error) {
setErrorMessage(error instanceof Error ? error.message : String(error))
@@ -327,7 +331,6 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
const startOcaAuth = useCallback(() => {
setStep("oca_auth")
setAuthStatus("Starting authentication...")
initiateOcaAuth()
}, [initiateOcaAuth])
@@ -358,7 +361,8 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
(value: string) => {
setSelectedProvider(value)
if (value === "oca") {
startOcaAuth()
// Show employee check screen before starting auth
setStep("oca_employee_check")
} else if (value === "openai-codex") {
setStep("openai_codex_auth")
startOpenAiCodexAuth()
@@ -534,9 +538,12 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
setBaseUrl("")
setStep("modelid")
break
case "oca_auth":
case "oca_employee_check":
setStep("provider")
break
case "oca_auth":
setStep("oca_employee_check")
break
case "cline_auth":
setStep("menu")
break
@@ -639,7 +646,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
<Box flexDirection="column">
<Text color="white">Model ID</Text>
<Text> </Text>
<Text color="gray">e.g., claude-sonnet-4-20250514, gpt-4o</Text>
<Text color="gray">e.g., claude-sonnet-4-6, gpt-4o</Text>
<Text> </Text>
<TextInput onChange={setModelId} onSubmit={handleModelIdSubmit} placeholder="model-id" value={modelId} />
<Text> </Text>
@@ -675,6 +682,9 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
</Box>
)
case "oca_employee_check":
return <OcaEmployeeCheck isActive={step === "oca_employee_check"} onCancel={goBack} onSignIn={startOcaAuth} />
case "oca_auth":
case "cline_auth":
return (
@@ -760,6 +770,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
const [menuIndex, setMenuIndex] = useState(0)
// Steps that allow going back with escape (apikey handled by ApiKeyInput component)
// OcaEmployeeCheck handles its own escape key, so oca_employee_check is not in this list
const canGoBack = [
"provider",
"modelid",
+19 -9
View File
@@ -114,8 +114,11 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
// Filtered regions
const filteredRegions = useMemo(() => {
const search = regionSearch.toLowerCase()
return search ? AWS_REGIONS.filter((r) => r.includes(search)) : AWS_REGIONS
const search = regionSearch.toLowerCase().trim()
if (!search) {
return AWS_REGIONS
}
return AWS_REGIONS.filter((r) => r.toLowerCase().includes(search))
}, [regionSearch])
const {
@@ -170,10 +173,18 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
}
}, [step, authMethod, onCancel])
const getSelectedRegion = useCallback(() => {
if (filteredRegions.length > 0 && regionIndex >= 0 && regionIndex < filteredRegions.length) {
return filteredRegions[regionIndex]
}
// If no matches, use the search term as custom region
return regionSearch.trim() || "us-east-1"
}, [filteredRegions, regionIndex, regionSearch])
const finish = useCallback(() => {
const config: BedrockConfig = {
awsAuthentication: authMethod === "default" ? "credentials" : authMethod,
awsRegion: filteredRegions[regionIndex] || "us-east-1",
awsRegion: getSelectedRegion(),
awsUseCrossRegionInference: crossRegion,
}
if (authMethod === "profile") {
@@ -184,7 +195,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
if (sessionToken) config.awsSessionToken = sessionToken
}
onComplete(config)
}, [authMethod, profileName, accessKey, secretKey, sessionToken, filteredRegions, regionIndex, crossRegion, onComplete])
}, [authMethod, profileName, accessKey, secretKey, sessionToken, getSelectedRegion, crossRegion, onComplete])
// Handle input for auth_method, region, and options steps
useInput(
@@ -204,11 +215,11 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
} else if (step === "region") {
if (key.escape) {
goBack()
} else if (key.upArrow) {
} else if (key.upArrow && filteredRegions.length > 0) {
setRegionIndex((prev) => (prev > 0 ? prev - 1 : filteredRegions.length - 1))
} else if (key.downArrow) {
} else if (key.downArrow && filteredRegions.length > 0) {
setRegionIndex((prev) => (prev < filteredRegions.length - 1 ? prev + 1 : 0))
} else if (key.return && filteredRegions.length > 0) {
} else if (key.return && (filteredRegions.length > 0 || regionSearch.trim())) {
setStep("options")
} else if (key.backspace || key.delete) {
setRegionSearch((prev) => prev.slice(0, -1))
@@ -330,7 +341,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
<Text color="white">AWS Region</Text>
<Text> </Text>
<Box>
<Text color="gray">Search: </Text>
<Text color="gray">Search or enter custom region: </Text>
<Text color="white">{regionSearch}</Text>
<Text inverse> </Text>
</Box>
@@ -350,7 +361,6 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
{showRegionBottom && (
<Text color="gray">... {filteredRegions.length - regionVisibleStart - regionVisibleCount} more below</Text>
)}
{filteredRegions.length === 0 && <Text color="gray">No regions match "{regionSearch}"</Text>}
<Text> </Text>
<Text color="gray">Type to search, arrows to navigate, Enter to select, Esc to go back</Text>
</Box>
+23
View File
@@ -150,6 +150,7 @@ import { HighlightedInput } from "./HighlightedInput"
import { HistoryPanelContent } from "./HistoryPanelContent"
import { providerModels } from "./ModelPicker"
import { SettingsPanelContent } from "./SettingsPanelContent"
import { SkillsPanelContent } from "./SkillsPanelContent"
import { SlashCommandMenu } from "./SlashCommandMenu"
import { ThinkingIndicator } from "./ThinkingIndicator"
@@ -412,6 +413,7 @@ export const ChatView: React.FC<ChatViewProps> = ({
| { type: "settings"; initialMode?: "model-picker" | "featured-models"; initialModelKey?: "actModelId" | "planModelId" }
| { type: "history" }
| { type: "help" }
| { type: "skills" }
| null
>(null)
@@ -1156,6 +1158,14 @@ export const ChatView: React.FC<ChatViewProps> = ({
setSlashMenuDismissed(true)
return
}
if (cmd.name === "skills") {
setActivePanel({ type: "skills" })
setTextInput("")
setCursorPos(0)
setSelectedSlashIndex(0)
setSlashMenuDismissed(true)
return
}
if (cmd.name === "clear") {
clearViewAndResetTask()
setSelectedSlashIndex(0)
@@ -1545,6 +1555,19 @@ export const ChatView: React.FC<ChatViewProps> = ({
{/* Help panel */}
{activePanel?.type === "help" && <HelpPanelContent onClose={() => setActivePanel(null)} />}
{/* Skills panel */}
{activePanel?.type === "skills" && ctrl && (
<SkillsPanelContent
controller={ctrl}
onClose={() => setActivePanel(null)}
onUseSkill={(skillPath) => {
setActivePanel(null)
setTextInput(`@${skillPath} `)
setCursorPos(skillPath.length + 2)
}}
/>
)}
{/* Slash command menu - below input (takes priority over file menu) */}
{showSlashMenu && !activePanel && (
<Box paddingLeft={1} paddingRight={1}>
+2 -2
View File
@@ -39,7 +39,7 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
const isSelected = i === selectedIndex
return (
<Box flexDirection="column" key={model.id} marginBottom={1}>
<Box flexDirection="column" key={`${model.id}-${model.labels[0] || "default"}`} marginBottom={1}>
<Box>
<Text color={isSelected ? COLORS.primaryBlue : undefined}>{isSelected ? " " : " "}</Text>
<Text bold color={isSelected ? COLORS.primaryBlue : "white"}>
@@ -81,7 +81,7 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
* Get the maximum valid index for the featured model picker
* (includes "Browse all" option if showBrowseAll is true)
*/
export function getFeaturedModelMaxIndex(showBrowseAll: boolean = true): number {
export function getFeaturedModelMaxIndex(showBrowseAll = true): number {
const featuredModels = getAllFeaturedModels()
return showBrowseAll ? featuredModels.length : featuredModels.length - 1
}
+18 -4
View File
@@ -6,6 +6,7 @@
import { Box, Text } from "ink"
import Spinner from "ink-spinner"
import React, { useEffect, useMemo, useState } from "react"
import { refreshOcaModels } from "@/core/controller/models/refreshOcaModels"
import { refreshOpenRouterModels } from "@/core/controller/models/refreshOpenRouterModels"
import {
type ApiProvider,
@@ -64,6 +65,7 @@ import {
xaiDefaultModelId,
xaiModels,
} from "@/shared/api"
import { StringRequest } from "@/shared/proto/cline/common"
import { filterOpenRouterModelIds } from "@/shared/utils/model-filters"
import { COLORS } from "../constants/colors"
import { getOpenRouterDefaultModelId, usesOpenRouterModels } from "../utils/openrouter-models"
@@ -105,7 +107,7 @@ export function hasStaticModels(provider: string): boolean {
}
export function hasModelPicker(provider: string): boolean {
return hasStaticModels(provider) || usesOpenRouterModels(provider)
return hasStaticModels(provider) || usesOpenRouterModels(provider) || provider === "oca"
}
export function getDefaultModelId(provider: string): string {
@@ -132,7 +134,7 @@ export const ModelPicker: React.FC<ModelPickerProps> = ({ provider, controller,
const [isLoading, setIsLoading] = useState(false)
const [asyncModels, setAsyncModels] = useState<string[]>([])
// Fetch OpenRouter models when needed using shared core function
// Fetch async models (OpenRouter or OCA) when needed
useEffect(() => {
if (usesOpenRouterModels(provider)) {
setIsLoading(true)
@@ -145,11 +147,23 @@ export const ModelPicker: React.FC<ModelPickerProps> = ({ provider, controller,
.finally(() => {
setIsLoading(false)
})
} else if (provider === "oca") {
setIsLoading(true)
refreshOcaModels(controller, StringRequest.create({ value: "" }))
.then((result) => {
if (result.models) {
const modelIds = Object.keys(result.models).sort((a, b) => a.localeCompare(b))
setAsyncModels(modelIds)
}
})
.finally(() => {
setIsLoading(false)
})
}
}, [provider, controller])
const modelList = useMemo(() => {
if (usesOpenRouterModels(provider)) {
if (usesOpenRouterModels(provider) || provider === "oca") {
return asyncModels
}
return getModelList(provider)
@@ -180,7 +194,7 @@ export const ModelPicker: React.FC<ModelPickerProps> = ({ provider, controller,
}
// If async fetch returned no models, render nothing
if (usesOpenRouterModels(provider) && modelList.length === 0) {
if ((usesOpenRouterModels(provider) || provider === "oca") && modelList.length === 0) {
return null
}
+88
View File
@@ -0,0 +1,88 @@
/**
* OCA (Oracle Cloud Assist) employee check component.
* Shows a checkbox for "I'm an Oracle Employee" and a sign-in button.
* Sets ocaMode in state before triggering the OAuth flow.
*/
import { Box, Text, useInput } from "ink"
// biome-ignore lint/style/useImportType: React is used as a value by JSX (jsx: "react" in tsconfig)
import React, { useCallback, useState } from "react"
import { StateManager } from "@/core/storage/StateManager"
import { COLORS } from "../constants/colors"
import { useStdinContext } from "../context/StdinContext"
interface OcaEmployeeCheckProps {
/** Whether this component is active and should handle input */
isActive: boolean
/** Called when user confirms and wants to proceed with sign-in */
onSignIn: () => void
/** Called when user presses Escape to go back */
onCancel: () => void
}
export const OcaEmployeeCheck: React.FC<OcaEmployeeCheckProps> = ({ isActive, onSignIn, onCancel }) => {
const { isRawModeSupported } = useStdinContext()
const [isEmployee, setIsEmployee] = useState(true) // Default to checked (internal), matching extension behavior
const [selectedIndex, setSelectedIndex] = useState(0) // 0 = checkbox, 1 = sign in button
const ITEM_COUNT = 2
const handleSignIn = useCallback(async () => {
// Persist ocaMode to state before starting auth
const stateManager = StateManager.get()
stateManager.setGlobalState("ocaMode", isEmployee ? "internal" : "external")
await stateManager.flushPendingState()
onSignIn()
}, [isEmployee, onSignIn])
useInput(
(_input, key) => {
if (key.escape) {
onCancel()
return
}
if (key.upArrow) {
setSelectedIndex((prev) => (prev > 0 ? prev - 1 : ITEM_COUNT - 1))
} else if (key.downArrow) {
setSelectedIndex((prev) => (prev < ITEM_COUNT - 1 ? prev + 1 : 0))
} else if (key.tab || (key.return && selectedIndex === 0)) {
// Toggle checkbox when Tab is pressed or Enter on checkbox item
if (selectedIndex === 0) {
setIsEmployee((prev) => !prev)
}
} else if (key.return && selectedIndex === 1) {
// Sign in button
handleSignIn()
}
},
{ isActive: isRawModeSupported && isActive },
)
return (
<Box flexDirection="column">
<Text color="white">Oracle Code Assist</Text>
<Text> </Text>
{/* Checkbox: I'm an Oracle Employee */}
<Text>
<Text bold color={selectedIndex === 0 ? COLORS.primaryBlue : undefined}>
{selectedIndex === 0 ? "" : " "}{" "}
</Text>
<Text color={selectedIndex === 0 || isEmployee ? COLORS.primaryBlue : "gray"}>{isEmployee ? "[✓]" : "[ ]"}</Text>
<Text color={selectedIndex === 0 ? COLORS.primaryBlue : "white"}> I'm an Oracle Employee</Text>
{selectedIndex === 0 && <Text color="gray"> (Tab to toggle)</Text>}
</Text>
{/* Sign in button */}
<Text>
<Text bold color={selectedIndex === 1 ? COLORS.primaryBlue : undefined}>
{selectedIndex === 1 ? "" : " "}{" "}
</Text>
<Text color={selectedIndex === 1 ? COLORS.primaryBlue : "white"}>Sign in with Oracle Code Assist</Text>
{selectedIndex === 1 && <Text color="gray"> (Enter)</Text>}
</Text>
<Text> </Text>
<Text color="gray">Please ask your IT administrator to set up Oracle Code Assist as a model provider.</Text>
<Text> </Text>
<Text color="gray">Arrows to navigate, Tab to toggle, Enter to continue, Esc to go back</Text>
</Box>
)
}
+23 -3
View File
@@ -14,10 +14,12 @@ import Spinner from "ink-spinner"
import React, { useCallback, useEffect, useMemo, useState } from "react"
import { buildApiHandler } from "@/core/api"
import type { Controller } from "@/core/controller"
import { refreshOcaModels } from "@/core/controller/models/refreshOcaModels"
import { StateManager } from "@/core/storage/StateManager"
import { openAiCodexOAuthManager } from "@/integrations/openai-codex/oauth"
import { ClineAccountService } from "@/services/account/ClineAccountService"
import { AuthService, ClineAccountOrganization } from "@/services/auth/AuthService"
import { StringRequest } from "@/shared/proto/cline/common"
import { openExternal } from "@/utils/env"
import { supportsReasoningEffortForModel } from "@/utils/model-utils"
import { version as CLI_VERSION } from "../../package.json"
@@ -37,6 +39,7 @@ import {
} from "./FeaturedModelPicker"
import { LanguagePicker } from "./LanguagePicker"
import { hasModelPicker, ModelPicker } from "./ModelPicker"
import { OcaEmployeeCheck } from "./OcaEmployeeCheck"
import { OrganizationPicker } from "./OrganizationPicker"
import { Panel, PanelTab } from "./Panel"
import { getProviderLabel, ProviderPicker } from "./ProviderPicker"
@@ -162,6 +165,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
const [isEnteringApiKey, setIsEnteringApiKey] = useState(false)
const [isConfiguringBedrock, setIsConfiguringBedrock] = useState(false)
const [isWaitingForCodexAuth, setIsWaitingForCodexAuth] = useState(false)
const [isShowingOcaEmployeeCheck, setIsShowingOcaEmployeeCheck] = useState(false)
const [codexAuthError, setCodexAuthError] = useState<string | null>(null)
const [pendingProvider, setPendingProvider] = useState<string | null>(null)
const [apiKeyValue, setApiKeyValue] = useState("")
@@ -235,6 +239,8 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
// OCA auth hook
const handleOcaAuthSuccess = useCallback(async () => {
await applyProviderConfig({ providerId: "oca", controller })
// Fetch OCA models from the API - this sets actModeOcaModelId/planModeOcaModelId in state
await refreshOcaModels(controller!, StringRequest.create({ value: "" }))
setProvider("oca")
refreshModelIds()
}, [controller, refreshModelIds])
@@ -1078,8 +1084,8 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
setProvider("oca")
refreshModelIds()
} else {
// Not logged in - trigger OAuth
startOcaAuth()
// Not logged in - show employee check before auth
setIsShowingOcaEmployeeCheck(true)
}
return
}
@@ -1370,7 +1376,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
return
}
},
{ isActive: isRawModeSupported && !isEnteringApiKey && !isConfiguringBedrock },
{ isActive: isRawModeSupported && !isEnteringApiKey && !isConfiguringBedrock && !isShowingOcaEmployeeCheck },
)
// Render content
@@ -1546,6 +1552,19 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
)
}
if (isShowingOcaEmployeeCheck) {
return (
<OcaEmployeeCheck
isActive={isShowingOcaEmployeeCheck}
onCancel={() => setIsShowingOcaEmployeeCheck(false)}
onSignIn={() => {
setIsShowingOcaEmployeeCheck(false)
startOcaAuth()
}}
/>
)
}
if (isWaitingForOcaAuth) {
return (
<Box flexDirection="column">
@@ -1727,6 +1746,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
!!codexAuthError ||
isPickingOrganization ||
isWaitingForClineAuth ||
isShowingOcaEmployeeCheck ||
isWaitingForOcaAuth ||
isEditing
@@ -0,0 +1,230 @@
/**
* Tests for SkillsPanelContent component
*
* Tests keyboard interactions and callbacks.
* Rendering tests are limited due to ink-testing-library constraints with nested components.
*/
import { render } from "ink-testing-library"
// biome-ignore lint/correctness/noUnusedImports: React must be in scope for JSX in this test file.
import React from "react"
import { beforeEach, describe, expect, it, vi } from "vitest"
// Mock refreshSkills
const mockRefreshSkills = vi.fn()
vi.mock("@/core/controller/file/refreshSkills", () => ({
refreshSkills: () => mockRefreshSkills(),
}))
// Mock toggleSkill
const mockToggleSkill = vi.fn()
vi.mock("@/core/controller/file/toggleSkill", () => ({
toggleSkill: (...args: unknown[]) => mockToggleSkill(...args),
}))
// Mock child_process exec
const mockExec = vi.fn()
vi.mock("node:child_process", () => ({
exec: (...args: unknown[]) => mockExec(...args),
}))
// Mock StdinContext
vi.mock("../context/StdinContext", () => ({
useStdinContext: () => ({ isRawModeSupported: true }),
}))
import { SkillsPanelContent } from "./SkillsPanelContent"
// Helper to wait for async state updates
const delay = (ms = 60) => new Promise((resolve) => setTimeout(resolve, ms))
describe("SkillsPanelContent", () => {
const mockController = {} as any
const mockOnClose = vi.fn()
const mockOnUseSkill = vi.fn()
const defaultProps = {
controller: mockController,
onClose: mockOnClose,
onUseSkill: mockOnUseSkill,
}
beforeEach(() => {
vi.clearAllMocks()
mockRefreshSkills.mockResolvedValue({
globalSkills: [],
localSkills: [],
})
})
describe("keyboard interactions", () => {
it("should call onClose when Escape is pressed", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
stdin.write("\x1B") // Escape
await delay()
expect(mockOnClose).toHaveBeenCalled()
})
it("should call onUseSkill with skill path when Enter is pressed on a skill", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
stdin.write("\r") // Enter
await delay()
expect(mockOnUseSkill).toHaveBeenCalledWith("/test/path/SKILL.md")
})
it("should call toggleSkill when Space is pressed on a skill", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
stdin.write(" ") // Space
await delay()
expect(mockToggleSkill).toHaveBeenCalledWith(
mockController,
expect.objectContaining({
skillPath: "/test/path/SKILL.md",
isGlobal: true,
enabled: false, // toggled from true to false
}),
)
})
it("should open marketplace URL when Enter is pressed on marketplace item", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [{ name: "skill", description: "desc", path: "/path", enabled: true }],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
// Navigate down to marketplace (past the one skill)
stdin.write("\x1B[B") // Down arrow
await delay()
stdin.write("\r") // Enter
await delay()
// Should have called exec with open command
expect(mockExec).toHaveBeenCalled()
const execCall = mockExec.mock.calls[0][0]
expect(execCall).toContain("https://skills.sh/")
})
it("should navigate through skills with arrow keys", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [
{ name: "skill-1", description: "First", path: "/path1", enabled: true },
{ name: "skill-2", description: "Second", path: "/path2", enabled: true },
],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
// Navigate down
stdin.write("\x1B[B") // Down arrow
await delay()
// Press Enter - should use second skill
stdin.write("\r")
await delay()
expect(mockOnUseSkill).toHaveBeenCalledWith("/path2")
})
it("should navigate with vim keys (j/k)", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [
{ name: "skill-1", description: "First", path: "/path1", enabled: true },
{ name: "skill-2", description: "Second", path: "/path2", enabled: true },
],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
// Navigate down with j
stdin.write("j")
await delay()
// Press Enter - should use second skill
stdin.write("\r")
await delay()
expect(mockOnUseSkill).toHaveBeenCalledWith("/path2")
})
it("should revert optimistic toggle on failure", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
localSkills: [],
})
mockToggleSkill.mockRejectedValueOnce(new Error("toggle failed"))
const { stdin, lastFrame } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
stdin.write(" ") // Space to toggle
await delay(100)
// toggleSkill was called with enabled: false (toggled from true)
expect(mockToggleSkill).toHaveBeenCalledWith(mockController, expect.objectContaining({ enabled: false }))
const frame = lastFrame() || ""
expect(frame).toContain("● test-skill")
expect(frame).not.toContain("○ test-skill")
})
it("should wrap navigation at list boundaries", async () => {
mockRefreshSkills.mockResolvedValue({
globalSkills: [{ name: "only-skill", description: "Only", path: "/only", enabled: true }],
localSkills: [],
})
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
await delay()
// Navigate up from first item (should wrap to last - marketplace)
stdin.write("\x1B[A") // Up arrow
await delay()
stdin.write("\r") // Enter
await delay()
// Should have opened marketplace (wrapped to last item)
expect(mockExec).toHaveBeenCalled()
})
})
describe("skill loading", () => {
it("should call refreshSkills on mount", async () => {
render(<SkillsPanelContent {...defaultProps} />)
await delay()
expect(mockRefreshSkills).toHaveBeenCalled()
})
})
})
+257
View File
@@ -0,0 +1,257 @@
/**
* Skills panel content for inline display in ChatView
* Shows installed skills with toggle and use functionality
*/
import { exec } from "node:child_process"
import os from "node:os"
import { Box, Text, useInput } from "ink"
import React, { useCallback, useEffect, useMemo, useState } from "react"
import type { Controller } from "@/core/controller"
import { refreshSkills } from "@/core/controller/file/refreshSkills"
import { toggleSkill } from "@/core/controller/file/toggleSkill"
import { COLORS } from "../constants/colors"
import { useStdinContext } from "../context/StdinContext"
import { isMouseEscapeSequence } from "../utils/input"
import { Panel } from "./Panel"
const SKILLS_MARKETPLACE_URL = "https://skills.sh/"
interface SkillInfo {
name: string
description: string
path: string
enabled: boolean
}
interface SkillsPanelContentProps {
controller: Controller
onClose: () => void
onUseSkill: (skillPath: string) => void
}
const MAX_VISIBLE = 8
export const SkillsPanelContent: React.FC<SkillsPanelContentProps> = ({ controller, onClose, onUseSkill }) => {
const { isRawModeSupported } = useStdinContext()
const [globalSkills, setGlobalSkills] = useState<SkillInfo[]>([])
const [localSkills, setLocalSkills] = useState<SkillInfo[]>([])
const [selectedIndex, setSelectedIndex] = useState(0)
const [isLoading, setIsLoading] = useState(true)
// Load skills on mount
useEffect(() => {
const loadSkills = async () => {
try {
const skillsData = await refreshSkills(controller)
setGlobalSkills(skillsData.globalSkills || [])
setLocalSkills(skillsData.localSkills || [])
} catch (_error) {
// Skills loading failed, show empty state
} finally {
setIsLoading(false)
}
}
loadSkills()
}, [controller])
// Build flat list of skills with source info (global first, then local, alphabetical within each)
const skillEntries = useMemo(() => {
const entries: { skill: SkillInfo; isGlobal: boolean }[] = []
globalSkills.forEach((skill) => entries.push({ skill, isGlobal: true }))
localSkills.forEach((skill) => entries.push({ skill, isGlobal: false }))
return entries.sort((a, b) => {
if (a.isGlobal !== b.isGlobal) return a.isGlobal ? -1 : 1
return a.skill.name.localeCompare(b.skill.name)
})
}, [globalSkills, localSkills])
// Handle toggle
const handleToggle = useCallback(async () => {
const entry = skillEntries[selectedIndex]
if (!entry) return
const newEnabled = !entry.skill.enabled
const setter = entry.isGlobal ? setGlobalSkills : setLocalSkills
const update = (enabled: boolean) =>
setter((prev) => prev.map((s) => (s.path === entry.skill.path ? { ...s, enabled } : s)))
// Optimistic update
update(newEnabled)
try {
await toggleSkill(controller, {
metadata: undefined,
skillPath: entry.skill.path,
isGlobal: entry.isGlobal,
enabled: newEnabled,
})
} catch {
// Revert on failure
update(!newEnabled)
}
}, [controller, skillEntries, selectedIndex])
// Handle use skill (insert @ mention)
const handleUse = useCallback(() => {
const entry = skillEntries[selectedIndex]
if (!entry) return
onUseSkill(entry.skill.path)
}, [skillEntries, selectedIndex, onUseSkill])
// Handle opening the marketplace URL
const openMarketplace = useCallback(() => {
const platform = os.platform()
let command: string
if (platform === "darwin") {
command = `open "${SKILLS_MARKETPLACE_URL}"`
} else if (platform === "win32") {
command = `start "${SKILLS_MARKETPLACE_URL}"`
} else {
command = `xdg-open "${SKILLS_MARKETPLACE_URL}"`
}
exec(command, (err) => {
if (err) {
// Fallback: show URL in terminal if browser open fails
console.error(`Visit: ${SKILLS_MARKETPLACE_URL}`)
}
})
}, [])
// Total items = skills + 1 for marketplace link
const totalItems = skillEntries.length + 1
const isMarketplaceSelected = selectedIndex === skillEntries.length
useInput(
(input, key) => {
if (isMouseEscapeSequence(input)) {
return
}
if (key.escape) {
onClose()
return
}
// Navigation
if (key.upArrow || input === "k") {
setSelectedIndex((i) => (i > 0 ? i - 1 : totalItems - 1))
return
}
if (key.downArrow || input === "j") {
setSelectedIndex((i) => (i < totalItems - 1 ? i + 1 : 0))
return
}
// Actions
if (key.return) {
if (isMarketplaceSelected) {
openMarketplace()
} else {
handleUse()
}
return
}
if (input === " " && !isMarketplaceSelected) {
handleToggle()
return
}
},
{ isActive: isRawModeSupported },
)
// Scrolling window (includes marketplace row)
const halfVisible = Math.floor(MAX_VISIBLE / 2)
const startIndex = Math.max(0, Math.min(selectedIndex - halfVisible, totalItems - MAX_VISIBLE))
if (isLoading) {
return (
<Panel label="Skills">
<Text color="gray">Loading skills...</Text>
</Panel>
)
}
// Check if marketplace row is in visible window
const marketplaceIndex = skillEntries.length
const showMarketplace = marketplaceIndex >= startIndex && marketplaceIndex < startIndex + MAX_VISIBLE
return (
<Panel label="Skills">
<Box flexDirection="column" gap={1}>
{skillEntries.length === 0 ? (
<Box flexDirection="column" gap={1}>
<Text color="gray">No skills installed.</Text>
<Text>
Install skills with: <Text color="white">npx skills add owner/repo</Text>
</Text>
</Box>
) : (
<Box flexDirection="column">
{skillEntries
.slice(startIndex, Math.min(startIndex + MAX_VISIBLE, skillEntries.length))
.map((entry, idx) => {
const actualIndex = startIndex + idx
const prevEntry = skillEntries[actualIndex - 1]
const showHeader = actualIndex === 0 || (prevEntry && prevEntry.isGlobal !== entry.isGlobal)
return (
<React.Fragment key={entry.skill.path}>
{showHeader && (
<Box marginTop={actualIndex > 0 ? 1 : 0}>
<Text bold color="gray">
{entry.isGlobal ? "Global Skills:" : "Workspace Skills:"}
</Text>
</Box>
)}
<SkillRow isSelected={actualIndex === selectedIndex} skill={entry.skill} />
</React.Fragment>
)
})}
</Box>
)}
{/* Marketplace link - selectable */}
{showMarketplace && (
<Box marginTop={1}>
<Text color={isMarketplaceSelected ? "cyan" : undefined}>
{isMarketplaceSelected ? " " : " "}
<Text color={COLORS.primaryBlue}>Browse more skills at https://skills.sh/</Text>
</Text>
</Box>
)}
{/* Help text */}
<Box marginTop={1}>
<Text color="gray">
/ Navigate Enter {isMarketplaceSelected ? "Open" : "Use"}
{!isMarketplaceSelected && " • Space Toggle"}
</Text>
</Box>
</Box>
</Panel>
)
}
const SkillRow: React.FC<{ skill: SkillInfo; isSelected: boolean }> = ({ skill, isSelected }) => {
return (
<Box flexDirection="column">
<Box>
<Text color={isSelected ? "cyan" : undefined}>
{isSelected ? " " : " "}
<Text color={skill.enabled ? "green" : "red"}>{skill.enabled ? "●" : "○"}</Text>
<Text> </Text>
<Text bold color="white">
{skill.name}
</Text>
</Text>
</Box>
{skill.description && (
<Box marginLeft={4}>
<Text color="gray">
{skill.description.length > 60 ? skill.description.slice(0, 57) + "..." : skill.description}
</Text>
</Box>
)}
</Box>
)
}
+12
View File
@@ -0,0 +1,12 @@
import { describe, expect, it } from "vitest"
import { getAllFeaturedModels } from "./featured-models"
describe("featured models", () => {
it("includes display names for all featured models", () => {
const models = getAllFeaturedModels()
for (const model of models) {
expect(model.name).toBeTruthy()
}
})
})
+19 -19
View File
@@ -10,53 +10,53 @@ export interface FeaturedModel {
labels: string[]
}
export const FEATURED_MODELS = {
export const FEATURED_MODELS: { recommended: FeaturedModel[]; free: FeaturedModel[] } = {
recommended: [
{
id: "anthropic/claude-sonnet-4.5",
name: "Claude Sonnet 4.5",
description: "Best balance of speed, cost, and quality",
labels: ["BEST"],
},
{
id: "anthropic/claude-opus-4.6",
name: "Claude Opus 4.6",
description: "State-of-the-art for complex coding",
labels: ["BEST"],
labels: ["NEW"],
},
{
id: "openai/gpt-5.2-codex",
name: "GPT 5.2 Codex",
description: "OpenAI's latest with strong coding abilities",
labels: ["NEW"],
labels: ["HOT"],
},
{
id: "google/gemini-3-pro-preview",
name: "Gemini 3 Pro",
description: "1M context window for large codebases",
labels: ["TRENDING"],
},
] as FeaturedModel[],
],
free: [
{
id: "minimax/minimax-m2.1",
name: "MiniMax M2.1",
description: "Exceptional Multi-Programming Language Capabilities",
id: "minimax/minimax-m2.5",
name: "MiniMax M2.5",
description: "MiniMax-M2.5 is a lightweight, state-of-the-art LLM optimized for coding and agentic workflows",
labels: ["FREE"],
},
{
id: "moonshotai/kimi-k2.5",
name: "Kimi K2.5",
description: "State-of-the-art model topping benchmarks",
id: "z-ai/glm-5",
name: "Z-AI GLM5",
description: "Z.AI's latest GLM 5 model with strong coding and agent performance",
labels: ["FREE"],
},
{
id: "kwaipilot/kat-coder-pro",
name: "KAT Coder Pro",
description: "Advanced agentic coding model",
description: "KwaiKAT's most advanced agentic coding model in the KAT-Coder series",
labels: ["FREE"],
},
{
id: "arcee-ai/trinity-large-preview:free",
name: "Trinity Large Preview",
description: "US built open source coding model",
description: "Arcee AI's advanced large preview model in the Trinity series",
labels: ["FREE"],
},
] as FeaturedModel[],
],
}
export function getAllFeaturedModels(): FeaturedModel[] {
+38 -9
View File
@@ -15,9 +15,7 @@ import { HostProvider } from "@/hosts/host-provider"
import { FileEditProvider } from "@/integrations/editor/FileEditProvider"
import { openAiCodexOAuthManager } from "@/integrations/openai-codex/oauth"
import { StandaloneTerminalManager } from "@/integrations/terminal/standalone/StandaloneTerminalManager"
import { BannerService } from "@/services/banner/BannerService"
import { ErrorService } from "@/services/error/ErrorService"
import { initializeDistinctId } from "@/services/logging/distinctId"
import { telemetryService } from "@/services/telemetry"
import { PostHogClientProvider } from "@/services/telemetry/providers/posthog/PostHogClientProvider"
import { HistoryItem } from "@/shared/HistoryItem"
@@ -76,7 +74,24 @@ async function disposeTelemetryServices(): Promise<void> {
await Promise.allSettled([telemetryService.dispose(), PostHogClientProvider.getInstance().dispose()])
}
/**
* Restore yoloModeToggled to its original value from before this CLI session.
* This ensures the --yolo flag is session-only and doesn't leak into future runs.
* Must be called before flushPendingState so the restored value gets persisted.
*/
function restoreYoloState(): void {
if (savedYoloModeToggled !== null) {
try {
StateManager.get().setGlobalState("yoloModeToggled", savedYoloModeToggled)
savedYoloModeToggled = null
} catch {
// StateManager may not be initialized (e.g., early exit before init)
}
}
}
async function disposeCliContext(ctx: CliContext): Promise<void> {
restoreYoloState()
await ctx.controller.stateManager.flushPendingState()
await ctx.controller.dispose()
await ErrorService.get().dispose()
@@ -189,9 +204,12 @@ function applyTaskOptions(options: TaskOptions): void {
telemetryService.captureHostEvent("max_consecutive_mistakes_flag", String(maxConsecutiveMistakes))
}
// Set yolo mode based on --yolo flag
// Override yolo mode only if --yolo flag is explicitly passed.
// The original value is saved in initializeCli and restored on exit.
if (options.yolo) {
StateManager.get().setGlobalState("yoloModeToggled", true)
const state = StateManager.get()
savedYoloModeToggled = state.getGlobalSettingsKey("yoloModeToggled") ?? false
state.setGlobalState("yoloModeToggled", true)
telemetryService.captureHostEvent("yolo_flag", "true")
}
@@ -296,6 +314,9 @@ let activeContext: CliContext | null = null
let isShuttingDown = false
// Track if we're in plain text mode (no Ink UI) - set by runTask when piped stdin detected
let isPlainTextMode = false
// Track the original yoloModeToggled value from before this CLI session so we can restore it on exit.
// The --yolo flag should only affect the current invocation, not persist across runs.
let savedYoloModeToggled: boolean | null = null
/**
* Wait for stdout to fully drain before exiting.
@@ -337,6 +358,10 @@ function setupSignalHandlers() {
printWarning(`${signal} received, shutting down...`)
try {
// Restore yolo state before any cleanup - this is idempotent and safe
// even if disposeCliContext also calls it (restoreYoloState checks savedYoloModeToggled !== null)
restoreYoloState()
if (activeContext) {
const task = activeContext.controller.task
if (task) {
@@ -344,6 +369,12 @@ function setupSignalHandlers() {
}
await disposeCliContext(activeContext)
} else {
// Best-effort flush of restored yolo state when no active context
try {
await StateManager.get().flushPendingState()
} catch {
// StateManager may not be initialized yet
}
await ErrorService.get().dispose()
await disposeTelemetryServices()
}
@@ -407,7 +438,6 @@ async function initializeCli(options: InitOptions): Promise<CliContext> {
Logger.subscribe(logToChannel)
await ClineEndpoint.initialize(EXTENSION_DIR)
await initializeDistinctId(extensionContext)
// Auto-update check (after endpoints initialized, so we can detect bundled configs)
autoUpdateOnStartup(CLI_VERSION)
@@ -437,6 +467,7 @@ async function initializeCli(options: InitOptions): Promise<CliContext> {
)
await StateManager.initialize(extensionContext as any)
await ErrorService.initialize()
// Initialize OpenAI Codex OAuth manager with extension context for secrets storage
@@ -445,8 +476,6 @@ async function initializeCli(options: InitOptions): Promise<CliContext> {
const webview = HostProvider.get().createWebviewProvider() as CliWebviewProvider
const controller = webview.controller
BannerService.initialize(webview.controller)
await telemetryService.captureExtensionActivated()
await telemetryService.captureHostEvent("cline_cli", "initialized")
@@ -761,9 +790,9 @@ program
program
.command("auth")
.description("Authenticate a provider and configure what model is used")
.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic)")
.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic, moonshot)")
.option("-k, --apikey <key>", "API key for the provider")
.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-5-20250929)")
.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-6, kimi-k2.5)")
.option("-b, --baseurl <url>", "Base URL (optional, only for openai provider)")
.option("-v, --verbose", "Show verbose output")
.option("-c, --cwd <path>", "Working directory for the task")
+1
View File
@@ -13,6 +13,7 @@ export default defineConfig({
},
resolve: {
alias: {
vscode: path.resolve(__dirname, "src/vscode-shim.ts"),
// Match tsconfig paths - baseUrl is parent directory
"@": path.resolve(__dirname, "../src"),
"@api": path.resolve(__dirname, "../src/core/api"),
+4 -4
View File
@@ -202,15 +202,15 @@ If Cline can't access files or run commands:
Learn about Cline CLI's core capabilities and use cases.
</Card>
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
Master interactive mode, headless automation, and multi-instance workflows.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Skills" icon="graduation-cap" href="/features/skills">
<Card title="Skills" icon="graduation-cap" href="/customization/skills">
Understand how Cline's Skills work across all editors via ACP.
</Card>
<Card title="Hooks" icon="link" href="/features/hooks/index">
<Card title="Hooks" icon="link" href="/customization/hooks">
Learn how to enforce policies with Hooks in any editor.
</Card>
</Columns>
-482
View File
@@ -1,482 +0,0 @@
---
title: "CLI Reference (Deprecated)"
description: "Command reference for Cline CLI versions earlier than 2.0.0 (deprecated). For the latest commands and options, see the current Cline CLI reference."
---
Complete command reference for Cline CLI. Use this for detailed documentation on all commands, options, and configuration.
For quick help in your terminal:
```bash
cline --help # Show all commands
cline task --help # Show task-specific commands
man cline # View the full manual page
```
## Manual Page
The complete manual page for the Cline CLI:
```
CLINE(1) User Commands CLINE(1)
NAME
cline - orchestrate and interact with Cline AI coding agents
SYNOPSIS
cline [prompt] [options]
cline command [subcommand] [options] [arguments]
DESCRIPTION
Try: cat README.md | cline "Summarize this for me:"
cline is a command-line interface for orchestrating multiple Cline AI
coding agents. Cline is an autonomous AI agent who can read, write,
and execute code across your projects. He operates through a
client-server architecture where Cline Core runs as a standalone
service, and the CLI acts as a scriptable interface for managing tasks,
instances, and agent interactions.
The CLI is designed for both interactive use and automation, making it
ideal for CI/CD pipelines, parallel task execution, and terminal-based
workflows. Multiple frontends (CLI, VSCode, JetBrains) can attach to
the same Cline Core instance, enabling seamless task handoff between
environments.
MODES OF OPERATION
Instant Task Mode
The simplest invocation: cline "prompt here" immediately spawns
an instance, creates a task, and enters chat mode. This is
equivalent to running cline instance new && cline task new &&
cline task chat in sequence.
Subcommand Mode
Advanced usage with explicit control: cline <command>
[subcommand] [options] provides fine-grained control over
instances, tasks, authentication, and configuration.
AGENT BEHAVIOR
Cline operates in two primary modes:
ACT MODE
Cline actively uses tools to accomplish tasks. He can read
files, write code, execute commands, use a headless browser, and
more. This is the default mode for task execution.
PLAN MODE
Cline gathers information and creates a detailed plan before
implementation. He explores the codebase, asks clarifying
questions, and presents a strategy for user approval before
switching to ACT MODE.
INSTANT TASK OPTIONS
When using the instant task syntax cline "prompt" the following options
are available:
-o, --oneshot
Full autonomous mode. Cline completes the task and stops
following after completion. Example: cline -o "what's 6 + 8?"
-s, --setting setting value
Override a setting for this task
-y, --no-interactive, --yolo
Enable fully autonomous mode. Disables all interactivity:
• ask_followup_question tool is disabled
• attempt_completion happens automatically
• execute_command runs in non-blocking mode with timeout
• PLAN MODE automatically switches to ACT MODE
-m, --mode mode
Starting mode. Options: act (default), plan
-w, --workspace path
Additional workspace paths. Can be specified multiple times to
include multiple directories. The current working directory is
always included as the first workspace. Example: cline -w
/path/to/other/project "refactor shared code"
GLOBAL OPTIONS
These options apply to all subcommands:
-F, --output-format format
Output format. Options: rich (default), json, plain
-h, --help
Display help information for the command.
-v, --verbose
Enable verbose output for debugging.
COMMANDS
Authentication
cline auth [provider] [key]
cline a [provider] [key]
Configure authentication for AI model providers. Launches an
interactive wizard if no arguments provided. If provider is
specified without a key, prompts for the key or launches the
appropriate OAuth flow.
Instance Management
Cline Core instances are independent agent processes that can run in
the background. Multiple instances can run simultaneously, enabling
parallel task execution.
cline instance
cline i
Display instance management help.
cline instance new [-d|--default]
cline i n [-d|--default]
Spawn a new Cline Core instance. Use --default to set it as
the default instance for subsequent commands.
cline instance list
cline i l
List all running Cline Core instances with their addresses and
status.
cline instance default address
cline i d address
Set the default instance to avoid specifying --address in task
commands.
cline instance kill address [-a|--all]
cline i k address [-a|--all]
Terminate a Cline Core instance. Use --all to kill all running
instances.
Task Management
Tasks represent individual work items that Cline executes. Tasks
maintain conversation history, checkpoints, and settings.
cline task [-a|--address ADDR]
cline t [-a|--address ADDR]
Display task management help. The --address flag specifies
which Cline Core instance to use (e.g., localhost:50052).
cline task new prompt [options]
cline t n prompt [options]
Create a new task in the default or specified instance.
Options:
-s, --setting setting value
Set task-specific settings
-y, --no-interactive, --yolo
Enable autonomous mode
-m, --mode mode
Starting mode (act or plan)
cline task open task-id [options]
cline t o task-id [options]
Resume a previous task from history. Accepts the same options
as task new.
cline task list
cline t l
List all tasks in history with their id and snippet
cline task chat
cline t c
Enter interactive chat mode for the current task. Allows
back-and-forth conversation with Cline.
cline task send [message] [options]
cline t s [message] [options]
Send a message to Cline. If no message is provided, reads from
stdin. Options:
-a, --approve
Approve Cline's proposed action
-d, --deny
Deny Cline's proposed action
-f, --file FILE
Attach a file to the message
-y, --no-interactive, --yolo
Enable autonomous mode
-m, --mode mode
Switch mode (act or plan)
cline task view [-f|--follow] [-c|--follow-complete]
cline t v [-f|--follow] [-c|--follow-complete]
Display the current conversation. Use --follow to stream
updates in real-time, or --follow-complete to follow until task
completion.
cline task restore checkpoint
cline t r checkpoint
Restore the task to a previous checkpoint state.
cline task pause
cline t p
Pause task execution.
Configuration
Configuration can be set globally. Override these global settings for
a task using the --setting flag
cline config
cline c
cline config set key value
cline c s key value
Set a configuration variable.
cline config get key
cline c g key
Read a configuration variable.
cline config list
cline c l
List all configuration variables and their values.
Context Window Configuration
For local model providers, you can configure the context window size:
Ollama
cline config s ollama-api-options-ctx-num=32768
LM Studio
cline config s lm-studio-max-tokens=32768
For other providers (Anthropic, OpenRouter, etc.), the context window
is defined per model in the model metadata and is not user-settable.
Cline uses each model's built-in context limits automatically.
TASK SETTINGS
Task settings are persisted in the ~/.cline/x/tasks directory. When
resuming a task with cline task open, task settings are automatically
restored.
Common settings include:
yolo Enable autonomous mode (true/false)
mode Starting mode (act/plan)
hooks_enabled
Enable or disable hooks for the task (true/false)
HOOKS INTEGRATION
Hooks let you inject custom logic into Cline's workflow at key moments.
They can validate operations before they execute, monitor tool usage,
and shape AI decisions. This allows you to integrate hooks into
automated workflows, CI/CD pipelines, and headless task execution.
Enable hooks for a task:
cline "prompt" -s hooks_enabled=true
Configure hooks globally:
cline config set hooks-enabled=true
cline config get hooks-enabled
Note: Hooks in the CLI are only supported on macOS and Linux.
For complete hooks documentation, see:
<https://docs.cline.bot/features/hooks/index>
NOTES & EXAMPLES
The cline task send and cline task new commands support reading from
stdin, enabling powerful pipeline compositions:
cat requirements.txt | cline task send
echo "Refactor this code" | cline -y
Instance Management
Manage multiple Cline instances:
# Start a new instance and make it default
cline instance new --default
# List all running instances
cline instance list
# Kill a specific instance
cline instance kill localhost:50052
# Kill all CLI instances
cline instance kill --all-cli
Task History
Work with task history:
# List previous tasks
cline task list
# Resume a previous task
cline task open 1760501486669
# View conversation history
cline task view
# Start interactive chat with this task
cline task chat
ARCHITECTURE
Cline operates on a three-layer architecture:
Presentation Layer
User interfaces (CLI, VSCode, JetBrains) that connect to Cline
Core via gRPC
Cline Core
The autonomous agent service handling task management, AI model
integration, state management, tool orchestration, and real-time
streaming updates
Host Provider Layer
Environment-specific integrations (VSCode APIs, JetBrains APIs,
shell APIs) that Cline Core uses to interact with the host
system
BUGS
Report bugs at: <https://github.com/cline/cline/issues>
For real-time help, join the Discord community at:
<https://discord.gg/cline>
SEE ALSO
Full documentation: <https://docs.cline.bot>
AUTHORS
Cline is developed by the Cline Bot Inc. and the open source community.
COPYRIGHT
Copyright © 2025 Cline Bot Inc. Licensed under the Apache License 2.0.
```
## JSON output (-F json)
When you run a command with `-F json` (or `--output-format json`), Cline prints each client message as JSON.
### ClineMessage schema
| Field | Type | Required | Notes |
|-------|------|----------|-------|
| `type` | `"ask" or "say"` | Yes | Top-level message category. |
| `text` | `string` | Yes | Human-readable message content. |
| `ts` | `number` | Yes | Unix epoch timestamp in milliseconds. |
| `reasoning` | `string` | No | Omitted when empty. |
| `say` | `string` | No | Omitted when empty. Present when `type` is `"say"`. |
| `ask` | `string` | No | Omitted when empty. Present when `type` is `"ask"`. |
| `partial` | `boolean` | No | Omitted when false. `true` for streaming updates. |
| `images` | `string[]` | No | Omitted when empty. Image URIs when included with a message. |
| `files` | `string[]` | No | Omitted when empty. File paths when attached to a message. |
| `lastCheckpointHash` | `string` | No | Omitted when empty. Git checkpoint hash when available. |
| `isCheckpointCheckedOut` | `boolean` | No | Omitted when false. `true` if Cline checked out a checkpoint. |
| `isOperationOutsideWorkspace` | `boolean` | No | Omitted when false. `true` if an operation happened outside the workspace. |
<Note>
Most fields are optional and omitted when empty. If you parse this output, treat missing fields as “not present”, not as empty strings.
</Note>
### Example
```json
{
"type": "say",
"text": "Cline is about to run a command.",
"ts": 1760501486669,
"say": "command",
"partial": false
}
```
### Shell Completion
Generate autocompletion scripts for various shells:
#### Bash
```bash
# Generate bash completion
cline completion bash > /etc/bash_completion.d/cline
# Or for user-level installation
cline completion bash > ~/.local/share/bash-completion/completions/cline
```
#### Zsh
```bash
# Generate zsh completion
cline completion zsh > "${fpath[1]}/_cline"
# Or add to your .zshrc
echo 'source <(cline completion zsh)' >> ~/.zshrc
```
#### Fish
```bash
# Generate fish completion
cline completion fish > ~/.config/fish/completions/cline.fish
```
#### PowerShell
```powershell
# Generate PowerShell completion
cline completion powershell > cline.ps1
# Add to your PowerShell profile
Add-Content $PROFILE "cline completion powershell | Out-String | Invoke-Expression"
```
### Version Command
```bash
# Show version information
cline version
```
### Environment Variables
#### CLINE_DIR
Override the default Cline directory location:
```bash
# Override default Cline directory
export CLINE_DIR=/custom/path
# Default: ~/.cline
```
This directory is used for:
- Instance registry database
- Configuration files
- Task history
- Checkpoints
+3 -5
View File
@@ -3,8 +3,6 @@ title: "CLI Reference"
description: "Complete command reference for Cline CLI including all commands, flags, and configuration options"
---
# CLI Reference
This page documents all available commands, flags, and configuration options for Cline CLI. For quick help in your terminal, use:
```bash
@@ -316,7 +314,7 @@ When using `--json`, each message is output as a JSON object (one per line):
Cline stores all data in `~/.cline/` by default:
```
```text
~/.cline/
├── data/ # Configuration directory
│ ├── globalState.json # Global settings
@@ -416,8 +414,8 @@ cline auth -p openai -k your-key -b https://api.example.com/v1
Keyboard shortcuts, slash commands, and file mentions.
</Card>
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
Interactive mode, direct execution, and automation patterns.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
+6 -6
View File
@@ -38,7 +38,7 @@ Rules help Cline understand your project's conventions, coding standards, and pr
### Workflows Tab
View and manage [workflows](/features/slash-commands/workflows/index):
View and manage [workflows](/customization/workflows):
- List available workflows
- View workflow definitions
@@ -46,7 +46,7 @@ View and manage [workflows](/features/slash-commands/workflows/index):
### Hooks Tab
Configure [hooks](/features/hooks/index) for custom logic integration:
Configure [hooks](/customization/hooks) for custom logic integration:
- Enable/disable hooks globally
- View configured hook scripts
@@ -58,7 +58,7 @@ Hooks must be enabled via settings. Use `cline config` to toggle `hooks-enabled`
### Skills Tab
Manage [skills](/features/skills) that extend Cline's capabilities:
Manage [skills](/customization/skills) that extend Cline's capabilities:
- View available skills
- Enable/disable specific skills
@@ -68,7 +68,7 @@ Manage [skills](/features/skills) that extend Cline's capabilities:
Cline stores configuration in `~/.cline/data/`:
```
```text
~/.cline/
├── data/ # Configuration directory
│ ├── globalState.json # Global settings
@@ -268,8 +268,8 @@ cline auth # Re-authenticate
## Next Steps
<Columns cols={2}>
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
Learn about interactive mode, direct execution, and automation patterns.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="CLI Reference" icon="terminal" href="/cline-cli/cli-reference">
+457
View File
@@ -0,0 +1,457 @@
---
title: "Getting Started"
description: "Run Cline AI coding agents directly in your terminal with an interactive CLI or automated workflows"
---
## What is Cline CLI?
Cline CLI brings the full power of Cline to your terminal. Whether you prefer an interactive experience or automated workflows for CI/CD pipelines, the CLI adapts to your needs.
The CLI supports macOS, Linux, and Windows, and works with all the same AI providers as the VS Code extension.
## Two Ways to Use Cline CLI
The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:
### Interactive Mode
Interactive mode is designed for **hands-on development sessions** where you want to collaborate with Cline in real-time. It provides a rich terminal interface that feels like chatting with an AI assistant.
**When it activates:** Running `cline` without arguments, or when stdin is a TTY (terminal).
```bash
cline
```
Key features:
- **Real-time conversation** - Type messages, see Cline's responses, and iterate on tasks
- **Visual feedback** - Animated welcome screen, syntax-highlighted code, and progress indicators
- **File mentions** with `@` - Reference workspace files with fuzzy search autocomplete
- **Slash commands** with `/` - Quick access to `/settings`, `/history`, `/models`, and workflows
- **Keyboard shortcuts** - `Tab` to toggle Plan/Act, `Shift+Tab` for auto-approve all
- **Session summaries** - See tasks completed, files modified, and token usage on exit
- **Settings panel** - Configure providers, models, and features without leaving the CLI
Interactive mode keeps you in control. You review Cline's plan, approve or modify actions, and guide the conversation.
[Learn more about interactive mode →](/cline-cli/interactive-mode)
### Headless Mode (Non-Interactive)
Headless mode is designed for **automation, scripting, and CI/CD pipelines** where human interaction isn't possible or desired.
**When it activates:** Using the `-y`/`--yolo` flag, `--json` flag, piping input/output, or when stdin is not a TTY.
```bash
# Headless with auto-approval (YOLO mode)
cline -y "Run tests and fix any failures"
# Headless with JSON output for parsing
cline --json "List all TODO comments" | jq '.text'
# Headless via piped input
cat README.md | cline "Summarize this document"
# Chain multiple headless commands
git diff | cline -y "explain these changes" | cline -y "write a commit message"
```
Key features:
- **No visual interface** - Clean text or JSON output suitable for scripting
- **Automatic execution** - With `-y`, Cline approves all actions and runs autonomously
- **Process control** - Exits automatically when the task completes
- **Piped workflows** - Read from stdin, write to stdout, chain with other commands
- **Machine-readable output** - Use `--json` to get structured output for parsing
<Warning>
Headless mode with `-y` gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
</Warning>
### Mode Detection Summary
Cline automatically detects which mode to use based on your invocation. This table shows how different command patterns trigger each mode, helping you predict behavior in scripts and interactive sessions.
| Invocation | Mode | Reason |
|------------|------|--------|
| `cline` | Interactive | No arguments, TTY connected |
| `cline "task"` | Interactive | TTY connected |
| `cline -y "task"` | Headless | YOLO flag forces headless |
| `cline --json "task"` | Headless | JSON flag forces headless |
| `cat file \| cline "task"` | Headless | stdin is piped |
| `cline "task" > output.txt` | Headless | stdout is redirected |
[Learn more about headless mode →](/cline-cli/three-core-flows)
## Supported Model Providers
Cline CLI supports all providers available in the VS Code extension:
- **Anthropic** (Claude)
- **OpenAI** (GPT-4o, GPT-4)
- **OpenAI Codex** (ChatGPT subscription)
- **OpenRouter**
- **AWS Bedrock**
- **Google Gemini**
- **X AI (Grok)**
- **Cerebras**
- **DeepSeek**
- **Ollama** (local models)
- **LM Studio** (local models)
- **OpenAI Compatible** (any compatible API)
During setup, authenticate with `cline auth` to configure your preferred provider. [See authentication →](#authenticate)
## What You Can Build
### Automated Code Maintenance
Keep your codebase healthy with automated fixes. Cline scans for issues and applies corrections across multiple files.
```bash
cline -y "Fix all ESLint errors in src/"
```
Finds and fixes linting violations throughout your source directory.
```bash
cline -y "Update all deprecated React lifecycle methods"
```
Migrates legacy code patterns to modern equivalents (e.g., `componentWillMount` → `useEffect`).
```bash
cline -y "Update dependencies with known vulnerabilities"
```
Identifies outdated packages with security issues and updates them to safe versions.
### CI/CD Integration
Integrate Cline into your continuous integration pipelines for automated code review and documentation.
```bash
git diff origin/main | cline -y "Review these changes for issues"
```
Pipes your PR diff to Cline for automated code review, catching bugs and style issues before merge.
```bash
git log --oneline v1.0..v1.1 | cline -y "Write release notes"
```
Generates human-readable release notes from your commit history between two tags.
```bash
cline -y "Run tests and fix failures" --timeout 600
```
Executes your test suite, analyzes failures, and attempts fixes with a 10-minute timeout.
### Development Workflows
From quick edits to complex refactors, Cline adapts to your workflow.
```bash
cline
```
Launches interactive mode for exploratory development and back-and-forth collaboration.
```bash
cline "Refactor this function to use async/await"
```
Executes a focused task directly from the command line with approval prompts at key steps.
```bash
cline "Based on @src/api.ts, add error handling to all endpoints"
```
Uses file mentions (`@`) to give Cline context about specific files in your workspace.
### Custom Shell Pipelines
Chain Cline with other CLI tools to build powerful automation workflows.
```bash
gh pr diff 123 | cline -y "Review this PR"
```
Fetches a GitHub PR diff and pipes it directly to Cline for review.
```bash
cline --json "List all TODO comments" | jq '.text'
```
Outputs structured JSON that you can process with tools like `jq` for scripting.
```bash
git diff | cline -y "explain" | cline -y "write a haiku about these changes"
```
Chains multiple Cline invocations together for creative multi-step workflows.
## Features at a Glance
| Feature | Interactive Mode | Non-Interactive Mode |
|---------|------------------|----------------------|
| Interactive chat | ✓ | - |
| File mentions (@) | ✓ | ✓ (inline) |
| Slash commands (/) | ✓ | - |
| Settings panel | ✓ | `cline config` |
| Plan/Act toggle | ✓ (Tab) | `-p` / `-a` flags |
| Auto-approve | ✓ (Shift+Tab) | `-y` flag |
| Session summary | ✓ | - |
| JSON output | - | `--json` |
| Piped input | - | ✓ |
---
## Installation & Setup
In just a few minutes, you can install the CLI, authenticate with your preferred AI provider, and start running tasks from any directory on your machine.
### Prerequisites
Cline CLI requires **Node.js version 20 or higher**. We recommend Node.js 22 for the best experience.
Check your Node.js version:
```bash
node --version
```
If you need to install or update Node.js, visit [nodejs.org](https://nodejs.org) or use a version manager like [nvm](https://github.com/nvm-sh/nvm).
### Install Cline CLI
Install globally via npm:
```bash
npm install -g cline
```
Verify the installation:
```bash
cline version
```
<Tip>
To install a specific version, use `npm install -g cline@2.0.0`. Check [npm](https://www.npmjs.com/package/cline) for available versions.
</Tip>
### Authenticate
After installation, run the authentication wizard:
```bash
cline auth
```
This launches an interactive wizard with multiple options. Choose the method that works best for your workflow.
#### Option 1: Sign in with Cline (Recommended)
Select **"Sign in with Cline"** to authenticate with your Cline account via OAuth. Your browser opens automatically to complete sign-in.
#### Option 2: Sign in with ChatGPT Subscription
If you have a ChatGPT Plus or Pro subscription, select **"Sign in with ChatGPT Subscription"**. This uses OpenAI's Codex OAuth to authenticate with your existing subscription.
#### Option 3: Import from Existing Tools
Already using another AI coding CLI? Cline can import your existing configuration:
- **Import from Codex CLI** - Imports credentials from `~/.codex/auth.json`
- **Import from OpenCode** - Imports configuration from `~/.local/share/opencode/auth.json`
#### Option 4: Bring Your Own API Key
Select **"Bring your own API key"** to manually configure any supported provider. Or skip the wizard entirely with flags:
```bash
# Anthropic (Claude)
cline auth -p anthropic -k sk-ant-api-xxxxx -m claude-sonnet-4-5-20250929
# OpenAI
cline auth -p openai-native -k sk-xxxxx -m gpt-4o
# OpenRouter
cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929
# OpenAI-compatible provider with custom base URL
cline auth -p openai -k your-api-key -b https://api.example.com/v1
```
**Quick Setup Flags:**
| Flag | Description |
|------|-------------|
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
| `-k, --apikey <key>` | Your API key |
| `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
| `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
<Tip>
Flags are especially useful for scripting, CI/CD environments, or setting up multiple machines.
</Tip>
#### Supported Providers
| Provider | Provider ID | Notes |
|----------|-------------|-------|
| Anthropic | `anthropic` | Direct Claude API access |
| OpenAI | `openai-native` | GPT-4o, GPT-4, etc. |
| OpenAI Codex | `openai-codex` | ChatGPT subscription OAuth |
| OpenRouter | `openrouter` | Access multiple providers |
| AWS Bedrock | `bedrock` | Claude via AWS |
| Google Gemini | `gemini` | Gemini Pro, etc. |
| X AI (Grok) | `xai` | Grok models |
| Cerebras | `cerebras` | Fast inference |
| DeepSeek | `deepseek` | DeepSeek models |
| Ollama | `ollama` | Local models |
| LM Studio | `lmstudio` | Local models |
| OpenAI Compatible | `openai` | Any OpenAI-compatible API |
### Verify Your Setup
Confirm everything is working with a simple test:
```bash
cline "What is 2 + 2?"
```
If Cline responds with an answer, your installation and authentication are complete.
Check your current configuration:
```bash
cline config
```
### Quick Start
Now you're ready to use Cline. Choose how you want to work:
#### Interactive Mode
Launch the interactive CLI for development:
```bash
cline
```
You'll see the Cline welcome screen. Type your task and press Enter. Use:
- `Tab` to toggle between Plan and Act modes
- `Shift+Tab` to enable auto-approve
- `/help` for available commands
[Learn more about interactive mode →](/cline-cli/interactive-mode)
#### Direct Task Execution
Run a task directly from your shell:
```bash
cline "Add error handling to utils.js"
```
For non-interactive execution (perfect for scripts and CI/CD):
```bash
cline -y "Run tests and fix any failures"
```
[Learn more about headless mode →](/cline-cli/three-core-flows)
### Switching Providers
To change your configured provider at any time:
```bash
cline auth
```
You can also use the settings panel in interactive mode:
```bash
cline
# Then type: /settings
# Navigate to the API tab
```
### Updating
Check for updates and install the latest version:
```bash
cline update
```
Or update manually via npm:
```bash
npm update -g cline
```
### Troubleshooting
#### Command Not Found
If `cline` is not found after installation:
1. Ensure npm global bin is in your PATH:
```bash
npm bin -g
```
2. Add the path to your shell configuration (`.bashrc`, `.zshrc`, etc.):
```bash
export PATH="$PATH:$(npm bin -g)"
```
3. Restart your terminal or source your shell config.
#### Permission Errors
If you get permission errors during installation:
```bash
# Option 1: Use a Node version manager (recommended)
# nvm, fnm, or volta handle permissions automatically
# Option 2: Fix npm permissions
# See: https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally
```
#### OAuth Flow Issues
If the browser doesn't open automatically during OAuth:
1. Copy the URL from the terminal
2. Paste it in your browser manually
3. Complete the sign-in flow
4. Return to the terminal
#### API Key Validation
If your API key is rejected:
1. Verify the key is correct and hasn't expired
2. Check that you've selected the correct provider
3. Ensure your API account has the necessary permissions
**Provider-specific tips:**
- **Anthropic**: Keys start with `sk-ant-`
- **OpenAI**: Keys start with `sk-`
- **AWS Bedrock**: Requires AWS credentials configured separately. See [AWS Bedrock documentation](/provider-config/aws-bedrock/api-key).
### Uninstallation
To remove Cline CLI:
```bash
npm uninstall -g cline
```
To also remove configuration data:
```bash
rm -rf ~/.cline
```
## Next Steps
- **[Interactive Mode](/cline-cli/interactive-mode)** - Master the interactive CLI with shortcuts and slash commands
- **[Headless Mode](/cline-cli/three-core-flows)** - Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows
- **[Configuration](/cline-cli/configuration)** - Configure settings, rules, workflows, and environment variables
- **[CLI Reference](/cline-cli/cli-reference)** - Complete command documentation with all flags and options
+8 -4
View File
@@ -74,6 +74,9 @@ cline auth -p openai-native -k sk-xxxxx -m gpt-4o
# OpenRouter
cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929
# Moonshot
cline auth -p moonshot -k sk-xxxxx -m kimi-k2.5
# OpenAI-compatible provider with custom base URL
cline auth -p openai -k your-api-key -b https://api.example.com/v1
```
@@ -82,7 +85,7 @@ cline auth -p openai -k your-api-key -b https://api.example.com/v1
| Flag | Description |
|------|-------------|
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`, `moonshot`) |
| `-k, --apikey <key>` | Your API key |
| `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
| `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
@@ -104,6 +107,7 @@ Flags are especially useful for scripting, CI/CD environments, or setting up mul
| X AI (Grok) | `xai` | Grok models |
| Cerebras | `cerebras` | Fast inference |
| DeepSeek | `deepseek` | DeepSeek models |
| Moonshot | `moonshot` | Kimi models via Moonshot AI |
| Ollama | `ollama` | Local models |
| LM Studio | `lmstudio` | Local models |
| OpenAI Compatible | `openai` | Any OpenAI-compatible API |
@@ -157,7 +161,7 @@ For non-interactive execution (perfect for scripts and CI/CD):
cline -y "Run tests and fix any failures"
```
[Learn more about CLI workflows →](/cline-cli/three-core-flows)
[Learn more about headless mode →](/cline-cli/three-core-flows)
## Switching Providers
@@ -260,8 +264,8 @@ rm -rf ~/.cline
Master the interactive CLI with shortcuts and slash commands.
</Card>
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
Learn interactive mode, direct execution, and automation patterns.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
+10 -10
View File
@@ -65,7 +65,7 @@ Keyboard shortcuts are the primary way to navigate and control the interactive C
Reference files from your workspace by typing `@` followed by the filename:
```
```text
@src/utils.ts can you add error handling to this file?
```
@@ -79,7 +79,7 @@ File search uses ripgrep for fast, fuzzy matching. You can type partial paths li
Include multiple files in a single message:
```
```text
Compare @src/old-api.ts with @src/new-api.ts and list the breaking changes
```
@@ -100,9 +100,9 @@ Type `/` to see available commands. Slash commands provide quick access to setti
### Workflow Commands
If you have [workflows](/features/slash-commands/workflows/index) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:
If you have [workflows](/customization/workflows) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:
```
```text
/code-review
```
@@ -120,7 +120,7 @@ Access the settings panel with `/settings`. Navigate between tabs using arrow ke
## Plan and Act Modes
Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/features/plan-and-act).
Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/core-workflows/plan-and-act).
### Plan Mode
@@ -211,7 +211,7 @@ Use terminal multiplexers like tmux or split terminals to run multiple Cline ins
Give Cline context about what you're working on:
```
```text
I'm building a REST API with Express. The routes are in @src/routes/ and models in @src/models/. Help me add user authentication.
```
@@ -219,7 +219,7 @@ I'm building a REST API with Express. The routes are in @src/routes/ and models
When you're unsure about the best approach:
```
```text
[Tab to Plan mode]
How should I structure the database schema for a multi-tenant SaaS app?
```
@@ -228,7 +228,7 @@ How should I structure the database schema for a multi-tenant SaaS app?
The interactive CLI maintains conversation context. Build on previous messages:
```
```text
> Add a login endpoint
[Cline creates the endpoint]
@@ -242,8 +242,8 @@ The interactive CLI maintains conversation context. Build on previous messages:
## Next Steps
<Columns cols={2}>
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
Learn about interactive mode, direct execution, and automation patterns.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
+14 -5
View File
@@ -15,6 +15,15 @@ Ready to get started? Check out the [installation guide](/cline-cli/installation
## Two Ways to Use Cline CLI
<Columns cols={2}>
<Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
**For hands-on development.** Launch `cline` in your terminal and collaborate with Cline in real-time — chat, review plans, approve actions, and iterate on tasks with a rich visual interface.
</Card>
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
**For automation & CI/CD.** Run `cline -y "task"` to let Cline work autonomously — no interaction needed. Pipe input/output, get JSON results, and chain commands in scripts and pipelines.
</Card>
</Columns>
The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:
### Interactive Mode
@@ -86,7 +95,7 @@ Cline automatically detects which mode to use based on your invocation. This tab
| `cat file \| cline "task"` | Headless | stdin is piped |
| `cline "task" > output.txt` | Headless | stdout is redirected |
[Learn more about CLI workflows →](/cline-cli/three-core-flows)
[Learn more about headless mode →](/cline-cli/three-core-flows)
## Supported Model Providers
@@ -210,8 +219,8 @@ Chains multiple Cline invocations together for creative multi-step workflows.
Master the interactive CLI with keyboard shortcuts and slash commands.
</Card>
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
Learn interactive mode, direct execution, and automation patterns.
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
@@ -222,7 +231,7 @@ Chains multiple Cline invocations together for creative multi-step workflows.
Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
</Card>
<Card title="Use in Other Editors" icon="code" href="/cline-cli/acp-editor-integrations">
Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
<Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
Real-world examples of headless workflows and automation patterns.
</Card>
</Columns>
@@ -3,8 +3,6 @@ title: "GitHub Actions Integration"
description: "Automatically respond to GitHub issues by mentioning @cline in comments using Cline CLI in GitHub Actions."
---
# GitHub Integration Sample
Automate GitHub issue analysis with AI. Mention `@cline` in any issue comment to trigger an autonomous investigation that reads files, analyzes code, and provides actionable insights - all running automatically in GitHub Actions.
@@ -273,7 +271,7 @@ git push
Once set up, simply mention `@cline` in any issue comment:
```
```text
@cline what's causing this error?
@cline analyze the root cause
+2 -4
View File
@@ -3,8 +3,6 @@ title: "GitHub Issue RCA Sample"
description: "Automated GitHub issue analysis using Cline CLI to identify root causes."
---
# GitHub Root Cause Analysis
Automated GitHub issue analysis using Cline CLI. This script uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues, outputting clean, parseable results that can be easily integrated into your development workflows.
<Note>
@@ -203,7 +201,7 @@ fi
This is where the magic happens:
```bash
# Ask Cline for his analysis, showing only the summary
# Ask Cline for its analysis, showing only the summary
cline -y "$PROMPT: $ISSUE_URL" --mode act $ADDRESS -F json | \
sed -n '/^{/,$p' | \
jq -r 'select(.say == "completion_result") | .text' | \
@@ -380,4 +378,4 @@ This pattern can be adapted for many other automation scenarios, from pull reque
- [CLI Installation Guide](https://docs.cline.bot/cline-cli/installation)
- [CLI Reference Documentation](https://docs.cline.bot/cline-cli/cli-reference)
- [Three Core Flows](https://docs.cline.bot/cline-cli/three-core-flows)
- [Headless Mode](https://docs.cline.bot/cline-cli/three-core-flows)
@@ -3,14 +3,8 @@ title: "GitHub PR Review"
description: "Automatically review Pull Requests with AI using Cline CLI in GitHub Actions."
---
# GitHub PR Review Sample
Automate code review for every Pull Request. Detailed analysis, security checks, and code suggestions provided by Cline running autonomously in GitHub Actions.
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/cli-pr-review.png" alt="Cline PR Review Comment" width="600" />
</Frame>
## The Workflow
When a PR is opened or marked ready for review, this workflow:
+8 -13
View File
@@ -3,26 +3,21 @@ title: "Model Orchestration"
description: "Use multiple AI models strategically: optimize costs, reduce bias, and leverage model-specific strengths in your workflows"
---
# Model Orchestration
Cline CLI's `--config` and `--thinking` flags enable sophisticated multi-model workflows. Instead of using a single model for all tasks, you can route different work to different models based on cost, capability, and specialization.
## Why Orchestrate Multiple Models?
**Cost Optimization**
- Use fast, cheap models (Haiku, Gemini Flash) for simple tasks like summarization
- Reserve expensive models (Opus, O1) for complex reasoning and planning
- Reduce API costs by 10-100x on routine operations
By routing work to the right model for the job, you can dramatically reduce API costs. Fast, inexpensive models like Haiku and Gemini Flash handle simple tasks such as summarization, while expensive models like Opus and O1 are reserved for complex reasoning and planning. This approach can reduce costs by 10-100x on routine operations.
**Bias Reduction**
- Different models catch different issues in code reviews
- Cross-validate solutions with multiple AI perspectives
- Reduce blind spots from single-model thinking
Different models catch different issues, so cross-validating solutions with multiple AI perspectives helps reduce blind spots that come from relying on a single model. In code reviews especially, combining viewpoints surfaces problems that any one model might miss.
**Specialization**
- Some models excel at code (Codex, DeepSeek)
- Others are better at documentation (GPT-4, Claude)
- Security analysis benefits from multiple viewpoints
Certain models excel in specific domains: Codex and DeepSeek are strong at code generation, while GPT-4 and Claude shine at documentation and prose. Security analysis in particular benefits from combining multiple model viewpoints, since each brings different training data and heuristics to the table.
## Pattern 1: CI/CD Code Review
@@ -213,8 +208,8 @@ cat *-sec.md | cline -y "find security issues all 3 reviews mentioned"
Complete documentation for --config and --thinking flags
</Card>
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
Learn about interactive mode, headless automation, and multi-instance workflows
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
<Card title="Model Selection Guide" icon="brain" href="/core-features/model-selection-guide">
+1 -1
View File
@@ -53,4 +53,4 @@ This section provides sample implementations that demonstrate various Cline CLI
- [CLI Installation Guide](/cline-cli/installation)
- [CLI Reference Documentation](/cline-cli/cli-reference)
- [Three Core Flows](/cline-cli/three-core-flows)
- [Headless Mode](/cline-cli/three-core-flows)
@@ -3,8 +3,6 @@ title: "Worktree Workflows"
description: "Use Git worktrees with Cline CLI to run parallel tasks, test different approaches, and pipe context between isolated environments"
---
# Worktree Workflows
Git worktrees let you have multiple branches checked out simultaneously in different folders. Combined with Cline CLI's `--cwd` flag, this enables powerful parallel development workflows and isolated experimentation.
<Tip>
@@ -269,7 +267,7 @@ git worktree remove ~/cline-worktrees/feature-auth
Complete documentation for --cwd and all other CLI flags
</Card>
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
Learn about interactive mode, task mode, and plain text workflows
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
</Card>
</Columns>
+101 -149
View File
@@ -1,134 +1,32 @@
---
title: "CLI Workflows"
description: "Learn the three ways to use Cline CLI: interactive mode, direct task execution, and automation"
title: "Headless Mode"
description: "Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows"
---
Cline CLI supports three primary workflows, each optimized for different use cases. Choose the approach that best fits your needs.
Headless mode runs Cline without an interactive interface — perfect for automation, scripting, and CI/CD pipelines where human interaction isn't possible or desired. Cline executes tasks, produces clean text or JSON output, and exits when complete.
For collaborative, conversational development, see [Interactive Mode](/cline-cli/interactive-mode) instead.
<Note>
**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler. Just run `cline` for interactive mode or `cline "task"` for direct execution.
**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler — just use `cline -y "task"` for headless execution.
</Note>
## 1. Interactive Mode
## When Headless Mode Activates
The interactive CLI provides the richest experience for interactive development.
Cline automatically enters headless mode when any of these conditions are met:
### Getting Started
| Invocation | Reason |
|------------|--------|
| `cline -y "task"` | `-y`/`--yolo` flag forces headless |
| `cline --json "task"` | `--json` flag forces headless |
| `cat file \| cline "task"` | stdin is piped |
| `cline "task" > output.txt` | stdout is redirected |
```bash
cline
```
If none of these apply (e.g., running `cline` or `cline "task"` in a terminal), Cline launches in [interactive mode](/cline-cli/interactive-mode).
This launches an interactive session in your current directory. Type your task, and Cline will analyze and execute it.
## YOLO Mode (Fully Autonomous)
### Key Features
**Plan/Act Mode Toggle** - Press `Tab` to switch between modes:
- **Plan Mode**: Cline analyzes your request and presents a strategy
- **Act Mode**: Cline executes actions directly
**Auto-approve Toggle** - Press `Shift+Tab` to enable automatic approval for all actions.
**Slash Commands** - Type `/` for quick access to:
- `/settings` - Configure providers, models, and features
- `/models` - Quick model switching
- `/history` - Browse and resume previous tasks
- `/clear` - Start a fresh task
- `/help` - Show available commands
**File Mentions** - Type `@` to reference workspace files:
```
@src/utils.ts add error handling to this file
```
**Session Summary** - When you exit with `Ctrl+C`, Cline displays a summary of your session including tasks completed, files modified, and token usage.
### When to Use Interactive Mode
- Exploring a new codebase
- Complex refactoring that requires back-and-forth
- Learning how Cline approaches problems
- Tasks where you want to review before executing
[Full Interactive Mode Guide →](/cline-cli/interactive-mode)
## 2. Direct Task Execution
Execute tasks directly from the command line without entering interactive mode.
### Basic Usage
```bash
cline "Add unit tests to utils.js"
```
Cline analyzes your task, creates a plan, and executes it. You'll be prompted for approval at key decision points.
### Piping Context
Pipe file contents or command output into Cline:
```bash
# Explain a file
cat README.md | cline "Summarize this document"
# Review git changes
git diff | cline "Review these changes and suggest improvements"
# Analyze command output
npm test 2>&1 | cline "Analyze these test failures and fix them"
```
### Chaining Cline Commands
Pipe Cline's output into another Cline instance for creative workflows:
```bash
# Explain changes, then write a commit message
git diff | cline -y "explain these changes" | cline -y "write a commit message for this"
# Generate code, then write tests
cline -y "create a fibonacci function" | cline -y "write unit tests for this code"
# Fun: Generate a poem about your code
git diff | cline -y "explain" | cline -y "write a haiku about this"
```
### Including Images
Attach images to your task:
```bash
cline task -i screenshot.png "Fix the layout issue shown in this screenshot"
# Or reference inline
cline "Fix the UI shown in @./design-mockup.png"
```
### Mode Selection
```bash
# Start in Plan mode (analyze before acting)
cline -p "Design a REST API for user management"
# Start in Act mode (default)
cline -a "Fix the typo in README.md"
```
### When to Use Direct Execution
- Quick, well-defined tasks
- Tasks with sufficient context in the prompt
- Scripting and shell workflows
- When you don't need interactive conversation
## 3. Automation & CI/CD
For fully autonomous operation in scripts, CI/CD pipelines, and automated workflows.
### YOLO Mode (Yes Mode)
The `-y` or `--yolo` flag enables fully autonomous operation:
The `-y` or `--yolo` flag enables fully autonomous operation — Cline approves all actions and runs without prompts:
```bash
cline -y "Run the test suite and fix any failures"
@@ -141,12 +39,59 @@ In YOLO mode:
- Perfect for CI/CD and scripts
<Warning>
Run YOLO mode on a clean git branch or directory. You get speed in exchange for oversight, so be ready to revert if needed.
YOLO mode gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
</Warning>
### JSON Output
### Mode Selection
Use `--json` for machine-readable output:
Control whether Cline plans first or acts immediately:
```bash
# Start in Plan mode (analyze before acting)
cline -y -p "Design a REST API for user management"
# Start in Act mode (default)
cline -y -a "Fix the typo in README.md"
```
## Piping Context
Pipe file contents or command output into Cline to provide context:
```bash
# Explain a file
cat README.md | cline "Summarize this document"
# Review git changes
git diff | cline "Review these changes and suggest improvements"
# Analyze command output
npm test 2>&1 | cline "Analyze these test failures and fix them"
# Pipe a GitHub PR diff
gh pr diff 123 | cline -y "Review this PR"
```
When stdin is piped, Cline automatically enters headless mode — the piped content becomes part of the task context.
## Chaining Commands
Pipe Cline's output into another Cline instance for multi-step workflows:
```bash
# Explain changes, then write a commit message
git diff | cline -y "explain these changes" | cline -y "write a commit message for this"
# Generate code, then write tests
cline -y "create a fibonacci function" | cline -y "write unit tests for this code"
# Fun: Generate a poem about your code
git diff | cline -y "explain" | cline -y "write a haiku about this"
```
## JSON Output
Use `--json` for machine-readable output that's easy to parse in scripts:
```bash
cline --json "List all TODO comments in the codebase" | jq '.text'
@@ -164,25 +109,36 @@ JSON output follows the same format as task files in `~/.cline/data/tasks/<id>/u
| `reasoning` | `string` | (Optional) Model reasoning |
| `partial` | `boolean` | (Optional) Streaming flag |
### Timeout Control
## Including Images
Set a maximum execution time:
Attach images to your headless task:
```bash
cline -y -i screenshot.png "Fix the layout issue shown in this screenshot"
# Or reference inline
cline -y "Fix the UI shown in @./design-mockup.png"
```
## Timeout Control
Set a maximum execution time to prevent runaway tasks:
```bash
cline -y --timeout 600 "Run full test suite"
```
### Environment Variables
## Environment Variables
Control Cline behavior via environment variables:
Control Cline behavior via environment variables — useful for CI/CD where you can't use interactive configuration.
**CLINE_DIR** - Custom configuration directory:
**CLINE_DIR** Custom configuration directory:
```bash
export CLINE_DIR=/path/to/config
cline -y "your task"
```
**CLINE_COMMAND_PERMISSIONS** - Restrict allowed commands:
**CLINE_COMMAND_PERMISSIONS** Restrict allowed commands:
```bash
export CLINE_COMMAND_PERMISSIONS='{"allow": ["npm *", "git *"], "deny": ["rm -rf *"]}'
cline -y "your task"
@@ -190,6 +146,8 @@ cline -y "your task"
See [Configuration](/cline-cli/configuration#environment-variables) for full documentation.
## CI/CD Integration
### GitHub Actions Example
Automate PR reviews with Cline:
@@ -232,7 +190,7 @@ jobs:
### Shell Script Example
Create a code review script:
Create a reusable code review script:
```bash
#!/bin/bash
@@ -252,30 +210,24 @@ fi
echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text'
```
### When to Use Automation Mode
## Common Use Cases
- CI/CD pipelines
- Scheduled maintenance tasks
- Batch processing
- Any workflow requiring non-interactive execution
## Choosing the Right Flow
| Use Case | Recommended Flow |
|----------|------------------|
| Exploring a new codebase | Interactive Mode |
| Complex refactoring | Interactive Mode (Plan first) |
| Quick file edits | Direct Execution |
| Code review | Direct Execution with pipe |
| CI/CD integration | Automation (`-y` flag) |
| Scheduled tasks | Automation (`-y` flag) |
| Learning Cline | Interactive Mode |
| Use Case | Example |
|----------|---------|
| Code review | `git diff \| cline -y "Review these changes"` |
| Fix test failures | `cline -y "Run tests and fix any failures"` |
| Generate release notes | `git log --oneline v1.0..v1.1 \| cline -y "Write release notes"` |
| Fix lint errors | `cline -y "Fix all ESLint errors in src/"` |
| Update dependencies | `cline -y "Update dependencies with known vulnerabilities"` |
| Migrate code patterns | `cline -y "Update all deprecated React lifecycle methods"` |
| PR automation | `gh pr diff 123 \| cline -y "Review this PR"` |
| Batch processing | `cline -y --json "List all TODO comments" \| jq '.text'` |
## Next Steps
<Columns cols={2}>
<Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
Master keyboard shortcuts, slash commands, and file mentions.
For hands-on development with keyboard shortcuts, slash commands, and file mentions.
</Card>
<Card title="CLI Reference" icon="book" href="/cline-cli/cli-reference">
@@ -286,7 +238,7 @@ echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text
Environment variables, rules, and advanced settings.
</Card>
<Card title="YOLO Mode" icon="zap" href="/features/yolo-mode">
Deep dive into autonomous execution and safety considerations.
<Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
Real-world examples of headless workflows and automation patterns.
</Card>
</Columns>
+316
View File
@@ -0,0 +1,316 @@
---
title: "Documentation Templates"
sidebarTitle: "Templates"
description: "Templates for different types of Cline documentation"
---
Use these templates as starting points for new documentation. Each template is designed for a specific purpose. Choose the one that best fits what you're documenting.
## Choosing a Template
| If you're documenting... | Use this template |
|--------------------------|-------------------|
| What a feature does and how to use it | Feature Doc |
| How to accomplish a specific task | How-To Guide |
| Technical specifications or API details | Reference Doc |
| A complete project walkthrough | Tutorial |
## Feature Doc
Use this template when explaining a Cline feature. Focus on what it does, how to use it, and real examples.
````text
---
title: "Feature Name"
sidebarTitle: "Feature Name"
---
[One sentence explaining what this feature does.]
<Frame>
<img src="..." alt="Feature in action" />
</Frame>
[1-2 paragraphs explaining the feature in plain terms. What problem does it
solve? Why would someone use it?]
## How It Works
[Explain the mechanics without jargon. What happens when you use this feature?]
## Using [Feature Name]
[Show how to access and use it. Include the exact UI path.]
### [Option or Variation 1]
[Details with examples]
### [Option or Variation 2]
[Details with examples]
## Inspiration
[Share how you personally use this feature. Use "I" voice. Give 2-3 real
examples that spark imagination about what's possible.]
<Note>
[Important caveat, limitation, or requirement]
</Note>
````
### Example: Checkpoints Feature
Here's how the [Checkpoints](/core-workflows/checkpoints) doc follows this pattern:
- Opens with one clear sentence about what checkpoints do
- Shows a screenshot of the feature in action
- Explains how checkpoints work under the hood
- Shows exact steps to create and restore checkpoints
- Includes real examples of when checkpoints save the day
## How-To Guide
Use this template when showing how to accomplish a specific task. Focus on clear steps and troubleshooting.
````text
---
title: "How to [Accomplish Task]"
sidebarTitle: "[Short Title]"
description: "[One sentence describing what the reader will learn]"
---
[Brief intro explaining what problem this guide solves and what you'll end up
with after following it.]
## Prerequisites
[What the reader needs before starting. Keep it short. Link to other docs
rather than explaining setup here.]
- Cline installed and configured
- [Other requirement]
## Steps
<Steps>
<Step title="[First Action]">
[Clear instructions. Show exactly what to click or type.]
```bash
example command if needed
```
</Step>
<Step title="[Second Action]">
[Next step. Include screenshots for complex UI interactions.]
<Frame>
<img src="..." alt="What you should see" />
</Frame>
</Step>
<Step title="[Final Action]">
[Complete the task. Show the expected result.]
</Step>
</Steps>
## Troubleshooting
Common issues and how to fix them:
- **Problem description**: Solution in one or two sentences.
- **Another problem**: Another solution.
## Next Steps
<Card title="Related Feature" icon="arrow-right" href="/path/to/related">
Continue learning with this related guide.
</Card>
````
### Example: Your First Project
The [Your First Project](/getting-started/your-first-project) guide follows this pattern:
- Clear goal stated upfront
- Prerequisites listed briefly
- Step-by-step instructions with the Steps component
- Troubleshooting section for common issues
## Reference Doc
Use this template for technical specifications, API documentation, or detailed configuration options.
````text
---
title: "[Component/API] Reference"
sidebarTitle: "[Short Title]"
description: "[What this reference covers]"
---
[Brief description of what this reference documents and when you'd need it.]
## Overview
[High-level explanation. What is this component? What role does it play?]
## [Category 1]
### [Item Name]
[What it does in one sentence.]
| Property | Type | Default | Description |
|----------|------|---------|-------------|
| `propertyName` | `string` | `"default"` | What this property controls |
| `anotherProp` | `boolean` | `false` | What this does |
**Example:**
```typescript
// Show practical usage
const example = {
propertyName: "custom value",
anotherProp: true
}
```
### [Another Item]
[Continue for each item in this category.]
## [Category 2]
[Continue with other categories as needed.]
## Examples
[Show 2-3 complete, practical examples that combine multiple concepts.]
### [Example 1 Title]
```typescript
// Complete working example
```
### [Example 2 Title]
```typescript
// Another complete example
```
## Related
- [Related Doc 1](/path/to/doc) - Brief description
- [Related Doc 2](/path/to/doc) - Brief description
````
### Example: Cline Tools Guide
The [Cline Tools Guide](/tools-reference/all-cline-tools) follows this pattern:
- Overview of the tool system
- Each tool documented with parameters and examples
- Practical examples showing tools in context
## Tutorial
Use this template for comprehensive project walkthroughs where users build something from start to finish.
````text
---
title: "[Build/Create X] Tutorial"
sidebarTitle: "[Short Title]"
description: "[What the reader will build]"
---
In this tutorial, you'll build [specific outcome]. By the end, you'll have
[tangible result you can see/use].
<Frame>
<img src="..." alt="Preview of what you'll build" />
</Frame>
## What You'll Learn
- [Skill or concept 1]
- [Skill or concept 2]
- [Skill or concept 3]
## Prerequisites
[Required setup. Link to installation guides rather than repeating them.]
- [Prerequisite 1]
- [Prerequisite 2]
## Part 1: [First Major Section]
[Introduction to this section. What are we doing and why?]
### [Subsection]
[Detailed walkthrough with code blocks and explanations.]
```typescript
// Code that the reader should write or understand
```
[Explain what the code does and why.]
## Part 2: [Second Major Section]
[Continue building on Part 1.]
### [Subsection]
[More detailed walkthrough.]
## Part 3: [Final Section]
[Complete the project.]
## Summary
You built [what they built]. Along the way, you learned:
- [Key takeaway 1]
- [Key takeaway 2]
- [Key takeaway 3]
## Next Steps
<CardGroup cols={2}>
<Card title="Go Deeper" icon="book" href="/path/to/advanced">
Learn more advanced techniques.
</Card>
<Card title="Related Tutorial" icon="code" href="/path/to/related">
Build something else with similar concepts.
</Card>
</CardGroup>
````
### Example Structure
A good tutorial:
- Shows the end result upfront so readers know what they're building
- Breaks the work into logical parts
- Explains the "why" alongside the "how"
- Ends with clear next steps
## Quick Tips
When using these templates:
1. **Delete sections you don't need.** Templates are starting points, not rigid structures.
2. **Add sections that make sense.** If your doc needs something not in the template, add it.
3. **Keep the reader moving forward.** Every section should lead naturally to the next.
4. **Test your own instructions.** Follow your guide from scratch to catch missing steps.
<Tip>
Use the `/write-docs` workflow to generate documentation from these templates automatically.
Cline helps you fill in each section based on your project.
</Tip>
+200
View File
@@ -0,0 +1,200 @@
---
title: "Documentation Guide"
sidebarTitle: "Documentation Guide"
description: "How to write and contribute to Cline documentation"
---
Cline's documentation lives in the `docs/` directory and uses [Mintlify](https://mintlify.com) for rendering. This guide covers how to write docs that match Cline's established style.
## Using the Documentation Workflow
The fastest way to create documentation is using the `/write-docs` workflow. Type `/write-docs` in Cline and describe what you want to document. Cline guides you through a 4-step process:
1. **Research**: Examine existing docs structure and patterns
2. **Scope**: Clarify audience, doc type, and key use cases
3. **Outline**: Select a template and create structure
4. **Write**: Generate documentation following style guidelines
The workflow file lives at `.clinerules/workflows/write-docs.md` and contains templates, style rules, and examples.
## Documentation Principles
### Write for Developers
Your audience is developers who value their time. Get to the point. Every sentence should either help them understand something or help them do something.
```markdown
# Good
Switch to bash in Cline Settings → Terminal → Default Terminal Profile.
# Bad
Users who are experiencing issues may find it helpful to navigate to the
Cline settings menu where they can locate the terminal configuration
options and subsequently modify the default terminal profile setting.
```
### Show Real Examples
Abstract descriptions don't help anyone. Show actual code, real file paths, and concrete implementations.
```markdown
# Good
I use `/deep-planning` whenever I'm building features that touch multiple
parts of the codebase. For example, when adding authentication, Cline
mapped every endpoint and created a migration plan that avoided breaking changes.
# Bad
The deep planning feature can be utilized for various complex tasks
that may require careful consideration and planning.
```
### Use Active Voice
Cline does things. Files don't get created by Cline, Cline creates files.
```markdown
# Good
Cline reads your project files and builds context automatically.
# Bad
Project files are read and context is built automatically.
```
### Use Neutral Pronouns for Cline
Refer to Cline as "it" not "he". Cline is software, not a person.
```markdown
# Good
When Cline encounters an error, it suggests fixes.
# Bad
When Cline encounters an error, he suggests fixes.
```
## File Format
All documentation uses MDX format with YAML frontmatter:
```yaml
---
title: "Full Page Title"
sidebarTitle: "Shorter Nav Title" # optional
description: "One sentence for SEO" # optional but recommended
---
```
### Adding New Pages
After creating a new `.mdx` file, add it to `docs/docs.json` in the appropriate navigation group:
```json
{
"group": "Features",
"pages": [
"features/existing-page",
"features/your-new-page"
]
}
```
## Mintlify Components
Use these components appropriately throughout your docs.
### Frame
Wrap all images and videos:
```jsx
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/filename.png"
alt="Descriptive alt text"
/>
</Frame>
```
### Callouts
Use sparingly and purposefully:
```jsx
<Tip>Helpful suggestions that improve the experience.</Tip>
<Note>Important information the reader needs to know.</Note>
<Warning>Something that could cause problems if ignored.</Warning>
```
### Steps
For sequential procedures:
```jsx
<Steps>
<Step title="Install the Extension">
Search for "Cline" in the VS Code marketplace.
</Step>
<Step title="Configure Your Model">
Open settings and add your API key.
</Step>
</Steps>
```
### Cards
For navigation and feature overviews:
```jsx
<CardGroup cols={2}>
<Card title="Getting Started" icon="rocket" href="/getting-started/installing-cline">
Install Cline and set up your first project.
</Card>
<Card title="Features" icon="wand-magic-sparkles" href="/core-workflows/plan-and-act">
Explore what Cline can do.
</Card>
</CardGroup>
```
## Style Rules
Quick reference for consistent documentation:
| Do | Don't |
|---|---|
| Use "use" | Use "utilize" |
| Keep sentences under 25 words | Write run-on sentences |
| Use bullet points for lists | Write walls of text |
| Show where things are in the UI | Assume users can find features |
| Cross-link related docs | Leave readers stranded |
| Use code blocks with language tags | Use inline code for long snippets |
### Avoid These Patterns
- Em dashes and emojis
- Starting with "This document explains..."
- The **Bold Text**: description pattern
- Explaining obvious things
- Passive voice
## Previewing Changes
Run the docs locally to preview your changes:
```bash
cd docs
npm install # first time only
npm run dev
```
Open `http://localhost:3000` to see your changes in real time.
## Related Resources
<CardGroup cols={2}>
<Card title="Documentation Templates" icon="file-lines" href="/contributing/doc-templates">
Templates for different documentation types.
</Card>
<Card title="Workflows" icon="diagram-project" href="/customization/workflows">
Learn about Cline's workflow system.
</Card>
</CardGroup>
+26 -8
View File
@@ -1,6 +1,6 @@
---
title: "Model Selection Guide"
description: "Last updated: August 20, 2025."
description: "Choose the right AI model for your workflow based on reliability, speed, cost, and context window size."
---
New models drop constantly, so this guide focuses on what's working well with Cline right now. We'll keep it updated as the landscape shifts.
@@ -59,12 +59,17 @@ Choose your preferred AI provider from the dropdown menu.
| **Cline** | Easiest setup | No API keys needed, access to multiple models including stealth models |
| **OpenRouter** | Value seekers | Multiple models, competitive pricing |
| **Anthropic** | Reliability | Claude models, most dependable tool usage |
| **OpenAI** | Latest tech | GPT models |
| **Google Gemini** | Large context | Google's AI models |
| **OpenAI** | Latest tech | GPT-5, o3, o4-mini models |
| **OpenAI Codex** | ChatGPT subscribers | Use your ChatGPT subscription — no API key needed |
| **Google Gemini** | Large context | Gemini 3/2.5 with up to 2M context |
| **DeepSeek** | Budget reasoning | V3.2, R1 models at low cost |
| **Alibaba Qwen** | Open source coding | Qwen3 Coder with 1M context |
| **Moonshot** | Agentic coding | Kimi K2.5 with 262K context |
| **Cerebras** | Speed | Up to 2,600 tokens/sec |
| **AWS Bedrock** | Enterprise | Advanced features |
| **Ollama** | Privacy | Run models locally |
See the [full provider list](/provider-config) for more options including Cerebras, Vertex AI, Azure, and more.
See the [full provider list](/getting-started/authorizing-with-cline) for all 30+ supported providers including xAI Grok, Mistral, Groq, Fireworks, Together, Baseten, SambaNova, Nebius, Hugging Face, and more.
<Info>
**Recommended for beginners:** Start with **Cline** as your provider - no API key management needed, instant access to multiple models, and occasional free inferencing through partner providers.
@@ -81,6 +86,19 @@ The next step depends on which provider you selected.
- You'll be redirected to [app.cline.bot](https://app.cline.bot) to authenticate
- After signing in, return to your IDE
<Note>
For detailed information about the Cline authentication flow, OAuth tokens, and troubleshooting, see [Authorizing with Cline](/getting-started/authorizing-with-cline).
</Note>
#### If you selected **OpenAI Codex** as your provider:
- **No API key needed!** If you have a ChatGPT subscription (Plus, Pro, or Team), you can use it directly in Cline
- Click **"Sign in with OpenAI"** to authenticate via your browser
- Once authorized, all models available on your OpenAI plan will appear automatically
- Usage is governed by your ChatGPT subscription — no separate API billing
See the full [OpenAI Codex setup guide](/provider-config/openai-codex) for details.
#### If you selected any other provider:
You'll need to get an API key from your chosen provider:
@@ -90,7 +108,7 @@ You'll need to get an API key from your chosen provider:
- **OpenRouter**: [openrouter.ai/keys](https://openrouter.ai/keys)
- **OpenAI**: [platform.openai.com/api-keys](https://platform.openai.com/api-keys)
- **Google**: [aistudio.google.com/apikey](https://aistudio.google.com/apikey)
- **Others**: See [Provider Setup Guide](/provider-config)
- **Others**: See [Provider Setup Guide](/getting-started/authorizing-with-cline)
2. **Generate a new API key** on the provider's website
@@ -168,8 +186,7 @@ Selecting the right model involves balancing several factors. Use this framework
## Model Comparison Resources
For detailed model comparisons, pricing, and performance metrics, see:
- [**Model Comparison & Pricing**](/model-config/model-comparison) - Complete pricing tables and performance benchmarks
For detailed model comparisons and performance metrics, see:
- [**Context Window Guide**](/model-config/context-windows) - Understanding and optimizing context usage
## Open Source vs Closed Source
@@ -195,8 +212,9 @@ For detailed model comparisons, pricing, and performance metrics, see:
| Huge context windows | Gemini 2.5 Pro or Claude Sonnet 4.5 |
| Open source | Qwen3 Coder, Z AI GLM 4.5, or Kimi K2 |
| Latest tech | GPT-5 |
| To use your ChatGPT subscription | [OpenAI Codex](/provider-config/openai-codex) — sign in with your OpenAI account, no API key needed |
| Speed | Qwen3 Coder on Cerebras (fastest available) |
## What Others Are Using
Check [OpenRouter's Cline usage stats](https://openrouter.ai/apps?url=https%3A%2F%2Fcline.bot%2F) to see real usage patterns from the community.
Check [Vercel's leaderboard](https://vercel.com/ai-gateway/leaderboards) to see real usage patterns from the community.
+95
View File
@@ -0,0 +1,95 @@
---
title: "Checkpoints"
sidebarTitle: "Checkpoints"
description: "Roll back code changes while keeping your conversation. Experiment freely."
---
Checkpoints let you undo code changes without losing your conversation. Every time Cline modifies a file or runs a command, it saves a snapshot of your project files. You can restore to any checkpoint, keeping the context you've built while reverting the code.
This changes how you work with Cline. Instead of carefully reviewing every change before approving, you can let Cline move fast and roll back if something goes wrong. The cost of a mistake drops to nearly zero.
<Tip>
Checkpoints are enabled by default. See [Enable or Disable Checkpoints](#enable-or-disable-checkpoints) if you need to turn them off.
</Tip>
## How It Works
Cline maintains a shadow Git repository separate from your project's actual Git history. After each tool use (file edits, commands, etc.), Cline commits the current state of your files to this shadow repo. Your main Git repository stays untouched.
This means:
- Your Git history remains clean and under your control
- Checkpoints capture everything, including files not tracked by Git
- You can restore to any point in a task without affecting commits you've made
- Checkpoints persist across editor sessions
Each checkpoint captures the complete file state at that moment. If Cline edits three files in sequence, you get three checkpoints and can restore to any of them independently.
## Enable or Disable Checkpoints
Checkpoints are enabled by default. To toggle them:
1. Open Cline settings (gear icon in the Cline sidebar)
2. Scroll to the "Feature Settings" section
3. Toggle "Enable Checkpoints"
<Note>
For very large repositories, checkpoints may use significant storage and slow down Cline as it commits file snapshots after each tool use. Consider disabling them if you notice performance issues.
</Note>
## Viewing and Comparing Changes
After each tool use, a checkpoint indicator appears in your conversation. Look for a bookmark icon labeled "Checkpoint" with a dotted line connecting to **Compare** and **Restore** buttons.
Click **Compare** to open a diff view showing exactly what changed at that checkpoint. This opens in your editor's diff viewer, letting you see additions, deletions, and modifications across all affected files.
This is useful when Cline makes changes you want to understand before deciding whether to keep them. You can review the diff, then either continue or restore to undo.
## Restoring Checkpoints
Click **Restore** next to any step to open the restore menu. You have three options:
| Option | What It Does | When to Use It |
|--------|--------------|----------------|
| **Restore Files** | Reverts your project's files to the snapshot at this checkpoint | Undoing code changes while keeping the conversation |
| **Restore Task Only** | Deletes messages after this point, does not affect files | Trying a different prompt while keeping current code |
| **Restore Files & Task** | Reverts files and deletes messages after this point | Starting over completely from a known good state |
The right choice depends on what went wrong:
- If the conversation is productive but the code changes broke something, use **Restore Files**. Cline keeps all the context you've discussed and can try a different implementation.
- If Cline's code changes are good but the conversation went off track, use **Restore Task Only**. You keep the files and can guide the conversation differently.
- If you want to start over from a clean slate, use **Restore Files & Task**. This resets both your files and the conversation to that checkpoint.
## When to Use Checkpoints
| Scenario | Recommended Action |
|----------|-------------------|
| Cline refactored code and broke something | Restore Files, ask for a different approach |
| Experimenting with multiple solutions | Compare each checkpoint, restore to the best one |
| Cline misunderstood your intent | Restore Files & Task, rephrase your request |
| Want to try a different prompt | Restore Task Only, keep the files, resubmit |
| Reviewing changes before committing to Git | Use Compare to inspect, then commit manually |
| Testing risky changes | Let Cline proceed, restore if it fails |
## Working with Auto-Approve
Checkpoints make [auto-approve](/features/auto-approve) practical. Without checkpoints, auto-approve feels risky because Cline can make many changes before you notice a problem. With checkpoints, you can let Cline work autonomously and roll back if needed.
A typical workflow:
1. Enable auto-approve for file edits and commands
2. Let Cline work through your task quickly
3. Review the final result
4. If something is wrong, restore to the last good checkpoint
5. Give Cline more specific guidance
This approach is faster than reviewing every change individually, and checkpoints provide the safety net.
## Checkpoints and Message Editing
The message editing feature integrates with checkpoints. When you edit a previous message and select "Restore All," Cline restores your files to the checkpoint at that point before resubmitting your edited message.
This lets you fix a poorly worded prompt and undo all the changes that resulted from it in one action.
+120
View File
@@ -0,0 +1,120 @@
---
title: "Plan & Act Mode"
sidebarTitle: "Plan & Act Mode"
description: "Think first, then build. Cline's dual-mode system for structured development."
---
Plan & Act modes separate thinking from doing. Plan mode lets you explore and strategize without changing files. Act mode executes against your plan.
<Tip>
**New to Plan & Act?** Watch [Plan & Act Deep Dive](https://youtu.be/b7o6URFPp64) to see it in action.
</Tip>
## Plan Mode
Plan mode is where you and Cline figure out what you're building and how. In this mode, Cline can read your codebase, run searches, and discuss strategy, but cannot modify any files or execute commands.
This constraint is intentional. It keeps the conversation focused on understanding and planning, without the distraction of implementation details. You can explore freely, ask questions, and iterate on the approach before committing to changes.
Use Plan mode to:
- Explore unfamiliar codebases before making changes
- Discuss architecture decisions and tradeoffs
- Identify edge cases and potential issues upfront
- Create a clear implementation strategy
- Review code and understand complex workflows
## Act Mode
Once you have a plan, switch to Act mode. Cline retains the full context from your planning session and can now modify files, run commands, and execute your strategy.
The conversation history carries over when you switch modes. Cline remembers everything you discussed in Plan mode, so you don't need to repeat yourself. This makes the transition seamless.
<Note>
While you can start directly in Act mode, planning first is highly recommended. The planning phase intentionally builds context that Cline needs to implement changes effectively. Without it, Cline may lack the understanding required to make the right decisions.
</Note>
## Typical Workflow
1. Start in Plan mode and describe what you want to build
2. Let Cline explore relevant files and understand the codebase
3. Discuss the approach, considering edge cases and potential issues
4. When confident in the plan, switch to Act mode
5. Cline implements the solution based on your planning session
For complex projects, you may cycle between modes multiple times. Return to Plan mode when you hit unexpected complexity or need to rethink the approach, then switch back to Act mode to continue implementation.
## When to Use Each Mode
| Scenario | Recommended Mode |
|----------|-----------------|
| Starting new features where the approach isn't obvious | Plan |
| Debugging tricky issues where you're unsure what's wrong | Plan |
| Making architectural decisions affecting multiple files | Plan |
| Understanding complex workflows before modifying them | Plan |
| Code review and security analysis | Plan |
| Learning a new codebase | Plan |
| Implementing a solution you've already planned | Act |
| Making routine changes with a clear approach | Act |
| Following established patterns in the codebase | Act |
| Running tests and making adjustments | Act |
| Quick fixes where the solution is obvious | Act |
## Using Different Models for Each Mode
You can configure separate models for Plan and Act modes. This is useful when you want to use a stronger reasoning model for planning and a faster model for implementation.
To enable this:
1. Open Cline Settings
2. Enable "Use different models for Plan and Act"
3. Select your preferred model for each mode
When enabled, switching between Plan and Act mode automatically switches to the configured model for that mode. Your model selection is preserved when you switch back.
**Example configurations:**
| Use Case | Plan Mode | Act Mode |
|----------|-----------|----------|
| Cost optimization | GLM 4.6 | Grok Code Fast |
| Maximum quality | Claude Opus | Claude Sonnet |
| Speed-focused | Gemini 3 Flash | Cerebras |
## Using `/deep-planning`
For complex tasks that need thorough analysis, use the `/deep-planning` slash command. This triggers an extended planning session where Cline:
1. Explores the codebase systematically
2. Identifies all affected files and dependencies
3. Creates a detailed implementation plan
4. Asks clarifying questions before proceeding
The deep planning prompt is optimized for each model family, so it adapts to the strengths of whatever model you're using. See the [Deep Planning docs](/features/deep-planning) for more details.
## Choosing the Right Approach by Task Size
### Small tasks: Act mode only
For quick fixes like typos, simple bug fixes, or following established patterns, start directly in Act mode. Planning adds overhead when the solution is obvious.
**Examples:** Fix a typo, add a missing import, update a config value, rename a variable.
### Medium tasks: Plan → Act
For most development work, start in Plan mode to understand the scope and approach, then switch to Act mode to implement. This is the sweet spot for features that touch a few files and have some complexity.
**Examples:** Add a new API endpoint, implement a UI component, fix a bug that requires investigation, refactor a single module.
### Large tasks: Use `/deep-planning`
For complex features that span multiple files, require architectural decisions, or will take multiple sessions to complete, use the `/deep-planning` slash command. This creates a detailed implementation plan that Cline can reference throughout the work.
**Examples:** Add a new feature across frontend and backend, major refactoring across the codebase, implementing a new system or integration, multi-step migrations.
## Tips
- Have Cline write a markdown file summarizing the plan for future reference
- Use [file mentions](/core-workflows/working-with-files) to point Cline at relevant files during planning
- Switch back to Plan mode when encountering unexpected complexity rather than pushing through
- Enable [Checkpoints](/core-workflows/checkpoints) before Act mode so you can roll back if needed
- For large tasks, ask Cline to create a todo list during planning that you can track in Act mode
+160
View File
@@ -0,0 +1,160 @@
---
title: "Tasks"
sidebarTitle: "Tasks"
description: "Organize your work with tasks - self-contained sessions that capture your conversations, code changes, and decisions."
---
Every interaction with Cline happens within a task. Tasks are self-contained work sessions that capture your entire conversation, code changes, command executions, and decisions.
## What are Tasks?
A task begins when you submit a prompt to Cline. Your prompt defines the goal, and Cline works toward it through conversation, code changes, and tool use. The quality of your initial prompt directly affects how well Cline performs - clear, specific prompts lead to better results.
Each task:
- Starts with your prompt and builds context through the conversation
- Has a unique identifier and dedicated storage directory
- Contains the full conversation history
- Tracks token usage, API costs, and execution time
- Can be interrupted and resumed across sessions
- Creates [checkpoints](/core-workflows/checkpoints) for file changes through Git-based snapshots
<Tip>
Want to get better results from Cline? Learn how to write effective prompts in our [Prompt Module](https://cline.bot/learn).
</Tip>
## Scoping Your Tasks
Each task carries its own context: the conversation history, decisions made, and understanding built up over the session. How you scope your tasks directly affects how well Cline can help you.
Think of it this way: **one task = one goal**. "Implement user authentication" is one task. "Fix an unrelated CSS bug" is a separate task, even if you notice it while working on auth.
A focused task produces better results. When a task tries to cover too many unrelated goals, the context becomes cluttered and responses become less relevant.
<Note>
If you're unsure, err on the side of starting fresh. You can always find previous sessions in your task history.
</Note>
### Context Window
Every AI model has a context window - a limit on how much information it can process at once. Think of it as Cline's working memory for the current task.
As you work, the context window fills up with:
- Your prompts and Cline's responses
- File contents Cline reads or edits
- Command outputs and tool results
- System instructions that guide Cline's behavior (including [Cline Rules](/customization/cline-rules))
When the context window approaches its limit, Cline automatically compresses older parts of the conversation to make room. This means very long tasks may lose some earlier details, though Cline preserves the most important context.
This is why task scoping matters: a focused task keeps relevant information in the context window. A sprawling task fills the window with noise, pushing out useful context.
If your starting context seems high even for simple prompts, add a [`.clineignore`](/customization/clineignore) file to exclude dependencies, build artifacts, and other files Cline doesn't need. This can dramatically reduce your baseline token usage.
<Tip>
For long-running tasks, enable [Auto-Compact](/features/auto-compact) to intelligently manage context as you work.
</Tip>
### New Task vs. Continue
Knowing when to start fresh versus continue can feel unclear at first. As you work with Cline more, you'll develop an intuition for it. Use this table as a starting point:
| Scenario | Action | Why |
|----------|--------|-----|
| Switching to a different feature | **New task** | Clean context, focused responses |
| Building on work Cline just completed | **Continue** | Shared understanding preserved |
| Cline keeps going off-track | **New task** | Fighting context wastes time |
| Iterating on the same files | **Continue** | Conversation history helps |
| Explaining what to ignore | **New task** | Cluttered context hurts quality |
| Refining Cline's last output | **Continue** | Momentum and decisions preserved |
To start a new task, click the **+** button in the Cline sidebar or use the `/newtask` command. Your file changes are preserved through [checkpoints](/core-workflows/checkpoints), and you can reference previous tasks from history anytime.
## Understanding Task Costs
Every cloud-based AI model charges for usage based on tokens, the units of text the model processes. Cline tracks these costs automatically and displays them in the task header so you can monitor spending as you work.
### How Costs Are Calculated
When you interact with Cline, the model processes:
- **Input tokens**: Your prompts, file contents, conversation history, and system instructions
- **Output tokens**: The model's responses, code suggestions, and tool calls
Cloud providers charge per million tokens, with output tokens typically costing more than input. Some providers also support **prompt caching**, which reduces costs when the same context (like your cline rules or large files) appears in multiple requests. Cline automatically tracks cache savings when available.
The estimated cost shown in the task header updates after each API request. This estimate uses the pricing information from your selected provider and may vary slightly from your final bill depending on how your provider rounds or bills usage.
### When You Pay
You pay for AI usage when using cloud providers like Anthropic, OpenAI, OpenRouter, or Google. Costs vary significantly:
| Provider Type | Billing Model |
|--------------|---------------|
| **Cline Provider** | Pay-per-use with credits you purchase |
| **Direct API keys** | Billed by your provider (Anthropic, OpenAI, etc.) |
| **OpenRouter/Requesty** | Aggregated billing across multiple models |
| **Local models** | Free (you provide the hardware) |
If you're using your own API keys, check your provider's pricing page for current rates. Prices change frequently and vary by model.
### Free Options
Not ready to pay? Cline offers several free paths:
- **Free models**: Search "free" in the model selector when using the Cline provider. These models display a **FREE** tag and work well for learning and experimentation.
- **Free tiers**: Some providers offer limited free usage when you use your own API key.
- **Local models**: Run models on your own hardware with zero per-request costs.
### Self-Hosted Models
Running models locally means no API costs, ever. Your only expense is the hardware to run them.
To run local models effectively, you need:
- **32GB RAM minimum** for entry-level models (4-bit quantization)
- **64GB RAM** for better quality (8-bit quantization)
- **128GB+ RAM** for cloud-competitive performance
The trade-off is speed. Local models run at 5-20 tokens per second on typical hardware, compared to hundreds of tokens per second from cloud APIs. They also require more setup and configuration.
<Tip>
If you have the hardware, local models offer unlimited experimentation with complete privacy. See [Running Models Locally](/running-models-locally/overview) to get started.
</Tip>
For most users, starting with free cloud models and moving to paid options as needed provides the best balance of cost, speed, and capability. Check [Selecting Your Model](/getting-started/authorizing-with-cline) for guidance on choosing the right option for your workflow.
## Task History
Every task you work on is saved automatically to your local machine. You can revisit past conversations, resume interrupted work, or reference successful approaches from earlier sessions.
### Finding Your History
Click the **History** button in the Cline sidebar (clock icon at the top-right) to open the history view. You'll see all your past tasks with their initial prompt, timestamp, and token usage. Each task card expands to show a preview of the conversation.
### Searching Tasks
Use the search bar at the top of the history view to find specific tasks. The fuzzy search looks across everything: your prompts, Cline's responses, code snippets, and file names.
Sort results by:
- **Newest/Oldest** for chronological browsing
- **Most Expensive/Most Tokens** to find resource-heavy tasks
- **Most Relevant** when searching for specific content
- **Favorites** to show only starred tasks
<Tip>
Use favorites strategically. Star tasks that represent successful patterns, good prompts, or complex work you might want to reference later. Favorited tasks are protected from deletion.
</Tip>
## Resuming Tasks
Cline can resume interrupted tasks with full context:
1. Open the task from history
2. Cline loads the complete conversation
3. File states are checked against [checkpoints](/core-workflows/checkpoints)
4. The task continues with awareness of the interruption
5. Provide additional context if needed
This works across sessions. Even if you close the editor and return days later, Cline can pick up where you left off.
+75
View File
@@ -0,0 +1,75 @@
---
title: "Using Commands"
sidebarTitle: "Using Commands"
description: "Built-in slash commands to manage context, plan implementations, and create reusable workflows."
---
Cline provides slash commands in chat that help you manage your conversation and plan complex implementations.
<Tip>
**New to slash commands?** Watch our [quick video walkthrough](https://youtu.be/MxS5Jerpf-o) to see these commands in action.
</Tip>
## Slash Commands
Type `/` in the chat input to see available slash commands:
| Command | What It Does |
|---------|--------------|
| `/newtask` | Start fresh task with distilled context from current conversation |
| `/smol` | Compress conversation history while preserving essential context |
| `/newrule` | Create a rule file to teach Cline your preferences |
| `/deep-planning` | Investigate codebase, plan thoroughly, then create implementation task |
| `/explain-changes` | Generate AI explanations for any git diff (VS Code only) |
| `/reportbug` | Report a bug with diagnostic info |
### /newtask
`/newtask` works like a developer handoff. It packages what matters (overall plan, work accomplished, relevant files, next steps) into a fresh task with a clean context window, leaving behind the noise of tool calls and implementation details.
I use `/newtask` when working through complex implementations. If I've completed 3 steps of a 10-step process and my context is already 75% full, I use `/newtask` to extract key decisions, file changes, and progress without all the noise.
### /smol
`/smol` (or its alias `/compact`) compresses your conversation history while preserving essential context. Unlike `/newtask` which creates a new task, `/smol` condenses your current conversation into a comprehensive summary, freeing up context window space while allowing you to continue working in the same task.
Use `/smol` when you're deep into a debugging session or brainstorming and need to continue in the same task without losing the insights you've gained. For more details, see [Smol Command](#smol).
### /newrule
`/newrule` creates a rule file that teaches Cline your preferences. Cline will guide you through setting up guidelines for communication style, coding standards, project context, and workflows. The rule is saved to your `.clinerules` directory and automatically loaded for future conversations.
Use `/newrule` when you find yourself repeating the same instructions across tasks. For more about rules, see [Cline Rules](/customization/cline-rules).
### /deep-planning
Transform Cline into a meticulous architect who investigates your codebase, asks clarifying questions, and creates a comprehensive implementation plan before writing any code. Deep planning follows a four-step process:
1. **Silent Investigation** - Cline explores your codebase structure and patterns
2. **Discussion** - Targeted questions about requirements and approach
3. **Plan Creation** - Generates `implementation_plan.md` with detailed specifications
4. **Task Creation** - Creates a new task with trackable implementation steps
Use `/deep-planning` for features touching multiple parts of your codebase, architectural changes, or complex integrations. For detailed documentation, see [Deep Planning](/features/deep-planning).
### /explain-changes
<Note>
This command is only available in VS Code.
</Note>
`/explain-changes` generates AI-powered explanations for any git diff. You can explain the last commit, uncommitted work, staged changes, specific commits, branches, PRs, or any range of changes.
Use `/explain-changes` when reviewing code, onboarding to a new codebase, or understanding what changed. For the full list of use cases and examples, see [Explain Changes Command](#explain-changes).
### /reportbug
`/reportbug` collects diagnostic information and helps you report issues with Cline. It gathers relevant context like your configuration, recent errors, and system details to make bug reports more useful for the development team.
Use `/reportbug` when you encounter unexpected behavior, crashes, or bugs you want to report.
## Custom Workflows
Beyond the built-in slash commands, you can create your own workflow files that work the same way. Store Markdown files in `.clinerules/workflows/` and invoke them with `/your-workflow.md`.
For a complete guide on creating and managing custom workflows, see [Workflows](/customization/workflows).
+145
View File
@@ -0,0 +1,145 @@
---
title: "Adding Context"
sidebarTitle: "Adding Context"
description: "Use @ mentions and drag & drop to bring files, terminal output, errors, git changes, and web content into your conversations."
---
Cline works best when it has the right context, not just more context. @ mentions let you pull in exactly the files, errors, terminal output, or documentation that matter for your task. No copying, no pasting, no context switching.
You can add context two ways:
- Type `@` in the chat input and select what you want
- Click the **+** button in the bottom left to browse files, images, or mentions
<Tip>
**Want to learn more about managing context?** Watch [Adding Context with @ Mentions](https://youtu.be/7j6R75Dvj1Y) to see it in action.
</Tip>
## Quick Reference
| What you want | Syntax | Example |
|---------------|--------|---------|
| File content | `@/path/to/file` | `@/src/index.ts` |
| Folder contents | `@/path/to/folder/` | `@/src/components/` |
| Workspace errors | `@problems` | `@problems` |
| Terminal output | `@terminal` | `@terminal` |
| Uncommitted changes | `@git-changes` | `@git-changes` |
| Specific commit | `@<commit-hash>` | `@a1b2c3d` |
| Web page | `@<url>` | `@https://react.dev/learn` |
## File Mentions
Reference any file with `@/path/to/file`. Cline sees the complete file content, including imports, related functions, and surrounding context.
```text
Can you refactor the error handling in @/src/api/users.ts?
```
## Folder Mentions
Reference entire directories with `@/path/to/folder/` (note the trailing slash). Cline sees the folder structure and all file contents.
```text
Explain how the components in @/src/components/auth/ work together.
```
<Note>
In multi-root workspaces, prefix paths with the workspace name: `@workspace-name:/path/to/file`
</Note>
## Problem Mentions
Use `@problems` to share all errors and warnings from your workspace's Problems panel.
```text
@problems Can you fix these TypeScript errors?
```
## Terminal Mentions
Use `@terminal` to share recent terminal output. Perfect for debugging build errors or test failures.
```text
@terminal The build is failing. What's wrong?
```
## Git Mentions
Reference uncommitted changes with `@git-changes`:
```text
@git-changes Review my changes before I commit.
```
Reference specific commits with `@<commit-hash>` (7-40 character hex):
```text
What did @a1b2c3d change?
```
## URL Mentions
Reference web content with `@https://example.com`. Cline fetches the page content.
```text
Implement the pattern described in @https://react.dev/learn/scaling-up-with-reducer-and-context
```
## Combining Mentions
Combine multiple @ mentions for comprehensive context:
```text
I'm getting these errors: @problems
Here's my component: @/src/components/Form.jsx
And the API endpoint: @/src/api/users.js
The error happens when I submit: @terminal
I think this commit might have caused it: @a1b2c3d
```
## Drag & Drop
Drag files directly into the chat input to add them to your conversation.
<Note>
In VS Code, hold **Shift** while dragging files into the chat input.
</Note>
Dragging workspace files automatically creates file mentions. You can also drag files from Finder or File Explorer directly into Cline.
### Supported File Types
Cline supports text files from your workspace, plus images, PDFs, CSVs, and Excel files from your file system.
<Note>
Images require a multimodal model. Check the model selector to see which models support image inputs.
</Note>
## Context Menu Commands
Right-click on selected code to access Cline without typing. This is the fastest way to get help with specific code since it automatically includes the selected text and its file location as context.
### Code Editor Commands
| Command | When to Use |
|---------|-------------|
| **Add to Cline** | Ask questions about code, get suggestions, or start a conversation with specific code as context |
| **Fix with Cline** | Quick fixes for errors, bugs, or issues in the selected code |
| **Explain with Cline** | Understand unfamiliar code, complex logic, or code you're reviewing |
| **Improve with Cline** | Get refactoring suggestions, performance improvements, or cleaner implementations |
**Fix with Cline** also appears in the lightbulb menu (Quick Fix) when your cursor is on an error or warning, making it easy to fix issues inline.
### Terminal Commands
Right-click in the terminal to "Add to Cline" and get help with:
- Build errors and failed commands
- Test failures and stack traces
- Configuration issues
- Any terminal output you need help interpreting
### Source Control Commands
In the Source Control panel, use "Generate Commit Message" to create AI-powered commit messages from your staged changes. Cline analyzes the diff and writes a descriptive commit message following conventional commit patterns.
+396
View File
@@ -0,0 +1,396 @@
---
title: "Rules"
sidebarTitle: "Rules"
description: "Define specific instructions and coding standards for Cline."
---
Rules are markdown files that provide persistent instructions across all conversations. Instead of repeating the same preferences every time you start a new task, rules let you define them once and have Cline follow them automatically.
Use rules when you want Cline to:
- Follow your team's coding standards (naming conventions, file organization, error handling patterns)
- Understand project-specific context (tech stack, architecture decisions, dependencies)
- Apply consistent documentation or testing requirements
- Remember constraints like "don't modify files in /legacy" or "always use TypeScript"
<Tip>
**New to Rules?** Watch [Cline Rules Explained](https://youtu.be/xQwsy2vkK5M) to see them in action.
</Tip>
## Supported Rule Types
Cline recognizes rules from multiple sources, so you can use existing rule files from other tools:
| Rule Type | Location | Description |
|-----------|----------|-------------|
| Cline Rules | `.clinerules/` | Primary rule format |
| Cursor Rules | `.cursorrules` | Automatically detected |
| Windsurf Rules | `.windsurfrules` | Automatically detected |
| AGENTS.md | `AGENTS.md` | [Standard format](https://agents.md/) for cross-tool compatibility |
All detected rule types appear in the Rules panel, where you can toggle them individually.
## Where Rules Live
Rules can be stored in two locations: your project workspace or globally on your system.
**Workspace rules** go in `.clinerules/` at your project root. Use these for team standards, project-specific constraints, and anything you want to share with collaborators via version control.
**Global rules** go in your system's Cline Rules directory. Use these for personal preferences that apply across all projects.
```text
your-project/
├── .clinerules/ # Workspace rules
│ ├── coding.md # Coding standards
│ ├── testing.md # Test requirements
│ └── architecture.md # Structural decisions
├── src/
└── ...
```
Cline processes all `.md` and `.txt` files inside `.clinerules/`, combining them into a unified set of rules. Numeric prefixes (like `01-coding.md`) help organize files but are optional.
When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
### Global Rules Directory
| Operating System | Default Location |
|------------------|------------------|
| Windows | `Documents\Cline\Rules` |
| macOS | `~/Documents/Cline/Rules` |
| Linux/WSL | `~/Documents/Cline/Rules` |
<Note>
Linux/WSL users: If you don't find global rules in `~/Documents/Cline/Rules`, check `~/Cline/Rules`.
</Note>
## Creating Rules
<Steps>
<Step title="Open the Rules menu">
Click the scale icon at the bottom of the Cline panel, to the left of the model selector.
</Step>
<Step title="Create a new rule file">
Click "New rule file..." and enter a filename (e.g., `coding-standards`). The file will be created with a `.md` extension.
</Step>
<Step title="Write your rule">
Add your instructions in markdown format. Keep each rule file focused on a single concern.
</Step>
</Steps>
You can also use the [`/newrule` slash command](/core-workflows/using-commands#newrule) to have Cline create a rule interactively.
### Toggling Rules
Every rule has a toggle to enable or disable it. This gives you fine-grained control over which rules apply to your current task without deleting the rule file.
For example, you might have a strict testing rule that you want to disable when prototyping, or a client-specific rule you only need when working on that client's features.
## Writing Effective Rules
### Structure
Rules work best when they're scannable and specific. Use markdown structure to organize instructions:
```markdown
# Rule Title
Brief context about why this rule exists (optional but helpful).
## Category 1
- Specific instruction
- Another instruction with example: `like this`
- Reference to file: see /src/utils/example.ts
## Category 2
- More instructions
- Include the "why" when it's not obvious
```
Cline reads rules as context, so formatting matters. Headers help Cline understand the scope of each instruction. Bullet points make individual requirements clear. Code examples show exactly what you want.
### Best Practices
**Be specific, not vague.** "Use descriptive variable names" is too broad. "Use camelCase for variables, PascalCase for classes, UPPER_SNAKE for constants" gives Cline something concrete to follow.
**Include the why.** When a rule might seem arbitrary, explain the reason. "Don't modify files in /legacy (this code is scheduled for removal in Q2)" helps Cline make better decisions in edge cases.
**Point to examples.** If your codebase already demonstrates the pattern you want, reference it. "Follow the error handling pattern in /src/utils/errors.ts" is more effective than describing the pattern from scratch.
**Keep rules current.** Outdated rules confuse Cline and waste context. If a constraint no longer applies, remove it. If your tech stack changes, update the rules.
**One concern per file.** Split rules by topic: `coding.md` for style, `testing.md` for test requirements, `architecture.md` for structural decisions. This makes it easy to toggle specific rules on or off.
<Warning>
Rules consume context tokens. Avoid lengthy explanations or pasting entire style guides. Keep rules concise and link to external documentation when detailed reference is needed.
</Warning>
## Example
```markdown
# Project Guidelines
## Code Style
- Use TypeScript for all new files
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts
## Documentation
- Update relevant docs when modifying features
- Keep README.md in sync with new capabilities
## Testing
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows
```
## Conditional Rules
Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files, keeping your context focused and relevant.
- **Without conditionals**: every rule loads for every request.
- **With conditionals**, rules activate only when your current files match their defined scope.
For example, documentation style rules should only appear when you're editing docs, not when you're writing application code or tests.
As your rule library grows, loading every rule for every request wastes context tokens and can dilute Cline's focus. Conditional rules solve this by giving Cline only the instructions that matter for the files you're actually touching. This means faster, more accurate responses. Your frontend rules won't compete for attention when you're deep in backend code, and your testing standards appear exactly when you're writing tests. It's the difference between handing someone an entire policy manual versus the one page they need right now.
### How It Works
Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules.
<Note>
When a conditional rule activates, you'll see a notification: **"Conditional rules applied: workspace:frontend-rules.md"**
</Note>
### Writing Conditional Rules
Add YAML frontmatter to the top of any rule file in your `.clinerules/` directory:
```yaml
---
paths:
- "src/components/**"
- "src/hooks/**"
---
# React Component Guidelines
When creating or modifying React components:
- Use functional components with React hooks
- Extract reusable logic into custom React hooks
- Keep components focused on a single responsibility
```
The `---` markers delimit the frontmatter. Everything after the closing `---` is your rule content.
#### The `paths` Conditional
Currently, `paths` is the supported conditional. It takes an array of glob patterns:
```yaml
---
paths:
- "src/**" # All files under src/
- "*.config.js" # Config files in root
- "packages/*/src/" # Monorepo package sources
---
```
**Glob pattern syntax:**
- `*` matches any characters except `/`
- `**` matches any characters including `/` (recursive)
- `?` matches a single character
- `[abc]` matches any character in the brackets
- `{a,b}` matches either pattern
| Pattern | Matches |
|---------|---------|
| `src/**/*.ts` | All TypeScript files under `src/` |
| `*.md` | Markdown files in root only |
| `**/*.test.ts` | Test files anywhere in the project |
| `packages/{web,api}/**` | Files in web or api packages |
| `src/components/*.tsx` | TSX files directly in components (not nested) |
#### Behavior Details
**Multiple patterns**: A rule activates if any pattern matches any file in your context.
```yaml
---
paths:
- "frontend/**"
- "mobile/**"
---
# Activates when working in frontend OR mobile
```
**No frontmatter**: Rules without frontmatter are always active.
**Empty paths array**: `paths: []` means the rule never activates. Use this to temporarily disable a rule.
**Invalid YAML**: If frontmatter can't be parsed, Cline fails open. The rule activates with raw content visible to help debugging.
### What Counts as "Current Context"
Cline evaluates rules based on:
1. **Your message**: File paths mentioned in your prompt (e.g., "update `src/App.tsx`")
2. **Open tabs**: Files currently open in your editor
3. **Visible files**: Files visible in your active editor panes
4. **Edited files**: Files Cline has created, modified, or deleted during the task
5. **Pending operations**: Files Cline is about to edit
Conditional rules can activate on your first message, when relevant files are open, or mid-task when Cline starts working with matching files.
<Tip>
Be explicit about file paths in your prompts. "Update `src/services/user.ts`" reliably triggers path-based rules; "update the user service" may not.
</Tip>
### Practical Examples
Copy these patterns and adapt them to your project structure.
#### Frontend vs Backend Rules
Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code, backend rules only load when working with API or service code.
```yaml
# .clinerules/frontend.md
---
paths:
- "src/components/**"
- "src/pages/**"
- "src/hooks/**"
---
# Frontend Guidelines
- Use Tailwind CSS for styling
- Prefer server components where possible
- Keep client components small and focused
```
```yaml
# .clinerules/backend.md
---
paths:
- "src/api/**"
- "src/services/**"
- "src/db/**"
---
# Backend Guidelines
- Use dependency injection for services
- All database queries go through repositories
- Return typed errors, not thrown exceptions
```
#### Test File Rules
Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it.
```yaml
# .clinerules/testing.md
---
paths:
- "**/*.test.ts"
- "**/*.spec.ts"
- "**/__tests__/**"
---
# Testing Standards
- Use descriptive test names: "should [expected behavior] when [condition]"
- One assertion per test when possible
- Mock external dependencies, not internal modules
- Use factories for test data, not fixtures
```
#### Documentation Rules
Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code.
```yaml
# .clinerules/docs.md
---
paths:
- "docs/**"
- "**/*.md"
- "**/*.mdx"
---
# Documentation Guidelines
- Use sentence case for headings
- Include code examples for all features
- Keep paragraphs short (3-4 sentences max)
- Link to related documentation
```
### Combining with Rule Toggles
Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely (it won't activate even if paths match). Toggle on to let it activate when conditions are met.
This provides two levels of control: manual toggles and automatic condition-based activation.
### Tips for Effective Conditional Rules
**Start Broad, Then Narrow.** Begin with broader patterns and refine as you learn what works:
```yaml
# Start here
paths:
- "src/**"
# Then narrow down
paths:
- "src/features/auth/**"
```
**Use Descriptive Filenames.** Name your rule files to indicate their scope:
```text
.clinerules/
├── api-endpoints.md # Rules for API code
├── database-models.md # Rules for DB layer
├── react-components.md # Rules for React
└── universal.md # No frontmatter = always active
```
**Keep Universal Rules Separate.** Put always-on rules (coding standards, project conventions) in files without frontmatter. Reserve conditional rules for context-specific guidance.
**Test Your Patterns.** Not sure if a pattern matches? Create a simple test rule:
```yaml
---
paths:
- "your/pattern/here/**"
---
TEST: This rule should activate for your/pattern/here files.
```
Then work with a file in that path and check if you see the activation notification.
### Troubleshooting Conditional Rules
**Rule not activating:**
- Check that file paths in your context match the glob pattern
- Verify the rule is toggled on in the rules panel
- Ensure YAML frontmatter has proper `---` delimiters
**Rule activating unexpectedly:**
- Review glob patterns. `**` is recursive and may match more than intended
- Check for open files that match the pattern
- File paths mentioned in your message also count as context
**Frontmatter showing in output:**
- YAML couldn't be parsed
- Check for syntax errors (unquoted special characters, improper indentation)
+110
View File
@@ -0,0 +1,110 @@
---
title: ".clineignore"
sidebarTitle: ".clineignore"
description: "Control which files and directories Cline can access in your project."
---
The `.clineignore` file tells Cline which files and directories to skip when analyzing your codebase. It works like `.gitignore`: create a file named `.clineignore` in your project root, add patterns for files you want excluded, and Cline will ignore them.
## Why It Matters
Without a `.clineignore`, Cline may load your entire project into context, including dependencies, build artifacts, and generated files. This wastes tokens, increases costs, and can push useful context out of the window.
Adding a `.clineignore` can cut your starting context from 200k+ tokens to under 50k. That means faster responses, lower costs, and the ability to use smaller, cheaper models effectively.
## Creating a .clineignore
Create a file named `.clineignore` in your project root:
```text
# Dependencies
node_modules/
**/node_modules/
# Build outputs
/build/
/dist/
/.next/
/out/
# Testing artifacts
/coverage/
# Environment variables
.env
.env.*
# Large data files
*.csv
*.xlsx
*.sqlite
# Generated/minified code
*.min.js
*.map
```
## Pattern Syntax
`.clineignore` uses the same pattern syntax as `.gitignore`:
| Pattern | Matches |
|---------|---------|
| `node_modules/` | The `node_modules` directory |
| `**/node_modules/` | `node_modules` at any depth |
| `*.csv` | All CSV files |
| `/build/` | The `build` directory at the project root only |
| `*.env.*` | Files like `.env.local`, `.env.production` |
| `!important.csv` | Exception: do not ignore this file |
Lines starting with `#` are comments. Blank lines are ignored.
## What to Exclude
Start with these categories and adjust for your project:
**Almost always exclude:**
- Package manager directories (`node_modules/`, `vendor/`, `.venv/`)
- Build outputs (`dist/`, `build/`, `.next/`, `out/`)
- Coverage reports (`coverage/`)
- Lock files if large (`package-lock.json`, `yarn.lock`)
**Exclude if present:**
- Large data files (`.csv`, `.xlsx`, `.sqlite`, `.parquet`)
- Binary assets (images, fonts, videos)
- Generated code (API clients, protobuf outputs, minified bundles)
- Environment files with secrets (`.env`, `.env.local`)
**Keep accessible:**
- Source code you actively work on
- Configuration files Cline needs to understand (`tsconfig.json`, `package.json`)
- Documentation and READMEs
- Test files (Cline often needs these for context)
## How It Works
When Cline scans your project to build context, it checks each file path against your `.clineignore` patterns. Matching files are excluded from:
- The file listing Cline sees when starting a task
- Automatic context gathering during conversations
- Search results when Cline looks for relevant code
You can still reference ignored files explicitly using [@ mentions](/core-workflows/working-with-files). If you type `@/node_modules/some-package/index.js`, Cline will read that specific file even though `node_modules/` is in your `.clineignore`. The ignore rules control automatic loading, not explicit access.
<Note>
`.clineignore` is separate from `.gitignore`. Files tracked by Git but irrelevant to Cline (like large test fixtures or data files) should go in `.clineignore` even if they're not in `.gitignore`.
</Note>
## Tips
- Add `.clineignore` early in your project. It's easier to start with broad exclusions and narrow them than to debug why context is bloated later.
- Check your token usage in the task header after adding a `.clineignore`. The difference is often dramatic.
- If Cline seems to be missing context about a file, check whether it's being excluded by your ignore patterns.
- For monorepos or multi-root workspaces, each workspace root can have its own `.clineignore`. See [Multi-Root Workspaces](/features/multiroot-workspace) for details.
## Related
- [Cline Rules](/customization/cline-rules) - Define persistent instructions for Cline
- [Task Management](/core-workflows/task-management#context-window) - Understand how context windows work
- [Auto-Compact](/features/auto-compact) - Automatic context compression during long tasks
- [Memory Bank](/features/memory-bank) - Structured documentation for cross-session context
+470
View File
@@ -0,0 +1,470 @@
---
title: "Hooks"
sidebarTitle: "Hooks"
description: "Inject custom logic into Cline's workflow to validate operations and shape Cline's decisions."
---
Hooks are scripts that run at key moments in Cline's workflow. Because they execute at known points with consistent inputs and outputs, hooks bring determinism to the non-deterministic nature of AI models by enforcing guardrails, validations, and context injection. You can validate operations before they execute, monitor tool usage, and shape how Cline makes decisions.
## What You Can Build
- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
- Run linters or custom validators before files get saved
- Prevent operations that violate security policies
- Track everything for analytics or compliance
- Trigger external tools or services at the right moments
- Add context to the conversation based on what Cline is doing
## Hook Types
Cline supports 8 hook types that run at different points in the task lifecycle:
| Hook Type | When It Runs |
|-----------|--------------|
| TaskStart | When you start a new task |
| TaskResume | When you resume an interrupted task |
| TaskCancel | When you cancel a running task |
| TaskComplete | When a task finishes successfully |
| PreToolUse | Before Cline executes a tool (read_file, write_to_file, etc.) |
| PostToolUse | After a tool execution completes |
| UserPromptSubmit | When you submit a message to Cline |
| PreCompact | Before Cline truncates conversation history to free up context |
## Hook Lifecycle
```mermaid
flowchart TD
%% Styling
classDef hook fill:#FFB74D,stroke:#E65100,stroke-width:2px,color:black,rx:5,ry:5;
classDef state fill:#E1F5FE,stroke:#0277BD,stroke-width:2px,color:black;
classDef action fill:#FFFFFF,stroke:#333,stroke-width:1px,color:black,stroke-dasharray: 5 5;
%% Entry Points
Start((Start)) --> CheckType{New or<br/>Resume?}
%% Initialization Hooks
CheckType -- New Task --> H_Start[TaskStart]:::hook
CheckType -- Resume --> H_Resume[TaskResume]:::hook
%% Main Loop
H_Start --> Loop(Task Active Loop):::state
H_Resume --> Loop
subgraph Conversation Cycle
direction TB
Loop -- User sends message --> H_Submit[UserPromptSubmit]:::hook
H_Submit --> Thinking[Cline Processes Context]:::state
%% Context Compaction Path
Thinking -. Context Limit Reached .-> H_Compact[PreCompact]:::hook
H_Compact -.-> Thinking
%% Tool Execution Path
Thinking -- Decides to use tool --> H_PreTool[PreToolUse]:::hook
H_PreTool -- Allowed --> ToolExec[Tool Executes]:::action
H_PreTool -- Cancelled --> Thinking
ToolExec --> H_PostTool[PostToolUse]:::hook
H_PostTool --> Thinking
end
%% Termination Paths
Thinking -- Task Successfully Finished --> H_Complete[TaskComplete]:::hook
Loop -- User Cancels Task --> H_Cancel[TaskCancel]:::hook
%% End
H_Complete --> End((End))
H_Cancel --> End
```
The diagram shows the complete hook lifecycle:
1. **Entry**: When you start a task, either **TaskStart** (new task) or **TaskResume** (interrupted task) runs first
2. **Conversation Cycle**: Each time you send a message, **UserPromptSubmit** runs, then Cline processes your request
3. **Tool Execution**: When Cline decides to use a tool, **PreToolUse** runs first-if allowed, the tool executes, then **PostToolUse** runs
4. **Context Management**: If the conversation approaches context limits, **PreCompact** runs before truncation
5. **Exit**: The task ends with either **TaskComplete** (success) or **TaskCancel** (user cancellation)
Orange nodes represent hooks where you can inject custom logic. The cycle repeats as you continue the conversation.
## Hook Locations
Hooks can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
- **Global hooks**: `~/Documents/Cline/Hooks/`
- **Project hooks**: `.clinerules/hooks/` in your repo (can be committed to version control)
When both global and workspace hooks exist for the same hook type, both run. Global hooks execute first, then workspace hooks. If either returns `cancel: true`, the operation stops.
## Creating a Hook
<Steps>
<Step title="Open the Hooks tab">
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Hooks tab.
</Step>
<Step title="Create a new hook">
Click **"New hook..."** dropdown and select a hook type (e.g., PreToolUse, TaskStart).
</Step>
<Step title="Review the hook's code">
Click the pencil icon to open and edit the hook script. Cline generates a template with examples.
</Step>
<Step title="Enable the hook">
Toggle the switch to activate the hook once you understand what it does.
</Step>
</Steps>
<Warning>
Always review a hook's code before enabling it. Hooks execute automatically during your workflow and can block operations or run shell commands.
</Warning>
## Quick Start: Your First Hook
Let's create a simple hook that logs every file Cline reads or writes. You'll see results in seconds.
### The Hook
Create a file called `file-logger` in your hooks directory with this content:
```bash
#!/bin/bash
# Logs all file operations to ~/cline-activity.log
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // "N/A"')
# Log to file
echo "$(date '+%H:%M:%S') - $TOOL: $FILE_PATH" >> ~/cline-activity.log
# Always allow the operation
echo '{"cancel":false}'
```
### Setup
<Steps>
<Step title="Create the hook file">
Save the script above as `~/Documents/Cline/Hooks/file-logger` (macOS/Linux) or create it through the Hooks UI.
</Step>
<Step title="Make it executable">
Run `chmod +x ~/Documents/Cline/Hooks/file-logger` in your terminal.
</Step>
<Step title="Enable it">
In Cline's Hooks tab, find "file-logger" under PreToolUse hooks and toggle it on.
</Step>
</Steps>
### Test It
Ask Cline to read any file in your project: "What's in package.json?"
Then check the log:
```bash
cat ~/cline-activity.log
```
You'll see entries like:
```text
14:23:45 - read_file: /path/to/package.json
14:23:47 - search_files: /path/to/src
```
### Customize It
Try modifying the hook to:
- Filter specific file types (only log `.ts` files)
- Add the task ID to each log entry
- Send notifications for write operations
- Block operations on certain paths
The sections below explain how hooks receive input and return output, plus more examples.
## How Hooks Work
Hooks are executable scripts that receive JSON input via stdin and return JSON output via stdout.
### Input Structure
Every hook receives a JSON object with common fields plus hook-specific data:
```json
{
"taskId": "abc123",
"clineVersion": "3.17.0",
"timestamp": 1736654400000,
"workspacePath": "/path/to/project",
// Hook-specific field (name matches hook type in camelCase)
"taskStart": {
"task": "Add authentication to the API"
}
}
```
The hook-specific field name matches the hook type:
- `taskStart`, `taskResume`, `taskCancel`, `taskComplete` contain `{ task: string }`
- `preToolUse` contains `{ tool: string, parameters: object }`
- `postToolUse` contains `{ tool: string, parameters: object, result: string, success: boolean, durationMs: number }`
- `userPromptSubmit` contains `{ prompt: string }`
- `preCompact` contains `{ conversationLength: number, estimatedTokens: number }`
### Output Structure
Hooks return a JSON object to stdout:
```json
{
"cancel": false,
"contextModification": "Optional text to add to the conversation",
"errorMessage": ""
}
```
| Field | Type | Description |
|-------|------|-------------|
| `cancel` | boolean | If `true`, stops the operation (blocks the tool, cancels the task start, etc.) |
| `contextModification` | string | Optional text that gets injected into the conversation as context for Cline |
| `errorMessage` | string | Shown to the user if `cancel` is `true` |
### Context Modification
The `contextModification` field lets hooks inject information into the conversation. This is useful for:
- Adding project-specific context when a task starts
- Providing validation results that Cline should consider
- Injecting environment information before tool execution
For example, a PreToolUse hook could add: `"Note: This file is auto-generated. Edits may be overwritten."`
## Hook Reference
### Task Lifecycle Hooks
#### TaskStart
Runs when you start a new task. Use it to:
- Log task start time for analytics
- Add project context to the conversation
- Check prerequisites before work begins
- Notify external systems (Slack, issue trackers)
```bash
#!/bin/bash
INPUT=$(cat)
TASK=$(echo "$INPUT" | jq -r '.taskStart.task')
echo "[TaskStart] Starting: $TASK" >&2
echo '{"cancel":false,"contextModification":"","errorMessage":""}'
```
#### TaskResume
Runs when you resume an interrupted task (instead of TaskStart). Use it to:
- Check for changes since the task was paused
- Refresh context with latest project state
- Notify that work is resuming
#### TaskCancel
Runs when you cancel a running task. Use it to:
- Clean up temporary files or resources
- Notify external systems about cancellation
- Log cancellation for analytics
#### TaskComplete
Runs when a task completes successfully. Use it to:
- Run tests or validation after changes
- Generate reports or summaries
- Notify stakeholders
- Trigger CI/CD pipelines
### Tool Hooks
#### PreToolUse
Runs before any tool executes. This is the most powerful hook for validation and safety. Use it to:
- Block dangerous operations
- Validate parameters before execution
- Add context about the file or resource being accessed
- Log tool usage
The input includes the tool name and its parameters:
```json
{
"preToolUse": {
"tool": "write_to_file",
"parameters": {
"path": "src/config.ts",
"content": "..."
}
}
}
```
Example that blocks `.js` files in a TypeScript project:
```bash
#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
exit 0
fi
echo '{"cancel":false}'
```
#### PostToolUse
Runs after a tool completes (success or failure). Use it to:
- Audit tool usage
- Validate results
- Trigger follow-up actions
- Monitor performance
The input includes execution results:
```json
{
"postToolUse": {
"tool": "execute_command",
"parameters": { "command": "npm test" },
"result": "All tests passed",
"success": true,
"durationMs": 3450
}
}
```
<Note>
PostToolUse hooks can return `cancel: true` to stop the task, but they cannot undo the tool execution that already happened.
</Note>
### Other Hooks
#### UserPromptSubmit
Runs when you send a message to Cline. Use it to:
- Log prompts for analytics
- Add context based on prompt content
- Validate or sanitize prompts
#### PreCompact
Runs before Cline truncates conversation history to stay within context limits. Use it to:
- Archive important conversation parts before they're removed
- Log compaction events
- Add a summary of what's being removed
The input includes context metrics:
```json
{
"preCompact": {
"conversationLength": 45,
"estimatedTokens": 125000
}
}
```
## Examples
### TypeScript Enforcement
Block creation of `.js` files in a TypeScript project:
```bash
#!/bin/bash
# PreToolUse hook
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
exit 0
fi
echo '{"cancel":false}'
```
### Tool Usage Logging
Log all tool executions to a file:
```bash
#!/bin/bash
# PostToolUse hook
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.postToolUse.tool')
SUCCESS=$(echo "$INPUT" | jq -r '.postToolUse.success')
DURATION=$(echo "$INPUT" | jq -r '.postToolUse.durationMs')
echo "$(date -Iseconds) | $TOOL | success=$SUCCESS | ${DURATION}ms" >> ~/.cline-tool-log.txt
echo '{"cancel":false}'
```
### Add Project Context on Task Start
Inject project-specific information when a task begins:
```bash
#!/bin/bash
# TaskStart hook
INPUT=$(cat)
WORKSPACE=$(echo "$INPUT" | jq -r '.workspacePath')
# Read project info if available
if [[ -f "$WORKSPACE/.project-context" ]]; then
CONTEXT=$(cat "$WORKSPACE/.project-context")
echo "{\"cancel\":false,\"contextModification\":\"Project context: $CONTEXT\"}"
else
echo '{"cancel":false}'
fi
```
## CLI Support
Hooks are available in the [Cline CLI](/cline-cli/getting-started):
```bash
# Enable hooks for a task
cline "What does this repo do?" -s hooks_enabled=true
# Configure hooks globally
cline config set hooks-enabled=true
```
<Note>
CLI hooks are only supported on macOS and Linux.
</Note>
## Troubleshooting
**Hook not running?**
- Check that the file is executable (`chmod +x hookname`)
- Verify the hook is enabled (toggle is on in the Hooks tab)
- Check that Hooks are enabled globally in Settings
**Hook output not parsed?**
- Ensure output is valid JSON on a single line to stdout
- Use stderr (`>&2`) for debug logging, not stdout
- Check for trailing characters or newlines before the JSON
**Hook blocking unexpectedly?**
- Review the hook's logic and test with sample input
- Check both global and workspace hooks (both run if they exist)
## Related Features
- [Rules](/customization/cline-rules) define high-level guidance that hooks can enforce programmatically
- [Checkpoints](/core-workflows/checkpoints) let you roll back if a hook didn't catch an issue
- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets
+86
View File
@@ -0,0 +1,86 @@
---
title: "Overview"
sidebarTitle: "Overview"
description: "Understand how Rules, Skills, Workflows, Hooks, and .clineignore work together to customize Cline."
---
Out of the box, Cline is a general-purpose AI assistant. Customizations transform it into an expert on your codebase, your team's conventions, and your workflows. Instead of repeating the same instructions every task, you define them once and Cline follows them automatically.
Cline offers five systems for this: Rules, Skills, Workflows, Hooks, and .clineignore. Each serves a different purpose and activates at different times.
## Quick Comparison
| Feature | Purpose | When Active | Best For |
|---------|---------|-------------|----------|
| **[Rules](/customization/cline-rules)** | Define how Cline behaves | Always (or contextually) | Coding standards, project constraints, team conventions |
| **[Skills](/customization/skills)** | Domain expertise loaded on-demand | Triggered by matching requests | Specialized knowledge, complex procedures, institutional expertise |
| **[Workflows](/customization/workflows)** | Step-by-step task automation | Invoked with `/workflow.md` | Repetitive processes, release procedures, setup scripts |
| **[Hooks](/customization/hooks)** | Inject custom logic at key moments | Automatically on specific events | Validation, enforcement, monitoring, automation triggers |
| **[.clineignore](/customization/clineignore)** | Control file access | Always | Excluding dependencies, build artifacts, large data files |
## Understanding Each Tool
**[Rules](/customization/cline-rules)** are always-on guidance. Use them when you want Cline to consistently follow certain patterns: coding standards, naming conventions, architectural constraints, or project-specific context. Rules shape *how* Cline works across all tasks. For example, a rule might say "always use TypeScript" or "follow the repository pattern for data access."
**[Skills](/customization/skills)** are domain expertise that loads only when relevant. Use them when you have extensive knowledge that would waste context if always active. Cline sees skill descriptions at startup and activates the full instructions only when your request matches. A data analysis skill might include pandas patterns, visualization preferences, and output formats that Cline only loads when you're working with data files.
**[Workflows](/customization/workflows)** are explicit task scripts you invoke on demand. Use them when you have a repeatable multi-step process that should run the same way every time. Type `/release.md` and Cline executes your release sequence: bump version, run tests, update changelog, commit, tag, push. Workflows define *what* to do, step by step.
**[Hooks](/customization/hooks)** are programmatic guardrails that run automatically at key moments. Use them when you need to validate, enforce, or extend Cline's behavior with custom code. A hook might block `.js` file creation in a TypeScript project, run linters before saves, or notify external services after deployments.
**[.clineignore](/customization/clineignore)** controls which files and directories Cline can access. Use it to exclude dependencies, build artifacts, generated files, and large data files from Cline's context. This reduces token usage, lowers costs, and keeps Cline focused on the code that matters. It works like `.gitignore`: add patterns to a `.clineignore` file in your project root and matching files are automatically excluded.
### Example: A Release Process
Consider how all five work together for releasing a new version:
1. **Rules** ensure Cline follows your team's commit message format and versioning policy
2. **Skills** offer deep knowledge about your CI/CD system that Cline loads when deployment questions arise
3. **Workflows** provide the explicit `/release.md` sequence: bump version, update changelog, tag, push
4. **Hooks** validate that tests pass before allowing any commit or that the changelog was actually updated
5. **.clineignore** keeps build artifacts, `node_modules/`, and generated files out of Cline's context so it stays focused
## Storage Locations
All five systems support both global and project-specific configurations:
| System | Global Location | Project Location |
|--------|-----------------|------------------|
| Rules | `~/Documents/Cline/Rules/` | `.clinerules/` |
| Skills | `~/.cline/skills/` | `.cline/skills/` |
| Workflows | `~/Documents/Cline/Workflows/` | `.clinerules/workflows/` |
| Hooks | `~/Documents/Cline/Hooks/` | `.clinerules/hooks/` |
| .clineignore | N/A | `.clineignore` |
### When to Use Each
**Start with project storage.** Most customizations belong in your project's directory because they're tied to that specific codebase. Team coding standards, deployment workflows, and architectural constraints all live with the code they describe. This also means your customizations travel with the repository, so collaborators get them automatically and changes can be reviewed in pull requests.
**Use global storage for personal preferences.** If you find yourself adding the same customization to every project, move it to global storage. Your preferred communication style, personal productivity workflows, and tools you use everywhere belong here. Global customizations apply to all projects but stay out of version control, so they won't affect your teammates.
When names conflict, project-specific configurations take precedence (except for Skills, where global takes precedence). This lets you override global defaults for specific projects when needed.
## Security Considerations
<Warning>
Always review customizations before adding them to your projects. Only use customizations from sources you trust.
</Warning>
Customizations are powerful. They shape how Cline writes code, execute commands automatically, and influence every interaction. Treat customization files with the same scrutiny you'd give any code running in your environment.
### Best Practices
Review any customization file before adding it to your project or global configuration. Understand what it does and why.
When downloading customizations from GitHub repositories, community shares, or other external sources, verify the source:
- Is the author reputable?
- Has the community reviewed it?
- Does the code do what it claims?
Look for dangerous commands:
- Shell commands that delete files (`rm`, `del`)
- Commands that transmit data (`curl`, `wget` with POST)
- File operations outside your project directory
- Commands that modify system configuration
Keep your customizations in version control so you can track changes, review diffs, and roll back if something goes wrong. When creating hooks, use the most restrictive event triggers necessary. Don't run hooks on every file save if you only need them before commits.
+261
View File
@@ -0,0 +1,261 @@
---
title: "Skills"
sidebarTitle: "Skills"
description: "Modular instruction sets that extend Cline's capabilities for specific tasks."
---
Skills are modular instruction sets that extend Cline's capabilities for specific tasks. Each skill packages detailed guidance, workflows, and optional resources that Cline loads only when relevant to your request.
Install multiple skills and Cline only loads what it needs. A deployment skill stays dormant until you ask about deploying. Unlike [rules](/customization/cline-rules) (which are always active), skills load on-demand so they don't consume context when you're working on something unrelated.
<Note>
Skills is an experimental feature. Enable it in **Settings → Features → Enable Skills**.
</Note>
## How Skills Work
Skills use progressive loading to maximize efficiency:
| Level | When Loaded | Token Cost | Content |
|-------|-------------|------------|---------|
| Metadata | Always (at startup) | ~100 tokens per skill | `name` and `description` from YAML frontmatter |
| Instructions | When skill is triggered | Under 5k tokens | SKILL.md body with instructions and guidance |
| Resources | As needed | Effectively unlimited | Bundled files accessed via `read_file` or executed scripts |
When you send a message, Cline sees a list of available skills with their descriptions. If your request matches a skill's description, Cline activates it using the `use_skill` tool, which loads the full instructions from SKILL.md.
## Skill Structure
Every skill is a directory containing a `SKILL.md` file with YAML frontmatter.
```text title="Skill directory structure"
my-skill/
├── SKILL.md # Required: main instructions
├── docs/ # Optional: additional documentation
│ └── advanced.md
└── scripts/ # Optional: utility scripts
└── helper.sh
```
The `SKILL.md` file has two parts: metadata and instructions.
```markdown title="SKILL.md"
---
name: my-skill
description: Brief description of what this skill does and when to use it.
---
# My Skill
Detailed instructions for Cline to follow when this skill is activated.
## Steps
1. First, do this
2. Then do that
3. For advanced usage, see [advanced.md](docs/advanced.md)
```
Required fields:
- `name` must exactly match the directory name
- `description` tells Cline when to use this skill (max 1024 characters)
## Creating a Skill
<Steps>
<Step title="Open the Skills menu">
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Skills tab.
</Step>
<Step title="Create a new skill">
Click "New skill..." and enter a name for your skill (e.g., `aws-deploy`). Cline creates a skill directory with a template `SKILL.md` file.
</Step>
<Step title="Write your skill instructions">
Edit the `SKILL.md` file:
- Update the `description` field to specify when this skill should trigger
- Add detailed instructions in the body
- Optionally add supporting files in `docs/`, `templates/`, or `scripts/` subdirectories
</Step>
</Steps>
You can also create skills manually by creating the directory structure in your file system. Place skill directories in `.cline/skills/` (workspace) or `~/.cline/skills/` (global) and Cline will detect them automatically.
Put the important information first in your SKILL.md. Cline reads the file sequentially, so front-load the common cases. Use clear section headers like "## Error Handling" or "## Configuration" so Cline can scan for relevant sections.
### Toggling Skills
Every skill has a toggle to enable or disable it. This lets you control which skills are active without deleting the skill directory. Skills are enabled by default when discovered.
For example, you might disable a CI/CD skill when working on local development, or enable a client-specific skill only when working on that client's project.
## Writing Your SKILL.md
### Naming Conventions
The skill name appears in the `name` field and must match the directory name exactly. Use lowercase with hyphens (kebab-case) and be descriptive about what the skill does.
Good names:
- `aws-cdk-deploy`
- `pr-review-checklist`
- `database-migration`
- `api-client-generator`
Avoid:
- `aws` (too vague)
- `my_skill` (underscores, not descriptive)
- `DeployToAWS` (use kebab-case, not PascalCase)
- `misc-helpers` (too generic)
### Writing Effective Descriptions
The description determines when Cline activates the skill. A vague description means the skill won't trigger when you expect it to.
Good descriptions are specific and actionable:
```yaml
description: Deploy applications to AWS using CDK. Use when deploying, updating infrastructure, or managing AWS resources.
description: Generate release notes from git commits. Use when preparing releases, writing changelogs, or summarizing recent changes.
description: Analyze CSV and Excel data files. Use when exploring datasets, generating statistics, or creating visualizations from tabular data.
```
Weak descriptions leave too much ambiguity:
```yaml
description: Helps with AWS stuff.
description: Data analysis helper.
description: Useful for releases.
```
Start with what the skill does (action verbs), include trigger phrases users might say, and mention specific file types, tools, or domains. Test your descriptions by trying different phrasings of requests to see if the skill triggers.
### Keeping Skills Focused
Keep SKILL.md under 5k tokens. If your skill needs more content, split it into separate files in a `docs/` directory and reference them from the main instructions. Cline loads referenced files only when needed.
Include real examples. Show what commands to run, what output to expect, and what the result should look like. Abstract instructions are harder to follow than concrete examples.
## Where Skills Live
Skills can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
Project skills:
- `.cline/skills/` (recommended)
- `.clinerules/skills/`
- `.claude/skills/`
Global skills:
- `~/.cline/skills/` (macOS/Linux)
- `C:\Users\USERNAME\.cline\skills\` (Windows)
When a global skill and project skill have the same name, the global skill takes precedence. This lets you keep general-purpose skills globally while using project-specific skills in `.cline/skills/` so the whole team can use them.
Version control your project skills by committing `.cline/skills/`. Your team can share, review, and improve them together.
## Bundling Supporting Files
Skills can include additional files that Cline accesses only when needed.
```text title="Directory structure"
complex-skill/
├── SKILL.md
├── docs/
│ ├── setup.md
│ └── troubleshooting.md
├── templates/
│ └── config.yaml
└── scripts/
└── validate.py
```
### docs/
Use docs for information that's too detailed for SKILL.md or only relevant in specific situations:
- Advanced configuration options
- Troubleshooting guides for edge cases
- Reference material (API schemas, database schemas)
- Platform-specific instructions
A deployment skill might have `docs/aws.md`, `docs/gcp.md`, and `docs/azure.md`. Cline loads only the relevant platform guide based on your request.
### templates/
Use templates when your skill creates configuration files, boilerplate code, or structured documents:
- Config files (Terraform, Docker Compose, CI/CD pipelines)
- Code scaffolding (component templates, test fixtures)
- Documentation templates (README, API docs)
A project setup skill could include `templates/dockerfile`, `templates/docker-compose.yml`, and `templates/.env.example` that Cline customizes for each new project.
### scripts/
Use scripts for deterministic operations where you want consistent behavior:
- Validation (linting configs, checking prerequisites)
- Data processing (parsing, formatting, transforming)
- Complex calculations (cost estimation, resource sizing)
- API interactions (fetching data, running health checks)
Scripts are token-efficient because only their output enters context, not the code itself. A 500-line validation script produces a simple "Passed" or detailed error messages without consuming any context for the script logic.
### Referencing Bundled Files
Reference these files in your SKILL.md instructions:
```markdown title="SKILL.md (referencing bundled files)"
For initial setup, follow [setup.md](docs/setup.md).
Use the config template at `templates/config.yaml` as a starting point.
Run the validation script to check your configuration:
python scripts/validate.py
```
Cline reads documentation files using `read_file` when the instructions reference them. Scripts can be executed directly, and only the script's output enters the context window.
| Use Scripts For | Use Instructions For |
|-----------------|---------------------|
| Deterministic operations (validation, formatting) | Flexible guidance that adapts to context |
| Complex computations | Decision-making workflows |
| Operations that need reliability | Steps that might vary by situation |
| Anything you'd rather not consume tokens explaining | Best practices and patterns |
## Example: Data Analysis Skill
Here's a practical skill for data analysis tasks. Create a directory called `data-analysis/` with this `SKILL.md`:
```markdown title="data-analysis/SKILL.md"
---
name: data-analysis
description: Analyze data files and generate insights. Use when working with CSV, Excel, or JSON data files that need exploration, cleaning, or visualization.
---
# Data Analysis
When analyzing data files, follow this workflow:
## 1. Understand the Data
- Read a sample of the file to understand its structure
- Identify column types and data quality issues
- Note any missing values or anomalies
## 2. Ask Clarifying Questions
Before diving in, ask the user:
- What specific insights are they looking for?
- Are there any known data quality issues?
- What format do they want for the output?
## 3. Perform Analysis
Use pandas for data manipulation:
import pandas as pd
# Load and explore
df = pd.read_csv("data.csv")
print(df.head())
print(df.describe())
print(df.info())
For visualization, prefer matplotlib or seaborn depending on complexity.
```
Skills transform Cline from a general-purpose assistant into a specialist that knows your domain. Start with one skill for a task you repeat often, test it, and iterate on the description until it triggers reliably.
+221
View File
@@ -0,0 +1,221 @@
---
title: "Workflows"
sidebarTitle: "Workflows"
description: "Automate repetitive tasks with Markdown-based workflow files."
---
Workflows are Markdown files that define a series of steps to guide Cline through repetitive or complex tasks. Type `/` followed by the workflow's filename to invoke it (e.g., `/deploy.md`).
Deploying, setting up a new project, running through a release checklist: these tasks often require remembering a dozen steps, running commands in the right order, and updating files manually. Mess up one step and you're debugging for an hour. Workflows turn those multi-step processes into one command. Type `/release.md` and Cline handles the version bump, runs tests, updates the changelog, commits, tags, and pushes. You just review and approve.
## Workflow Structure
A workflow is a markdown file with a title and steps. The filename becomes the command: `demo-workflow.md` is invoked with `/demo-workflow.md`.
````markdown title="demo-workflow.md"
# Demo Workflow
Brief description of what this workflow accomplishes.
## Step 1: Check prerequisites
Verify the environment is ready. Look for required tools and dependencies.
## Step 2: Run the build
Execute the build command:
```bash
npm run build
```
## Step 3: Verify results
Check that the build completed successfully and report any issues.
````
Steps can be written at different levels of detail:
- **High-level**: "Run the test suite and fix any failures" lets Cline decide how to accomplish the goal
- **Specific**: Use XML tool syntax or exact commands when you need precise control
## Creating Workflows
<Steps>
<Step title="Open the Workflows menu">
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Workflows tab.
</Step>
<Step title="Create a new workflow file">
Click "New workflow file..." and enter a filename (e.g., `deploy`). The file will be created with a `.md` extension.
</Step>
<Step title="Write your workflow">
Add a title and numbered steps in markdown format. Describe what each step should accomplish.
</Step>
</Steps>
<Tip>
**Create workflows from completed tasks.** After finishing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." Cline analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
</Tip>
### Invoking Workflows
Type `/` in the chat input to see available workflows. Cline shows autocomplete suggestions as you type, so `/rel` would match `release-prep.md`. Select a workflow and press Enter to start it.
Cline executes each step in sequence, pausing for your approval when needed. You can stop a workflow at any point by rejecting a step.
### Toggling Workflows
Every workflow has a toggle to enable or disable it. This lets you control which workflows appear in the `/` menu without deleting the file.
## Where Workflows Live
Workflows can be stored in two locations: your project workspace or globally on your system.
**Workspace workflows** go in `.clinerules/workflows/` at your project root. Use these for project-specific automation like deployment scripts, release processes, or setup procedures that your team shares.
**Global workflows** go in your system's Cline Workflows directory. Use these for personal productivity workflows you use across all projects.
### Global Workflows Directory
| Operating System | Default Location |
|------------------|------------------|
| Windows | `Documents\Cline\Workflows` |
| macOS | `~/Documents/Cline/Workflows` |
| Linux/WSL | `~/Documents/Cline/Workflows` |
Workspace workflows take precedence when names match global workflows. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
## What Workflows Can Use
Workflows can combine natural language instructions with specific tool calls. This flexibility lets you write workflows that are as simple or as precise as your task requires.
### Natural Language
Write steps as plain instructions. Cline interprets them and figures out which tools to use:
```markdown
## Step 1: Check for uncommitted changes
Look at the git status. If there are uncommitted changes, ask whether to continue or abort.
## Step 2: Run the test suite
Execute all tests. If any fail, show the failures and stop.
```
This approach works well when you want Cline to adapt to the situation rather than follow rigid steps.
### Cline Tools
For precise control, use Cline's built-in tools with XML syntax. This guarantees specific actions:
```xml
<execute_command>
<command>npm run test</command>
<requires_approval>false</requires_approval>
</execute_command>
```
```xml
<read_file>
<path>src/config.json</path>
</read_file>
```
```xml
<ask_followup_question>
<question>Deploy to production or staging?</question>
<options>["Production", "Staging", "Cancel"]</options>
</ask_followup_question>
```
See the full list in the [Cline Tools Reference](/tools-reference/all-cline-tools).
### CLI Tools
Reference any command-line tool installed on your machine. Git, npm, docker, gh, make, curl: whatever you have available.
```bash
git log --author="$(git config user.name)" --since="yesterday" --oneline
```
### MCP Tools
If you have [MCP servers](/mcp/mcp-overview) connected, use them in your workflows with the `use_mcp_tool` syntax. This lets you integrate with external services like GitHub, Slack, databases, or custom internal tools.
```xml
<use_mcp_tool>
<server_name>github-server</server_name>
<tool_name>create_release</tool_name>
<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
</use_mcp_tool>
```
Or describe the intent in natural language and let Cline figure out the tool call:
```markdown
## Step 3: Create GitHub release
Use the GitHub MCP server to create a release tagged with the version from package.json.
Include the changelog as the release body.
```
## Writing Effective Workflows
**Start simple.** Write natural language steps first. Only add XML tool calls when you need guaranteed behavior.
**Be specific about decisions.** If a step requires user input, make that explicit: "Ask whether to deploy to production or staging."
**Include failure handling.** Tell Cline what to do when something goes wrong: "If tests fail, show the failures and stop the workflow."
**Keep workflows focused.** A `deploy.md` should deploy. A `setup-db.md` should set up the database. Split complex processes into multiple workflows that can be run independently.
**Version control your workflows.** Store workflows in `.clinerules/workflows/` and commit them. Your team can share, review, and improve them together.
<Warning>
Workflows execute with your permissions. Review workflows before running them, especially those from external sources.
</Warning>
## Example: Release Preparation
This workflow automates the tedious pre-release checklist. It verifies your working directory is clean, runs tests and builds, prompts you for the version bump, and generates a changelog from recent commits.
The workflow demonstrates both approaches: XML tool syntax (`<execute_command>`, `<ask_followup_question>`) for steps that need precise control, and natural language for steps where Cline should adapt to the situation.
````markdown title="release-prep.md"
# Release Preparation
Prepare a new release by running tests, building, and updating version info.
## Step 1: Check for clean working directory
<execute_command>
<command>git status --porcelain</command>
</execute_command>
If there are uncommitted changes, ask whether to continue or stash them first.
## Step 2: Run the test suite
<execute_command>
<command>npm run test</command>
</execute_command>
If any tests fail, stop the workflow and report the failures.
## Step 3: Build the project
<execute_command>
<command>npm run build</command>
</execute_command>
Verify the build completes without errors.
## Step 4: Ask for new version
<ask_followup_question>
<question>What should the new version be?</question>
<options>["Patch (x.x.X)", "Minor (x.X.0)", "Major (X.0.0)", "Custom"]</options>
</ask_followup_question>
## Step 5: Update version
Update the version in `package.json` to the new version specified by the user.
## Step 6: Generate changelog entry
<execute_command>
<command>git log --oneline $(git describe --tags --abbrev=0)..HEAD</command>
</execute_command>
Use these commits to write a changelog entry for the new version.
````
Invoke it with `/release-prep.md` and Cline walks through each step.
+320 -163
View File
@@ -1,6 +1,6 @@
{
"$schema": "https://mintlify.com/docs.json",
"theme": "linden",
"theme": "mint",
"name": "Cline",
"description": "AI-powered coding agent for complex work",
"colors": {
@@ -60,180 +60,91 @@
"icon": "square-terminal",
"groups": [
{
"group": "Introduction",
"group": "Home",
"pages": [
"introduction/welcome",
"introduction/overview"
"home",
"getting-started/quick-start"
]
},
{
"group": "Getting Started",
"pages": [
"getting-started/what-is-cline",
"getting-started/installing-cline",
"getting-started/selecting-your-model",
"getting-started/authorizing-with-cline",
"getting-started/your-first-project"
]
},
{
"group": "Best Practices",
"group": "Core Workflows",
"pages": [
"prompting/understanding-context-management",
"prompting/prompt-engineering-guide",
"prompting/cline-memory-bank"
"core-workflows/task-management",
"core-workflows/plan-and-act",
"core-workflows/working-with-files",
"core-workflows/using-commands",
"core-workflows/checkpoints"
]
},
{
"group": "CLI",
"group": "Customization",
"pages": [
"customization/overview",
"customization/cline-rules",
"customization/skills",
"customization/workflows",
"customization/hooks",
"customization/clineignore"
]
},
{
"group": "Cline CLI",
"pages": [
"cline-cli/overview",
"cline-cli/installation",
"cline-cli/interactive-mode",
"cline-cli/configuration",
"cline-cli/three-core-flows",
"cline-cli/acp-editor-integrations",
{
"group": "CLI Samples",
"group": "Headless Mode",
"pages": [
"cline-cli/three-core-flows",
"cline-cli/samples/overview",
"cline-cli/samples/model-orchestration",
"cline-cli/samples/worktree-workflows",
"cline-cli/samples/github-issue-rca",
"cline-cli/samples/github-integration",
"cline-cli/samples/github-pr-review"
"cline-cli/samples/github-pr-review",
"cline-cli/samples/model-orchestration",
"cline-cli/samples/worktree-workflows"
]
},
"cline-cli/configuration",
"cline-cli/acp-editor-integrations",
"cline-cli/cli-reference"
]
},
{
"group": "Features",
"pages": [
{
"group": "@ Mentions",
"pages": [
"features/at-mentions/overview",
"features/at-mentions/file-mentions",
"features/at-mentions/terminal-mentions",
"features/at-mentions/problem-mentions",
"features/at-mentions/git-mentions",
"features/at-mentions/url-mentions"
]
},
"features/memory-bank",
"features/focus-chain",
"features/auto-approve",
"features/auto-compact",
"features/background-edit",
"features/checkpoints",
{
"group": "Cline Rules",
"pages": [
"features/cline-rules/overview",
"features/cline-rules/conditional-rules"
]
},
{
"group": "Commands & Shortcuts",
"pages": [
"features/commands-and-shortcuts/overview",
"features/commands-and-shortcuts/code-commands",
"features/commands-and-shortcuts/terminal-integration",
"features/commands-and-shortcuts/git-integration",
"features/commands-and-shortcuts/keyboard-shortcuts"
]
},
{
"group": "Customization",
"pages": [
"features/customization/opening-cline-in-sidebar",
"features/customization/disable-terminal-pagers"
]
},
"features/dictation",
"features/drag-and-drop",
"features/editing-messages",
"features/explain-changes",
"features/focus-chain",
{
"group": "Hooks",
"pages": [
"features/hooks/index",
"features/hooks/hook-reference",
"features/hooks/samples"
]
},
"features/jupyter-notebooks",
"features/multiroot-workspace",
"features/plan-and-act",
"features/skills",
"features/subagents",
{
"group": "Slash Commands",
"pages": [
"features/slash-commands/new-task",
"features/slash-commands/new-rule",
"features/slash-commands/explain-changes",
"features/slash-commands/smol",
"features/slash-commands/report-bug",
"features/slash-commands/deep-planning"
]
},
{
"group": "Workflows",
"pages": [
"features/slash-commands/workflows/index",
"features/slash-commands/workflows/quickstart",
"features/slash-commands/workflows/best-practices"
]
},
{
"group": "Task Management",
"pages": [
"features/tasks/understanding-tasks",
"features/tasks/task-management"
]
},
"features/worktrees",
"features/yolo-mode"
"features/background-edit",
"features/jupyter-notebooks",
"features/deep-planning",
"features/web-tools",
"features/worktrees"
]
},
{
"group": "Model & Provider Configuration",
"group": "Models & Providers",
"pages": [
{
"group": "Model Selection",
"group": "Choosing & Configuring Models",
"pages": [
"core-features/model-selection-guide",
"model-config/model-comparison",
"model-config/context-windows"
]
},
{
"group": "Cloud Providers",
"pages": [
"provider-config/anthropic",
"provider-config/claude-code",
"provider-config/openai",
"provider-config/openai-codex",
"provider-config/openrouter",
"provider-config/cerebras",
"provider-config/deepseek",
"provider-config/groq",
"provider-config/xai-grok",
"provider-config/mistral-ai",
"provider-config/doubao",
"provider-config/fireworks",
"provider-config/zai",
"provider-config/gcp-vertex-ai",
"provider-config/baseten",
{
"group": "AWS Bedrock",
"pages": [
"provider-config/aws-bedrock/api-key",
"provider-config/aws-bedrock/iam-credentials",
"provider-config/aws-bedrock/cli-profile"
]
}
]
},
{
"group": "Running Models Locally",
"pages": [
@@ -242,47 +153,94 @@
"running-models-locally/lm-studio"
]
},
{
"group": "Cloud Providers",
"pages": [
"provider-config/qwen",
"provider-config/anthropic",
"provider-config/asksage",
"provider-config/baseten",
"provider-config/cerebras",
"provider-config/claude-code",
"provider-config/deepseek",
"provider-config/doubao",
"provider-config/fireworks",
"provider-config/gcp-vertex-ai",
"provider-config/google-gemini",
"provider-config/groq",
"provider-config/huawei-cloud-maas",
"provider-config/huggingface",
"provider-config/minimax",
"provider-config/mistral-ai",
"provider-config/moonshot",
"provider-config/nebius",
"provider-config/nousresearch",
"provider-config/openai",
"provider-config/openai-codex",
"provider-config/openrouter",
"provider-config/oracle-code-assist",
"provider-config/qwen-code",
"provider-config/sambanova",
"provider-config/together",
"provider-config/xai-grok",
"provider-config/zai",
{
"group": "AWS Bedrock",
"pages": [
"provider-config/aws-bedrock/api-key",
"provider-config/aws-bedrock/iam-credentials",
"provider-config/aws-bedrock/cli-profile"
]
}
]
},
{
"group": "Advanced Configuration",
"pages": [
"provider-config/openai-compatible",
"provider-config/aihubmix",
"provider-config/dify",
"provider-config/hicap",
"provider-config/litellm-and-cline-using-codestral",
"provider-config/vscode-language-model-api",
"provider-config/openai-compatible",
"provider-config/requesty",
"provider-config/sap-aicore",
"provider-config/vercel-ai-gateway",
"provider-config/requesty"
"provider-config/vscode-language-model-api"
]
}
]
},
{
"group": "MCP Integration",
"group": "MCP (Extending Cline)",
"pages": [
"mcp/mcp-overview",
"mcp/adding-mcp-servers-from-github",
"mcp/configuring-mcp-servers",
"mcp/connecting-to-a-remote-server",
"mcp/mcp-marketplace",
"mcp/adding-and-configuring-servers",
"mcp/mcp-server-development-protocol",
"mcp/connecting-to-a-remote-server",
"mcp/mcp-transport-mechanisms"
]
},
{
"group": "Cline Tools Reference",
"group": "Tools Reference",
"pages": [
"exploring-clines-tools/cline-tools-guide",
"exploring-clines-tools/new-task-tool",
"exploring-clines-tools/remote-browser-support"
"tools-reference/all-cline-tools",
"tools-reference/browser-automation"
]
},
{
"group": "Reference",
"group": "Troubleshooting",
"pages": [
"troubleshooting/networking-and-proxies",
"troubleshooting/terminal-quick-fixes",
"troubleshooting/terminal-integration-guide",
"troubleshooting/task-history-recovery",
"more-info/telemetry"
"troubleshooting/networking-and-proxies",
"troubleshooting/task-history-recovery"
]
},
{
"group": "Contributing",
"pages": [
"contributing/documentation-guide",
"contributing/doc-templates"
]
}
]
@@ -336,8 +294,7 @@
"pages": [
"enterprise-solutions/monitoring/overview",
"enterprise-solutions/monitoring/telemetry",
"enterprise-solutions/monitoring/opentelemetry",
"enterprise-solutions/monitoring/opentelemetry_override"
"enterprise-solutions/monitoring/opentelemetry"
]
}
]
@@ -362,7 +319,7 @@
{
"name": "Overview",
"icon": "house",
"url": "introduction/overview"
"url": "getting-started/what-is-cline"
}
],
"redirects": [
@@ -370,17 +327,21 @@
"source": "/getting-started/installing-cline-jetbrains",
"destination": "/getting-started/installing-cline"
},
{
"source": "/getting-started/what-is-cline",
"destination": "/introduction/overview"
},
{
"source": "/getting-started/overview",
"destination": "/introduction/overview"
"destination": "/getting-started/what-is-cline"
},
{
"source": "/introduction",
"destination": "/introduction/welcome"
"destination": "/getting-started/what-is-cline"
},
{
"source": "/introduction/welcome",
"destination": "/getting-started/what-is-cline"
},
{
"source": "/introduction/overview",
"destination": "/getting-started/what-is-cline"
},
{
"source": "/getting-started/model-selection-guide",
@@ -396,11 +357,39 @@
},
{
"source": "/getting-started/understanding-context-management",
"destination": "/prompting/understanding-context-management"
"destination": "/model-config/context-windows"
},
{
"source": "/best-practices/understanding-context-management",
"destination": "/prompting/understanding-context-management"
"destination": "/model-config/context-windows"
},
{
"source": "/prompting/understanding-context-management",
"destination": "/model-config/context-windows"
},
{
"source": "/prompting/prompt-engineering-guide",
"destination": "/customization/cline-rules"
},
{
"source": "/prompting/cline-memory-bank",
"destination": "/features/memory-bank"
},
{
"source": "/customization/memory-bank",
"destination": "/features/memory-bank"
},
{
"source": "/customization/focus-chain",
"destination": "/features/focus-chain"
},
{
"source": "/customization/auto-approve",
"destination": "/features/auto-approve"
},
{
"source": "/customization/auto-compact",
"destination": "/features/auto-compact"
},
{
"source": "/getting-started/your-first-task",
@@ -410,9 +399,149 @@
"source": "/cline-cli/samples",
"destination": "/cline-cli/samples/overview"
},
{
"source": "/cline-cli/overview",
"destination": "/cline-cli/getting-started"
},
{
"source": "/features/hooks/real-world-examples",
"destination": "/features/hooks/samples"
"destination": "/customization/hooks"
},
{
"source": "/features/hooks/index",
"destination": "/customization/hooks"
},
{
"source": "/features/hooks/hook-reference",
"destination": "/customization/hooks"
},
{
"source": "/features/hooks/samples",
"destination": "/customization/hooks"
},
{
"source": "/features/plan-and-act",
"destination": "/core-workflows/plan-and-act"
},
{
"source": "/features/checkpoints",
"destination": "/core-workflows/checkpoints"
},
{
"source": "/features/tasks/understanding-tasks",
"destination": "/core-workflows/task-management"
},
{
"source": "/features/tasks/task-management",
"destination": "/core-workflows/task-management"
},
{
"source": "/features/at-mentions/overview",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/file-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/folder-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/terminal-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/problem-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/git-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/at-mentions/url-mentions",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/drag-and-drop",
"destination": "/core-workflows/working-with-files"
},
{
"source": "/features/yolo-mode",
"destination": "/features/auto-approve"
},
{
"source": "/features/cline-rules",
"destination": "/customization/cline-rules"
},
{
"source": "/features/cline-rules/overview",
"destination": "/customization/cline-rules"
},
{
"source": "/features/cline-rules/conditional-rules",
"destination": "/customization/cline-rules"
},
{
"source": "/features/commands-and-shortcuts/overview",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/commands-and-shortcuts/code-commands",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/commands-and-shortcuts/terminal-integration",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/commands-and-shortcuts/git-integration",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/commands-and-shortcuts/keyboard-shortcuts",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/slash-commands/new-task",
"destination": "/core-workflows/using-commands"
},
{
"source": "/features/slash-commands/workflows/index",
"destination": "/customization/workflows"
},
{
"source": "/features/slash-commands/workflows/quickstart",
"destination": "/customization/workflows"
},
{
"source": "/features/slash-commands/workflows/best-practices",
"destination": "/customization/workflows"
},
{
"source": "/exploring-clines-tools/cline-tools-guide",
"destination": "/tools-reference/all-cline-tools"
},
{
"source": "/exploring-clines-tools/new-task-tool",
"destination": "/tools-reference/all-cline-tools"
},
{
"source": "/exploring-clines-tools/remote-browser-support",
"destination": "/tools-reference/browser-automation"
},
{
"source": "/mcp/adding-mcp-servers-from-github",
"destination": "/mcp/adding-and-configuring-servers"
},
{
"source": "/mcp/configuring-mcp-servers",
"destination": "/mcp/adding-and-configuring-servers"
},
{
"source": "/more-info/telemetry",
"destination": "/enterprise-solutions/monitoring/telemetry"
},
{
"source": "/enterprise-solutions/configure-AWS-Bedrock-Admin",
@@ -439,16 +568,44 @@
"destination": "/enterprise-solutions/team-management/managing-members"
},
{
"source": "/features/cline-rules",
"destination": "/features/cline-rules/overview"
"source": "/features/customization/opening-cline-in-sidebar",
"destination": "/getting-started/installing-cline"
},
{
"source": "/features/conditional-rules",
"destination": "/features/cline-rules/conditional-rules"
"source": "/prompting/prompt-engineering-guide/clineignore-file-guide",
"destination": "/customization/clineignore"
},
{
"source": "/cline-cli/authentication",
"destination": "/cline-cli/installation"
"source": "/getting-started/selecting-your-model",
"destination": "/getting-started/authorizing-with-cline"
},
{
"source": "/model-config/model-comparison",
"destination": "/core-features/model-selection-guide"
},
{
"source": "/troubleshooting/terminal-integration-guide",
"destination": "/troubleshooting/terminal-quick-fixes"
},
{
"source": "/features/slash-commands/deep-planning",
"destination": "/features/deep-planning"
},
{
"source": "/features/slash-commands/smol",
"destination": "/core-workflows/using-commands#smol"
},
{
"source": "/features/slash-commands/explain-changes",
"destination": "/core-workflows/using-commands#explain-changes"
},
{
"source": "/features/slash-commands/new-rule",
"destination": "/core-workflows/using-commands#newrule"
},
{
"source": "/features/skills",
"destination": "/customization/skills"
}
],
"search": {
@@ -1,287 +0,0 @@
---
title: "Bundled Endpoints Configuration"
description: "Enterprise guide for distributing Cline with pre-configured endpoints"
---
# Bundled Endpoints Configuration
This guide explains how enterprise customers can distribute Cline with pre-configured endpoints bundled directly into the installation packages.
## Overview
Cline supports bundling custom endpoint configurations directly into distribution packages (VSIX, NPM, or JetBrains). This eliminates the need for end users to manually configure endpoints, ensuring consistent configuration across your organization.
### Configuration Priority
When Cline starts, it checks for endpoints configuration in this order:
1. **Bundled endpoints.json** (in extension installation directory) - Highest priority
2. **User endpoints.json** (`~/.cline/endpoints.json`) - Fallback
3. **Built-in endpoints** (standard Cline URLs) - Default
When a bundled `endpoints.json` is found, Cline automatically switches to self-hosted mode and uses those endpoints exclusively.
## Prerequisites
- Official Cline release package (VSIX, TGZ, or ZIP)
- Your `endpoints.json` configuration file
- `jq` command-line tool (for JSON validation)
- `unzip`, `zip`, `tar` utilities
## Creating endpoints.json
Create a JSON file with your organization's endpoints:
```json
{
"appBaseUrl": "https://cline.yourcompany.com",
"apiBaseUrl": "https://api-cline.yourcompany.com",
"mcpBaseUrl": "https://api-cline.yourcompany.com/v1/mcp"
}
```
### Required Fields
All three fields are required and must be valid URLs:
- **appBaseUrl**: Web application base URL
- **apiBaseUrl**: API server base URL
- **mcpBaseUrl**: MCP (Model Context Protocol) server URL
### Validation
The packaging scripts automatically validate:
- Valid JSON syntax
- All required fields present
- Non-empty string values
- Valid URL format (must start with `http://` or `https://`)
## Packaging Scripts
Cline provides three scripts for adding bundled endpoints to packages:
### VSCode Extension (VSIX)
```bash
./scripts/add-endpoints-to-vsix.sh \
cline-3.55.0.vsix \
cline-3.55.0-enterprise.vsix \
endpoints.json
```
This script:
1. Extracts the VSIX package
2. Adds `endpoints.json` to the `extension/` directory
3. Repackages as a new VSIX file
### NPM Package (CLI)
```bash
./scripts/add-endpoints-to-npm.sh \
cline-3.55.0.tgz \
cline-3.55.0-enterprise.tgz \
endpoints.json
```
This script:
1. Extracts the NPM tarball
2. Adds `endpoints.json` to the package root
3. Repackages as a new tarball
### JetBrains Plugin (ZIP)
```bash
./scripts/add-endpoints-to-jetbrains.sh \
cline-jetbrains-3.55.0.zip \
cline-jetbrains-3.55.0-enterprise.zip \
endpoints.json
```
This script:
1. Extracts the ZIP package
2. Adds `endpoints.json` to the plugin directory
3. Repackages as a new ZIP file
## Distribution Workflow
### 1. Download Official Release
Download the official Cline package for your platform:
```bash
# VSCode - from marketplace or GitHub releases
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
# NPM - from npm registry
npm pack @cline/cline@3.55.0
# JetBrains - from marketplace or GitHub releases
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-jetbrains-3.55.0.zip
```
### 2. Create Endpoints Configuration
Create your `endpoints.json` file:
```json
{
"appBaseUrl": "https://cline.internal.company.com",
"apiBaseUrl": "https://cline-api.internal.company.com",
"mcpBaseUrl": "https://cline-api.internal.company.com/v1/mcp"
}
```
### 3. Run Packaging Script
Choose the appropriate script for your platform:
```bash
# VSCode
./scripts/add-endpoints-to-vsix.sh \
cline-3.55.0.vsix \
cline-3.55.0-yourcompany.vsix \
endpoints.json
# CLI
./scripts/add-endpoints-to-npm.sh \
cline-3.55.0.tgz \
cline-3.55.0-yourcompany.tgz \
endpoints.json
# JetBrains
./scripts/add-endpoints-to-jetbrains.sh \
cline-jetbrains-3.55.0.zip \
cline-jetbrains-3.55.0-yourcompany.zip \
endpoints.json
```
### 4. Distribute to Users
Distribute the enterprise package to your users through your internal channels:
- **VSCode**: Install via `code --install-extension cline-3.55.0-yourcompany.vsix`
- **CLI**: Install via `npm install -g cline-3.55.0-yourcompany.tgz`
- **JetBrains**: Install through IDE plugin manager from disk
## Verification
After installation, verify the configuration is active:
1. Launch Cline
2. Check the logs for: `"Cline running in self-hosted mode with custom endpoints"`
3. Confirm that environment switching is disabled (as expected in self-hosted mode)
## User Experience
### What Users See
- Cline automatically uses the bundled endpoints
- No manual configuration required
- Environment switching is disabled (prevents accidental misconfiguration)
- All API calls route to your organization's infrastructure
### User Override
Users **cannot** override bundled endpoints through the UI. The bundled configuration takes absolute precedence. This ensures:
- Consistent configuration across the organization
- No accidental connections to external services
- Simplified deployment and support
If users have a `~/.cline/endpoints.json` file, it will be ignored when bundled configuration is present.
## Troubleshooting
### Invalid Configuration Error
If users see an error about invalid configuration on startup:
```
ClineConfigurationError: Invalid JSON in bundled endpoints configuration file
```
**Solution**: The bundled `endpoints.json` is malformed. Repackage with a valid JSON file.
### Missing Required Field Error
```
ClineConfigurationError: Missing required field "apiBaseUrl" in endpoints configuration file
```
**Solution**: Ensure all three required fields are present in `endpoints.json`.
### Invalid URL Error
```
ClineConfigurationError: Field "appBaseUrl" must be a valid URL. Got: "not-a-url"
```
**Solution**: All URLs must start with `http://` or `https://`.
## Security Considerations
1. **Bundle Validation**: The packaging scripts validate JSON structure and required fields
2. **Read-Only Configuration**: Users cannot modify bundled endpoints through the UI
3. **Self-Hosted Mode**: Automatic switch to self-hosted mode prevents external connections
4. **Audit Trail**: All endpoint access is logged with configuration source
## Updating Endpoints
To update endpoints for existing installations:
1. Create updated `endpoints.json`
2. Repackage the same Cline version with new endpoints
3. Distribute updated package
4. Users reinstall/update the package
The version number remains the same since only configuration changed, not the Cline code.
## Support
For questions or issues with bundled endpoints:
1. Verify your `endpoints.json` is valid JSON with all required fields
2. Check that URLs are accessible from user networks
3. Review Cline logs for configuration loading messages
4. Contact your Cline support representative for assistance
## Example: Complete Workflow
Here's a complete example for VSCode deployment:
```bash
# 1. Download official release
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
# 2. Create endpoints configuration
cat > endpoints.json << 'EOF'
{
"appBaseUrl": "https://cline.acme.internal",
"apiBaseUrl": "https://cline-api.acme.internal",
"mcpBaseUrl": "https://cline-api.acme.internal/v1/mcp"
}
EOF
# 3. Validate JSON
jq empty endpoints.json # Should succeed silently
# 4. Run packaging script
./scripts/add-endpoints-to-vsix.sh \
cline-3.55.0.vsix \
cline-3.55.0-acme.vsix \
endpoints.json
# 5. Verify output
unzip -l cline-3.55.0-acme.vsix | grep endpoints.json
# Should show: extension/endpoints.json
# 6. Test installation (on test machine)
code --install-extension cline-3.55.0-acme.vsix
# 7. Distribute to organization
# Upload to internal package repository
# or distribute via configuration management system
```
## Changelog
- **v3.55.0**: Initial release of bundled endpoints support
@@ -1,105 +0,0 @@
---
title: "Choosing Your Configuration Path"
sidebarTitle: "Deployment Guide"
description: "Decide between SaaS and Self-Hosted configuration for your Cline Enterprise deployment"
---
Choose the right configuration approach for your organization. Most teams start with SaaS for quick deployment, while enterprises with complex requirements opt for self-hosted infrastructure.
## Configuration Paths
<CardGroup cols={2}>
<Card title="SaaS Provider Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
### Quick Setup via Web Console
✅ No infrastructure required
✅ 5-10 minute configuration
✅ Web-based admin console
✅ Automatic updates
✅ Simplified credential management
**Best for:**
- Small to medium teams (5-50 developers)
- Quick deployment needs
- Limited DevOps resources
- Standard security requirements
- Single region deployments
</Card>
<Card title="Self-Hosted Configuration" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
### Full Infrastructure Control
✅ Your own AWS/GCP/K8s
✅ VPC endpoints & private connectivity
✅ Multi-account setups
✅ Advanced compliance & audit
✅ GitOps workflows
**Best for:**
- Large enterprises (50+ developers)
- Complex security requirements
- Existing cloud infrastructure
- Multi-region deployments
- Custom compliance needs
</Card>
</CardGroup>
## Detailed Comparison
### Feature Comparison
| Feature | SaaS | Self-Hosted |
|---------|------|-------------|
| **Configuration** | Web UI | YAML + Helm/Kubernetes |
| **Infrastructure** | None required | Full AWS/GCP/K8s |
| **VPC Endpoints** | Basic | Full private connectivity |
| **Multi-Account** | ❌ | ✅ |
| **IAM** | Standard RBAC roles | Standard RBAC roles |
| **Compliance** | Standard | Custom frameworks |
| **GitOps** | ❌ | ✅ |
| **Maintenance** | Managed by Cline | Self-managed |
| **Updates** | Automatic (extension) | Automatic (extension) + Infrastructure control |
### Security & Compliance
| Capability | SaaS | Self-Hosted |
|------------|------|-------------|
| **Network Encryption** | HTTPS/TLS | HTTPS/TLS |
| **Network** | Public internet | Private VPC endpoints |
| **Access Control** | Standard RBAC | Standard RBAC |
| **Audit Logs** | OpenTelemetry traces | OpenTelemetry traces + Infrastructure logs |
| **Data Residency** | Cline-managed deployment | Customer-controlled deployment |
### Cost Structure
| Cost Category | SaaS | Self-Hosted |
|---------------|------|-------------|
| **Cline Subscription** | Fixed enterprise fee | Fixed enterprise fee |
| **Inference Provider Costs** | Usage-based | Usage-based |
| **Infrastructure** | ✅ None required | Kubernetes, networking, storage |
| **Personnel** | ✅ None required | DevOps team needed |
| **Total Cost Profile** | Predictable and simple | Variable based on scale |
## Migration Path
<Note>
Most organizations start with SaaS configuration for quick deployment, then migrate to self-hosted later as requirements grow. This minimizes risk and ensures your infrastructure meets actual usage patterns.
</Note>
## Getting Started
<CardGroup cols={2}>
<Card title="Start with SaaS" icon="rocket" href="/enterprise-solutions/configuration/remote-configuration/overview">
Begin with quick SaaS setup
</Card>
<Card title="Deploy Self-Hosted" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
Plan your infrastructure deployment
</Card>
</CardGroup>
## Need Help Deciding?
- [**Contact Cline Enterprise Sales**](https://cline.bot/contact-sales) for a consultation on your specific requirements
- [**Start with SaaS**](/enterprise-solutions/configuration/remote-configuration/overview) if unsure - it's lower risk and you can always migrate later
- [**Review Self-Hosted Requirements**](/enterprise-solutions/configuration/infrastructure-configuration/overview) if you have existing infrastructure that could benefit from self-hosted deployment
@@ -1,35 +0,0 @@
---
title: "Overview"
sidebarTitle: "Overview"
description: "Configure Cline settings for your enterprise deployment"
---
This section covers configuration options for controlling Cline's behavior in enterprise deployments.
## Available Settings
<Card title="YOLO Mode" icon="rocket" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode">
Control enterprise access to autonomous operation mode with complete auto-approval
</Card>
## Configuration Methods
These settings can be configured through:
### Individual Users
- Users can toggle settings in their local Cline interface
- Enterprise policies can restrict certain settings
- Changes apply immediately to new tasks
## Enterprise Controls
Administrators can enforce policies through remote configuration:
```json
{
"yoloModeAllowed": false
}
```
When `yoloModeAllowed` is set to `false`, users cannot enable YOLO Mode in their local Cline interface.
@@ -1,565 +0,0 @@
---
title: "MCP Marketplace"
sidebarTitle: "MCP Marketplace"
description: "Deploy pre-built enterprise MCP servers from the Cline marketplace with one-click configuration"
---
The MCP Marketplace provides curated, enterprise-ready integrations with popular development tools and services. All marketplace servers are built with enterprise security, compliance, and scalability in mind.
## Enterprise Marketplace Benefits
<CardGroup cols={2}>
<Card title="One-Click Deployment" icon="rocket">
Deploy complex integrations instantly with pre-configured enterprise settings.
</Card>
<Card title="Security Hardened" icon="shield-check">
All servers include enterprise security features, audit logging, and compliance controls.
</Card>
<Card title="Maintained & Updated" icon="sync">
Regular security updates and feature enhancements managed by Cline Enterprise team.
</Card>
<Card title="Enterprise Support" icon="headset">
Dedicated support channels for marketplace integration issues and customization.
</Card>
</CardGroup>
## Available Integrations
### Development Tools
<CardGroup cols={3}>
<Card title="GitHub Enterprise" icon="github">
Repository management, issue tracking, PR workflows, and code analysis
</Card>
<Card title="GitLab Enterprise" icon="gitlab">
Project management, CI/CD pipelines, merge requests, and security scanning
</Card>
<Card title="Bitbucket Enterprise" icon="bitbucket">
Source code management, build pipelines, and deployment automation
</Card>
</CardGroup>
### Project Management
<CardGroup cols={3}>
<Card title="Jira Enterprise" icon="jira">
Issue tracking, sprint management, custom fields, and workflow automation
</Card>
<Card title="Azure DevOps" icon="microsoft">
Work items, boards, repos, pipelines, and test management
</Card>
<Card title="Linear" icon="linear">
Issue tracking, project planning, and development workflow integration
</Card>
</CardGroup>
### Communication & Collaboration
<CardGroup cols={3}>
<Card title="Slack Enterprise Grid" icon="slack">
Notifications, bot interactions, file sharing, and workflow automation
</Card>
<Card title="Microsoft Teams" icon="microsoft-teams">
Chat notifications, meeting integration, and collaborative workflows
</Card>
<Card title="Discord" icon="discord">
Community management, bot interactions, and developer notifications
</Card>
</CardGroup>
### Cloud Services
<CardGroup cols={3}>
<Card title="AWS Services" icon="aws">
EC2, S3, Lambda, RDS, CloudWatch, and other AWS service integrations
</Card>
<Card title="Google Cloud" icon="google-cloud">
Compute Engine, Cloud Storage, BigQuery, and GCP service management
</Card>
<Card title="Azure Services" icon="azure">
Virtual Machines, Storage Accounts, Functions, and Azure resource management
</Card>
</CardGroup>
## Installing Marketplace Servers
### Via Cline Enterprise Dashboard
1. **Access Marketplace**: Navigate to `Settings > Enterprise > MCP Marketplace`
2. **Browse Integrations**: Filter by category, popularity, or search by name
3. **Review Details**: Check compatibility, permissions, and configuration requirements
4. **Install**: Click "Install" and configure required settings
5. **Deploy**: Approve deployment to your selected environment
### Via Configuration File
Install marketplace servers through enterprise configuration:
```yaml
# enterprise-mcp-config.yaml
mcp:
marketplace_servers:
- name: "github-enterprise"
package: "@cline/mcp-github-enterprise"
version: "2.1.0"
environment: "production"
config:
github:
base_url: "https://github.company.com/api/v3"
token: "${GITHUB_ENTERPRISE_TOKEN}"
organization: "company"
features:
issue_management: true
pull_request_automation: true
code_analysis: true
security_scanning: true
permissions:
repositories: "read-write"
issues: "write"
pull_requests: "write"
compliance:
audit_logging: true
data_retention_days: 365
encryption_at_rest: true
- name: "jira-enterprise"
package: "@cline/mcp-jira-enterprise"
version: "1.8.3"
environment: "production"
config:
jira:
base_url: "https://company.atlassian.net"
username: "${JIRA_USERNAME}"
api_token: "${JIRA_API_TOKEN}"
projects:
- key: "DEV"
permissions: ["read", "write", "transition"]
- key: "OPS"
permissions: ["read", "comment"]
compliance:
field_encryption: ["description", "comments"]
audit_trail: true
```
### Via CLI
Deploy using the Cline Enterprise CLI:
```bash
# Install GitHub Enterprise integration
cline-enterprise mcp install github-enterprise \
--version 2.1.0 \
--config-file github-config.yaml \
--environment production
# Install Slack Enterprise Grid integration
cline-enterprise mcp install slack-enterprise-grid \
--version 1.5.2 \
--config workspace_id=T1234567890 \
--config bot_token=${SLACK_BOT_TOKEN} \
--environment production
# List installed marketplace servers
cline-enterprise mcp list --environment production
# Check server status
cline-enterprise mcp status github-enterprise --environment production
```
## Configuration Examples
### GitHub Enterprise Integration
```yaml
# github-enterprise-config.yaml
github:
base_url: "https://github.company.com/api/v3"
token: "${GITHUB_ENTERPRISE_TOKEN}"
organization: "company"
# Repository access controls
repositories:
allowed_patterns:
- "company/*"
- "internal/*"
blocked_patterns:
- "*/secrets"
- "*/private-keys"
# Feature configuration
features:
issue_management:
enabled: true
auto_assign: true
labels:
- "ai-generated"
- "cline-task"
pull_requests:
enabled: true
auto_review_request: true
required_approvals: 2
enforce_branch_protection: true
code_analysis:
enabled: true
languages: ["typescript", "python", "go", "rust"]
security_scan: true
# Security and compliance
security:
webhook_secret: "${GITHUB_WEBHOOK_SECRET}"
rate_limiting:
requests_per_hour: 5000
burst_limit: 100
ip_whitelist:
- "10.0.0.0/8"
- "192.168.0.0/16"
audit:
log_level: "INFO"
include_payloads: false
retention_days: 365
destinations: ["datadog", "splunk"]
```
### Jira Enterprise Integration
```yaml
# jira-enterprise-config.yaml
jira:
base_url: "https://company.atlassian.net"
username: "${JIRA_USERNAME}"
api_token: "${JIRA_API_TOKEN}"
# Project access configuration
projects:
- key: "DEV"
name: "Development"
permissions: ["read", "write", "transition", "assign"]
issue_types: ["Story", "Bug", "Task", "Subtask"]
- key: "OPS"
name: "Operations"
permissions: ["read", "comment", "watch"]
# Custom field mappings
custom_fields:
story_points: "customfield_10002"
epic_link: "customfield_10014"
sprint: "customfield_10020"
# Workflow automation
automation:
auto_transition:
enabled: true
rules:
- from_status: "To Do"
to_status: "In Progress"
condition: "assignee_changed"
auto_assign:
enabled: true
rules:
- issue_type: "Bug"
component: "Frontend"
assignee: "frontend-team-lead"
# Security and compliance
security:
encrypt_fields: ["description", "comment"]
mask_sensitive_data: true
audit_changes: true
compliance:
gdpr_compliant: true
data_retention_policy: "365_days"
audit_log_retention: "7_years"
```
### Slack Enterprise Grid Integration
```yaml
# slack-enterprise-config.yaml
slack:
workspace_id: "T1234567890"
bot_token: "${SLACK_BOT_TOKEN}"
signing_secret: "${SLACK_SIGNING_SECRET}"
# Channel management
channels:
notifications:
- name: "#dev-alerts"
types: ["deployments", "errors", "security"]
- name: "#ai-activity"
types: ["cline-tasks", "completions"]
private_channels:
- name: "#security-incidents"
members: ["security-team"]
types: ["security-alerts", "compliance-issues"]
# Bot behavior
bot:
display_name: "Cline Enterprise"
default_channel: "#general"
response_delay_ms: 1000
commands:
- command: "/cline-status"
description: "Check Cline Enterprise status"
permission: "all"
- command: "/cline-deploy"
description: "Trigger deployment"
permission: "admin"
# Enterprise features
enterprise:
app_approval_required: true
data_residency: "US"
compliance_export: true
dlp:
enabled: true
scan_messages: true
block_sensitive_data: true
# Security settings
security:
require_app_approval: true
audit_api_calls: true
encrypt_messages: true
retain_audit_logs_days: 2555 # 7 years
```
## Enterprise Management
### Multi-Environment Deployment
Deploy marketplace servers across environments:
```yaml
# environments-config.yaml
environments:
development:
marketplace_servers:
- github-enterprise:
version: "2.1.0-beta"
config_override:
github:
base_url: "https://github-dev.company.com/api/v3"
organization: "company-dev"
staging:
marketplace_servers:
- github-enterprise:
version: "2.1.0-rc1"
config_override:
github:
base_url: "https://github-staging.company.com/api/v3"
organization: "company-staging"
production:
marketplace_servers:
- github-enterprise:
version: "2.1.0"
config_override:
github:
base_url: "https://github.company.com/api/v3"
organization: "company"
```
### Version Management
Control marketplace server versions:
```bash
# List available versions
cline-enterprise mcp versions github-enterprise
# Upgrade to latest version
cline-enterprise mcp upgrade github-enterprise --version 2.2.0 --environment staging
# Rollback to previous version
cline-enterprise mcp rollback github-enterprise --version 2.1.0 --environment staging
# Pin to specific version (disable auto-updates)
cline-enterprise mcp pin github-enterprise --version 2.1.0
```
### Health Monitoring
Monitor marketplace server health:
```yaml
# monitoring-config.yaml
monitoring:
marketplace_servers:
health_checks:
interval_seconds: 30
timeout_seconds: 10
metrics:
- server_status
- request_latency
- error_rate
- resource_usage
alerts:
- name: "marketplace-server-down"
condition: "server_status != 1"
severity: "critical"
- name: "high-error-rate"
condition: "error_rate > 0.05"
severity: "warning"
- name: "performance-degradation"
condition: "request_latency > 5s"
severity: "warning"
```
## Security & Compliance
### Enterprise Security Features
All marketplace servers include:
- **Authentication Integration**: SSO, SAML, OAuth2 support
- **Authorization Controls**: RBAC and fine-grained permissions
- **Audit Logging**: Comprehensive activity tracking
- **Data Encryption**: At-rest and in-transit encryption
- **Network Security**: VPN, IP whitelisting, private endpoints
- **Compliance**: SOC2, GDPR, HIPAA compliance frameworks
### Data Governance
Configure data handling policies:
```yaml
# data-governance-config.yaml
data_governance:
classification:
public:
retention_days: 90
backup_required: false
internal:
retention_days: 365
backup_required: true
encryption_required: false
confidential:
retention_days: 2555 # 7 years
backup_required: true
encryption_required: true
audit_access: true
restricted:
retention_days: 2555
backup_required: true
encryption_required: true
audit_access: true
approval_required: true
privacy:
pii_detection: true
pii_masking: true
gdpr_compliance: true
data_subject_requests: true
compliance:
frameworks: ["SOC2", "GDPR", "CCPA", "HIPAA"]
audit_frequency: "quarterly"
certification_renewal: "annual"
```
## Best Practices
### Installation
1. **Review Permissions**: Always review required permissions before installation
2. **Test in Staging**: Deploy to staging environment first
3. **Configuration Validation**: Validate configuration files before deployment
4. **Backup Current State**: Create configuration backups before changes
5. **Monitor Deployment**: Watch health metrics during rollout
### Configuration
1. **Environment Separation**: Use different configurations per environment
2. **Secret Management**: Store sensitive data in secure secret stores
3. **Version Pinning**: Pin versions for production deployments
4. **Access Controls**: Implement least-privilege access policies
5. **Regular Updates**: Schedule regular security and feature updates
### Monitoring
1. **Health Checks**: Monitor server health continuously
2. **Performance Metrics**: Track latency and throughput
3. **Error Tracking**: Alert on error rates and failure patterns
4. **Resource Usage**: Monitor CPU, memory, and network usage
5. **Audit Reviews**: Regular review of audit logs and access patterns
## Troubleshooting
### Common Issues
**Installation Failures**:
```bash
# Check marketplace connectivity
cline-enterprise mcp marketplace-status
# Verify authentication
cline-enterprise auth verify --service marketplace
# Check installation logs
cline-enterprise logs mcp-installer --lines 100
```
**Configuration Errors**:
```bash
# Validate configuration
cline-enterprise mcp validate-config --file config.yaml
# Test connectivity
cline-enterprise mcp test-connection github-enterprise --environment staging
# Check server status
cline-enterprise mcp status --all
```
**Performance Issues**:
```bash
# Check server metrics
cline-enterprise mcp metrics github-enterprise --duration 1h
# View recent error logs
cline-enterprise logs github-enterprise --level error --lines 50
```
## Support
For marketplace server issues:
- **Documentation**: Check server-specific documentation in the dashboard
- **Community**: Join the Cline Enterprise community forum
- **Support Tickets**: Create support tickets for critical issues
- **Professional Services**: Engage professional services for custom configurations
Enterprise customers have access to dedicated support channels with SLA guarantees.
@@ -1,571 +0,0 @@
---
title: "MCP Integration"
sidebarTitle: "Overview"
description: "Configure Model Context Protocol (MCP) servers and marketplace integrations for enterprise Cline deployments"
---
Model Context Protocol (MCP) provides standardized communication between AI models and external data sources, tools, and services. Enterprise MCP integration allows you to securely connect Cline to your organization's systems while maintaining governance and compliance.
## Enterprise MCP Benefits
<CardGroup cols={2}>
<Card title="Extensible Architecture" icon="puzzle-piece">
Connect to unlimited external tools, databases, APIs, and services through standardized MCP servers.
</Card>
<Card title="Enterprise Security" icon="shield-alt">
Secure authentication, authorization, and audit trails for all MCP server communications.
</Card>
<Card title="Centralized Management" icon="network-wired">
Manage and deploy MCP servers enterprise-wide with version control and configuration management.
</Card>
<Card title="Compliance Ready" icon="clipboard-check">
Built-in logging, monitoring, and data governance for regulatory compliance requirements.
</Card>
</CardGroup>
## MCP Architecture Overview
```mermaid
graph TB
A[Cline Enterprise] --> B[MCP Hub]
B --> C[MCP Marketplace]
B --> D[Remote MCP Servers]
B --> E[Internal MCP Servers]
C --> F[GitHub Integration]
C --> G[Slack Integration]
C --> H[Jira Integration]
D --> I[Custom APIs]
D --> J[Databases]
D --> K[Cloud Services]
E --> L[Internal Tools]
E --> M[Legacy Systems]
E --> N[Security Systems]
O[Enterprise Admin] --> B
P[Audit Logging] --> B
Q[Authentication] --> B
```
## Core Components
<CardGroup cols={2}>
<Card title="MCP Marketplace" icon="store" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace">
Pre-built, enterprise-ready MCP servers for popular tools and services with one-click deployment.
</Card>
<Card title="Remote MCP Servers" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers">
Deploy and manage custom MCP servers across your infrastructure with centralized configuration.
</Card>
</CardGroup>
## Enterprise Configuration
### Basic MCP Hub Setup
Configure the central MCP hub for your enterprise deployment:
```yaml
# mcp-hub-config.yaml
mcp:
hub:
enabled: true
port: 8080
authentication:
method: "enterprise-sso"
jwt_secret: "${MCP_JWT_SECRET}"
# Server discovery
discovery:
methods: ["marketplace", "remote", "local"]
marketplace_url: "https://mcp.cline.bot/marketplace"
# Security settings
security:
enforce_tls: true
allowed_origins: ["https://*.company.com"]
rate_limiting:
requests_per_minute: 1000
burst_size: 100
# Audit and compliance
audit:
enabled: true
log_level: "INFO"
destinations: ["file", "syslog", "datadog"]
retention_days: 90
```
### Multi-Environment Configuration
Deploy MCP configurations across environments:
<Tabs>
<Tab title="Development">
```yaml
# mcp-dev-config.yaml
mcp:
environment: "development"
servers:
- name: "github-dev"
type: "marketplace"
package: "@cline/mcp-github"
version: "latest"
config:
github_token: "${GITHUB_DEV_TOKEN}"
org: "company-dev"
- name: "local-db"
type: "remote"
url: "http://localhost:3001"
auth:
type: "api-key"
key: "${DEV_DB_API_KEY}"
policies:
allow_experimental: true
auto_update: true
rate_limits:
relaxed: true
```
</Tab>
<Tab title="Production">
```yaml
# mcp-prod-config.yaml
mcp:
environment: "production"
servers:
- name: "github-prod"
type: "marketplace"
package: "@cline/mcp-github"
version: "1.2.3" # Pinned version
config:
github_token: "${GITHUB_PROD_TOKEN}"
org: "company"
- name: "crm-integration"
type: "remote"
url: "https://mcp-crm.internal.company.com"
auth:
type: "mtls"
cert_path: "/certs/mcp-client.pem"
key_path: "/certs/mcp-client-key.pem"
- name: "security-scanner"
type: "remote"
url: "https://security-mcp.company.com"
auth:
type: "oauth2"
client_id: "${SECURITY_CLIENT_ID}"
client_secret: "${SECURITY_CLIENT_SECRET}"
policies:
allow_experimental: false
auto_update: false
strict_versioning: true
monitoring:
metrics: true
health_checks: true
alert_on_failure: true
```
</Tab>
</Tabs>
## Server Management
### Lifecycle Management
Manage MCP server deployments with GitOps:
```yaml
# mcp-server-manifest.yaml
apiVersion: mcp.cline.bot/v1
kind: MCPServer
metadata:
name: custom-api-server
namespace: cline-enterprise
spec:
image: company/custom-mcp-server:v1.0.0
replicas: 3
config:
api_endpoint: "https://api.internal.company.com"
timeout: 30s
retry_attempts: 3
auth:
type: service-account
service_account: mcp-custom-api
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
monitoring:
enabled: true
metrics_port: 9090
health_endpoint: "/health"
security:
network_policy: strict
pod_security_standard: restricted
```
### Configuration Management
Use Helm charts for enterprise MCP deployments:
```yaml
# values-prod.yaml
mcp:
hub:
replicaCount: 3
image:
repository: cline/mcp-hub-enterprise
tag: "1.5.2"
servers:
marketplace:
enabled: true
catalog_url: "https://enterprise-catalog.company.com"
custom:
- name: "salesforce"
enabled: true
image: "company/mcp-salesforce:1.0.0"
config:
instance_url: "https://company.my.salesforce.com"
- name: "jira"
enabled: true
image: "company/mcp-jira:2.1.0"
config:
base_url: "https://company.atlassian.net"
ingress:
enabled: true
className: nginx
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
hosts:
- host: mcp.company.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: mcp-tls
hosts:
- mcp.company.com
```
## Security & Governance
### Authentication & Authorization
Configure enterprise authentication for MCP servers:
```yaml
# mcp-auth-config.yaml
authentication:
providers:
- name: "enterprise-sso"
type: "oidc"
issuer: "https://sso.company.com"
client_id: "${SSO_CLIENT_ID}"
client_secret: "${SSO_CLIENT_SECRET}"
- name: "service-accounts"
type: "jwt"
signing_key: "${SERVICE_ACCOUNT_KEY}"
authorization:
policies:
- name: "developers"
subjects: ["group:developers"]
resources: ["mcp:servers:read", "mcp:servers:execute"]
- name: "admins"
subjects: ["group:mcp-admins"]
resources: ["mcp:*"]
- name: "security-team"
subjects: ["group:security"]
resources: ["mcp:audit:*", "mcp:servers:security-*"]
rbac:
enabled: true
default_role: "viewer"
```
### Network Security
Implement network policies for MCP communications:
```yaml
# mcp-network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: mcp-server-policy
namespace: cline-enterprise
spec:
podSelector:
matchLabels:
app: mcp-server
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: cline-enterprise
- podSelector:
matchLabels:
app: cline-core
ports:
- protocol: TCP
port: 8080
egress:
# Allow DNS
- to: []
ports:
- protocol: UDP
port: 53
# Allow HTTPS to external APIs
- to: []
ports:
- protocol: TCP
port: 443
```
## Monitoring & Observability
### Metrics Collection
Configure comprehensive MCP monitoring:
```yaml
# mcp-monitoring.yaml
monitoring:
metrics:
enabled: true
interval: 30s
collectors:
- name: "server-health"
metrics:
- mcp_server_status
- mcp_server_response_time
- mcp_server_error_rate
- name: "hub-performance"
metrics:
- mcp_hub_requests_total
- mcp_hub_request_duration
- mcp_hub_active_connections
- name: "resource-usage"
metrics:
- mcp_memory_usage
- mcp_cpu_usage
- mcp_network_io
alerts:
- name: "server-down"
condition: "mcp_server_status == 0"
severity: "critical"
notification_channels: ["pagerduty", "slack"]
- name: "high-error-rate"
condition: "mcp_server_error_rate > 0.05"
severity: "warning"
notification_channels: ["slack"]
- name: "performance-degradation"
condition: "mcp_server_response_time > 5s"
severity: "warning"
notification_channels: ["email"]
```
### Audit Logging
Implement comprehensive audit trails:
```json
{
"timestamp": "2024-01-15T10:30:00Z",
"event_type": "mcp_server_call",
"user_id": "john.doe@company.com",
"session_id": "sess_abc123",
"server_name": "github-prod",
"method": "github.create_issue",
"request": {
"repository": "company/project",
"title": "Bug fix required",
"sensitive_data_detected": false
},
"response": {
"status": "success",
"issue_id": "12345",
"duration_ms": 234
},
"compliance": {
"data_classification": "internal",
"retention_required": true,
"pii_detected": false
}
}
```
## Custom MCP Server Development
### Development Framework
Create custom MCP servers using the enterprise SDK:
```typescript
// custom-mcp-server.ts
import { MCPServer, Tool, Resource } from '@cline/mcp-enterprise-sdk';
class CustomAPIServer extends MCPServer {
constructor() {
super({
name: 'custom-api-server',
version: '1.0.0',
description: 'Custom API integration server'
});
this.addTool(new DatabaseQueryTool());
this.addResource(new UserDataResource());
}
}
class DatabaseQueryTool implements Tool {
name = 'query_database';
description = 'Query the company database';
async execute(params: any) {
// Implement database query logic
const result = await this.database.query(params.sql);
// Audit log the query
await this.auditLog({
action: 'database_query',
query: params.sql,
user: params.user_id,
results_count: result.length
});
return result;
}
async validate(params: any): Promise<boolean> {
// Implement query validation
return params.sql && !this.containsMaliciousSQL(params.sql);
}
}
```
### Deployment Pipeline
Automate MCP server deployments:
```yaml
# .github/workflows/deploy-mcp-server.yml
name: Deploy MCP Server
on:
push:
branches: [main]
paths: ['mcp-servers/**']
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Build MCP Server
run: |
docker build -t company/mcp-server:${{ github.sha }} .
docker push company/mcp-server:${{ github.sha }}
- name: Deploy to Staging
run: |
helm upgrade mcp-server-staging ./helm-chart \
--set image.tag=${{ github.sha }} \
--namespace mcp-staging
- name: Run Integration Tests
run: |
kubectl wait --for=condition=ready pod -l app=mcp-server -n mcp-staging
npm run test:integration
- name: Deploy to Production
if: success()
run: |
helm upgrade mcp-server-prod ./helm-chart \
--set image.tag=${{ github.sha }} \
--namespace mcp-prod
```
## Best Practices
### Security
1. **Authentication**: Always require authentication for MCP servers
2. **Encryption**: Use TLS for all MCP communications
3. **Validation**: Validate all inputs and sanitize outputs
4. **Least Privilege**: Grant minimal required permissions
5. **Audit**: Log all MCP server interactions
### Performance
1. **Caching**: Implement response caching where appropriate
2. **Connection Pooling**: Reuse connections to external services
3. **Async Operations**: Use non-blocking operations for I/O
4. **Resource Limits**: Set appropriate CPU and memory limits
5. **Load Balancing**: Scale MCP servers based on demand
### Reliability
1. **Health Checks**: Implement comprehensive health endpoints
2. **Circuit Breakers**: Fail fast when external services are down
3. **Retry Logic**: Implement exponential backoff for failures
4. **Graceful Degradation**: Provide fallback behavior
5. **Monitoring**: Set up proactive alerting and monitoring
## Production Checklist
Before deploying MCP servers to production:
- [ ] Security review completed
- [ ] Authentication and authorization configured
- [ ] Network policies implemented
- [ ] Monitoring and alerting set up
- [ ] Audit logging enabled
- [ ] Resource limits configured
- [ ] Health checks implemented
- [ ] Integration tests passing
- [ ] Disaster recovery plan documented
- [ ] Compliance requirements validated
## Getting Started
Ready to implement enterprise MCP integration? Start with:
1. [MCP Marketplace](/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace) - Deploy pre-built integrations
2. [Remote MCP Servers](/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers) - Configure custom servers
3. Review our [MCP Development Guide](/mcp/mcp-overview) for building custom integrations
@@ -1,95 +0,0 @@
---
title: "Self-Hosted Configuration"
sidebarTitle: "Overview"
description: "Deploy and configure Cline on your own infrastructure with enterprise-grade security and compliance"
---
<Warning>
**Self-Hosted Configuration Path**
This section is for enterprises deploying **self-hosted Cline infrastructure** with complex security, compliance, and multi-environment requirements. Configuration is done through YAML files, Kubernetes/Helm deployments, and infrastructure-as-code.
**Looking for simple setup?** See [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview) for quick configuration through the app.cline.bot admin console - no infrastructure deployment required, just web-based settings.
</Warning>
Self-Hosted Configuration provides centralized control over all aspects of your Cline deployment on your own infrastructure, from AI providers to custom workflows. This section covers how to configure, manage, and optimize your enterprise Cline installation with advanced security, compliance, and operational features.
## Configuration Categories
<CardGroup cols={2}>
<Card title="Providers" icon="cloud" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/overview">
Configure AI providers including AWS Bedrock, LiteLLM, and Google Vertex AI with enterprise-grade security and governance.
</Card>
<Card title="MCP Integration" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/overview">
Manage Model Context Protocol servers, marketplace integrations, and remote MCP server configurations.
</Card>
<Card title="Rules Engine" icon="shield-check" href="/enterprise-solutions/configuration/infrastructure-configuration/rules">
Define and enforce enterprise governance rules, security policies, and compliance requirements.
</Card>
<Card title="Workflows" icon="workflow" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
Create automated workflows for development processes, approval chains, and integration pipelines.
</Card>
</CardGroup>
## Advanced Controls
<CardGroup cols={2}>
<Card title="Control Other Cline Features" icon="toggles" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/overview">
Enable or disable specific Cline features across your organization with granular permission controls.
</Card>
<Card title="Monitoring" icon="chart-line" href="/enterprise-solutions/monitoring/overview">
Configure OpenTelemetry integration for comprehensive monitoring, logging, and analytics.
</Card>
</CardGroup>
## Getting Started
1. **Assessment**: Review your current infrastructure and integration requirements
2. **Provider Setup**: Configure your preferred AI providers with enterprise credentials
3. **Security Configuration**: Implement rules and access controls
4. **Monitoring Setup**: Enable telemetry and monitoring for operational visibility
5. **User Onboarding**: Deploy configurations to your development teams
## Enterprise Architecture Considerations
### Security & Compliance
- **Zero Trust Architecture**: All configurations support zero-trust security models
- **Audit Logging**: Complete audit trails for all configuration changes
- **Role-Based Access**: Granular permissions for different administrative roles
- **Data Sovereignty**: Keep sensitive data within your infrastructure boundaries
### Scalability & Performance
- **Multi-Region Support**: Deploy configurations across multiple geographic regions
- **Load Balancing**: Distribute AI provider requests across multiple endpoints
- **Caching Strategies**: Optimize performance with intelligent caching
- **Rate Limiting**: Prevent abuse with configurable rate limits
### Integration & Automation
- **GitOps Integration**: Version control your configurations alongside code
- **CI/CD Pipeline Integration**: Automate configuration deployment
- **Webhook Support**: React to configuration changes with custom automation
- **API-First Design**: Programmatically manage all configurations
## Configuration Management
All enterprise configurations support:
- **Version Control**: Track changes with full revision history
- **Environment Promotion**: Deploy configurations from dev → staging → production
- **Rollback Capabilities**: Quickly revert problematic configurations
- **Configuration Validation**: Automated testing of configuration changes
- **Drift Detection**: Monitor and alert on configuration drift
## Next Steps
Ready to configure your enterprise deployment? Start with:
1. [Provider Configuration](/enterprise-solutions/configuration/infrastructure-configuration/providers/overview) - Set up your AI providers
2. [Security Rules](/enterprise-solutions/configuration/infrastructure-configuration/rules) - Implement governance policies
3. [Monitoring Setup](/enterprise-solutions/monitoring/overview) - Enable operational visibility
For hands-on configuration assistance, contact your Cline Enterprise support team or refer to our implementation guides.
@@ -1,182 +0,0 @@
---
title: "AWS Bedrock Configuration"
sidebarTitle: "AWS Bedrock"
description: "Configure AWS Bedrock for your Cline deployment"
---
<Info>
**Configuration Path: Self-Hosted**
This guide covers Bedrock configuration for self-hosted deployments. For simple web-based setup, see [AWS Bedrock SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration).
</Info>
Configure Cline to use AWS Bedrock for enterprise access to Claude and other foundation models through Amazon's managed service.
## Configuration Format
Configure Bedrock through your remote configuration JSON using the `providerSettings.AwsBedrock` section:
```json
{
"providerSettings": {
"AwsBedrock": {
"models": [
{
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"name": "Claude 3.5 Sonnet"
}
],
"awsRegion": "us-east-1"
}
}
}
```
## Configuration Fields
| Field | Type | Description | Required |
|-------|------|-------------|----------|
| `models` | Array | List of model configurations | Yes |
| `awsRegion` | String | AWS region (e.g., `us-east-1`) | Yes |
| `awsUseCrossRegionInference` | Boolean | Enable cross-region inference | No |
| `awsUseGlobalInference` | Boolean | Enable global inference routing | No |
| `awsBedrockUsePromptCache` | Boolean | Enable prompt caching | No |
| `awsBedrockEndpoint` | String | Custom Bedrock endpoint URL | No |
| `customModels` | Array | Custom model configurations | No |
### Model Configuration
Each model in the `models` array requires:
```json
{
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"name": "Claude 3.5 Sonnet",
"info": {
"maxTokens": 8192,
"contextWindow": 200000,
"supportsImages": true,
"supportsPromptCache": true
}
}
```
## Common Model IDs
| Model ID | Description | Context Window |
|----------|-------------|----------------|
| `anthropic.claude-3-5-sonnet-20241022-v2:0` | Latest Claude Sonnet | 200K tokens |
| `anthropic.claude-3-5-haiku-20241022-v1:0` | Latest Claude Haiku | 200K tokens |
| `anthropic.claude-3-opus-20240229-v1:0` | Claude Opus | 200K tokens |
<Note>
Model availability varies by region. See [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) for region-specific model availability.
</Note>
## Example Configurations
### Basic Configuration
```json
{
"providerSettings": {
"AwsBedrock": {
"models": [
{
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"name": "Claude 3.5 Sonnet"
}
],
"awsRegion": "us-east-1"
}
}
}
```
### With Prompt Caching
```json
{
"providerSettings": {
"AwsBedrock": {
"models": [
{
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"name": "Claude 3.5 Sonnet"
}
],
"awsRegion": "us-east-1",
"awsBedrockUsePromptCache": true
}
}
}
```
### Multiple Models
```json
{
"providerSettings": {
"AwsBedrock": {
"models": [
{
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
"name": "Claude 3.5 Sonnet"
},
{
"id": "anthropic.claude-3-5-haiku-20241022-v1:0",
"name": "Claude 3.5 Haiku"
}
],
"awsRegion": "us-east-1"
}
}
}
```
## Prerequisites
Before configuring Cline to use Bedrock, you need:
1. **AWS Account** with Bedrock access enabled
2. **IAM Permissions** for Bedrock API calls (`bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream`)
3. **Model Access** enabled for desired models in the Bedrock console
4. **AWS Credentials** configured (IAM role, access keys, or AWS profile)
<Tip>
For AWS account setup and IAM configuration, see the [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).
</Tip>
## Troubleshooting
**"Access Denied" Errors**
Ensure your AWS credentials have the required Bedrock permissions. See [AWS IAM documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html) for permission requirements.
**"Model Not Found" Errors**
Verify model access is enabled in the AWS Bedrock console and the model is available in your configured region.
**High Latency**
Consider using a region closer to your users or enabling cross-region inference for better performance.
## Related Resources
<CardGroup cols={2}>
<Card title="AWS Bedrock Docs" icon="book" href="https://docs.aws.amazon.com/bedrock/">
Complete AWS Bedrock documentation
</Card>
<Card title="Model Access" icon="key" href="https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html">
How to enable model access
</Card>
<Card title="IAM Permissions" icon="shield" href="https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html">
Required IAM permissions
</Card>
<Card title="Pricing" icon="dollar-sign" href="https://aws.amazon.com/bedrock/pricing/">
AWS Bedrock pricing details
</Card>
</CardGroup>
@@ -1,254 +0,0 @@
---
title: "Custom Provider Configuration"
sidebarTitle: "Custom Providers"
description: "Configure custom OpenAI-compatible providers for your Cline deployment"
---
<Info>
**Configuration Path: Self-Hosted**
This guide covers custom provider configuration for self-hosted deployments.
</Info>
Configure Cline to use any OpenAI-compatible API provider, including Azure OpenAI, self-hosted inference servers, and other third-party services.
## What are Custom Providers?
Custom providers include any API that implements the OpenAI API format:
- **Azure OpenAI Service**: Microsoft's managed OpenAI models
- **vLLM**: Self-hosted inference server
- **Ollama**: Local model runner
- **Text Generation Inference (TGI)**: Hugging Face's inference server
- **LocalAI**: Local OpenAI API replacement
- **Other OpenAI-compatible APIs**: Any custom implementation
## Configuration Format
Configure custom providers through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "https://your-api.company.com/v1"
}
}
}
```
## Configuration Fields
| Field | Type | Description | Required |
|-------|------|-------------|----------|
| `models` | Array | List of model configurations | Yes |
| `openAiBaseUrl` | String | API endpoint base URL | Yes |
| `openAiApiKey` | String | API key for authentication | No |
| `openAiModelId` | String | Default model identifier | No |
### Azure OpenAI Specific Fields
For Azure OpenAI, additional fields are available:
| Field | Type | Description |
|-------|------|-------------|
| `azureApiVersion` | String | Azure API version (e.g., `2024-02-15-preview`) |
## Example Configurations
### Azure OpenAI
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "https://your-resource.openai.azure.com/openai/deployments/gpt-4-turbo",
"openAiApiKey": "your-azure-api-key",
"azureApiVersion": "2024-02-15-preview"
}
}
}
```
### Self-Hosted vLLM
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "meta-llama/Llama-2-70b-chat-hf",
"name": "Llama 2 70B"
}
],
"openAiBaseUrl": "http://vllm.company.com:8000/v1"
}
}
}
```
### Local Ollama
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "codellama",
"name": "Code Llama"
}
],
"openAiBaseUrl": "http://localhost:11434/v1"
}
}
}
```
### Text Generation Inference (TGI)
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "mistralai/Mistral-7B-Instruct-v0.2",
"name": "Mistral 7B Instruct"
}
],
"openAiBaseUrl": "http://tgi.company.com:8080/v1",
"openAiApiKey": "your-tgi-api-key"
}
}
}
```
### LocalAI
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-3.5-turbo",
"name": "Local GPT-3.5"
}
],
"openAiBaseUrl": "http://localhost:8080/v1"
}
}
}
```
### Internal Network (No Auth)
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "custom-model",
"name": "Custom Model"
}
],
"openAiBaseUrl": "http://internal.api:8000/v1"
}
}
}
```
## Model Configuration
Each model requires basic information:
```json
{
"id": "model-identifier",
"name": "Display Name",
"info": {
"maxTokens": 4096,
"contextWindow": 128000,
"supportsImages": true,
"supportsPromptCache": false
}
}
```
## Prerequisites
Before configuring a custom provider, you need:
1. **API Endpoint**: URL of your OpenAI-compatible API
2. **API Key** (if required): Authentication credentials
3. **Model IDs**: Names of available models
4. **Network Access**: Connectivity from where Cline is being used
## Troubleshooting
**Connection Errors**
Verify the endpoint is accessible:
```bash
curl https://your-api.company.com/v1/models
```
**Authentication Errors**
Test authentication with your API key:
```bash
curl -H "Authorization: Bearer your-api-key" \
https://your-api.company.com/v1/models
```
**Model Not Found**
Ensure the model ID in your configuration matches what the API expects. Check available models:
```bash
curl -H "Authorization: Bearer your-api-key" \
https://your-api.company.com/v1/models
```
**Timeout Issues**
If responses are slow:
- Check network latency
- Verify server has adequate resources
- Consider using faster models
## Provider Documentation
For setup and deployment of these services, see their official documentation:
<CardGroup cols={2}>
<Card title="Azure OpenAI" icon="microsoft" href="https://learn.microsoft.com/en-us/azure/ai-services/openai/">
Microsoft's managed OpenAI service
</Card>
<Card title="vLLM" icon="server" href="https://docs.vllm.ai/">
High-performance inference engine
</Card>
<Card title="Ollama" icon="download" href="https://ollama.ai/">
Run models locally
</Card>
<Card title="Text Generation Inference" icon="code" href="https://huggingface.co/docs/text-generation-inference/">
Hugging Face inference server
</Card>
</CardGroup>
@@ -1,185 +0,0 @@
---
title: "Google Vertex AI Configuration"
sidebarTitle: "Google Vertex"
description: "Configure Google Vertex AI for your Cline deployment"
---
<Info>
**Configuration Path: Self-Hosted**
This guide covers Vertex AI configuration for self-hosted deployments. For simple web-based setup, see [Google Vertex SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration).
</Info>
Configure Cline to use Google Vertex AI for enterprise access to Gemini and other Google AI models through Google Cloud Platform.
## Configuration Format
Configure Vertex AI through your remote configuration JSON using the `providerSettings.Vertex` section:
```json
{
"providerSettings": {
"Vertex": {
"models": [
{
"id": "claude-3-5-sonnet-v2@20241022",
"name": "Claude 3.5 Sonnet"
}
],
"vertexProjectId": "my-project-id",
"vertexRegion": "us-central1"
}
}
}
```
## Configuration Fields
| Field | Type | Description | Required |
|-------|------|-------------|----------|
| `models` | Array | List of model configurations | Yes |
| `vertexProjectId` | String | Google Cloud project ID | Yes |
| `vertexRegion` | String | GCP region (e.g., `us-central1`) | Yes |
### Model Configuration
Each model in the `models` array requires:
```json
{
"id": "claude-3-5-sonnet-v2@20241022",
"name": "Claude 3.5 Sonnet",
"info": {
"maxTokens": 8192,
"contextWindow": 200000,
"supportsImages": true,
"supportsPromptCache": true
}
}
```
## Common Model IDs
| Model ID | Description | Context Window |
|----------|-------------|----------------|
| `claude-3-5-sonnet-v2@20241022` | Claude 3.5 Sonnet | 200K tokens |
| `claude-3-5-haiku@20241022` | Claude 3.5 Haiku | 200K tokens |
| `claude-3-opus@20240229` | Claude 3 Opus | 200K tokens |
| `gemini-2.0-flash-exp` | Gemini Flash (experimental) | 1M tokens |
| `gemini-1.5-pro-002` | Gemini Pro | 2M tokens |
| `gemini-1.5-flash-002` | Gemini Flash | 1M tokens |
<Note>
Model availability varies by region. See [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models) for region-specific model availability.
</Note>
## Example Configurations
### Basic Configuration
```json
{
"providerSettings": {
"Vertex": {
"models": [
{
"id": "claude-3-5-sonnet-v2@20241022",
"name": "Claude 3.5 Sonnet"
}
],
"vertexProjectId": "my-company-prod",
"vertexRegion": "us-central1"
}
}
}
```
### Multiple Models
```json
{
"providerSettings": {
"Vertex": {
"models": [
{
"id": "claude-3-5-sonnet-v2@20241022",
"name": "Claude 3.5 Sonnet"
},
{
"id": "gemini-1.5-pro-002",
"name": "Gemini Pro"
}
],
"vertexProjectId": "my-company-prod",
"vertexRegion": "us-central1"
}
}
}
```
### With Extended Thinking
```json
{
"providerSettings": {
"Vertex": {
"models": [
{
"id": "claude-3-5-sonnet-v2@20241022",
"name": "Claude 3.5 Sonnet",
"thinkingBudgetTokens": 1600
}
],
"vertexProjectId": "my-company-prod",
"vertexRegion": "us-central1"
}
}
}
```
## Prerequisites
Before configuring Cline to use Vertex AI, you need:
1. **Google Cloud Project** with Vertex AI API enabled
2. **Service Account** with Vertex AI User role (`roles/aiplatform.user`)
3. **Service Account Credentials** configured for authentication
4. **Model Access** verified in your project and region
<Tip>
For Google Cloud setup and authentication configuration, see the [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/start/quickstarts/quickstart-multimodal).
</Tip>
## Troubleshooting
**"Permission Denied" Errors**
Ensure your service account has the required Vertex AI permissions. See [Google Cloud IAM documentation](https://cloud.google.com/vertex-ai/docs/general/access-control) for permission requirements.
**"API Not Enabled" Errors**
Verify the Vertex AI API is enabled in your Google Cloud project.
**"Model Not Found" Errors**
Check that the model is available in your configured region and that your project has access to it.
## Related Resources
<CardGroup cols={2}>
<Card title="Vertex AI Docs" icon="book" href="https://cloud.google.com/vertex-ai/docs">
Complete Vertex AI documentation
</Card>
<Card title="Service Accounts" icon="key" href="https://cloud.google.com/iam/docs/service-accounts">
Service account best practices
</Card>
<Card title="Model Guide" icon="brain" href="https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models">
Available models and features
</Card>
<Card title="Pricing" icon="dollar-sign" href="https://cloud.google.com/vertex-ai/pricing">
Vertex AI pricing details
</Card>
</CardGroup>
@@ -1,215 +0,0 @@
---
title: "LiteLLM Configuration"
sidebarTitle: "LiteLLM"
description: "Configure LiteLLM proxy for your Cline deployment"
---
<Info>
**Configuration Path: Self-Hosted**
This guide covers LiteLLM configuration for self-hosted deployments. For web-based setup, see [LiteLLM SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration).
</Info>
Configure Cline to use an existing LiteLLM proxy for unified access to multiple AI models through a single API endpoint.
## What is LiteLLM?
[LiteLLM](https://github.com/BerriAI/litellm) is an open-source proxy that provides a unified OpenAI-compatible API for accessing 100+ AI models from different providers. Cline connects to your deployed LiteLLM instance.
<Note>
LiteLLM is a separate service you deploy and manage. This guide covers how to configure Cline to connect to an existing LiteLLM deployment.
</Note>
## Configuration Format
Configure LiteLLM through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "https://litellm.yourcompany.com/v1"
}
}
}
```
## Configuration Fields
| Field | Type | Description | Required |
|-------|------|-------------|----------|
| `models` | Array | List of model configurations | Yes |
| `openAiBaseUrl` | String | LiteLLM proxy endpoint URL | Yes |
| `openAiApiKey` | String | API key for authentication | No |
### Model Configuration
Each model in the `models` array requires:
```json
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo",
"info": {
"maxTokens": 4096,
"contextWindow": 128000,
"supportsImages": true
}
}
```
<Note>
Model IDs must match the model names configured in your LiteLLM proxy deployment.
</Note>
## Example Configurations
### Basic Configuration
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "https://litellm.company.com/v1"
}
}
}
```
### With Authentication
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "https://litellm.company.com/v1",
"openAiApiKey": "sk-your-litellm-key"
}
}
}
```
### Multiple Models
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
},
{
"id": "claude-3-5-sonnet",
"name": "Claude 3.5 Sonnet"
},
{
"id": "gemini-pro",
"name": "Gemini Pro"
}
],
"openAiBaseUrl": "https://litellm.company.com/v1",
"openAiApiKey": "sk-your-litellm-key"
}
}
}
```
### Internal Network (No Auth)
```json
{
"providerSettings": {
"OpenAiCompatible": {
"models": [
{
"id": "gpt-4-turbo",
"name": "GPT-4 Turbo"
}
],
"openAiBaseUrl": "http://litellm.internal:4000/v1"
}
}
}
```
## Prerequisites
Before configuring Cline to use LiteLLM, you need:
1. **LiteLLM Proxy** deployed and accessible
2. **LiteLLM Configuration** with desired models enabled
3. **API Key** (if authentication is enabled)
4. **Network Access** from where Cline is being used
<Tip>
For LiteLLM deployment and configuration, see the [LiteLLM documentation](https://docs.litellm.ai/docs/proxy/quick_start).
</Tip>
## Troubleshooting
**Connection Errors**
Verify the LiteLLM proxy is running and accessible:
```bash
curl https://litellm.yourcompany.com/health
```
**Authentication Errors**
Check your API key is valid:
```bash
curl -H "Authorization: Bearer sk-your-key" \
https://litellm.yourcompany.com/v1/models
```
**Model Not Found**
Verify the model is configured in your LiteLLM deployment. Model IDs in Cline's config must match the model names in LiteLLM's configuration.
## Benefits of Using LiteLLM
- **Multi-Provider Access**: Connect to multiple AI providers through one endpoint
- **Load Balancing**: Distribute requests across providers automatically
- **Fallback Support**: Automatic retry with different models on failure
- **Cost Tracking**: Monitor usage and costs across all models
- **Rate Limiting**: Control usage at the proxy level
## Related Resources
<CardGroup cols={2}>
<Card title="LiteLLM Docs" icon="book" href="https://docs.litellm.ai/">
Complete LiteLLM documentation
</Card>
<Card title="LiteLLM GitHub" icon="github" href="https://github.com/BerriAI/litellm">
Source code and deployment examples
</Card>
<Card title="Proxy Setup" icon="server" href="https://docs.litellm.ai/docs/proxy/quick_start">
LiteLLM proxy deployment guide
</Card>
<Card title="Supported Providers" icon="list" href="https://docs.litellm.ai/docs/providers">
List of supported AI providers
</Card>
</CardGroup>
@@ -1,144 +0,0 @@
---
title: "AI Provider Configuration"
sidebarTitle: "Overview"
description: "Configure AI provider settings for your Cline deployment"
---
<Info>
**Configuration Path: Self-Hosted**
This section covers provider configuration for self-hosted deployments. For web-based configuration through app.cline.bot, see [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview).
</Info>
Configure which AI providers your team can use and manage provider credentials centrally. Cline supports major AI providers with enterprise-grade authentication options.
## Supported Providers
<CardGroup cols={2}>
<Card title="AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
Amazon's managed service for Claude and other foundation models
</Card>
<Card title="Google Vertex AI" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
Google Cloud's AI platform with Gemini and PaLM models
</Card>
<Card title="LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
Universal proxy for accessing 100+ AI models through a unified API
</Card>
<Card title="Custom Providers" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
OpenAI-compatible APIs and self-hosted models
</Card>
</CardGroup>
## What is Provider Configuration?
Provider configuration in Cline allows administrators to:
1. **Manage Credentials Centrally**: Store API keys and authentication details in one place
2. **Control Model Access**: Specify which models teams can use
3. **Enforce Provider Usage**: Direct all team members to approved providers
## How It Works
Provider settings are configured through your remote configuration JSON file:
```json
{
"providerSettings": {
"provider": "bedrock",
"bedrockRegion": "us-east-1",
"bedrockServiceRole": "arn:aws:iam::..."
}
}
```
When configured, these settings:
- Apply to all team members automatically
- Override individual user settings
- Ensure consistent provider usage across the team
## Configuration Options
### Provider Selection
Choose from supported providers:
- **bedrock**: Use AWS Bedrock
- **vertex**: Use Google Vertex AI
- **openai**: Use OpenAI API
- **azure**: Use Azure OpenAI
- **litellm**: Use a LiteLLM proxy
### Authentication
Each provider supports different authentication methods:
**AWS Bedrock:**
- IAM roles with cross-account access
- Access keys (not recommended for production)
**Google Vertex AI:**
- Service account JSON keys
- Workload Identity (for GKE deployments)
**OpenAI/Azure:**
- API keys
**LiteLLM:**
- Endpoint URL + API key
## Example Configurations
### AWS Bedrock with IAM Role
```json
{
"providerSettings": {
"provider": "bedrock",
"bedrockRegion": "us-east-1",
"bedrockServiceRole": "arn:aws:iam::123456789012:role/ClineBedrockRole"
}
}
```
### Google Vertex AI
```json
{
"providerSettings": {
"provider": "vertex",
"vertexProject": "my-project-id",
"vertexRegion": "us-central1"
}
}
```
### LiteLLM Proxy
```json
{
"providerSettings": {
"provider": "litellm",
"litellmBaseUrl": "https://litellm.company.com",
"litellmApiKey": "sk-..."
}
}
```
## Next Steps
<CardGroup cols={2}>
<Card title="Configure AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
Set up AWS Bedrock integration
</Card>
<Card title="Configure Google Vertex" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
Set up Google Vertex AI integration
</Card>
<Card title="Configure LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
Set up LiteLLM proxy integration
</Card>
<Card title="Configure Custom Provider" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
Set up custom OpenAI-compatible provider
</Card>
</CardGroup>
@@ -1,239 +0,0 @@
---
title: "Rules"
sidebarTitle: "Rules"
description: "Custom instruction files that guide Cline's behavior in your enterprise deployment"
---
Rules are custom instruction files that provide Cline with guidelines about your coding preferences, standards, and best practices. These instructions get added to Cline's context when working on tasks.
## What are Rules?
Rules are simple markdown files stored in a `.clinerules/` directory that contain your team's conventions, preferences, and guidelines. They help Cline understand your:
- Coding style and conventions
- Preferred libraries and frameworks
- Architectural patterns
- Testing strategies
- Documentation standards
- Communication preferences
<Tip>
Rules are just `.md` files - no complex configuration needed!
</Tip>
## Quick Example
Here's a simple rule file that guides TypeScript development:
```markdown
# TypeScript Conventions
## Code Style
- Use 2-space indentation
- Prefer `const` over `let`
- Always use explicit return types for functions
- Use named exports instead of default exports
## Testing
- Write unit tests for all utility functions
- Use Vitest as the testing framework
- Aim for 80%+ code coverage
## Dependencies
- Prefer native TypeScript features over external libraries
- Use Zod for runtime type validation
- Use date-fns for date manipulation
```
## Creating Rules
<Tabs>
<Tab title="Using /newrule Command">
The easiest way to create a rule is with the `/newrule` command:
1. During a conversation with Cline, type `/newrule`
2. Cline will analyze your conversation and preferences
3. It creates an appropriately named `.md` file in `.clinerules/`
**Example:**
```
/newrule
Based on our conversation, create a rule for React component structure
```
</Tab>
<Tab title="Manual Creation">
You can also create rule files manually:
1. Create a `.clinerules/` directory in your repository root
2. Add markdown files with your guidelines
3. Use descriptive names like `react-patterns.md` or `api-conventions.md`
**File structure:**
```
your-repo/
├── .clinerules/
│ ├── typescript-style.md
│ ├── testing-standards.md
│ └── code-review-checklist.md
└── src/
```
</Tab>
</Tabs>
## Global vs Workspace Rules
<CardGroup cols={2}>
<Card title="Workspace Rules" icon="folder">
**Location:** `.clinerules/` in your repository
**Scope:** Specific to that project
**Use for:** Project-specific conventions and patterns
</Card>
<Card title="Global Rules" icon="globe">
**Location:** `Documents/Cline/` directory
**Scope:** All your projects
**Use for:** Personal preferences that apply everywhere
</Card>
</CardGroup>
## Managing Rules
### Toggling Rules
You can enable or disable individual rule files:
1. Click the rules icon in Cline's interface
2. Toggle rules on/off as needed
3. Changes apply immediately to new tasks
<Note>
Disabling a rule removes it from Cline's context, but keeps the file intact. You can re-enable it anytime.
</Note>
### Enterprise Remote Rules
<Info>
Enterprise deployments can configure **remote global rules** that apply to all team members. These are managed through your infrastructure configuration and cannot be toggled off by individual developers.
See [Self-Hosted Configuration](/enterprise-solutions/configuration/infrastructure-configuration/overview) for details on remote rules.
</Info>
## Compatible Formats
Cline also respects rules from other AI coding tools:
| File/Directory | Tool | Location |
|----------------|------|----------|
| `.cursorrules` | Cursor | Workspace root (single file) |
| `.cursor/rules/` | Cursor | Workspace directory (`.mdc` files) |
| `.windsurfrules` | Windsurf | Workspace root (single file) |
| `AGENTS.md` | Various | Workspace root + recursive search |
<Note>
**AGENTS.md behavior:** Cline only searches for nested `AGENTS.md` files recursively if a top-level `AGENTS.md` exists in your workspace root. If found, all `AGENTS.md` files are combined with their relative paths as headers.
</Note>
These files work the same way as `.clinerules/` files and can be toggled on/off independently.
## Best Practices
<AccordionGroup>
<Accordion title="Keep Rules Focused" icon="bullseye">
Each rule file should focus on one topic:
- ✅ `typescript-conventions.md`
- ✅ `react-component-structure.md`
- ❌ `everything-about-our-codebase.md`
</Accordion>
<Accordion title="Be Specific, Not Generic" icon="crosshairs">
Base rules on actual team preferences, not assumptions:
- ✅ "We use React Query for server state management"
- ❌ "Use best practices for state management"
</Accordion>
<Accordion title="Update Rules as Projects Evolve" icon="rotate">
Review and update rules periodically:
- When adopting new technologies
- After major architectural changes
- When team conventions evolve
</Accordion>
<Accordion title="Don't Overdo It" icon="gauge-simple-high">
Too many rules can overwhelm Cline's context:
- Start with 3-5 essential rules
- Add more only when truly needed
- Remove outdated rules promptly
</Accordion>
</AccordionGroup>
## Example Rule Files
<AccordionGroup>
<Accordion title="API Design Standards" icon="code">
```markdown
# API Design Standards
## REST Conventions
- Use plural nouns for endpoints (`/users`, not `/user`)
- Use HTTP methods semantically (GET, POST, PUT, DELETE)
- Return appropriate status codes
## Response Format
\`\`\`typescript
{
data: T,
error?: string,
metadata?: {
page: number,
total: number
}
}
\`\`\`
## Error Handling
- Always return error messages in `error` field
- Use 4xx for client errors, 5xx for server errors
- Include request ID in error responses
```
</Accordion>
<Accordion title="Testing Requirements" icon="vial">
```markdown
# Testing Requirements
## Test Organization
- Place tests next to source files (`Button.test.tsx`)
- Use `describe` blocks to group related tests
- Write descriptive test names
## Coverage Requirements
- Unit tests for all utility functions
- Integration tests for API endpoints
- E2E tests for critical user flows
- Minimum 80% coverage for new code
## Mocking Strategy
- Mock external API calls
- Use test fixtures for complex data
- Prefer dependency injection for testability
```
</Accordion>
</AccordionGroup>
## Next Steps
<CardGroup cols={2}>
<Card title="Workflows" icon="diagram-project" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
Combine rules with automated workflows
</Card>
<Card title="Remote Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
Deploy global rules for your team
</Card>
</CardGroup>
@@ -1,324 +0,0 @@
---
title: "Workflows"
sidebarTitle: "Workflows"
description: "Reusable instruction sets that can be invoked on-demand via slash commands"
---
Workflows are markdown files containing reusable instructions that you can invoke on-demand using slash commands. Think of them as "rules you can call when needed" rather than always-active guidelines.
## What are Workflows?
Workflows are similar to [Rules](/enterprise-solutions/configuration/infrastructure-configuration/rules), but with one key difference:
<CardGroup cols={2}>
<Card title="Rules" icon="book">
**Always Active**
Automatically applied to every task when toggled on
Example: Coding standards, style guides
</Card>
<Card title="Workflows" icon="diagram-project">
**On-Demand**
Invoked only when you use the slash command
Example: Deployment checklists, review processes
</Card>
</CardGroup>
<Tip>
Workflows are just markdown files, no complex configuration needed!
</Tip>
## Quick Example
Here's a simple deployment workflow:
**File:** `.clinerules/workflows/deploy.md`
```markdown
# Deployment Workflow
Before deploying to production, ensure:
## Pre-Deployment Checklist
1. All tests passing (unit, integration, e2e)
2. Code review approved by 2+ engineers
3. Staging environment tested successfully
4. Database migrations reviewed
5. Rollback plan documented
## Deployment Steps
1. Create deployment branch from main
2. Run final test suite
3. Deploy to production
4. Monitor error rates for 30 minutes
5. Verify key user flows
## Post-Deployment
1. Update deployment log
2. Notify team in #deployments channel
3. Monitor metrics for 24 hours
```
**Usage:**
```
/deploy
I'm ready to deploy the new authentication feature
```
When invoked, Cline adds the workflow instructions to its context for that specific task.
## Creating Workflows
<Tabs>
<Tab title="Manual Creation">
Create workflow files in the `.clinerules/workflows/` directory:
1. Create `.clinerules/workflows/` in your repository root
2. Add markdown files with your workflow instructions
3. Use descriptive names matching your slash command
**File structure:**
```
your-repo/
├── .clinerules/
│ └── workflows/
│ ├── deploy.md
│ ├── code-review.md
│ └── bug-triage.md
└── src/
```
</Tab>
<Tab title="Slash Command">
You can also create workflows during a conversation:
1. Have a conversation about a process you want to codify
2. Type `/newrule` and specify it should be a workflow
3. Cline creates the workflow file in `.clinerules/workflows/`
<Note>
The `/newrule` command can create both rules and workflows - just specify your intent clearly.
</Note>
</Tab>
</Tabs>
## Using Workflows
### Invoking Workflows
Simply type `/` followed by the workflow filename (without `.md`):
```
/deploy
/code-review
/bug-triage
```
The workflow instructions are added to Cline's context for the current task only.
### Workflow Naming
- Use lowercase with hyphens: `deploy.md`, `code-review.md`
- Keep names short and memorable
- Name should indicate the workflow's purpose
<Warning>
Workflow filenames become slash commands, so choose names that are easy to type and remember.
</Warning>
## Global vs Workspace Workflows
<CardGroup cols={2}>
<Card title="Workspace Workflows" icon="folder">
**Location:** `.clinerules/workflows/` in your repository
**Scope:** Specific to that project
**Use for:** Project-specific processes and checklists
</Card>
<Card title="Global Workflows" icon="globe">
**Location:** `Documents/Cline/Workflows/` directory
**Scope:** All your projects
**Use for:** Personal workflows that apply everywhere
</Card>
</CardGroup>
<Info>
**Precedence:** Local workflows override global workflows if they have the same name.
</Info>
## Managing Workflows
### Toggling Workflows
You can enable or disable workflows:
1. Click the rules icon in Cline's interface
2. Switch to the "Workflows" tab
3. Toggle workflows on/off as needed
<Note>
Disabling a workflow prevents it from being invoked, but keeps the file intact. The slash command won't work until you re-enable it.
</Note>
### Enterprise Remote Workflows
<Info>
Enterprise deployments can configure **remote global workflows** that are available to all team members. These are managed through your infrastructure configuration.
See [Self-Hosted Configuration](/enterprise-solutions/configuration/infrastructure-configuration/overview) for details on remote workflows.
</Info>
## Example Workflows
<AccordionGroup>
<Accordion title="Code Review Workflow" icon="code-review">
```markdown
# Code Review Workflow
## Pre-Review Checklist
- [ ] Code follows project style guide
- [ ] All tests pass locally
- [ ] No console.log or debugging code
- [ ] Comments explain "why" not "what"
- [ ] PR description is clear and complete
## Review Focus Areas
1. **Architecture**: Does this fit our existing patterns?
2. **Security**: Any potential vulnerabilities?
3. **Performance**: Any obvious bottlenecks?
4. **Testing**: Are edge cases covered?
5. **Documentation**: Is it clear how to use new features?
## Review Response
- Address all feedback within 24 hours
- Mark conversations as resolved when addressed
- Re-request review after major changes
```
</Accordion>
<Accordion title="Bug Triage Workflow" icon="bug">
```markdown
# Bug Triage Workflow
## Information Gathering
1. Reproduce the bug in local environment
2. Identify affected versions/environments
3. Check if similar issues exist
4. Gather error logs and stack traces
## Priority Assessment
**P0 (Critical)**: Production down, data loss, security breach
**P1 (High)**: Major feature broken, significant user impact
**P2 (Medium)**: Minor feature broken, workaround available
**P3 (Low)**: Cosmetic issue, minimal impact
## Create Ticket
- Use template: "Bug Report"
- Add reproduction steps
- Include screenshots/videos if applicable
- Tag with affected component
- Assign priority label
## Next Steps
- P0/P1: Immediate fix required
- P2: Schedule for current sprint
- P3: Add to backlog
```
</Accordion>
<Accordion title="Feature Planning Workflow" icon="lightbulb">
```markdown
# Feature Planning Workflow
## Requirements Gathering
1. Define the user problem we're solving
2. List success criteria (measurable)
3. Identify edge cases and constraints
4. Document technical dependencies
## Design Considerations
1. How does this fit existing architecture?
2. What data models are needed?
3. What API changes are required?
4. How will this impact performance?
## Implementation Plan
1. Break into smaller, shippable pieces
2. Identify which pieces can be done in parallel
3. Note any feature flags needed
4. Plan for backwards compatibility
## Testing Strategy
1. What unit tests are needed?
2. What integration tests are needed?
3. How will we test edge cases?
4. What manual testing is required?
```
</Accordion>
</AccordionGroup>
## Best Practices
<AccordionGroup>
<Accordion title="Keep Workflows Action-Oriented" icon="list-check">
Workflows should contain **actionable steps**, not general advice:
- ✅ "Run `npm test` and verify all tests pass"
- ❌ "Make sure testing is done properly"
</Accordion>
<Accordion title="Use Checklists" icon="square-check">
Format workflows as checklists when possible:
- Easy to follow step-by-step
- Clear progress tracking
- Reduces missed steps
</Accordion>
<Accordion title="Include Context" icon="circle-info">
Add **why** behind each step:
```markdown
1. Check staging environment first
(Catching issues in staging prevents production incidents)
```
</Accordion>
<Accordion title="Version as Code" icon="code-branch">
Workflows live in your repository:
- Track changes in git
- Review updates in PRs
- Maintain history of process evolution
</Accordion>
</AccordionGroup>
## Workflows vs Rules: When to Use Each
| Use Rules When | Use Workflows When |
|----------------|-------------------|
| Guidance should apply to every task | Process is invoked occasionally |
| Standards that rarely change | Checklist for specific scenarios |
| Always-on coding conventions | On-demand deployment processes |
| General coding style | Specific review procedures |
**Example:**
- **Rule**: "Use TypeScript strict mode and explicit return types"
- **Workflow**: "Follow these 10 steps when deploying to production"
## Next Steps
<CardGroup cols={2}>
<Card title="Rules" icon="book" href="/enterprise-solutions/configuration/infrastructure-configuration/rules">
Learn about always-active rules
</Card>
<Card title="Remote Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
Deploy global workflows for your team
</Card>
</CardGroup>
@@ -1,97 +0,0 @@
---
title: "Configuration Overview"
sidebarTitle: "Overview"
description: "Understanding enterprise configuration options for inference providers and system settings"
---
Cline offers two distinct approaches to configure inference providers and system settings for your organization. Understanding the difference between these approaches will help you choose the right configuration method for your needs.
## Configuration Types
<Info>
**Need help choosing?** See the [Deployment Guide](/enterprise-solutions/configuration/choosing-your-deployment) for a detailed comparison and decision tree.
</Info>
<CardGroup cols={2}>
<Card title="SaaS Provider Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
**Simple cloud-based setup**
Configure inference providers through the Cline [admin console](https://app.cline.bot/dashboard). Ideal for quick organizational deployment with minimal infrastructure requirements.
</Card>
<Card title="Self-Hosted Configuration" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
**Advanced enterprise setup**
Deep infrastructure integration with VPC endpoints, multi-account support, compliance features, and custom workflows on your own infrastructure.
</Card>
</CardGroup>
## Choosing the Right Configuration
### Use SaaS Configuration When:
- **Quick Setup**: You need to get your team up and running quickly
- **Centralized Management**: You want simple, cloud-based provider management
- **Standard Requirements**: Your organization has typical security and compliance needs
- **Small to Medium Teams**: You're managing dozens to hundreds of users
### Use Self-Hosted Configuration When:
- **Enterprise Security**: You need advanced security features and compliance controls
- **Complex Infrastructure**: You have existing AWS/GCP infrastructure to integrate with
- **Custom Workflows**: You need custom rules, workflows, and automation
- **Large Organizations**: You're managing hundreds to thousands of users
- **Air-Gapped Environments**: You need on-premises or restricted network deployment
## Configuration Comparison
| Feature | SaaS Configuration | Self-Hosted Configuration |
|---------|-------------------|---------------------------|
| **Setup Complexity** | Simple | Advanced |
| **Deployment Time** | Minutes | Days to Weeks |
| **Infrastructure Required** | None | AWS/GCP/Azure |
| **Compliance Features** | Basic | Advanced |
| **Custom Rules** | No | Yes |
| **Multi-Account Support** | No | Yes |
| **VPC Integration** | No | Yes |
| **Cost** | Lower | Higher |
## Getting Started
<Steps>
<Step title="Evaluate Your Requirements">
Review your organization's security, compliance, and infrastructure requirements to determine which configuration approach fits your needs.
</Step>
<Step title="Choose Your Path">
Select either SaaS Configuration for simple setup or Self-Hosted Configuration for advanced enterprise features. Use the [Deployment Guide](/enterprise-solutions/configuration/choosing-your-deployment) if you need help deciding.
</Step>
<Step title="Follow Configuration Guide">
Complete the setup process using the detailed guides for your chosen configuration type.
</Step>
<Step title="Onboard Team Members">
Once configured, team members can connect using the provider-specific member guides.
</Step>
</Steps>
---
## Available Providers
Both configuration approaches support the same core inference providers:
<CardGroup cols={3}>
<Card title="AWS Bedrock" icon="aws">
Enterprise AI models with AWS infrastructure integration and security features.
</Card>
<Card title="LiteLLM" icon="layer-group">
Unified proxy for accessing 100+ AI models through a single interface.
</Card>
<Card title="Google Vertex AI" icon="google">
Google Cloud's AI platform with advanced ML capabilities and global infrastructure.
</Card>
</CardGroup>
The main difference lies in how these providers are configured and managed within your organization's infrastructure and security requirements.
@@ -4,7 +4,7 @@ sidebarTitle: "Configure AWS Bedrock (Member)"
description: "Guide for engineers configuring AWS Bedrock credentials in VS Code after admin setup"
---
As a team member, you can connect your local development environment to your organization's AWS Bedrock setup. This guide walks you through configuring your AWS credentials in VS Code so you can start using models through your organization's Bedrock infrastructure. Your administrator has already configured the provider settingsyou just need to add your credentials to get started.
As a team member, you can connect your local development environment to your organization's AWS Bedrock setup. This guide walks you through configuring your AWS credentials in VS Code so you can start using models through your organization's Bedrock infrastructure. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
## Before You Begin
@@ -4,7 +4,7 @@ sidebarTitle: "Configure Google Vertex (Member)"
description: "Guide for engineers connecting to their organization's Google Vertex AI setup through VS Code after admin setup"
---
As a team member, you can connect your local development environment to your organization's Google Vertex AI setup. This guide walks you through configuring your Google Cloud credentials in VS Code so you can start using Vertex AI models through your organization's configured project and regional settings. Your administrator has already configured the provider settingsyou just need to add your credentials to get started.
As a team member, you can connect your local development environment to your organization's Google Vertex AI setup. This guide walks you through configuring your Google Cloud credentials in VS Code so you can start using Vertex AI models through your organization's configured project and regional settings. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
## Before You Begin
@@ -4,7 +4,7 @@ sidebarTitle: "Configure LiteLLM (Member)"
description: "Guide for engineers connecting to their organization's LiteLLM proxy through VS Code after admin setup"
---
As a team member, you can connect your local development environment to your organization's LiteLLM proxy setup. This guide walks you through configuring your connection in VS Code so you can start using multiple AI models through your organization's unified proxy interface. Your administrator has already configured the provider settingsyou just need to add your credentials to get started.
As a team member, you can connect your local development environment to your organization's LiteLLM proxy setup. This guide walks you through configuring your connection in VS Code so you can start using multiple AI models through your organization's unified proxy interface. Your administrator has already configured the provider settings-you just need to add your credentials to get started.
## Before You Begin
@@ -1,266 +0,0 @@
---
title: "OpenTelemetry Integration Override"
sidebarTitle: "OpenTelemetry Override"
description: "Export Cline telemetry to your observability platform using OpenTelemetry Protocol (OTLP)"
---
Cline includes opt-in OpenTelemetry support for exporting metrics and logs to your own observability infrastructure using the OpenTelemetry Protocol (OTLP).
<Note>
OpenTelemetry integration is **optional** and intended for advanced users with existing observability infrastructure. Most users won't need this feature.
</Note>
## What is OpenTelemetry?
[OpenTelemetry](https://opentelemetry.io/) is an industry-standard observability framework that provides a unified way to collect and export telemetry data (metrics, logs, and traces).
Cline's OpenTelemetry support allows you to:
- Export telemetry to your own systems
- Integrate with observability platforms like Datadog, New Relic, Grafana Cloud, etc.
- Maintain full control over your monitoring data
- Use your organization's existing monitoring infrastructure
## Supported Features
Cline supports OpenTelemetry's **OTLP (OpenTelemetry Protocol)** export with:
<CardGroup cols={2}>
<Card title="Metrics Export" icon="chart-bar">
Export metrics about Cline usage, performance, and errors
</Card>
<Card title="Logs Export" icon="file-lines">
Export structured logs for debugging and analysis
</Card>
</CardGroup>
### Export Formats
Cline supports three OTLP export protocols:
- **gRPC** (default, recommended)
- **HTTP/protobuf**
- **HTTP/JSON**
### Export Destinations
You can export to:
- **Console** (for testing)
- **OTLP endpoint** (your own collector or observability platform)
## Configuration
OpenTelemetry is configured using environment variables before launching Cline.
### Basic Setup
Enable OpenTelemetry and configure an OTLP endpoint:
```bash
# Enable OpenTelemetry
export CLINE_OTEL_TELEMETRY_ENABLED=true
# Configure metrics and logs export
export CLINE_OTEL_METRICS_EXPORTER=otlp
export CLINE_OTEL_LOGS_EXPORTER=otlp
# Set your OTLP endpoint
export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://your-collector:4317
# Optional: Set protocol (default is grpc)
export CLINE_OTEL_EXPORTER_OTLP_PROTOCOL=grpc
```
### Environment Variables
| Variable | Description | Default |
|----------|-------------|---------|
| `CLINE_OTEL_TELEMETRY_ENABLED` | Enable OpenTelemetry (`true`) | Disabled |
| `CLINE_OTEL_METRICS_EXPORTER` | Metrics exporter type (`console`, `otlp`, or both) | None |
| `CLINE_OTEL_LOGS_EXPORTER` | Logs exporter type (`console`, `otlp`, or both) | None |
| `CLINE_OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP endpoint URL | None |
| `CLINE_OTEL_EXPORTER_OTLP_PROTOCOL` | Protocol (`grpc`, `http/protobuf`, `http/json`) | `grpc` |
| `CLINE_OTEL_EXPORTER_OTLP_INSECURE` | Allow insecure connections | `false` |
| `CLINE_OTEL_EXPORTER_OTLP_HEADERS` | Custom headers (comma-separated `key=value` pairs) | None |
### Advanced Configuration
**Separate endpoints for metrics and logs:**
```bash
export CLINE_OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://metrics-collector:4317
export CLINE_OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs-collector:4317
```
**Custom headers for authentication:**
```bash
export CLINE_OTEL_EXPORTER_OTLP_HEADERS="api-key=your-key,x-custom-header=value"
```
**Multiple exporters (console + OTLP):**
```bash
export CLINE_OTEL_METRICS_EXPORTER=console,otlp
export CLINE_OTEL_LOGS_EXPORTER=console,otlp
```
**Export intervals:**
```bash
# Metrics export interval in milliseconds (default: 60000)
export CLINE_OTEL_METRIC_EXPORT_INTERVAL=30000
# Logs batch size and timeout
export CLINE_OTEL_LOG_BATCH_SIZE=512
export CLINE_OTEL_LOG_BATCH_TIMEOUT=5000
export CLINE_OTEL_LOG_MAX_QUEUE_SIZE=2048
```
## Integration Examples
### Datadog
Export to Datadog using their OTLP endpoint:
```bash
export CLINE_OTEL_TELEMETRY_ENABLED=true
export CLINE_OTEL_METRICS_EXPORTER=otlp
export CLINE_OTEL_LOGS_EXPORTER=otlp
export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://api.datadoghq.com
export CLINE_OTEL_EXPORTER_OTLP_HEADERS="dd-api-key=YOUR_DD_API_KEY"
```
### New Relic
Export to New Relic:
```bash
export CLINE_OTEL_TELEMETRY_ENABLED=true
export CLINE_OTEL_METRICS_EXPORTER=otlp
export CLINE_OTEL_LOGS_EXPORTER=otlp
export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.nr-data.net:4317
export CLINE_OTEL_EXPORTER_OTLP_HEADERS="api-key=YOUR_NEW_RELIC_LICENSE_KEY"
```
### Grafana Cloud
Export to Grafana Cloud:
```bash
export CLINE_OTEL_TELEMETRY_ENABLED=true
export CLINE_OTEL_METRICS_EXPORTER=otlp
export CLINE_OTEL_LOGS_EXPORTER=otlp
export CLINE_OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp-gateway-prod-us-central-0.grafana.net/otlp
export CLINE_OTEL_EXPORTER_OTLP_HEADERS="Authorization=Basic YOUR_BASE64_CREDENTIALS"
```
## Testing Configuration
Test your configuration with console output before sending to a real endpoint:
```bash
# Enable console output to see what data would be exported
export CLINE_OTEL_TELEMETRY_ENABLED=true
export CLINE_OTEL_METRICS_EXPORTER=console
export CLINE_OTEL_LOGS_EXPORTER=console
```
Then launch Cline and check the console output for metrics and logs.
## Troubleshooting
### No Data Being Exported
1. **Verify OpenTelemetry is enabled:**
```bash
echo $CLINE_OTEL_TELEMETRY_ENABLED
```
Should output `true`
2. **Check exporters are configured:**
```bash
echo $CLINE_OTEL_METRICS_EXPORTER
echo $CLINE_OTEL_LOGS_EXPORTER
```
3. **Test with console exporter first:**
```bash
export CLINE_OTEL_METRICS_EXPORTER=console
export CLINE_OTEL_LOGS_EXPORTER=console
```
### Connection Errors
1. **Verify endpoint is accessible:**
```bash
curl -v https://your-otlp-endpoint:4317
```
2. **Check if insecure mode is needed:**
```bash
export CLINE_OTEL_EXPORTER_OTLP_INSECURE=true
```
3. **Verify authentication headers:**
Double-check your API keys and authentication headers are correct
### Debug Mode
Enable debug logging to see detailed OpenTelemetry information:
```bash
export TEL_DEBUG_DIAGNOSTICS=true
```
This will output detailed information about:
- Configuration being used
- Exporters being created
- Connection attempts
- Export successes/failures
## What Gets Exported
When OpenTelemetry is enabled, Cline exports:
### Metrics
- Feature usage counts
- Task execution metrics
- Error rates and types
- Performance measurements
### Logs
- System events
- Error logs with context
- Operational information
<Warning>
Exported data is already anonymous and doesn't include code content, file paths, or sensitive information. However, you're responsible for securing the data once exported to your systems.
</Warning>
## Limitations
Current OpenTelemetry support in Cline:
- ✅ OTLP metrics export (console, gRPC, HTTP)
- ✅ OTLP logs export (console, gRPC, HTTP)
- ✅ Basic configuration via environment variables
- ❌ Distributed tracing (not yet implemented)
- ❌ Custom instrumentation API (not yet exposed)
- ❌ Sampling configuration (uses defaults)
## Best Practices
1. **Test First**: Always test with console exporter before sending to production
2. **Secure Credentials**: Never hardcode API keys; use secure environment variable management
3. **Monitor Costs**: Be aware of data ingestion costs with your observability platform
4. **Start Simple**: Begin with metrics only, add logs if needed
5. **Use Compression**: OTLP supports compression; check if your endpoint requires it
## Next Steps
<CardGroup cols={2}>
<Card title="Cline Telemetry" icon="chart-simple" href="/enterprise-solutions/monitoring/telemetry">
Configure simple built-in telemetry
</Card>
<Card title="OpenTelemetry Docs" icon="book" href="https://opentelemetry.io/docs/">
Learn more about OpenTelemetry
</Card>
</CardGroup>
+1 -1
View File
@@ -5,7 +5,7 @@ description: "This guide explains how administrators configure SSO provisioning
---
## Overview
Cline Enterprise integrates with your existing identity provider (IdP) via WorkOS to deliver secure SSO and zero-touch user lifecycle management. In this guide, you'll connect your IdP (Okta, Azure AD, Google Workspace, or any SAML/OIDC provider), enable just-in-time (JIT) provisioning so new users are created automatically on first sign-in, and configure role mapping so permissions stay aligned with your directoryno manual invites or seat reconciliations required.
Cline Enterprise integrates with your existing identity provider (IdP) via WorkOS to deliver secure SSO and zero-touch user lifecycle management. In this guide, you'll connect your IdP (Okta, Azure AD, Google Workspace, or any SAML/OIDC provider), enable just-in-time (JIT) provisioning so new users are created automatically on first sign-in, and configure role mapping so permissions stay aligned with your directory-no manual invites or seat reconciliations required.
## Prerequisites
+1 -1
View File
@@ -90,6 +90,6 @@ Rolling out to your organization:
- Review security architecture
- Configure [cloud provider setup](/provider-config/aws-bedrock/api-key) (AWS Bedrock, Vertex AI, Azure)
- Set up [MCP servers](/mcp/mcp-overview) for custom tooling
- Add [custom instructions](/features/cline-rules) for your codebase
- Add [custom instructions](/customization/cline-rules) for your codebase
Schedule a walkthrough to see how Cline Enterprise fits your infrastructure. We'll work with your security and compliance requirements to deploy in your environment.
@@ -1,100 +0,0 @@
---
title: "Cline Tools Reference Guide"
---
## What Can Cline Do?
Cline is your AI assistant that can:
- Edit and create files in your project
- Run terminal commands
- Search and analyze your code
- Help debug and fix issues
- Automate repetitive tasks
- Integrate with external tools
## Available Tools
For the most up-to-date implementation details, you can view the full source code in the [Cline repository](https://github.com/cline/cline/blob/main/src/core/prompts/system-prompt/tools).
Cline has access to the following tools for various tasks:
1. **File Operations**
- `write_to_file`: Create or overwrite files
- `read_file`: Read file contents
- `replace_in_file`: Make targeted edits to files
- `search_files`: Search files using regex
- `list_files`: List directory contents
2. **Terminal Operations**
- `execute_command`: Run CLI commands
- `list_code_definition_names`: List code definitions
3. **MCP Tools**
- `use_mcp_tool`: Use tools from MCP servers
- `access_mcp_resource`: Access MCP server resources
- Users can create custom MCP tools that Cline can then access
- Example: Create a weather API tool that Cline can use to fetch forecasts
4. **Interaction Tools**
- `ask_followup_question`: Ask user for clarification
- `attempt_completion`: Present final results
Each tool has specific parameters and usage patterns. Here are some examples:
- Create a new file (write_to_file):
```xml
<write_to_file>
<path>src/components/Header.tsx</path>
<content>
// Header component code
</content>
</write_to_file>
```
- Search for a pattern (search_files):
```xml
<search_files>
<path>src</path>
<regex>function\s+\w+\(</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
```
- Run a command (execute_command):
```xml
<execute_command>
<command>npm install axios</command>
<requires_approval>false</requires_approval>
</execute_command>
```
## Common Tasks
1. **Create a New Component**
- "Create a new React component called Footer"
2. **Fix a Bug**
- "Fix the error in src/utils/format.ts"
3. **Refactor Code**
- "Refactor the Button component to use TypeScript"
4. **Run Commands**
- "Run npm install to add axios"
## Getting Help
- [Join the Discord community](https://discord.gg/cline)
- Check the documentation
- Provide feedback to improve Cline
@@ -1,386 +0,0 @@
---
title: "New Task Tool"
---
### The `new_task` Tool & Context Management Strategies
#### Overview
Cline includes a powerful internal tool, `new_task`, designed to help manage workflow continuity and context preservation, especially during complex or long-running tasks. This tool, combined with Cline's awareness of its own context window usage and the flexibility of `.clinerules`, enables sophisticated strategies for breaking down work and ensuring seamless transitions between task sessions.
Understanding the core capabilities and how they interact with custom rules is key to leveraging this feature effectively.
#### Core Capabilities
Two fundamental capabilities enable advanced context management:
1. **The `new_task` Tool:**
- **Function:** Allows Cline, upon user approval, to end the current task session and immediately start a new one.
- **Context Preloading:** Crucially, Cline can **preload** this new task session with specific context provided within the tool's `<context>` block. This context can be anything Cline or a `.clinerules` file defines summaries, code snippets, next steps, project state, etc.
2. **Context Window Awareness:**
- **Tracking:** Cline internally tracks the percentage of its available context window currently being used during a task.
- **Visibility:** This information is visible in the `environment_details` provided to Cline in its prompt.
#### Using the `/newtask` Slash Command
As a quick alternative to Cline suggesting the `newtask` tool or defining complex rules, you can directly initiate the process using a Slash Command.
- **How:** Simply type `/newtask` in the chat input field.
- **Action:** Cline will propose creating a new task, typically suggesting context based on the current session (similar to its default behavior when using the tool). You will still get the `ask_followup_question` prompt to confirm and potentially modify the context before the new task is created.
- **Benefit:** Provides a fast, user-initiated way to leverage the `new_task` functionality for branching explorations or managing long sessions without waiting for Cline to suggest it.
<Note>
For more details on using the `/newtask` slash command, see the [New Task Command](/features/slash-commands/new-task)
documentation.
</Note>
#### Default Behavior (Without `.clinerules`)
By default, without specific `.clinerules` dictating its behavior:
- **Tool Availability:** The `new_task` tool exists, and Cline _can_ choose to use it.
- **Context Awareness:** Cline _is_ aware of its context usage percentage.
- **No Automatic Trigger:** Cline **will not** automatically initiate a task handoff _solely_ based on context usage reaching a specific percentage (like 50%). The decision to suggest using `new_task` comes from the AI model's reasoning based on the overall task progress and prompt instructions.
- **Basic Context Preloading:** If `new_task` is used without specific rules defining the `<context>` block structure, Cline will attempt to preload relevant information based on its current understanding (e.g., a basic summary of progress and next steps), but this may be less comprehensive than a rule-driven approach.
#### The Power of `.clinerules`: Enabling Custom Workflows
While the core capabilities exist by default, the true power, automation, and customization emerge when you combine `new_task` and context awareness with custom workflows defined in `.clinerules`. This allows you to precisely control _when_ and _how_ Cline manages context and task continuity.
Key benefits of using `.clinerules` with `new_task`:
- **Automated Context Management:** Define rules to automatically trigger handoffs at specific context percentages (e.g., >50%, >70%) or token counts, ensuring optimal performance and preventing context loss.
- **Model-Specific Optimization:** Tailor handoff triggers based on known thresholds for different LLMs (e.g., trigger earlier for models known to degrade past a certain token count).
- **Intelligent Breakpoints:** Instruct Cline via rules to find logical stopping points (e.g., after completing a function or test) _after_ a context threshold is passed, ensuring cleaner handoffs.
- **Structured Task Decomposition:** Use Plan Mode to define subtasks, then use `.clinerules` to have Cline automatically create a new task via `new_task` upon completing each subtask, preloading the context for the _next_ subtask.
- **Custom Context Packaging:** Mandate the exact structure and content of the `<context>` block in `.clinerules` for highly detailed and consistent handoffs (see example below).
- **Improved Memory Persistence:** Use `new_task` context blocks as a primary, integrated way to persist information across sessions, potentially replacing or supplementing file-based memory systems.
- **Workflow Automation:** Define rules for specific scenarios, like always preloading certain setup instructions or project boilerplate when starting tasks of a particular type.
#### Example Rule-Driven Workflow: Task Handoff Process
A common workflow, **driven by specific `.clinerules` like the example below**, involves these steps:
1. **Trigger Identification (Rule-Based):** Cline monitors for handoff points defined in the rules (e.g., context usage > 50%, task completion).
2. **User Confirmation:** Cline uses `ask_followup_question` to propose creating a new task, often showing the intended context defined by the rules.
```xml
<ask_followup_question>
<question>I've completed [specific accomplishment] and context usage is high (XX%). Would you like me to create a new task to continue with [remaining work], preloading the following context?</question>
<options>["Yes, create new task", "Modify context first", "No, continue this session"]</options>
</ask_followup_question>
```
3. **User Control:** You can approve, deny, or ask Cline to modify the context before the new task is created.
4. **Context Packaging (`new_task` Tool):** If approved, Cline uses `new_task`, packaging the context according to the structure mandated by the `.clinerules`.
5. **New Task Creation:** The current task ends, and a new session begins immediately, preloaded with the specified context.
#### The Handoff Context Block (Rule-Defined Structure)
The effectiveness of rule-driven handoffs depends heavily on how `.clinerules` define the `<context>` block. A comprehensive structure often includes:
- **`## Completed Work`**: Detailed list of accomplishments, files modified/created, key decisions.
- **`## Current State`**: Project status, running processes, key file states.
- **`## Next Steps`**: Clear, prioritized list of remaining tasks, implementation details, known challenges.
- **`## Reference Information`**: Links, code snippets, patterns, user preferences.
- **Actionable Start:** A clear instruction for the immediate next action.
#### Potential Use Cases & Workflows
The flexibility of `new_task` combined with `.clinerules` opens up many possibilities:
- **Proactive Context Window Management:** Automatically trigger handoffs at specific percentages (e.g., 50%, 70%) or token counts to maintain optimal performance.
- **Intelligent Breakpoints:** Instruct Cline to find logical stopping points (e.g., after completing a function or test) _after_ a context threshold is passed, ensuring cleaner handoffs.
- **Structured Task Decomposition:** Use Plan Mode to define subtasks, then use `.clinerules` to have Cline automatically create a new task via `new_task` upon completing each subtask.
- **Automated Session Summaries:** Configure the `<context>` block to always include a summary of the previous session's key discussion points.
- **Preloading Boilerplate/Setup:** Start new tasks related to specific projects preloaded with standard setup instructions or file templates.
- **"Memory Bank" Alternative:** Use `new_task` context blocks as the primary way to persist information across sessions, potentially replacing file-based memory systems.
Experimenting with `.clinerules` is encouraged to discover workflows that best suit your needs!
#### Example `.clinerules`: Task Handoff Strategy Guide
Below is an example `.clinerules` file focused specifically on using `new_task` for context window management. **Remember, this is just one specific strategy; the core `new_task` tool can be used differently with other custom rules.**
````markdown
# You MUST use the `new_task` tool: Task Handoff Strategy Guide
**CRITICAL INSTRUCTIONS - YOU MUST FOLLOW THESE GUIDELINES**
This guide provides **MANDATORY** instructions for effectively breaking down complex tasks and implementing a smooth handoff process between tasks. You **MUST** follow these guidelines to ensure continuity, context preservation, and efficient task completion.
## CONTEXT WINDOW MONITORING - MANDATORY ACTION REQUIRED
You **MUST** monitor the context window usage displayed in the environment details. When usage exceeds 50% of the available context window, you **MUST** initiate a task handoff using the `new_task` tool.
Example of context window usage over 50% with a 200K context window:
\`\`\`text
# Context Window Usage
105,000 / 200,000 tokens (53%)
Model: anthropic/claude-sonnet-4 (200K context window)
\`\`\`
**IMPORTANT**: When you see context window usage at or above 50%, you MUST:
1. Complete your current logical step
2. Use the `ask_followup_question` tool to offer creating a new task
3. If approved, use the `new_task` tool with comprehensive handoff instructions
## Task Breakdown in Plan Mode - REQUIRED PROCESS
Plan Mode is specifically designed for analyzing complex tasks and breaking them into manageable subtasks. When in Plan Mode, you **MUST**:
### 1. Initial Task Analysis - REQUIRED
- **MUST** begin by thoroughly understanding the full scope of the user's request
- **MUST** identify all major components and dependencies of the task
- **MUST** consider potential challenges, edge cases, and prerequisites
### 2. Strategic Task Decomposition - REQUIRED
- **MUST** break the overall task into logical, discrete subtasks
- **MUST** prioritize subtasks based on dependencies (what must be completed first)
- **MUST** aim for subtasks that can be completed within a single session (15-30 minutes of work)
- **MUST** consider natural breaking points where context switching makes sense
### 3. Creating a Task Roadmap - REQUIRED
- **MUST** present a clear, numbered list of subtasks to the user
- **MUST** explain dependencies between subtasks
- **MUST** provide time estimates for each subtask when possible
- **MUST** use Mermaid diagrams to visualize task flow and dependencies when helpful
\`\`\`mermaid
graph TD
A[Main Task] --> B[Subtask 1: Setup]
A --> C[Subtask 2: Core Implementation]
A --> D[Subtask 3: Testing]
A --> E[Subtask 4: Documentation]
B --> C
C --> D
\`\`\`
### 4. Getting User Approval - REQUIRED
- **MUST** ask for user feedback on the proposed task breakdown
- **MUST** adjust the plan based on user priorities or additional requirements
- **MUST** confirm which subtask to begin with
- **MUST** request the user to toggle to Act Mode when ready to implement
## Task Implementation and Handoff Process - MANDATORY PROCEDURES
When implementing tasks in Act Mode, you **MUST** follow these guidelines for effective task handoff:
### 1. Focused Implementation - REQUIRED
- **MUST** focus on completing the current subtask fully
- **MUST** document progress clearly through comments and commit messages
- **MUST** create checkpoints at logical completion points
### 2. Recognizing Completion Points - CRITICAL
You **MUST** identify natural handoff points when:
- The current subtask is fully completed
- You've reached a logical stopping point in a larger subtask
- The implementation is taking longer than expected and can be continued later
- The task scope has expanded beyond the original plan
- **CRITICAL**: The context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
### 3. Initiating the Handoff Process - MANDATORY ACTION
When you've reached a completion point, you **MUST**:
1. Summarize what has been accomplished so far
2. Clearly state what remains to be done
3. **MANDATORY**: Use the `ask_followup_question` tool to offer creating a new task:
\`\`\`xml
<ask_followup_question>
<question>I've completed [specific accomplishment]. Would you like me to create a new task to continue with [remaining work]?</question>
<options>["Yes, create a new task", "No, continue in this session", "Let me think about it"]</options>
</ask_followup_question>
\`\`\`
### 4. Creating a New Task with Context - REQUIRED ACTION
If the user agrees to create a new task, you **MUST** use the `new_task` tool with comprehensive handoff instructions:
\`\`\`xml
<new_task>
<context>
# Task Continuation: [Brief Task Title]
## Completed Work
- [Detailed list of completed items]
- [Include specific files modified/created]
- [Note any important decisions made]
## Current State
- [Description of the current state of the project]
- [Any running processes or environment setup]
- [Key files and their current state]
## Next Steps
- [Detailed list of remaining tasks]
- [Specific implementation details to address]
- [Any known challenges to be aware of]
## Reference Information
- [Links to relevant documentation]
- [Important code snippets or patterns to follow]
- [Any user preferences noted during the current session]
Please continue the implementation by [specific next action].
</context>
</new_task>
\`\`\`
### 5. Detailed Context Transfer - MANDATORY COMPONENTS
When creating a new task, you **MUST** always include:
#### Project Context - REQUIRED
- **MUST** include the overall goal and purpose of the project
- **MUST** include key architectural decisions and patterns
- **MUST** include technology stack and dependencies
#### Implementation Details - REQUIRED
- **MUST** list files created or modified in the current session
- **MUST** describe specific functions, classes, or components implemented
- **MUST** explain design patterns being followed
- **MUST** outline testing approach
#### Progress Tracking - REQUIRED
- **MUST** provide checklist of completed items
- **MUST** provide checklist of remaining items
- **MUST** note any blockers or challenges encountered
#### User Preferences - REQUIRED
- **MUST** note coding style preferences mentioned by the user
- **MUST** document specific approaches requested by the user
- **MUST** highlight priority areas identified by the user
## Best Practices for Effective Handoffs - MANDATORY GUIDELINES
### 1. Maintain Continuity - REQUIRED
- **MUST** use consistent terminology between tasks
- **MUST** reference previous decisions and their rationale
- **MUST** maintain the same architectural approach unless explicitly changing direction
### 2. Preserve Context - REQUIRED
- **MUST** include relevant code snippets in the handoff
- **MUST** summarize key discussions from the previous session
- **MUST** reference specific files and line numbers when applicable
### 3. Set Clear Next Actions - REQUIRED
- **MUST** begin the handoff with a clear, actionable next step
- **MUST** prioritize remaining tasks
- **MUST** highlight any decisions that need to be made
### 4. Document Assumptions - REQUIRED
- **MUST** clearly state any assumptions made during implementation
- **MUST** note areas where user input might be needed
- **MUST** identify potential alternative approaches
### 5. Optimize for Resumability - REQUIRED
- **MUST** structure the handoff so the next session can begin working immediately
- **MUST** include setup instructions if environment configuration is needed
- **MUST** provide a quick summary at the top for rapid context restoration
## Example Task Handoff
### Example #1 of an effective task handoff:
\`\`\`xml
<new_task>
<context>
# Task Continuation: Implement User Authentication System
## Completed Work
- Created basic Express.js server structure
- Implemented MongoDB connection and user schema
- Completed user registration endpoint with password hashing
- Added input validation using Joi
- Created initial test suite for registration endpoint
## Current State
- Server runs successfully on port 3000
- MongoDB connection is established
- Registration endpoint (/api/users/register) is fully functional
- Test suite passes for all registration scenarios
## Next Steps
1. Implement login endpoint (/api/users/login)
- Use bcrypt to compare passwords
- Generate JWT token upon successful login
- Add proper error handling for invalid credentials
2. Create authentication middleware
- Verify JWT tokens
- Extract user information
- Handle expired tokens
3. Add protected routes that require authentication
4. Implement password reset functionality
## Reference Information
- JWT secret should be stored in .env file
- Follow the existing error handling pattern in routes/users.js
- User schema is defined in models/User.js
- Test patterns are established in tests/auth.test.js
Please continue by implementing the login endpoint following the same patterns established in the registration endpoint.
</context>
</new_task>
\`\`\`
### Example #2 of an ineffective task handoff:
_(Note: The example provided in the original rules showing "YOLO MODE Implementation" seems less like a direct handoff context block and more like a general status update with future considerations. A true ineffective handoff might lack detail in 'Current State' or 'Next Steps')._
## When to Use Task Handoffs - MANDATORY TRIGGERS
You **MUST** initiate task handoffs in these scenarios:
1. **CRITICAL**: When context window usage exceeds 50% (e.g., 100,000+ tokens for a 200K context window)
2. **Long-running projects** that exceed a single session
3. **Complex implementations** with multiple distinct phases
4. **When context window limitations** are approaching
5. **When switching focus areas** within a larger project
6. **When different expertise** might be beneficial for different parts of the task
**FINAL REMINDER - CRITICAL INSTRUCTION**
You **MUST** monitor the context window usage in the environment details section. When it exceeds 50% (e.g., "105,000 / 200,000 tokens (53%)"), you **MUST** proactively initiate the task handoff process using the `ask_followup_question` tool followed by the `new_task` tool. You MUST use the `new_task` tool.
By strictly following these guidelines, you'll ensure smooth transitions between tasks, maintain project momentum, and provide the best possible experience for users working on complex, multi-session projects.
```markdown
## User Interaction & Workflow Considerations
- **Linear Flow:** Currently, using `new_task` creates a linear sequence. The old task ends, and the new one begins. The old task history remains accessible for backtracking.
- **User Approval:** You always have control, approving the handoff and having the chance to modify the context Cline proposes to carry forward.
- **Flexibility:** The core `new_task` tool is a flexible building block. Experiment with `.clinerules` to create workflows that best suit your needs, whether for strict context management, task decomposition, or other creative uses.
```
````
@@ -1,113 +0,0 @@
---
title: "Remote Browser Support"
description: "Remote browser support allows Cline to utilize a remote Chrome instance, leveraging authentication tokens and session cookies relevant to certain web development test cases."
---
The Remote Browser feature in Cline allows the AI assistant to interact with web content directly through a controlled browser instance. This enables several powerful capabilities:
- Viewing and interacting with websites
- Testing locally running web applications
- Monitoring console logs and errors
- Performing browser actions like clicking, typing, and scrolling
## Remote Browser in Cline
### What is Remote Browser?
Remote Browser allows Cline to view and interact with websites directly. This feature enables Cline to:
- Visit websites and view their content
- Test your locally running web applications
- Fill out forms and click on elements
- Capture screenshots of what it sees
- Scroll through pages to see more content
### How to Use Remote Browser
#### Basic Commands
You can ask Cline to use the browser with simple instructions:
- **Open a website**: "Use the browser to check the website at [https://example.com](https://example.com/)"
- **Click on elements**: "Click the login button"
- **Type text**: "Type 'Hello world' in the search box"
- **Scroll the page**: "Scroll down to see more content"
- **Close the browser**: "Close the browser now"
#### Example Workflows
**Testing a Web Application:**
```javascript
Can you start my React app with "npm start" and then check if it's working properly at http://localhost:3000?
```
**Analyzing a Website:**
```javascript
Can you visit https://example.com and tell me what you think about its design and layout?
```
**Filling Out a Form:**
```javascript
Please go to https://example.com/contact, fill out the contact form with some test data, and submit it.
```
### Important Things to Know
#### One Browser at a Time
Cline can only use one browser at a time. If you want to visit a different website, you can either:
- Ask Cline to navigate to a new URL within the same browser session
- Ask Cline to close the current browser and open a new one
#### Browser Must Be Closed Before Using Other Tools
If you want Cline to edit files or run commands after using the browser, you must first ask it to close the browser:
```javascript
Close the browser and then update the CSS file to fix the alignment issue we saw.
```
#### What Cline Sees
The browser has a fixed viewport size (900x600 pixels by default), similar to a small laptop screen. Cline will share screenshots after each action so you can see exactly what it sees.
#### Console Logs
Cline captures browser console logs, which can be helpful for debugging web applications. These logs are included with each screenshot.
### Common Use Cases
- **Web Development**: Test your websites and web applications
- **UI/UX Review**: Get feedback on website design and usability
- **Content Research**: Have Cline browse websites to gather information
- **Form Testing**: Verify that forms work correctly
- **Responsive Design Testing**: Check how websites look at different screen sizes
### Troubleshooting
- **If a website doesn't load**: Try providing a direct URL with the http:// or https:// prefix
- **If clicking doesn't work**: Try describing the location of the element more precisely
- **If the browser seems stuck**: Ask Cline to close the browser and try again
### Using Remote Browser with VS Code in WSL
When running VS Code in WSL, you'll need to configure Windows to allow WSL to connect to Chrome. Follow these steps:
#### Open PowerShell as Administrator and Run:
```powershell
# Allow WSL to connect to Chrome's debugging port
New-NetFirewallRule -DisplayName "WSL Chrome Debug" -Direction Inbound -LocalPort 9222 -Protocol TCP -Action Allow
```
#### Configure Cline in VS Code:
1. Open VS Code settings
2. Search for "Cline: Chrome Executable Path"
3. Set the value to the path of your Chrome executable (e.g., `C:\Program Files\Google\Chrome\Application\chrome.exe`)
Cline should now be able to use the Remote Browser feature from within WSL.
@@ -1,45 +0,0 @@
---
title: "File Mentions"
sidebarTitle: "File Mentions"
---
File mentions let you pull any file from your workspace directly into your conversation with Cline. No more copying and pasting code snippets - just type `@/` and point to the file you need help with.
When you type `@/` in the chat, Cline shows your workspace files. Navigate through folders, select the file you want, and it's instantly available to Cline - complete with all imports, related functions, and surrounding context.
I use file mentions constantly when debugging. Instead of trying to figure out which parts of my code to copy over, I just reference the file directly:
```
I'm getting this error when my form submits: @terminal
Here's my component: @/src/components/ContactForm.jsx
And the API endpoint: @/src/api/contact.js
What am I missing?
```
This gives Cline everything it needs - the error message, the component code, and the API endpoint - all without me having to copy anything. Cline can see imports, dependencies, and all the surrounding context that might be causing the issue.
File mentions shine when you're dealing with complex bugs that span multiple files. Before, I'd have to carefully copy each relevant file, making sure I didn't miss anything important. Now I just reference each file with `@/` and Cline gets the complete picture.
Next time you're stuck on a problem, try using file mentions instead of copying code. You'll save time and get better answers because Cline has all the context it needs.
## How It Works Under the Hood
When you use a file mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@/path/to/file` pattern in your text
2. The extension resolves the file path relative to your workspace root
3. It checks if the file is binary (like an image) or text-based
4. For text files, it reads the complete file content
5. The file content is appended to your message in a structured format:
```
<file_content path="path/to/file">
[Complete file content]
</file_content>
```
6. This enhanced message with the embedded file content is sent to the AI
7. The AI can now "see" the complete file content as if you had copied and pasted it
This seamless process happens automatically whenever you use a file mention, giving the AI full context without you having to manually copy anything.
@@ -1,58 +0,0 @@
---
title: "Folder Mentions"
sidebarTitle: "Folder Mentions"
---
Folder mentions let you bring entire directories into your conversation with Cline. Just type `@/` followed by a folder path ending with a slash, and Cline gets access to the folder structure and its contents.
When you type `@/` in chat, Cline shows your workspace files and folders. Navigate to the folder you want, make sure to include the trailing slash, and Cline will see the folder's structure and contents.
I use folder mentions when I need help understanding or refactoring a whole section of my codebase. Instead of referencing individual files one by one, I can just point to the entire directory:
```
I'm trying to understand how the authentication flow works in my app.
Can you explain the structure and relationships between the files in @/src/auth/?
```
Cline can then see all the files in the auth directory, their contents, and how they relate to each other. This gives it the full context to explain complex interactions between multiple files.
Folder mentions are also perfect for getting help with project organization. When I'm unsure if my project structure makes sense, I'll ask Cline to review it:
```
I'm setting up a new React project. Does this folder structure make sense? @/src/
What would you change to make it more maintainable as the project grows?
```
Next time you're working with multiple related files, try using folder mentions instead of referencing each file individually. You'll get more comprehensive help because Cline can see the bigger picture of how everything fits together.
## How It Works Under the Hood
When you use a folder mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@/path/to/folder/` pattern (with trailing slash) in your text
2. The extension resolves the folder path relative to your workspace root
3. It calls `fs.readdir()` to get a list of all files and subdirectories in that folder
4. For each file in the directory, it checks if it's binary or text-based
5. For text files, it extracts the complete content
6. The folder structure and file contents are appended to your message in a structured format:
```
<folder_content path="path/to/folder">
├── file1.txt
├── file2.js
└── subfolder/
<file_content path="path/to/folder/file1.txt">
[File content]
</file_content>
<file_content path="path/to/folder/file2.js">
[File content]
</file_content>
</folder_content>
```
7. This enhanced message with the embedded folder structure and file contents is sent to the AI
8. The AI can now "see" both the directory structure and the content of files within that directory
This process happens automatically whenever you use a folder mention, giving the AI a comprehensive view of your project structure and file contents.
@@ -1,84 +0,0 @@
---
title: "Git Mentions"
sidebarTitle: "Git Mentions"
---
Git mentions let you bring your repository's history and changes directly into your conversation with Cline. You can reference uncommitted changes with `@git-changes` or specific commits with `@[commit-hash]`.
When you type `@` in chat, you can select "Git Changes" from the menu or type `@git-changes` directly. For specific commits, type `@` followed by the commit hash (at least 7 characters). Cline will immediately see the git status, diffs, commit messages, and other relevant information.
I use git mentions constantly when I'm trying to understand code changes or troubleshoot issues introduced by recent commits. Instead of trying to copy and paste diffs or commit logs, I just ask:
```
I think this commit broke our authentication flow: @a1b2c3d
Can you explain what changed and why it might be causing the issue?
```
This gives Cline the complete commit information, including the commit message, author, date, and the full diff. Cline can then analyze exactly what changed and how it might affect other parts of the codebase.
The `@git-changes` mention is perfect when you're working on changes and want feedback before committing:
```
Here are my current changes: @git-changes
I'm trying to implement a new feature for user profiles. Does my approach make sense?
Are there any potential issues or improvements you'd suggest?
```
This shows Cline all your uncommitted changes, including new files, modified files, and their diffs. Cline can then review your changes and provide feedback on your implementation.
Git mentions are especially powerful when combined with file mentions. When I'm investigating a bug, I'll often reference both:
```
I think this commit introduced a bug: @a1b2c3d
Here's the current implementation: @/src/components/Auth.jsx
How can I fix the issue while preserving the intended functionality?
```
Next time you're working with code changes or investigating issues, try using git mentions instead of manually describing or copying changes. You'll get more accurate help because Cline can see exactly what changed and in what context.
## How It Works Under the Hood
When you use git mentions in your message, here's what happens behind the scenes:
### For Git Changes (`@git-changes`)
1. When you send your message, Cline detects the `@git-changes` pattern in your text
2. The extension runs git commands to get the current working state of your repository
3. It captures the output of `git status` and `git diff` to see all uncommitted changes
4. This information is appended to your message in a structured format:
```
<git_working_state>
On branch main
Changes not staged for commit:
modified: src/components/Button.jsx
modified: src/styles/main.css
[Complete diff output with all changes]
</git_working_state>
```
### For Specific Commits (`@[commit-hash]`)
1. When you send your message, Cline detects the `@` followed by a commit hash pattern
2. The extension runs `git show` and related commands to get information about that commit
3. It retrieves the commit message, author, date, and the complete diff
4. This information is appended to your message in a structured format:
```
<git_commit hash="a1b2c3d">
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t
Author: Developer Name <dev@example.com>
Date: Mon May 20 14:30:45 2025 -0700
Fix authentication bug in login form
[Complete diff output showing all changes in the commit]
</git_commit>
```
This process happens automatically whenever you use git mentions, giving the AI complete visibility into your code changes without you having to copy and paste diffs or commit logs.
-118
View File
@@ -1,118 +0,0 @@
---
title: "@ Mentions Overview"
sidebarTitle: "Overview"
---
@ mentions are one of Cline's most powerful features, letting you seamlessly bring external context into your conversations. Instead of copying and pasting code, error messages, or documentation, you can simply reference them with an @ symbol.
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/at-mentions.png" alt="@ Mentions Overview" />
</Frame>
When you type `@` in the chat input, Cline shows a menu of available mention types. These mentions let you reference files, folders, problems, terminal output, git changes, and even web content directly in your conversations.
## Available @ Mentions
Cline supports several types of @ mentions, each designed to bring different kinds of context into your conversations:
<Columns cols={2}>
<Card title="File Mentions" icon="file" href="/features/at-mentions/file-mentions">
Reference any file in your workspace with `@/path/to/file`. Cline sees the complete file content, including imports, related
functions, and surrounding context.
</Card>
{" "}
<Card title="Folder Mentions" icon="folder" href="/features/at-mentions/folder-mentions">
Reference entire directories with `@/path/to/folder/`. Cline sees the folder structure and all file contents, perfect for
understanding complex interactions between multiple files.
</Card>
{" "}
<Card title="Problem Mentions" icon="triangle-exclamation" href="/features/at-mentions/problem-mentions">
Use `@problems` to show Cline all the errors and warnings in your workspace. Cline sees the complete list with file locations
and error messages.
</Card>
{" "}
<Card title="Terminal Mentions" icon="terminal" href="/features/at-mentions/terminal-mentions">
Use `@terminal` to share your recent terminal output. Cline sees the complete output with formatting preserved, perfect for
debugging build errors or test failures.
</Card>
{" "}
<Card title="Git Mentions" icon="code-branch" href="/features/at-mentions/git-mentions">
Reference uncommitted changes with `@git-changes` or specific commits with `@[commit-hash]`. Cline sees the complete diff,
commit message, and other relevant information.
</Card>
<Card title="URL Mentions" icon="globe" href="/features/at-mentions/url-mentions">
Reference web content with `@https://example.com`. Cline fetches and sees the complete webpage content, perfect for
referencing documentation or GitHub issues.
</Card>
</Columns>
## Why @ Mentions Matter
@ mentions transform how you interact with Cline by:
1. **Eliminating copy-paste**: No more copying and pasting code, error messages, or terminal output. Just reference them directly.
2. **Preserving context**: Cline sees the complete context, including imports, related functions, and surrounding code that might be relevant.
3. **Maintaining formatting**: Terminal output, error messages, and web content keep their formatting, making them easier to understand.
4. **Enabling complex workflows**: Combine multiple @ mentions to give Cline a complete picture of your problem:
```
I'm getting these errors: @problems
Here's my component: @/src/components/Form.jsx
And the API endpoint: @/src/api/users.js
The error happens when I submit: @terminal
I think this commit might have caused it: @a1b2c3d
```
## Getting Started
To use @ mentions:
1. Type `@` in the chat input
2. Select the type of mention from the menu or continue typing
3. For files and folders, navigate through your workspace structure
4. Send your message as usual
Cline will automatically process the mentions and include the referenced content in the context sent to the AI.
Try using @ mentions in your next conversation with Cline - you'll be amazed at how much more efficient and effective your interactions become when you can seamlessly bring in external context.
## How It Works Under the Hood
When you use @ mentions in your messages, there's a sophisticated process happening behind the scenes:
1. **Detection**: When you send a message, Cline scans the text for @ mention patterns using regular expressions
2. **Processing**: For each detected mention, Cline:
- Determines the mention type (file, folder, problems, terminal, git, URL)
- Fetches the relevant content (file contents, terminal output, etc.)
- Formats the content appropriately
3. **Enhancement**: The original message is enhanced with structured data:
```
Your original message with @/path/to/file
<file_content path="/path/to/file">
[Complete file content]
</file_content>
```
4. **Context Inclusion**: This enhanced message with all the embedded content is sent to the AI model
5. **Seamless Response**: The AI can now "see" all the referenced content as if you had manually copied and pasted it
This entire process happens automatically and seamlessly whenever you use @ mentions, giving the AI complete context without you having to manually copy anything.
Each type of @ mention has its own specific implementation details, which you can find in their respective documentation pages.
@@ -1,52 +0,0 @@
---
title: "Problem Mentions"
sidebarTitle: "Problem Mentions"
---
The problems mention gives Cline instant access to all the errors and warnings in your workspace. Just type `@problems` and Cline can see every diagnostic issue VSCode has detected.
When you type `@` in chat, select "Problems" from the menu or just type `@problems` directly. Cline will immediately see all the errors and warnings from your workspace, complete with file locations and error messages.
I use the problems mention constantly when I'm stuck on build errors or TypeScript issues. Instead of trying to describe the errors or copy them one by one, I just ask:
```
I'm getting these TypeScript errors and I'm not sure how to fix them: @problems
Can you help me understand what's wrong and how to fix it?
```
This gives Cline the complete list of errors with their exact locations and messages. Cline can then analyze the patterns across multiple errors and suggest comprehensive solutions.
The problems mention is especially powerful when combined with file mentions. When I'm dealing with complex type errors, I'll reference both:
```
I'm getting these type errors: @problems
Here's my component: @/src/components/DataTable.tsx
And the types file: @/src/types/api.ts
How can I fix these issues?
```
This approach gives Cline everything it needs - the exact errors, the component code, and the type definitions - all without me having to copy anything manually.
Next time you're stuck on errors, try using `@problems` instead of copying error messages. You'll get more accurate help because Cline can see the complete error context and locations.
## How It Works Under the Hood
When you use the problems mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@problems` pattern in your text
2. The extension calls VSCode's built-in `vscode.languages.getDiagnostics()` API to get all errors and warnings
3. It formats these diagnostics into a structured text representation with file paths, line numbers, and error messages
4. The formatted problems list is appended to your message in a structured format:
```
<workspace_diagnostics>
/path/to/file.js:10:5 - error TS2322: Type 'string' is not assignable to type 'number'.
/path/to/file.js:15:3 - warning: This variable is never used.
</workspace_diagnostics>
```
5. This enhanced message with the embedded diagnostics is sent to the AI
6. The AI can now "see" all the errors and warnings in your workspace, complete with their locations and messages
This process happens automatically whenever you use the problems mention, giving the AI a comprehensive view of all the issues in your workspace without you having to copy them manually.
@@ -1,73 +0,0 @@
---
title: "Terminal Mentions"
sidebarTitle: "Terminal Mentions"
---
The terminal mention lets you bring your terminal output directly into your conversation with Cline. Just type `@terminal` and Cline can see the recent output from your terminal.
When you type `@` in chat, select "Terminal" from the menu or just type `@terminal` directly. Cline will immediately see the recent output from your active terminal, including error messages, build logs, or command results.
I use the terminal mention all the time when I'm dealing with build errors, test failures, or debugging output. Instead of trying to copy and paste terminal output (which often loses formatting), I just ask:
```
I'm getting this error when running my tests: @terminal
What's causing this and how can I fix it?
```
This gives Cline the complete terminal output with all its formatting intact. Cline can then analyze the error messages, stack traces, and surrounding context to provide more accurate help.
The terminal mention is especially powerful when combined with file mentions. When I'm debugging a failed API call, I'll reference both:
```
I'm getting this error when calling my API: @terminal
Here's my API client code: @/src/api/client.js
And the endpoint implementation: @/src/server/routes/users.js
What am I doing wrong?
```
This approach gives Cline everything it needs - the exact error output, the client code, and the server implementation - all without me having to copy anything manually.
Next time you're running into issues with command output or build errors, try using `@terminal` instead of copying the output. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
## How It Works Under the Hood
When you use the terminal mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@terminal` pattern in your text
2. The extension calls `getLatestTerminalOutput()` which accesses VSCode's terminal API
3. It captures the recent output buffer from your active terminal
4. The terminal output is appended to your message in a structured format:
```
<terminal_output>
$ npm run test
> project@1.0.0 test
> jest
FAIL src/components/__tests__/Button.test.js
● Button component renders correctly
[Complete terminal output with formatting preserved]
</terminal_output>
```
5. This enhanced message with the embedded terminal output is sent to the AI
6. The AI can now "see" the complete terminal output with all formatting preserved
This process happens automatically whenever you use the terminal mention, giving the AI access to your command results, error messages, and other terminal output without you having to copy it manually.
## Troubleshooting Terminal Issues
If you're experiencing issues with terminal mentions or terminal integration in general (such as "Shell Integration Unavailable" or commands not showing output), please refer to our comprehensive [Terminal Integration Troubleshooting Guide](/troubleshooting/terminal-integration-guide).
Common issues include:
- Terminal mentions not capturing output
- "Shell Integration Unavailable" messages in Cline chat
- Commands executing but output not visible to Cline
- Terminal integration working inconsistently
The troubleshooting guide provides platform-specific solutions and detailed configuration steps to resolve these issues.
@@ -1,65 +0,0 @@
---
title: "URL Mentions"
sidebarTitle: "URL Mentions"
---
URL mentions let you bring web content directly into your conversation with Cline. Just type `@` followed by any URL, and Cline can see the content of that webpage without you having to copy and paste anything.
When you type `@` in chat followed by a URL (like `@https://example.com`), Cline will fetch the content of that webpage and include it in the context. This works for documentation pages, GitHub issues, Stack Overflow questions, or any other web content you want to reference.
I use URL mentions constantly when I'm working with external APIs or libraries. Instead of trying to explain how an API works or copying documentation snippets, I just reference the docs directly:
```
I'm trying to implement authentication with this API: @https://api.example.com/docs/auth
Can you help me write the code to get an access token based on these docs?
```
This gives Cline the complete documentation page, so it can see all the authentication requirements, endpoints, parameters, and examples. Cline can then provide more accurate and comprehensive help based on the official documentation.
URL mentions are especially useful for referencing GitHub issues or discussions:
```
I'm trying to fix this issue in our project: @https://github.com/our-org/our-repo/issues/123
Here's my current implementation: @/src/components/Feature.jsx
What changes do I need to make to address the issue?
```
This shows Cline the complete GitHub issue, including the description, comments, and any code snippets or screenshots. Cline can then help you implement a solution that directly addresses the reported issue.
Next time you're working with external documentation or online resources, try using URL mentions instead of copying and pasting content. You'll get more accurate help because Cline can see the complete context of the webpage, including formatting, code examples, and surrounding information.
## How It Works Under the Hood
When you use a URL mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@http://...` or `@https://...` pattern in your text
2. The extension launches a headless browser (Puppeteer) in the background
3. It navigates to the URL and waits for the page to load completely
4. The browser captures the page content, including text, formatting, and code examples
5. The content is converted to a Markdown format that preserves the structure
6. This content is appended to your message in a structured format:
```
<url_content url="https://example.com/docs">
# Example API Documentation
## Authentication
To authenticate with the API, you need to...
const token = await api.authenticate({
username: 'user',
password: 'pass'
});
[Complete webpage content in Markdown format]
</url_content>
```
7. The browser is then closed to free up resources
8. This enhanced message with the embedded webpage content is sent to the AI
This process happens automatically whenever you use a URL mention, giving the AI access to the complete content of the webpage without you having to copy and paste anything.
+82 -72
View File
@@ -1,12 +1,12 @@
---
title: "Auto Approve"
title: "Auto Approve & YOLO Mode"
sidebarTitle: "Auto Approve"
description: "Let Cline take specific actions without asking for approval every time."
description: "Control which actions Cline can take without asking for approval."
---
Auto Approve lets you decide which actions Cline can take without prompting you each time. It keeps you out of approval popups during routine work, while still letting you keep tight control over high-risk actions.
Auto Approve lets you decide which actions Cline can take without prompting you each time. It keeps you out of approval popups during routine work while letting you keep tight control over high-risk actions.
If you find yourself repeatedly clicking approve for the same safe operations, Auto Approve is the setting that fixes that. The goal is fewer interruptions without losing the ability to review changes when it matters.
If you find yourself repeatedly clicking approve for the same safe operations, Auto Approve fixes that.
<Frame>
<video
@@ -18,90 +18,100 @@ If you find yourself repeatedly clicking approve for the same safe operations, A
/>
</Frame>
## How it works
## How It Works
Auto Approve is evaluated per tool call. When Cline is about to read a file, edit a file, run a command, or use the browser, Cline checks your Auto Approve settings for that category.
Auto Approve is evaluated per tool call. When Cline is about to read a file, edit a file, run a command, or use the browser, it checks your Auto Approve settings for that category.
A few details matter in practice:
A few details matter:
- **Workspace vs outside your workspace**: Read all files and Edit all files only extend the base toggle. If the base toggle is off, the all files option does nothing.
- **Terminal commands**: Cline treats terminal commands as either safe or requiring approval. “Execute safe commands” covers the first category. “Execute all commands” extends this to commands flagged as requiring approval.
- **Notifications**: If enabled, Cline sends OS-level notifications when approval is required, and when an auto-approved terminal command has been running for 30 seconds and may need attention.
<Note>
[YOLO mode](/features/yolo-mode) bypasses these granular approvals.
</Note>
- **Workspace vs outside workspace**: "Read all files" and "Edit all files" only extend the base toggle. If the base toggle is off, the "all files" option does nothing.
- **Terminal commands**: Cline treats commands as either safe or requiring approval. "Execute safe commands" covers safe commands. "Execute all commands" extends to commands flagged as requiring approval.
- **Notifications**: If enabled, Cline sends OS-level notifications when approval is required, and when an auto-approved terminal command has been running for 30 seconds.
## Permissions
These labels match what you see in the Auto Approve menu.
| Setting | What it allows | Notes |
|--------|-----------------|------|
| Read project files | Read files, list files, search in your workspace | Good default for most tasks |
| Read all files | Read files outside your workspace | Requires “Read project files” |
| Edit project files | Create and edit files in your workspace | Consider using checkpoints |
| Edit all files | Edit files outside your workspace | Requires “Edit project files” |
| Execute safe commands | Run terminal commands marked safe | Can still run long |
| Execute all commands | Run commands marked as requiring approval | Requires “Execute safe commands” |
| Use the browser | Allows use of the browser tool for web fetching and searching | Proxy issues can apply |
| Use MCP servers | Use MCP tools and access MCP resources | Some servers also have per-tool auto-approve |
| Enable notifications | Notifies you about long-running auto-approved commands | Accessible directly in the Auto Approve menu |
| Setting | What It Allows |
|---------|----------------|
| Read project files | Read files, list files, search in your workspace |
| Read all files | Read files outside your workspace (requires base toggle) |
| Edit project files | Create and edit files in your workspace |
| Edit all files | Edit files outside your workspace (requires base toggle) |
| Execute safe commands | Run terminal commands marked safe |
| Execute all commands | Run commands requiring approval (requires base toggle) |
| Use the browser | Browser tool for web fetching and searching |
| Use MCP servers | MCP tools and resources |
| Enable notifications | Notifies you about long-running commands |
<Warning>
Read all files and Edit all files only matter if their base toggle is enabled. They extend access outside your workspace.
"Read all files" and "Edit all files" only matter if their base toggle is enabled. They extend access outside your workspace.
</Warning>
<Card title="Networking & proxies" icon="globe" href="/troubleshooting/networking-and-proxies">
If browser-based tools fail in corporate networks, this page covers the common fixes.
</Card>
## Safe vs Approval-Required Commands
## Safe vs approval-required command examples
Cline does not use a fixed allowlist. The model marks each command with a `requires_approval` flag based on the command and arguments. These are examples, not guarantees.
Cline does not use a fixed allowlist of safe or unsafe commands. The model marks each command with a `requires_approval` flag based on the command and its arguments, and Auto Approve uses that flag.
These are examples, not guarantees.
### Commonly treated as safe
| Example | Why it is usually safe |
|--------|-------------------------|
| `npm run build` | Build output, no direct file deletions |
| `npm test` | Runs tests |
| `git status` | Read-only |
| `ls -la` | Read-only |
| `cat package.json` | Read-only |
### Commonly requires approval
| Example | Why it often needs approval |
|--------|------------------------------|
| `npm install <pkg>` | Modifies dependencies and lockfiles |
| `rm -rf <path>` | Deletes files |
| `mv <a> <b>` | Moves files (can overwrite) |
| `sed -i ...` | In-place file edits |
| `curl https://...` | Downloads and executes remote code |
<Note>
Whether a command is treated as safe depends on the exact command, flags, and the current task. When in doubt, keep command auto-approval off and approve commands manually.
</Note>
## Enable notifications
Auto-approved actions can run for a while, especially long terminal commands. If you enable notifications, Cline can notify you when an auto-approved command has been running for a while and may need attention.
The **Enable notifications** toggle is located at the bottom of the Auto Approve menu, below a separator line. This puts the notification setting right where you manage your auto-approval permissions, making it easy to discover and adjust.
**Commonly treated as safe:**
- `npm run build`, `npm test` - Build/test output
- `git status`, `ls -la`, `cat package.json` - Read-only commands
**Commonly requires approval:**
- `npm install <pkg>` - Modifies dependencies
- `rm -rf <path>` - Deletes files
- `mv <a> <b>` - Moves files (can overwrite)
- `sed -i ...` - In-place file edits
## Recommendations
A good default setup is:
A good default setup:
- Enable **Read project files**
- Leave **Edit project files**, **Execute safe commands**, **Use the browser**, and **Use MCP servers** off until you have a specific reason to enable them
- Leave edits, commands, browser, and MCP off until you have a specific reason
If you enable edits, use [Checkpoints](/features/checkpoints) so you can roll back quickly.
If you enable edits, use [Checkpoints](/core-workflows/checkpoints) so you can roll back quickly.
If youre working in a sensitive environment (production credentials, personal files, corporate devices), keep external file access and command execution locked down and approve actions manually as you go.
---
## YOLO Mode
YOLO mode is Auto Approve on steroids. Check the box and Cline auto-approves everything: file changes, terminal commands, browser actions, MCP tools, and mode transitions.
<Note>
**Warning: This is dangerous.** YOLO mode disables all safety checks. Cline executes whatever it decides without asking permission.
</Note>
### What Gets Auto-Approved
When YOLO mode is enabled:
- All file operations anywhere on your system
- All terminal commands including potentially destructive ones
- Browser actions
- MCP server tools
- Mode transitions (Plan to Act)
### When to Use YOLO Mode
**Rapid prototyping** where you want zero friction and don't care about potential mistakes. Perfect for throwaway experiments.
**Trusted, repetitive tasks** where you've validated Cline's approach and want to eliminate approval overhead.
**Demonstration purposes** where you want to show Cline's capabilities without interruptions.
### What Could Go Wrong
Cline could:
- Delete important files without warning
- Execute commands that modify system settings
- Make network requests to external services
- Overwrite configuration files
- Install or uninstall packages
- Commit and push changes to version control
### Best Practices for YOLO Mode
- **Start with isolated environments.** Use throwaway projects or sandboxed environments first.
- **Be specific with requests.** Vague instructions + unlimited permissions = unpredictable results.
- **Monitor the output.** Cline still shows what it's doing. Watch the terminal and file changes.
- **Keep version control handy.** Git becomes your safety net.
### Enabling YOLO Mode
Navigate to Cline Settings, then Features, and check "YOLO Mode." No confirmation dialogs. Once enabled, Cline auto-approves all actions immediately. Uncheck to disable.
+23 -34
View File
@@ -1,75 +1,64 @@
---
title: "Automatic Context Summarization"
title: "Auto Compact"
sidebarTitle: "Auto Compact"
description: "Automatic context summarization to keep working when approaching context limits."
---
When your conversation approaches the model's context window limit, Cline automatically summarizes it to free up space and keep working.
When your conversation approaches the model's context window limit, Cline automatically summarizes it to free up space and keep working.
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/condensing.png"
alt="Auto-compact feature condensing conversation context"
alt="Auto-compact condensing conversation context"
/>
</Frame>
## How It Works
Cline monitors token usage during your conversation. When you're getting close to the limit, he:
Cline monitors token usage during your conversation. When you're getting close to the limit, it:
1. Creates a comprehensive summary of everything that's happened
2. Preserves all the technical details, code changes, and decisions
2. Preserves all technical details, code changes, and decisions
3. Replaces the conversation history with the summary
4. Continues exactly where he left off
4. Continues exactly where it left off
You'll see a summarization tool call when this happens, showing the total cost like any other api call in the chat view.
You'll see a summarization tool call when this happens, showing the cost like any other API call.
## Why This Matters
Previously, Cline would truncate older messages when hitting context limits. This meant losing important context from earlier in the conversation.
Previously, Cline would truncate older messages when hitting context limits, losing important context.
Now with summarization:
- All technical decisions and code patterns are preserved
- File changes and project context remain intact
- Cline remembers everything he's done
- Cline remembers everything it's done
- You can work on much larger projects without interruption
<Tip>
Context Summarization synergizes beautifully with [Focus Chain](/features/focus-chain). When Focus Chain is enabled, todo lists persist across summarizations. This means Cline can work on long-horizon tasks that span multiple context windows while staying on track with the todo list guiding him through each reset.
Auto Compact works beautifully with [Focus Chain](/features/focus-chain). When Focus Chain is enabled, todo lists persist across summarizations. Cline can work on long-horizon tasks spanning multiple context windows while staying on track.
</Tip>
## Technical Details
The summarization happens through your configured API provider using the same model you're already using. It leverages prompt caching to minimize costs.
1. Cline uses a [summarization prompt](https://github.com/cline/cline/blob/main/src/core/prompts/contextManagement.ts) to request a summary of the conversation.
2. Once the summary is generated, Cline replaces the conversation history with a [continuation prompt](https://github.com/cline/cline/blob/main/src/core/prompts/contextManagement.ts#L69) that asks Cline to keep working and provides the summary as context.
Different models have different context window thresholds for when auto-summarization kicks in. You can see how thresholds are determined in [context-window-utils.ts](https://github.com/cline/cline/blob/main/src/core/context/context-management/context-window-utils.ts).
## Cost Considerations
Summarization leverages your existing prompt cache from the conversation, so it costs about the same as any other tool call.
Since most input tokens are already cached, you're primarily paying for the summary generation (output tokens), making it very cost-effective.
Since most input tokens are already cached, you're primarily paying for summary generation (output tokens), making it cost-effective.
## Restoring Context with Checkpoints
## Supported Models
You can use [checkpoints](/features/checkpoints) to restore your task state from before a summarization occurred. This means you never truly lose context - you can always roll back to previous versions of your conversation.
Auto Compact uses advanced LLM-based summarization for these models:
- Claude 4 series
- Gemini 2.5 series
- GPT-5
- Grok 4
<Note>
Editing a message before a summarization tool call will work similarly to a checkpoint, allowing you to restore the conversation to that point.
With other models, Cline falls back to standard rule-based context truncation, even if Auto Compact is enabled.
</Note>
## Next Generation Model Support
## Restoring Context
Auto Compact uses advanced LLM-based summarization which we've found works significantly better for next-generation models. We currently support this feature for the following models:
You can use [checkpoints](/core-workflows/checkpoints) to restore your task state from before a summarization occurred. You never truly lose context since you can always roll back.
- **Claude 4 series**
- **Gemini 2.5 series**
- **GPT-5**
- **Grok 4**
<Note>
When using other models, Cline automatically falls back to the standard rule-based context truncation method, even if Auto Compact is enabled in settings.
</Note>
Editing a message before a summarization tool call works similarly, restoring the conversation to that point.
-103
View File
@@ -1,103 +0,0 @@
---
title: "Checkpoints"
sidebarTitle: "Checkpoints"
---
Checkpoints automatically save snapshots of your workspace after each step in a task. This feature lets you track changes, roll back when needed, and experiment confidently with your code.
## How Checkpoints Work
Cline creates a checkpoint after each tool use (file edits, commands, etc.). These checkpoints:
- Work alongside your Git workflow without interference
- Maintain context between restores
- Use a shadow Git repository to track changes
For example, if you're working on a feature and Cline makes multiple file changes, each change creates a checkpoint. This means you can review each modification and, if needed, roll back to any point without affecting your main Git repository.
## Enabling or Disabling Checkpoints
Checkpoints are enabled by default in Cline. To toggle this feature:
1. Open the Cline settings by clicking the gear icon in the Cline panel
2. Go to "Feature Settings"
3. Toggle the **"Enable Checkpoints"** checkbox on or off
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/checkpoints.gif"
alt="Checkpoints toggle in settings"
/>
</Frame>
### When to Disable Checkpoints
While checkpoints provide valuable safety nets, you might want to disable them in certain situations:
- **Large repositories**: If you're working with very large codebases, checkpoints may use additional storage space
- **Performance concerns**: On systems with limited resources, disabling checkpoints can slightly improve performance
- **Simple tasks**: For quick, low-risk operations where rollback isn't needed
## Viewing Changes & Restoring
After each tool use, you can:
1. Click the "Compare" button to see modified files
2. Click the "Restore" button to open restore options
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(13).png"
alt="Checkpoint comparison and restore options"
/>
</Frame>
## Restore Options
To restore to a previous point:
1. Click the "Restore" button next to any step
2. Choose from three options:
- **Restore Task and Workspace**: Reset both codebase and task to that point
- **Restore Task Only**: Keep codebase changes but revert task context
- **Restore Workspace Only**: Reset codebase while preserving task context
Example: If Cline makes changes you don't like while styling a component, you can use "Restore Workspace Only" to revert the code changes while keeping the conversation context, allowing you to try a different approach.
<Frame caption="Reverting both codebase and task to before any changes were made to start fresh">
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/checkpointsDemo.gif" alt="Checkpoint restore demo" />
</Frame>
## Use Cases
Checkpoints let you be more experimental with Cline. While human coding is often methodical and iterative, AI can make substantial changes quickly. Checkpoints help you track these changes and revert if needed.
### Using Auto-Approve Mode
- Provides safety net for rapid iterations
- Makes it easy to undo unexpected results
### Testing Different Approaches
- Try multiple solutions confidently
- Compare different implementations
- Quickly revert to working states
- Ideal for exploring different design patterns or architectural approaches
## Best Practices
1. Use checkpoints as safety nets when experimenting
2. Leverage auto-approve mode more confidently, knowing you can always roll back
3. Restore selectively based on needs:
- Use "Restore Task and Workspace" for a fresh start
- Use "Restore Task Only" to try different prompts, but keep file changes
- Use "Restore Workspace Only" to attempt different implementations while preserving conversation context
## Relationship with Message Editing
The [message editing feature](/features/editing-messages) uses checkpoints under the hood when you select the "Restore All" option. This allows you to not only edit and resubmit your message but also restore your workspace to the state it was in at that point in the conversation.
## Deleting Checkpoints
You can delete all checkpoints by using the **"Delete All History"** button in the task history menu. Note that this will also delete all tasks. Checkpoints are stored in VS Code's globalStorage.
@@ -1,267 +0,0 @@
---
title: "Conditional Rules"
sidebarTitle: "Conditional Rules"
description: "Activate rules automatically based on which files you're working with"
---
Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files, keeping your context focused and relevant.
For an introduction to Cline Rules, see the [Overview](/features/cline-rules/overview).
- **Without conditionals**: every rule loads for every request.
- **With conditionals**, rules activate only when your current files match their defined scope.
For example, React component rules should appear when you're working with React components, not when you're editing Python or documentation.
## How It Works
Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules.
<Note>
When a conditional rule activates, you'll see a notification: **"Conditional rules applied: workspace:frontend-rules.md"**
</Note>
## Writing Conditional Rules
Add YAML frontmatter to the top of any rule file in your `.clinerules/` directory:
```yaml
---
paths:
- "src/components/**"
- "src/hooks/**"
---
# React Component Guidelines
When creating or modifying React components:
- Use functional components with React hooks
- Extract reusable logic into custom React hooks
- Keep components focused on a single responsibility
```
The `---` markers delimit the frontmatter. Everything after the closing `---` is your rule content.
### The `paths` Conditional
Currently, `paths` is the supported conditional. It takes an array of glob patterns:
```yaml
---
paths:
- "src/**" # All files under src/
- "*.config.js" # Config files in root
- "packages/*/src/" # Monorepo package sources
---
```
**Glob pattern syntax:**
- `*` matches any characters except `/`
- `**` matches any characters including `/` (recursive)
- `?` matches a single character
- `[abc]` matches any character in the brackets
- `{a,b}` matches either pattern
**Examples:**
| Pattern | Matches |
|---------|---------|
| `src/**/*.ts` | All TypeScript files under `src/` |
| `*.md` | Markdown files in root only |
| `**/*.test.ts` | Test files anywhere in the project |
| `packages/{web,api}/**` | Files in web or api packages |
| `src/components/*.tsx` | TSX files directly in components (not nested) |
### Behavior Details
**Multiple patterns**: A rule activates if any pattern matches any file in your context.
```yaml
---
paths:
- "frontend/**"
- "mobile/**"
---
# Activates when working in frontend OR mobile
```
**No frontmatter**: Rules without frontmatter are always active.
**Empty paths array**: `paths: []` means the rule never activates. Use this to temporarily disable a rule.
**Invalid YAML**: If frontmatter can't be parsed, Cline fails open: the rule activates with raw content visible to help debugging.
## What Counts as "Current Context"
Cline evaluates rules based on:
1. **Your message**: File paths mentioned in your prompt (e.g., "update `src/App.tsx`")
2. **Open tabs**: Files currently open in your editor
3. **Visible files**: Files visible in your active editor panes
4. **Edited files**: Files Cline has created, modified, or deleted during the task
5. **Pending operations**: Files Cline is about to edit
Conditional rules can activate on your first message, when relevant files are open, or mid-task when Cline starts working with matching files.
<Tip>
Be explicit about file paths in your prompts. "Update `src/services/user.ts`" reliably triggers path-based rules; "update the user service" may not.
</Tip>
## Practical Examples
Copy these patterns and adapt them to your project structure.
### Frontend vs Backend Rules
Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code, backend rules only load when working with API or service code.
```yaml
# .clinerules/frontend.md
---
paths:
- "src/components/**"
- "src/pages/**"
- "src/hooks/**"
---
# Frontend Guidelines
- Use Tailwind CSS for styling
- Prefer server components where possible
- Keep client components small and focused
```
```yaml
# .clinerules/backend.md
---
paths:
- "src/api/**"
- "src/services/**"
- "src/db/**"
---
# Backend Guidelines
- Use dependency injection for services
- All database queries go through repositories
- Return typed errors, not thrown exceptions
```
### Test File Rules
Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it.
```yaml
# .clinerules/testing.md
---
paths:
- "**/*.test.ts"
- "**/*.spec.ts"
- "**/__tests__/**"
---
# Testing Standards
- Use descriptive test names: "should [expected behavior] when [condition]"
- One assertion per test when possible
- Mock external dependencies, not internal modules
- Use factories for test data, not fixtures
```
### Documentation Rules
Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code.
```yaml
# .clinerules/docs.md
---
paths:
- "docs/**"
- "**/*.md"
- "**/*.mdx"
---
# Documentation Guidelines
- Use sentence case for headings
- Include code examples for all features
- Keep paragraphs short (3-4 sentences max)
- Link to related documentation
```
## Combining with Rule Toggles
Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely (it won't activate even if paths match). Toggle on to let it activate when conditions are met.
This provides two levels of control: manual toggles and automatic condition-based activation.
## Tips for Effective Conditional Rules
### Start Broad, Then Narrow
Begin with broader patterns and refine as you learn what works:
```yaml
# Start here
paths:
- "src/**"
# Then narrow down
paths:
- "src/features/auth/**"
```
### Use Descriptive Filenames
Name your rule files to indicate their scope:
```
.clinerules/
├── api-endpoints.md # Rules for API code
├── database-models.md # Rules for DB layer
├── react-components.md # Rules for React
└── universal.md # No frontmatter = always active
```
### Keep Universal Rules Separate
Put always-on rules (coding standards, project conventions) in files without frontmatter. Reserve conditional rules for context-specific guidance.
### Test Your Patterns
Not sure if a pattern matches? Create a simple test rule:
```yaml
---
paths:
- "your/pattern/here/**"
---
TEST: This rule should activate for your/pattern/here files.
```
Then work with a file in that path and check if you see the activation notification.
## Troubleshooting
**Rule not activating:**
- Check that file paths in your context match the glob pattern
- Verify the rule is toggled on in the rules panel
- Ensure YAML frontmatter has proper `---` delimiters
**Rule activating unexpectedly:**
- Review glob patterns: `**` is recursive and may match more than intended
- Check for open files that match the pattern
- File paths mentioned in your message also count as context
**Frontmatter showing in output:**
- YAML couldn't be parsed
- Check for syntax errors (unquoted special characters, improper indentation)
## Related
- [Cline Rules Overview](/features/cline-rules/overview) - Complete rules system guide
- [Skills](/features/skills) - Load instructions on demand with `/skill` command
- [Workflows](/features/slash-commands/workflows/index) - Define explicit task automation
- [@ Mentions](/features/at-mentions/overview) - Add files to context explicitly
- [Understanding Context Management](/prompting/understanding-context-management) - How Cline manages context window
-205
View File
@@ -1,205 +0,0 @@
---
title: "Cline Rules"
sidebarTitle: "Overview"
description: "Add persistent instructions and context to guide Cline's behavior"
---
Cline Rules provide system-level guidance for your projects. Rules persist across conversations, ensuring consistent behavior without repeating instructions in every chat.
## How It Works
Rules are loaded when Cline starts a task. Here's what happens:
**Loading order**: Cline checks for rules in this sequence:
1. `.clinerules/` folder (all `.md` files inside)
2. Single `.clinerules` file
3. `AGENTS.md` file
**Scope precedence**: Workspace rules override global rules when both define the same guidance.
**Multiple files**: When using a `.clinerules/` folder, all Markdown files are combined into one ruleset. Numeric prefixes (like `01-`, `02-`) control the order.
**Conditional activation**: Rules with YAML frontmatter activate only when you're working with matching files. See [Conditional Rules](/features/cline-rules/conditional-rules) for details.
## Supported Rule Files
Cline reads rules from multiple file formats in your workspace root, letting you share rules across different AI coding tools:
| File/Folder | Source | Notes |
|-------------|--------|-------|
| `.clinerules/` | Cline | Folder with `.md` files (recommended) |
| `.cursor/rules/` | Cursor | Folder with `.mdc` files |
| `.windsurf/rules` | Windsurf | Folder with multiple `md` files |
| `AGENTS.md` | Universal | Follows [agents.md](https://agents.md/) standard, searched recursively |
Cline prioritizes `.clinerules` when present. Other formats load only if no `.clinerules` exists (except `AGENTS.md`, which always searches subdirectories). All rules appear in the Rules popover where you can toggle them.
## Creating Rules
Click the `+` button in the Rules tab to create a new rule. This opens a file in your editor where you write your guidance.
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/cline-rules.png" alt="Create a Rule" />
</Frame>
When you save the file, it's stored in:
- **Workspace rules**: `.clinerules/` in your project root
- **Global rules**: Platform-specific location (see table below)
You can also use the [`/newrule` slash command](/features/slash-commands/new-rule) to have Cline generate a rule based on your description.
### Global Rules Location
| Operating System | Default Location |
|------------------|------------------|
| **Windows** | `Documents\Cline\Rules` |
| **macOS** | `~/Documents/Cline/Rules` |
| **Linux/WSL** | `~/Documents/Cline/Rules` or `~/Cline/Rules` |
<Note>
Linux/WSL users: Check both locations if you don't find global rules in `~/Documents/Cline/Rules`.
</Note>
## Managing Rules
The Rules popover (below the chat input) shows active rules and lets you toggle them on or off.
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/image%20(1).png" alt="Rules Popover" />
</Frame>
The popover displays:
- **Global rules**: From your user-level Rules directory
- **Workspace rules**: From `.clinerules/` in your project
Toggle any rule to enable or disable it. Disabled rules won't load, even if they match conditions.
## When to Use Rules
Rules work best for persistent project context:
- **Code standards**: Formatting preferences, naming conventions, project-specific patterns
- **Documentation requirements**: Where to add docs, what format to follow
- **Architecture decisions**: Design patterns, dependency rules, module boundaries
- **Team conventions**: PR processes, branch naming, commit message format
- **Technology constraints**: Required libraries, banned APIs, version requirements
Rules are less effective for:
- One-time instructions (just say it in the chat)
- Complex multi-step workflows (use [Workflows](/features/slash-commands/workflows/index) instead)
- Dynamic decisions that depend on runtime context
## Example Rule
```markdown
# Backend API Guidelines
## Route Handlers
- Use async/await, not callbacks
- Validate request bodies with Zod schemas
- Return typed errors from `src/errors.ts`
- All routes require authentication unless in `publicRoutes` array
## Database Access
- All queries go through repository classes in `src/repositories/`
- Use transactions for multi-table updates
- Never expose raw database errors to clients
## Testing
- Unit tests for business logic in `src/services/`
- Integration tests for route handlers in `src/routes/`
- Mock external APIs, not internal modules
```
This rule provides clear, actionable guidance without explaining obvious concepts or using vague language.
## Using a Folder Structure
For projects with many rules, organize them in a `.clinerules/` folder:
```
your-project/
├── .clinerules/
│ ├── 01-coding-standards.md
│ ├── 02-documentation.md
│ └── 03-testing.md
├── src/
└── ...
```
Cline loads all Markdown files in `.clinerules/` automatically. The numeric prefixes help you control ordering, but they're optional.
### Organizing a Rules Bank
Maintain a separate folder for rules you might need but don't always want active:
```
your-project/
├── .clinerules/ # Active rules
│ ├── 01-coding.md
│ └── client-a.md
├── clinerules-bank/ # Available but inactive
│ ├── clients/
│ │ ├── client-a.md
│ │ └── client-b.md
│ └── frameworks/
│ ├── react.md
│ └── vue.md
└── ...
```
Copy files from the bank to `.clinerules/` when you need them. This keeps your active context lean while maintaining a library of reusable guidance.
Switch contexts with simple file operations:
```bash
# Switch to Client B
rm .clinerules/client-a.md
cp clinerules-bank/clients/client-b.md .clinerules/
```
<Tip>
Consider git-ignoring `.clinerules/` while tracking `clinerules-bank/` so team members can activate the rules relevant to their current work.
</Tip>
## Conditional Rules
Scope rules to specific file patterns using YAML frontmatter. This keeps React guidance out of Python code and backend rules away from frontend work.
```yaml
---
paths:
- "src/components/**"
- "src/hooks/**"
---
# React Guidelines
Use functional components with hooks. Extract reusable logic into custom hooks.
```
This rule activates only when working with files matching those patterns. Read the [Conditional Rules guide](/features/cline-rules/conditional-rules) for pattern syntax, behavior details, and more examples.
## Tips for Effective Rules
**Be specific**: "Use async/await for all database calls" beats "write good async code."
**Show patterns**: Include file paths and real examples. "Follow the error handling in `src/utils/errors.ts`" gives Cline a concrete reference.
**Focus on outcomes**: Describe what you want, not step-by-step instructions. Let Cline figure out how.
**Test and refine**: Start with core standards. Add rules when you find yourself repeating the same feedback.
**Use conditional rules**: Load guidance only when relevant. This keeps context efficient and reduces noise.
## Related
- [Conditional Rules](/features/cline-rules/conditional-rules) - Activate rules based on file patterns
- [Skills](/features/skills) - Load instructions on demand with `/skill` command
- [Workflows](/features/slash-commands/workflows/index) - Define explicit task automation
- [New Rule Slash Command](/features/slash-commands/new-rule) - Generate rules with AI assistance
- [Plan and Act Mode](/features/plan-and-act) - Use different rules for planning vs execution
@@ -1,129 +0,0 @@
---
title: "Code Commands"
sidebarTitle: "Code Commands"
---
Cline's code commands bring AI assistance directly into your editor, letting you interact with your code without leaving your workflow. With a simple right-click, you can add code to Cline, and through the lightbulb menu, you can fix errors, get explanations, or improve your code.
## Available Code Commands
When you interact with code in your editor, you can access Cline commands in two ways:
### Right-Click Context Menu
When you right-click on selected code, you'll see:
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/code-commands.png" alt="Right Click Menu" />
</Frame>
#### Add to Cline
The "Add to Cline" command sends your selected code to the Cline chat panel. This is perfect for:
- Asking questions about specific code snippets
- Requesting improvements or optimizations
- Getting explanations of complex logic
When you use this command, Cline automatically includes:
- The file path (as a file mention)
- The selected code with proper formatting
- The programming language for accurate syntax highlighting
### Lightbulb Menu (Code Actions)
When you see a lightbulb icon in your editor, click it to access these Cline commands:
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/lightbulb-actions.png" alt="Lightbulb Menu" />
</Frame>
#### Fix with Cline
The "Fix with Cline" command appears in the lightbulb menu when your code has errors or warnings. This command:
1. Captures the selected code
2. Identifies the errors or warnings from VSCode's diagnostics
3. Sends both to Cline with a request to fix the issues
4. Provides a solution that addresses the specific problems
This is incredibly useful for quickly resolving syntax errors, linter warnings, or type issues without having to manually describe the problem.
#### Explain with Cline
The "Explain with Cline" command helps you understand complex code. When you select code and use this command from the lightbulb menu, Cline:
1. Analyzes the selected code
2. Provides a clear explanation of what the code does
3. Breaks down complex logic into understandable parts
4. Highlights important patterns or techniques used
#### Improve with Cline
The "Improve with Cline" command helps you enhance your code. When you select code and use this command from the lightbulb menu, Cline:
1. Analyzes the selected code for potential improvements
2. Suggests optimizations, refactorings, or better practices
3. Explains the reasoning behind the suggested changes
4. Provides improved code that maintains the original functionality
## How to Use Code Commands
Using Cline's code commands is simple:
### For Right-Click Commands:
1. Select the code you want to work with
2. Right-click to open the context menu
3. Choose "Add to Cline"
4. View the result in the Cline chat panel
### For Lightbulb Menu Commands:
1. Select the code you want to work with
2. Look for the lightbulb icon that appears in the editor gutter
3. Click the lightbulb to see available actions
4. Choose the appropriate Cline command (Fix, Explain, or Improve)
5. View the result in the Cline chat panel
After using any command, you can:
- Ask follow-up questions
- Request modifications to the solution
- Apply the changes back to your code
## How It Works Under the Hood
When you use a code command, here's what happens behind the scenes:
1. **Code Selection**: The extension captures your selected code and its context
2. **Metadata Collection**: Cline gathers important metadata:
- File path and name
- Programming language
- Any associated diagnostics (errors/warnings)
- Surrounding code context when relevant
3. **Command Processing**:
- For "Add to Cline," the code is formatted and sent to the chat panel
- For "Fix with Cline," the code and diagnostics are analyzed and a fix is generated
- For "Explain with Cline," the code is analyzed to provide a clear explanation
- For "Improve with Cline," the code is analyzed for potential optimizations and improvements
4. **Integration with Chat**: The results appear in the Cline chat panel, where you can:
- See the AI's response
- Ask follow-up questions
- Apply suggested changes
This seamless integration between your editor and Cline's AI capabilities makes it easy to get assistance without disrupting your coding flow.
## Tips for Effective Use
- **Select complete logical units**: When possible, select entire functions, classes, or modules to give Cline complete context
- **Include imports**: For language-specific help, include relevant imports so Cline understands dependencies
- **Combine with @ mentions**: For complex issues, use code commands along with file or problem mentions for more context
- **Use keyboard shortcuts**: Speed up your workflow by [assigning keyboard shortcuts](/features/commands-and-shortcuts/keyboard-shortcuts) to common code commands
Next time you're struggling with a piece of code, try using Cline's code commands instead of switching to a separate chat interface. You'll be amazed at how much more efficient your workflow becomes when AI assistance is integrated directly into your editor.
@@ -1,71 +0,0 @@
---
title: "Generate Commit Message"
sidebarTitle: "Generate Commit Message"
---
Cline's Git integration brings AI assistance directly to your version control workflow. Generate commit messages without leaving your editor.
## Generate Commit Message
One of the most useful Git integrations is the ability to automatically generate meaningful commit messages:
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/generate-commit-message-with-cline.png"
alt="Generate Commit Message with Cline"
/>
</Frame>
1. Make your changes and stage them in Git
2. Click the robot icon in the Source Control view or run the "Generate Commit Message with Cline" command
3. Cline analyzes your changes and generates a descriptive commit message
4. The message is automatically inserted into the commit message input box
The generated commit messages:
- Start with a concise summary (50-72 characters)
- Use imperative mood (e.g., "Add feature" not "Added feature")
- Describe what was changed and why
- Follow Git best practices
This feature saves time and ensures your commit history is consistent and informative.
<Tip>
For information about using `@git-changes` and `@[commit-hash]` mentions in your chat messages, see the [Git
Mentions](/features/at-mentions/git-mentions) documentation.
</Tip>
## How It Works
When you use Cline's commit message generation feature, here's what happens behind the scenes:
1. Cline retrieves the current Git diff using `getWorkingState()`
2. It formats this diff into a specialized prompt for the AI
3. The AI analyzes the changes and generates an appropriate commit message
4. The message is extracted and inserted into the Git commit message input box
This process uses your current Cline API configuration, so the quality of the generated messages matches your chosen AI model.
## Tips for Effective Use
- **Generate commit messages for complex changes**: The AI excels at summarizing multiple related changes into a coherent message.
- **Review and edit generated messages**: While the AI generates high-quality messages, it's always good practice to review and adjust them if needed.
- **Stage related changes together**: For the best results, stage related changes together so the AI can generate a cohesive message.
- **Use for consistent commit history**: Using the generate commit message feature helps maintain a consistent style across your commit history.
## How It Works Under the Hood
The commit message generation leverages VSCode's Git extension API to access repository information:
1. When you trigger the command:
- Cline gets the current diff
- It sends this to the AI with specific instructions for commit message formatting
- It parses the AI's response
- It accesses the Git extension API to set the commit message
This integration with Git makes it easy to generate high-quality commit messages without disrupting your workflow.
Next time you're struggling to write a good commit message, try using Cline's commit message generation. You'll save time and improve your version control workflow with AI assistance right where you need it.
@@ -1,204 +0,0 @@
---
title: "Keyboard Shortcuts"
sidebarTitle: "Keyboard Shortcuts"
---
Speed up your workflow by accessing Cline's AI assistance without taking your hands off the keyboard.
<Tip>
**The One Shortcut You Need:** `Ctrl+'` (Windows/Linux) or `Cmd+'` (macOS)
This context-aware shortcut handles your most common needs:
- **With text selected:** Adds code to Cline chat
- **Without selection:** Focuses the chat input
Master this one shortcut, and you're 90% there.
</Tip>
## Default Shortcuts
Cline has minimal default shortcuts by design, so they won't conflict with your existing VSCode setup:
| Shortcut | Windows/Linux | macOS | What It Does |
| -------- | ------------- | ----- | ------------ |
| **Add to Chat / Focus Input** | `Ctrl+'` | `Cmd+'` | Context-aware: adds selected code or focuses chat |
That's it! Everything else is available for you to customize.
## Quick Workflow Examples
Here's how keyboard shortcuts fit into real coding workflows:
### Debug & Fix Workflow
1. **Find error in code** → VSCode highlights it
2. **Select the problematic code** → `Shift+Arrow` or `Ctrl+L` / `Cmd+L`
3. **Send to Cline** → `Ctrl+'` / `Cmd+'`
4. **Ask for help** → Type your question, hit `Enter`
### Code Review Workflow
1. **Review a function** → Select it with `Ctrl+L` / `Cmd+L`
2. **Get AI review** → `Ctrl+'` / `Cmd+'` then ask "Review this"
3. **Iterate** → Apply suggestions and repeat
### Terminal Integration Workflow
1. **Open terminal** → Press `` Ctrl+` `` / `` Cmd+` ``
2. **Run your command** → Execute in terminal
3. **Capture output** → Press `Alt+T` (after assigning shortcut)
4. **Get help** → Ask Cline to interpret errors or output
<Info>
**Pro Tip:** Assign `Alt+T` to the `cline.addTerminalOutputToChat` command for quick terminal output capture. Without a shortcut, you can still right-click in the terminal and select "Add to Cline" - but the keyboard approach is much faster for frequent debugging workflows.
</Info>
## Customizing Shortcuts
Want to assign shortcuts to more Cline commands? Here's how:
**Step 1:** Open VSCode's Keyboard Shortcuts editor
- Press `Ctrl+K Ctrl+S` (Windows/Linux) or `Cmd+K Cmd+S` (macOS)
- Or: **File → Preferences → Keyboard Shortcuts**
**Step 2:** Search for "Cline"
**Step 3:** Click the ✏️ icon next to any command
**Step 4:** Press your desired key combo, then `Enter`
<Warning>
**Avoid Conflicts:** Check that your shortcut doesn't override important VSCode commands. The shortcuts editor will warn you about conflicts.
</Warning>
## Available Commands Reference
<Accordion title="Task Management Commands">
These commands help you navigate and manage Cline tasks:
| Command ID | Description | Suggested Shortcut |
| ---------- | ----------- | ------------------ |
| `cline.plusButtonClicked` | Start a new task | `Ctrl+Shift+N` / `Cmd+Shift+N` |
| `cline.historyButtonClicked` | Open task history | `Ctrl+Shift+H` / `Cmd+Shift+H` |
| `claude-dev.SidebarProvider.focus` | Open Cline sidebar | `Ctrl+Shift+L` / `Cmd+Shift+L` |
**Note:** `claude-dev` prefix is for historical reasons - it works with Cline.
</Accordion>
<Accordion title="Code Interaction Commands">
Work directly with your code:
| Command ID | Description | Suggested Shortcut |
| ---------- | ----------- | ------------------ |
| `cline.addToChat` | Add selected code to chat | `Ctrl+'` / `Cmd+'` ⭐ (default) |
| `cline.focusChatInput` | Focus chat input | `Ctrl+'` / `Cmd+'` ⭐ (default) |
| `cline.explainCode` | Explain selected code | `Ctrl+Shift+E` / `Cmd+Shift+E` |
| `cline.improveCode` | Suggest code improvements | `Ctrl+Shift+I` / `Cmd+Shift+I` |
⭐ These share the same shortcut - it's context-aware!
</Accordion>
<Accordion title="Terminal Integration Commands">
Connect Cline with your terminal:
| Command ID | Description | Suggested Shortcut |
| ---------- | ----------- | ------------------ |
| `cline.addTerminalOutputToChat` | Add terminal output to Cline | `Alt+T` |
**Tip:** Use this after running commands to get help interpreting output or fixing errors.
</Accordion>
<Accordion title="Git Integration Commands">
Generate commit messages with AI:
| Command ID | Description | Suggested Shortcut |
| ---------- | ----------- | ------------------ |
| `cline.generateGitCommitMessage` | Generate commit message | `Ctrl+Shift+G` / `Cmd+Shift+G` |
| `cline.abortGitCommitMessage` | Stop generation | `Ctrl+Shift+Esc` / `Cmd+Shift+Esc` |
</Accordion>
<Accordion title="Settings & Configuration Commands (Advanced)">
These commands open Cline's configuration panels. Most users access these via the sidebar buttons, but keyboard shortcuts can be useful for:
- **Frequent MCP server developers** who constantly adjust server configurations
- **Demo/presentation scenarios** where you need quick, keyboard-only navigation
- **Accessibility workflows** where mouse usage is minimized
| Command ID | Description | Suggested Shortcut |
| ---------- | ----------- | ------------------ |
| `cline.settingsButtonClicked` | Open Cline settings | `Ctrl+Alt+,` / `Cmd+Opt+,` |
| `cline.mcpButtonClicked` | Open MCP servers config | `Ctrl+Alt+M` / `Cmd+Opt+M` |
| `cline.accountButtonClicked` | Open account settings | `Ctrl+Alt+A` / `Cmd+Opt+A` |
| `cline.openWalkthrough` | Open walkthrough guide | (not recommended) |
**Our take:** Unless you're constantly tweaking settings or building MCP servers, the sidebar buttons are more convenient. But if you find yourself opening these panels frequently, shortcuts can save time.
</Accordion>
## What About "Fix with Cline"?
<Warning>
**You CAN'T assign a keyboard shortcut to "Fix with Cline"**
This command only appears in the **lightbulb menu** (💡) when VSCode detects errors in your code. It needs the error context to work, so it's not available as a standalone command.
**Workarounds:**
- Click the 💡 lightbulb icon that appears next to errors
- Or select code with errors and use `Ctrl+'` / `Cmd+'` to ask Cline to fix them
- Or right-click and select "Add to Cline"
</Warning>
Learn more about code actions in our [Code Commands documentation](/features/commands-and-shortcuts/code-commands).
## Best Practices
<Tip>
**Start Simple**
Don't try to memorize 20 shortcuts on day one. Start with:
1. `Ctrl+'` / `Cmd+'` (the essential one)
2. Add 1-2 more based on your actual usage patterns
3. Build muscle memory over time
</Tip>
**Choose Shortcuts Wisely:**
- **Be ergonomic:** Use comfortable key combinations
- **Create patterns:** Group related commands (e.g., all Cline shortcuts use `Ctrl+Shift+...`)
- **Avoid conflicts:** Don't override VSCode essentials like `Ctrl+C` or `Ctrl+S`
- **Use modifiers:** Combine `Ctrl`/`Cmd` + `Shift` + `Alt` to reduce conflicts
**Build the Habit:**
- Use shortcuts consistently for a week to build muscle memory
- Keep a note of your custom shortcuts until they're automatic
- Review monthly to see if your workflow has changed
## Discovering Commands
Not sure what commands are available? Use VSCode's Command Palette:
1. Press `Ctrl+Shift+P` / `Cmd+Shift+P`
2. Type "Cline" to filter
3. Browse all available commands
4. Assign shortcuts to your favorites
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/editor-integration.png"
alt="Editor Integration Overview"
/>
</Frame>
---
<Info>
**Remember:** The goal isn't to memorize every possible shortcut. Master `Ctrl+'` / `Cmd+'` first, then gradually add shortcuts for commands you use frequently. Quality over quantity!
</Info>
@@ -1,65 +0,0 @@
---
title: "Commands & Shortcuts Overview"
sidebarTitle: "Overview"
---
Cline integrates directly into VSCode's interface, letting you access AI assistance without disrupting your workflow. These integrations appear as commands in context menus, keyboard shortcuts, and quick fixes throughout the editor.
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/editor-integration.png"
alt="Editor Integration Overview"
/>
</Frame>
### What are Editor Integrations?
Editor integrations are commands and shortcuts that let you use Cline right where you're working. Instead of switching to the Cline panel first, you can select code, right-click, and immediately send it to Cline for help.
These integrations appear in different places throughout VSCode:
- In the editor context menu (right-click menu) - "Add to Cline"
- In the terminal context menu - "Add to Cline"
- In the Source Control view - "Generate Commit Message"
- As keyboard shortcuts - Various Cline commands
- As Quick Fix options (lightbulb menu) - "Fix with Cline", "Explain with Cline", "Improve with Cline"
### Available Editor Integrations
Cline offers several editor integrations, each designed to enhance different aspects of your development workflow:
<Columns cols={2}>
<Card title="Code Commands" icon="code" href="/features/commands-and-shortcuts/code-commands">
Right-click on code to add it to Cline, or use the lightbulb menu to fix errors, explain code, or improve it. Cline sees the complete code context, including imports and surrounding functions.
</Card>
{" "}
<Card title="Terminal Integration" icon="terminal" href="/features/commands-and-shortcuts/terminal-integration">
Add terminal output to Cline with a right-click or use `@terminal` mentions. Perfect for debugging build errors, test
failures, or runtime issues.
</Card>
{" "}
<Card title="Git Integration" icon="code-branch" href="/features/commands-and-shortcuts/git-integration">
Generate commit messages, explain diffs, or analyze changes with Cline's Git integration. Cline understands your version
control context.
</Card>
{" "}
<Card title="Keyboard Shortcuts" icon="keyboard" href="/features/commands-and-shortcuts/keyboard-shortcuts">
Speed up your workflow with keyboard shortcuts for common Cline actions. Quickly add code to chat, fix errors, or improve your code.
</Card>
</Columns>
### How They Work
When you use these commands, Cline:
- Captures the relevant context (selected code, file path, terminal output, etc.)
- Focuses the Cline interface
- Creates a conversation with the captured context
- In some cases, automatically generates a suggested prompt
Behind the scenes, these commands use VSCode's extension API to register commands, access editor state, and control VSCode's interface.
@@ -1,98 +0,0 @@
---
title: "Terminal Integration"
sidebarTitle: "Terminal Integration"
---
Cline's terminal integration lets you bring your terminal output directly into your conversations with Cline. Instead of copying and pasting error messages or command results, you can send them to Cline with a simple right-click in the terminal.
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/terminal-integration.png"
alt="Terminal Integration"
/>
</Frame>
## Right-Click Terminal Integration
When you're working in the VSCode terminal and see output you want to discuss with Cline:
1. Right-click in the terminal
2. Select "Add to Cline" from the context menu
3. The terminal output is immediately sent to the Cline chat panel
This is perfect for:
- Debugging build errors
- Understanding test failures
- Analyzing command output
- Getting help with error messages
The right-click terminal integration is especially useful when you're already working in the terminal and encounter an issue.
Instead of switching context to the Cline chat panel and typing a description of the problem, you can send the terminal output directly to Cline with just a couple of clicks.
Alternatively, you can use the [`@terminal`](/features/at-mentions/terminal-mentions) mention to send the full terminal output to Cline.
<Tip>
For information about using `@terminal` mentions in your chat messages, see the [Terminal
Mentions](/features/at-mentions/terminal-mentions) documentation.
</Tip>
## How Terminal Integration Works
When you use the right-click terminal integration, Cline:
1. Captures the terminal output with all formatting preserved
2. Includes the complete context, including command history and results
3. Formats it appropriately for the AI to understand
4. Enables the AI to see exactly what you're seeing
This gives Cline the full context it needs to provide accurate help with terminal-related issues.
## Behind the Scenes
The terminal integration uses a clever technique to capture terminal output:
1. When you trigger the integration, Cline:
- Temporarily saves your current clipboard content
- Selects all terminal content (or uses your existing selection)
- Copies it to the clipboard
- Reads the clipboard to get the terminal content
- Restores your original clipboard content
2. The terminal content is then:
- Formatted with proper syntax highlighting
- Added to your message or sent as a new message
- Enhanced with additional context when needed
This approach ensures that all terminal output, including colors and formatting, is accurately captured without affecting your clipboard.
## Tips for Effective Use
- **Use terminal integration for error messages**: When you encounter an error in the terminal, sending it to Cline often results in faster resolution than trying to describe the error.
- **Select specific output when needed**: By default, the integration captures all terminal content, but you can also select specific lines before right-clicking to focus on just the relevant output.
- **Combine terminal outputs with file mentions**: After sending terminal output to Cline, you can enhance your question by mentioning relevant files using the @ mentions feature.
- **Contextualize build & test outputs with the terminal**: Terminal integration is particularly useful for understanding complex build errors or test failures that span multiple lines.
Next time you're staring at a cryptic error message in your terminal, try using Cline's terminal integration instead of copying and pasting. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
## Troubleshooting Terminal Issues
If you're experiencing issues with terminal integration, such as "Shell Integration Unavailable" or commands not showing output, please refer to our comprehensive [Terminal Integration Troubleshooting Guide](/troubleshooting/terminal-integration-guide).
The troubleshooting guide covers:
- Common terminal integration issues and quick fixes
- Platform-specific solutions for Windows, macOS, and Linux
- Shell-specific configurations for zsh, bash, PowerShell, and more
- Advanced debugging techniques
- Terminal settings optimization
<Tip>
**Quick Fix**: Most terminal issues can be resolved by switching to bash in the Cline settings and increasing the shell
integration timeout to 10 seconds.
</Tip>
@@ -1,79 +0,0 @@
---
title: "Disable Terminal Pagers During Cline Sessions"
description: "Make CLI output non-interactive when Cline runs commands by detecting the CLINE_ACTIVE environment variable and disabling pagers like less."
---
Many CLI tools (like Git) use a pager such as `less` for interactive, scrollable output. When Cline runs commands in your terminal, that interactivity gets in the way — the pager can pause on the first page and block progress. You can configure your shell so that when a terminal is spawned by Cline, pagers are disabled and output streams through normally.
## How it works
Cline sets an environment variable for terminals it opens to run commands:
- `CLINE_ACTIVE` — non-empty when the shell is running under Cline
You can detect this variable in your shell startup file and adjust environment variables or aliases only for Cline-run sessions. This keeps your normal interactive terminals unchanged.
## Quick setup (Zsh/Bash)
Add the following to your `~/.zshrc`, `~/.bashrc`, or `~/.bash_profile`:
```bash
# Disable pagers when the terminal is launched by Cline
if [[ -n "$CLINE_ACTIVE" ]]; then
export PAGER=cat
export GIT_PAGER=cat
export SYSTEMD_PAGER=cat
export LESS="-FRX"
fi
```
<Note>
- `PAGER=cat` ensures generic pager-aware tools print directly to stdout
- `GIT_PAGER=cat` prevents Git from invoking `less`
- `SYSTEMD_PAGER=cat` disables paging in systemd tools (if present)
- `LESS="-FRX"` makes `less` behave more like streaming output if a tool still calls it
</Note>
This configuration only applies when `CLINE_ACTIVE` is set, so your normal terminals keep their usual interactive behavior.
## Verify
- Open a task in Cline that runs terminal commands and check:
- `echo "$CLINE_ACTIVE"` prints a non-empty value
- `git log` or other long outputs should stream without pausing
- If changes don't take effect:
- Make sure you updated the correct startup file for your shell
- Restart VS Code/Cursor so integrated terminals reload your shell config
- Confirm your terminal profile sources your `~/.zshrc` or `~/.bashrc`
## Optional tweaks
- Prefer command-line options when you don't want to rely on env vars:
```bash
# One-off usage (no aliases)
git --no-pager log -n 50 --decorate --oneline
systemctl --no-pager status nginx
journalctl --no-pager -u nginx -n 200
less -FRX README.md
```
- You can also override paging via shell aliases scoped to Cline sessions using options rather than env vars:
```bash
if [[ -n "$CLINE_ACTIVE" ]]; then
# Make 'less' non-interactive by default
alias less='less -FRX'
# Disable paging for common tools via CLI flags
alias git='command git --no-pager'
alias systemctl='command systemctl --no-pager'
alias journalctl='command journalctl --no-pager'
fi
```
- If you prefer environment variables, many CLIs also respect a generic or tool-specific pager variable:
- Git: `GIT_PAGER=cat`
- Systemd: `SYSTEMD_PAGER=cat`
- Man pages: `MANPAGER=cat` (not typically needed for Cline-driven commands)
- Aliases affect the current interactive shell, while environment variables propagate to child processes. Choose the approach that best fits your workflow.
@@ -1,60 +0,0 @@
---
title: "Opening Cline in the Right Sidebar"
description: "Learn how to open Cline in the right sidebar in VS Code and Cursor"
---
By default, when you first install Cline, it appears in VS Code's left sidebar alongside your file explorer and other extensions. However, for a better coding experience, we recommend moving Cline to the right sidebar. This allows you to keep your project files visible in the left sidebar while chatting with Cline on the right, giving you full visibility of your codebase as Cline works on your project.
## VS Code
To open Cline in the right sidebar:
<Steps>
<Step title="Align Extension View">
Make sure your extension view is aligned vertically to the left
</Step>
<Step title="Open Right Side View">
Click the button that opens the right side panel in VS Code (typically used to open GitHub Copilot chat). Optionally use the `Option + CMD/Ctrl + B` shortcut.
</Step>
<Step title="Drag Cline Icon">
Drag the Cline icon over to the nav panel at the top of that right view
</Step>
</Steps>
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/vscode_right_view.gif"
alt="VS Code Right Sidebar Setup"
/>
</Frame>
## Cursor
To open Cline in the right sidebar:
<Steps>
<Step title="Align Extensions">
Cursor uses a horizontal activity bar by default to optimize space for the AI chat interface ([see here for details](https://cursor.com/docs/configuration/migrations/vscode#activity-bar-orientation)). To switch to vertical:
1. Open the Command Palette (`CMD/Ctrl + Shift + P`)
2. Search for "Preferences: Open Settings (UI)"
3. Search for `workbench.activityBar.orientation`
4. Set the value to `vertical`
5. Restart Cursor for the changes to take effect
</Step>
<Step title="Open the AI Pane">
Click the Cursor cube icon button (AI Pane) that opens Cursor's agent (right side view panel)
</Step>
<Step title="Drag Cline to the AI Pane Sidebar">
Drag the Cline icon directly into the AI Pane sidebar.
</Step>
</Steps>
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/Cursor-sidebar.gif"
alt="Cursor Right Sidebar Setup"
/>
</Frame>
Once set up, Cline will load on the right side and you can use it as normal.
+129
View File
@@ -0,0 +1,129 @@
---
title: "Deep Planning"
sidebarTitle: "Deep Planning"
description: "Transform Cline into a meticulous architect who investigates your codebase and creates comprehensive implementation plans."
---
Deep Planning (`/deep-planning`) turns Cline into an architect before it becomes a builder. Instead of jumping straight into code, Cline systematically explores your codebase, asks targeted questions, and produces a detailed implementation plan — all before writing a single line.
<Tip>
**When should you use this?** Use `/deep-planning` for features that touch multiple files, architectural changes, complex integrations, or any task where "just start coding" would lead to rework.
</Tip>
## How It Works
Deep Planning follows a four-step process:
<Steps>
<Step title="Silent Investigation">
Cline explores your codebase without asking you anything. It reads relevant files, traces dependencies, examines patterns, and builds a mental model of how your project is structured. You'll see Cline reading files and running searches during this phase.
This step is intentionally silent — Cline gathers context first so it can ask better questions next.
</Step>
<Step title="Discussion">
Based on what it learned, Cline asks you targeted, specific questions about your requirements and preferences. These aren't generic questions — they're informed by what Cline found in your code.
For example, instead of asking "how should authentication work?", Cline might ask "I see you're using JWT tokens in `auth/middleware.ts` with refresh token rotation. Should the new endpoint follow the same pattern, or do you want session-based auth for this feature?"
Answer these questions to shape the plan. The more specific you are, the better the implementation plan will be.
</Step>
<Step title="Plan Creation">
Cline generates a comprehensive `implementation_plan.md` file in your project. This plan typically includes:
- **Overview** of the feature and its scope
- **File-by-file changes** with specific descriptions of what to add, modify, or remove
- **Dependencies** between changes (what needs to happen first)
- **Edge cases** and error handling considerations
- **Testing strategy** for the implementation
The plan is saved as a markdown file you can review, edit, and share with your team before any code is written.
</Step>
<Step title="Task Creation">
After you approve the plan, Cline creates a new task with the implementation steps loaded as trackable items. This gives you a clean context window focused entirely on execution, with the plan serving as the roadmap.
</Step>
</Steps>
## Using Deep Planning
### Invoking It
Type `/deep-planning` in the Cline chat input, followed by a description of what you want to build:
```
/deep-planning Add a notification system that sends email and in-app
notifications when users receive comments on their posts
```
The more context you provide upfront, the more focused the investigation phase will be. Include:
- What you want to build
- Any constraints or preferences
- Which parts of the codebase are relevant (if you know)
### Reviewing the Plan
Once Cline generates `implementation_plan.md`, review it carefully:
1. **Check the scope** — Does it cover everything you need? Is anything missing?
2. **Verify the approach** — Does the technical approach match your preferences?
3. **Review the order** — Are dependencies handled correctly?
4. **Edit if needed** — It's a markdown file. Change anything that doesn't look right.
Tell Cline about any adjustments before proceeding to implementation.
## Model-Specific Optimization
The deep planning prompt is optimized for each model family. Cline adapts its investigation and planning approach based on the strengths of whatever model you're using — whether that's Claude, GPT, Gemini, DeepSeek, or others.
This means you get effective deep planning regardless of your model choice, though stronger reasoning models will generally produce more thorough plans.
<Tip>
Consider using a stronger reasoning model for the planning phase and a faster model for implementation. You can configure separate models for Plan and Act modes in Cline Settings. See [Plan & Act Mode](/core-workflows/plan-and-act#using-different-models-for-each-mode) for details.
</Tip>
## Pairing with Other Features
Deep Planning works well with several other Cline features:
| Feature | How It Helps |
|---------|-------------|
| [Focus Chain](/features/focus-chain) | Tracks implementation progress against the plan with a visible todo list |
| [Memory Bank](/features/memory-bank) | Preserves project context across sessions so deep planning has richer input |
| [Plan & Act Mode](/core-workflows/plan-and-act) | Use Plan mode for quick exploration, deep planning for thorough architecture |
| [Checkpoints](/core-workflows/checkpoints) | Roll back implementation steps if something goes wrong during execution |
<Tip>
A powerful workflow: run `/deep-planning` to create the plan, enable [Focus Chain](/features/focus-chain) to track progress, then let Cline implement step by step. You get architecture-level thinking with granular progress visibility.
</Tip>
## Deep Planning vs Plan Mode
Both involve thinking before doing, but they serve different purposes:
| | Plan Mode | Deep Planning |
|---|-----------|---------------|
| **Scope** | Quick exploration and discussion | Thorough codebase investigation |
| **Output** | Conversation context | `implementation_plan.md` file |
| **Best for** | Medium tasks, understanding code | Large tasks, multi-file features |
| **Duration** | Minutes | Longer — depends on codebase size |
| **Persistence** | Lives in conversation history | Saved as a file you can reference later |
For most development work, starting in Plan mode is sufficient. Reserve `/deep-planning` for tasks where you'd normally spend significant time planning on a whiteboard before coding.
## Tips
- **Be specific in your initial prompt.** "Add authentication" gives a vague plan. "Add OAuth2 authentication with Google and GitHub providers, using our existing user model in `models/user.ts`" gives a focused one.
- **Point Cline at relevant files.** Use `@` mentions to highlight key files in your prompt so the investigation phase starts in the right place.
- **Edit the plan before implementing.** The generated plan is a starting point. Adjust priorities, remove unnecessary steps, or add details before Cline starts coding.
- **Save plans for reference.** The `implementation_plan.md` file is useful documentation even after the feature is built. Consider committing it or moving it to a docs folder.
- **Use for onboarding.** Run `/deep-planning` on a feature you're unfamiliar with to get Cline to map out the codebase and explain how things connect.
## Related
- [Plan & Act Mode](/core-workflows/plan-and-act) — Cline's dual-mode system for structured development
- [Focus Chain](/features/focus-chain) — Automatic todo list tracking for long-running tasks
- [Memory Bank](/features/memory-bank) — Structured documentation for cross-session context
- [Using Commands](/core-workflows/using-commands) — All available slash commands
+28 -132
View File
@@ -1,152 +1,48 @@
---
title: "Dictation"
description: "Communicate with Cline using your voice for faster, more natural AI collaboration"
title: "Dictation (Deprecated)"
description: "Voice input feature has been removed from Cline"
---
Dictation transforms how you work with AI. Instead of typing out complex thoughts, you speak naturally and share your complete intent. This isn't just about speed - though voice is faster - it's about enabling fluid collaboration that typing can't match.
# Dictation Feature Removed
## Why Voice Changes Everything
The dictation (voice-to-text) feature has been removed from Cline as of this release.
When you type, you edit yourself. You simplify complex ideas, skip context, and lose nuance. When you speak, you share everything on your mind - the full problem, the constraints, the edge cases you're worried about.
## What Happened?
Use Dictation constantly in [Plan mode](/features/plan-and-act) for rapid back-and-forth discussions. Instead of typing careful, structured prompts, think about a problem. Cline asks clarifying questions, respond immediately, and iterate until having a solid plan.
The voice input feature that allowed you to speak to Cline instead of typing has been discontinued and is no longer available in the extension.
The friction of typing was holding back real collaboration. Voice removes that friction.
## Alternative Workflows
## Getting Started
While the built-in dictation feature is no longer available, you can still work efficiently with Cline using these approaches:
**Enable Dictation:**
1. Go to Settings → Features → Dictation
2. Toggle "Enable Dictation" on
3. Sign into your Cline account when prompted
4. Install FFmpeg if you haven't already (Cline will guide you)
### 1. System-Level Voice Input
Once enabled, you'll see a microphone button in the chat input area.
Both macOS and Windows offer built-in dictation features that work across all applications:
**Using Dictation:**
- Click the microphone button to start recording
- Speak naturally
- Click again to stop recording
- Wait for transcription to appear in the chat
- **macOS**: Press `Fn` twice (or `Fn Fn`) to activate dictation in any text field
- **Windows**: Press `Windows + H` to open voice typing
- **Linux**: Various desktop environments offer voice input through accessibility features
<Tip>
Dictation works with any AI model you've configured. The transcription happens through Cline's service, but your conversation continues with whatever model you're using.
</Tip>
These system-level tools will work in Cline's chat input just like any other text field.
## System Requirements
### 2. Copy-Paste from Voice Notes
<Note>
Dictation is currently not available on Windows. Support for Windows is planned for a future release.
</Note>
If you prefer to think out loud:
1. Use your phone's voice recorder or a voice memo app
2. Transcribe using your preferred tool (many phones have built-in transcription)
3. Copy and paste the transcribed text into Cline
Dictation uses FFmpeg to capture your voice across all platforms:
### 3. Third-Party Transcription Tools
- **macOS**: FFmpeg (via Homebrew: `brew install ffmpeg`)
- **Linux**: FFmpeg (via apt: `sudo apt-get install ffmpeg`)
Many standalone transcription tools can be used alongside Cline:
- Browser-based transcription services
- Desktop transcription applications
- AI-powered note-taking apps with transcription features
If you don't have FFmpeg installed, Cline will automatically detect this and prompt you to install it with a single click.
## Why Was It Removed?
## Where Dictation Shines
The dictation feature was removed to streamline Cline's core functionality and focus development efforts on the primary AI assistance capabilities.
### Plan Mode Conversations
## Questions?
Dictation is perfect for [Plan mode](/features/plan-and-act) discussions. Instead of carefully crafting prompts, you can:
- Dictate your entire problem context in one go
- Respond to Cline's questions immediately
- Iterate on ideas without typing friction
- Think out loud while Cline listens
Start a planning session by speaking for 2-3 minutes straight, explaining the full context of what you're trying to build, the constraints you're working with, and the specific challenges you're facing.
### Complex Problem Explanation
Some problems are hard to type out. When you're dealing with:
- Multi-step workflows with edge cases
- Integration challenges across multiple systems
- Performance issues with specific reproduction steps
- UI/UX problems that need detailed context
Speaking lets you explain the full situation naturally, including all the "oh, and also..." details that matter.
### Code Review and Debugging
When reviewing code or explaining bugs, voice lets you walk through your thought process:
- "This function looks fine, but I'm worried about what happens when..."
- "The issue might be in this section, or possibly this other area..."
- "I tried X and Y, but neither worked because..."
You can share your complete debugging journey instead of just the final question.
## Technical Requirements
**System Requirements:**
- FFmpeg installed on your system
- Active internet connection
- Cline account with transcription credits
**Audio Quality:**
- Records in WebM format with Opus codec
- Mono audio at 16kHz sample rate
- Optimized for voice recognition
**Privacy:**
- Audio recorded locally on your machine
- Only audio files sent for transcription
- No audio stored after transcription
- Temporary files automatically cleaned up
## Cost and Credits
Voice transcription costs $0.006 per minute through your Cline account. For most users, this works out to pennies per session.
A typical 5-minute planning conversation costs about 3 cents. Even heavy voice users rarely spend more than a few dollars per month.
<Note>
Pricing is experimental and may change as we refine the service.
</Note>
## Best Practices
**Speak Naturally**
Don't try to speak like you type. Use your normal conversational tone and don't worry about perfect grammar.
**Give Context First**
Start with the big picture, then drill down into specifics. "I'm building a React app that needs to handle real-time data, and I'm running into performance issues with the WebSocket connection..."
**Use Voice for Exploration**
Dictation is perfect for exploratory conversations where you're not sure exactly what you need. Start talking through the problem and let the conversation evolve.
**Combine with Text**
You don't have to use voice for everything. Use voice for complex explanations and context, then switch to text for quick follow-ups or code snippets.
## Troubleshooting
**Microphone Not Working**
- Check your IDE permissions for microphone access
- Ensure FFmpeg is properly installed
- Try refreshing VSCode/your editor
**Poor Transcription Quality**
- Speak clearly and at normal volume
- Reduce background noise if possible
- Check your microphone settings
**Connection Issues**
- Verify internet connection
- Check if firewall is blocking Cline's servers
- Try signing out and back into your Cline account
**Authentication Issues**
- Sign out and back into your Cline account if you see authentication errors
- Check that your account has sufficient transcription credits
- Verify your internet connection is stable
**Audio Recording Issues**
- Ensure FFmpeg is properly installed and accessible
- Check that your browser/IDE has microphone permissions
- Try restarting your editor if audio capture fails
## The Future of AI Collaboration
When you can speak your thoughts as fast as you think them, you stop self-editing. You share the full context, the edge cases, the "what if" scenarios that matter. This leads to better solutions and fewer back-and-forth clarifications.
If you have questions about this change or need help setting up alternative voice input methods, please reach out through Cline's support channels.

Some files were not shown because too many files have changed in this diff Show More