Compare commits

..

225 Commits

Author SHA1 Message Date
Zhongying Qiao 6e8f7ef629 Merge branch 'account-sync' of github.com:cline/cline into account-sync 2025-12-10 13:44:42 -08:00
Zhongying Qiao 9be15b8cc4 attempt to fix e2e test 2025-12-10 13:44:26 -08:00
Zhongying Qiao 312e229b08 Merge branch 'main' into account-sync 2025-12-10 13:01:13 -08:00
Ara 27c9971774 feat(mistral): fix proxy support and add new model definitions (#8018)
* feat: Added Devstral 2 Models

* feat(mistral): fix proxy support and add new model definitions

- Fix HTTPClient fetcher to properly extract URL and options from Request
  objects, enabling proxy support in standalone mode (JetBrains/CLI)
- Add duplex option for body streams required by Node.js/undici
- Rename devstral-small-latest to labs-devstral-small-2512
- Add mistral-large-2512 model (256K context, $0.5/$1.5 pricing)
- Add ministral-14b-2512 model (256K context, $0.2/$0.2 pricing)

---------

Co-authored-by: omercelik <omercelik@users.noreply.github.com>
2025-12-10 12:35:25 -08:00
Robin Newhouse 644d06c487 Fix tool use argument handling in Claude Code provider (#8023)
The Claude Code CLI returns tool arguments as complete objects, but the
StreamResponseHandler expects string chunks for streaming. This caused
tool calls to fail with "missing parameter" errors because the object
was being concatenated with a string, resulting in "[object Object]".

This change stringifies the tool arguments in the Claude Code provider
before yielding them, ensuring they are correctly parsed by the
StreamResponseHandler.
2025-12-10 11:56:49 -08:00
Tony Loehr 1be314dfed Enterprise docs (#7714)
* enterprise docs

* tested for accuracy

* Reorganize Enterprise docs structure

- Consolidate member management under team-management/
- Unify all configuration under configuration/ with two clear paths:
  - remote-configuration/ for simple cloud-based setup
  - infrastructure-configuration/ for advanced enterprise features
- Create comprehensive overview pages explaining the differences
- Update all internal links to reflect new paths
- Preserve all existing content while eliminating redundancy
- Maintain clear separation between admin and member documentation

* removed trailing backslash

* fix docs.json

* enterprise docs reformat

* monday update

* tidied up managing members section

* fixed deployment guide

* simplify rules

* workflow cleanup

* rules tweak

* Update docs/enterprise-solutions/configuration/overview.mdx

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

* fix other features

* fixed provider docs

* fixed monitoring

* fix providers

* updated cta and rbac

* fix enterprise overview

* enterprise-docs

* hid self-hosted section for now

* addressed format fixed

* docs: restructure monitoring navigation and move telemetry

- Remove unnecessary OpenTelemetry dropdown wrapper in Enterprise navigation
- Move Cline Telemetry from control-other-cline-features to monitoring section
- Update all internal documentation links to new telemetry path
- Simplify Control Other Cline Features section to focus on Yolo Mode only
- Group related monitoring features (overview, telemetry, opentelemetry) together

This creates a more cohesive navigation structure where telemetry-related
features are adjacent and eliminates unnecessary nested dropdowns.

* docs: rename Basic Telemetry to Cline Telemetry and add link

- Rename all instances of 'Basic Telemetry' to 'Cline Telemetry' for consistency
- Add href link to Cline Telemetry card in Monitoring Options section
- Update section headings and subheadings to use 'Cline Telemetry'
- Ensures consistent naming across monitoring documentation

* docs: restructure Enterprise YOLO Mode to focus on administrator controls

- Change title from 'Yolo Mode' to 'YOLO Mode' for consistency
- Add reference link to /features/yolo-mode for general documentation
- Remove duplicate content about basic YOLO Mode functionality
- Focus exclusively on Enterprise administrator configuration and controls
- Add comprehensive policy recommendations by organization size
- Include security implications, monitoring requirements, and compliance considerations
- Provide detailed technical implementation guidance
- Update overview.mdx card description to reflect enterprise focus

* docs: hide self-hosted/infrastructure configuration references

- Remove choosing-your-deployment from Enterprise navigation
- Remove self-hosted references from enterprise-solutions/overview.mdx
- Remove self-hosted comparison and warning from remote-configuration/overview.mdx
- Remove Info boxes linking to infrastructure config from provider pages (AWS, Google, LiteLLM)
- Remove Self-Hosted OpenTelemetry Collector section from opentelemetry.mdx
- Remove self-hosted deployment section from control-other-cline-features/overview.mdx

All self-hosted/infrastructure configuration documentation remains intact but is no longer
navigable or linked from SaaS provider configuration pages. This allows easy restoration
when features become available.

* clarified domain and seat info

* fixed getOpenTabs function

* Update getOpenTabs.ts

* Update package.json

* Revert package-lock files to main

---------

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: Juan Pablo Flores <juan@cline.bot>
2025-12-10 11:05:14 -08:00
Saoud Rizwan 91940fbb4a v3.40.2 Release Notes (hotfix)
Hotfix release including:
- 279e371cf: fix: prevent logout on network errors during token refresh (#8021)
2025-12-11 03:37:29 +09:00
Saoud Rizwan 279e371cf5 fix: prevent logout on network errors during token refresh (#8021)
* fix: prevent logout on network errors during token refresh

When network errors occur at startup (e.g., opening laptop while offline),
users were being logged out because the token refresh failed and returned
null to AuthService.

Now on network errors or max retries exceeded, we return the stored auth
data instead of clearing the session. This keeps users logged in with
their existing credentials. If the token is truly invalid, the actual API
request will fail later when the user tries to use Cline, rather than
logging them out preemptively at startup.

* chore: add changeset
2025-12-10 10:33:00 -08:00
Saoud Rizwan 4eda267981 fix(e2e): update auth test to handle Santa Cline logo with multiple paths
The Santa Cline logo has 3 path elements, causing strict mode violation.
Select the container instead of a specific path element.
2025-12-11 03:21:26 +09:00
Robin Newhouse 3441363805 fix: only send thinking params to Gemini models that support them (#8014) 2025-12-09 21:37:53 -08:00
Robin Newhouse 5389be991e Refactor Vertex provider to use metadata for model capabilities (#7999)
This change removes hardcoded switch statements in VertexHandler and moves model-specific configurations (like reasoning support and prompt caching) into the centralized model metadata in src/shared/api.ts.

Benefits:
- Decouples handler logic from specific model IDs
- Centralizes model capabilities for easier maintenance
- Simplifies adding future Vertex models
- Improves type safety

Related: ENG-1408, ENG-1385
2025-12-09 15:36:02 -08:00
Sarah Fortune 41fd610203 Don't enable gRPC debug logs in the cli (#8013)
If you need this for development you can enable them locally, they shouldn't be turned on in the released version; they are spammy af.
2025-12-09 15:10:37 -08:00
Jose R. Perez e1e7470fdd feature: xmas special santa cline (#8010)
* feat: hide whats new modal header image for now

* feature: change set

* feat: xmas special santa cline

* fix: minor change to actual svg

* Fix colors

---------

Co-authored-by: Arafatkatze <arafat.da.khan@gmail.com>
2025-12-09 15:04:11 -08:00
Zhongying Qiao 2f0e0ee56d feat: configure Litellm API key with remote config (#7937)
* feat: configure Litellm API key with remote config
2025-12-09 14:56:23 -08:00
Robin Newhouse 7f89ebf276 fix: make initial checkpoint commit non-blocking but block unsafe tools [#AI-26] (#8008)
* fix: make initial checkpoint commit non-blocking while preventing tool execution races

- Captures the initial checkpoint commit promise in the Task class
- Ensures executeTool waits for the initial commit to complete before running any tools
- Resolves race condition where tools could modify files before the initial state was fully captured

* feat: allow read-only tools to bypass initial checkpoint block

- Defines READ_ONLY_TOOLS allowlist in shared/tools.ts
- Updates Task executor to check tool name against whitelist
- Allows exploration tools (list_files, read_file, browser_action, etc.) to run in parallel with initial commit
- Maintains blocking for state-modifying tools (write_to_file) to ensure data integrity
2025-12-09 14:43:30 -08:00
Jose R. Perez 99ed1b7e86 feat: hide whats new modal header image for now (#8009)
* feat: hide whats new modal header image for now

* feature: change set
2025-12-09 13:49:42 -08:00
Ara 45c9fcf575 Removing unused file in Dify Provider (#7968) 2025-12-09 13:41:42 -08:00
Stewi 4f73f4460b fix(docs): correct broken signup link in installing-cline docs
Fixed a broken link in installing-cline.mdx: replaced https://app.cline.bot/signup with https://authkit.cline.bot/ for account creation.
2025-12-09 12:56:30 -08:00
Ara fb872fd316 feat(banners): add dismiss functionality to banner carousel (#7982)
* feat(banners): add dismiss functionality to banner carousel

- Add onDismiss callback to BannerData interface
- Implement dismiss button (X icon) in BannerCarousel component
- Add onDismiss handlers for info, model, and CLI banners
- Update banner version in state when user dismisses a banner
- Fix carousel index bounds handling when banners are removed
- Refactor carousel handlers with useCallback for better performance

* Fix imports

* feat(banners): show dismiss X only on last card in carousel
2025-12-09 12:46:30 -08:00
Tomás Barreiro 5292242a8e Add loaders to login buttons (#7945)
* Add loaders to login buttons

* Disable the button when loading

* Add changeset

* Remove log

* Fix tests
2025-12-09 20:41:56 +01:00
CandiedUniverse 78b8aed50f feat(hooks): Implement PreCompact hook [ENG-1005] (#7513)
* feat(hooks): Implement PreCompact hook

feat(hooks): Continuing implementation of PreCompact hook

feat(hooks): PreCompact supports contextModification

Fixes as per Cline code reviewing the PreCompact implementation

feat(hooks): Tweaking the PreCompact hook behavior while testing

feat(hooks): Implement PreCompact hook in handleContextWindowExceededError code path

feat(hooks): Implement conversation history temp file in task directory for PreCompact to access

feat(hooks): Implement context window temp file in task history directory for PreCompact to access

feat(hooks): Refactor complex function into helpers

* feat(hooks): Improvements from Cline code reviewing the change set

feat(hooks): Refactor duplicate logic into common utility function

feat(hooks): Improve compaction strategy naming

feat(hooks): Deduplicate a small piece of logic

feat(hooks): DRY for getNextTruncationRange()

feat(hooks): Fix contextModification for PreCompact hook

feat(hooks): Improvements as per Cline's code review feedback

feat(hooks): Improving code quality/reduce complexity

feat(hooks): Further code improvements as per Cline code reviewing

* feat(hooks): Changes as per PR feedback
2025-12-09 11:20:29 -08:00
Tomás Barreiro d01f7b4618 Log session information (#7944)
* Prevent multiple simultaneos refreshes when retrieving auth info

* refactor

* Track logout events

* Add changeset

* Persist the startedAt date

* Fix bug

* Use snake case for event properties

* Log failed refresh request information
2025-12-09 20:10:20 +01:00
CandiedUniverse dec215cd9c feat(hooks): Enable hooks in the CLI [ENG-1375] (#7948)
* feat(cli): Add hooks_enabled support to CLI settings

- Add hooks_enabled field to Settings proto message (field 134)
- Add hooks_enabled parsing to CLI settings parser
- Enables users to toggle hooks via -s hooks_enabled=true/false flag

Fixes missing CLI support for hooks that was available in the VSCode extension

* feat(hooks): Enable hooks in the CLI

* Add include back in after resolving merge conflict

* feat(hooks): Changes as per human code review feedback.

---------

Co-authored-by: NightTrek <Daniels@dual4t.com>
2025-12-09 10:32:18 -08:00
Toshii 8ce7e132d2 add feature flag check to tool handlers (#7997) 2025-12-08 19:48:50 -08:00
Toshii 6ab008b204 adding search models to usage tables in ui (#7996) 2025-12-08 19:18:31 -08:00
Sarah Fortune 769523998d Add the cline distribution type to the telemetry (#7940)
* Add the cline distribution type to the telemetry

In the telemetry we currently have the IDE name, but because there are so many variants of VSCode and JetBrains, it's not easy to group them by VSCode extension or JetBrains plugin. Add this field to the telemetry.

* update unit tests

* Update src/services/telemetry/TelemetryService.ts

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

* Update src/services/telemetry/TelemetryService.ts

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

* Update unit tests

---------

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
2025-12-08 17:14:54 -08:00
Zhongying Qiao 6db409864b Merge branch 'account-sync' of github.com:cline/cline into account-sync 2025-12-08 15:04:08 -08:00
Zhongying Qiao b01fe70655 fix e2e test 2025-12-08 15:03:30 -08:00
Zhongying Qiao 1b7352e936 Merge branch 'main' into account-sync 2025-12-08 14:45:27 -08:00
Zhongying Qiao 56b647be0c add new method to test mock 2025-12-08 13:40:51 -08:00
Max 64a6bcc39b show mcp messages in cli output (#7989)
Co-authored-by: Max Paulus 🥪 <max@cline.bot>
2025-12-08 13:20:20 -08:00
Zhongying Qiao c40cda6d3c ensure extension displays new org after creating them on dashboard 2025-12-08 12:57:31 -08:00
AJ Juaire 19ceafd4a4 Add Amazon Nova 2 Lite support. (#7987)
https://github.com/cline/cline/discussions/7855
2025-12-08 11:34:24 -08:00
Robin Newhouse 4b5218b3b8 Refactor OpenAI native handler to use metadata for model capabilities (#7947)
This change removes hardcoded switch statements in OpenAiNativeHandler and moves model-specific configurations (like streaming support, system role, and tools support) into the centralized model metadata in src/shared/api.ts.

Benefits:
- Decouples handler logic from specific model IDs
- Centralizes model capabilities for easier maintenance
- Simplifies adding future OpenAI models
- Improves type safety with updated getModel() signature

Related: #7920
2025-12-08 11:07:10 -08:00
Toshii b68d716675 in tests websearch shows up in cline provider prompt (#7976) 2025-12-08 00:00:19 -08:00
Toshii f820c6d00a adding handler for websearch in cli (#7570) 2025-12-08 00:00:05 -08:00
Toshii 1fcbbaa9d0 adding websearch and integrating new handler (#7514)
* implementing prompt injection for web_search and associated web fetch handler

* remove printing of the ms took

* ui showing query user is searching for

* updating the fields we pass in api request

* updating text for search tool
2025-12-07 23:10:44 -08:00
Toshii 4005df6eae updating webfetch and integrating new handler (#7509)
* updating system prompt for webfetch and integrating new handler

* updating tests to match new webfetch tool
2025-12-07 22:37:48 -08:00
Toshii 0e3cdab82b adding webtools to the features menu (#7566)
* adding webtools to the features menu

* telemetry for toggling web tools

* adding feature flag for webtools
2025-12-07 22:34:43 -08:00
Sarah Fortune ada6b0c955 Move terminal impls into the correct package. (#7970)
Move VSCode terminal impls into the src/hosts/vscode package. The VSCode specific code needs to be contained in this directory.
The `src/shared` package is for things shared with the extension and the _webview_; everything in src/ that's _not_ under `src/hosts` is shared with VSCode, JB, CLI implicitly.

ref CLIENTS-34
2025-12-07 20:35:00 -08:00
Jose R. Perez 921dd2ec8c feat: welcome screen ui enhancements (#7878)
* feat: Announcement Cards, Recent Tasks Refresh, Whats new modal

* feat: adjustments to welcome modal functionality

* chore: add changeset for welcome ui enhancements

* refactor: replace inline styles with Tailwind classes where appropriate

* fix: removed close mechanisim for cards fix modal linking issue

* feat: suggested changes

* fix: arias for accessibility

* fix: test modal fix

* feat: e2e test fix

* update e2e tests with new welcome ui

* feat: small arias change

---------

Co-authored-by: abeatrix <beatrix@cline.bot>
2025-12-07 20:32:42 -08:00
Richard 4b212994a8 fix(security): set restrictive file permissions for secrets.json (#7782) 2025-12-07 19:23:29 -08:00
CandiedUniverse 3fe3c866ea fix(hooks): Want TaskCancel to get triggered properly (#7952) 2025-12-07 06:59:19 -08:00
Ara e9136f60cc feat(terminal): Move Standalone terminal Code to Typescript (#7927)
* feat(terminal): add shared terminal types and interfaces

Add shared terminal module with types and interfaces that enable
terminal management across VSCode, CLI, and JetBrains environments.

- Define ITerminal, ITerminalManager, and TerminalInfo interfaces
- Add TerminalProcessResultPromise for async command execution
- Include StandaloneTerminalOptions for non-VSCode environments
- Prepare module structure for standalone implementations

* feat(terminal): export standalone terminal implementations

Enable exports for standalone terminal classes that were previously
commented out as placeholders:
- StandaloneTerminal
- StandaloneTerminalManager
- StandaloneTerminalProcess
- StandaloneTerminalRegistry

These implementations are now ready for use outside the terminal module.

* fix: resolve TerminalInfo type incompatibility in settings update

- Remove unused TerminalInfo import from both updateSettings files
- Use `as any` cast to handle type mismatch between VSCode and standalone TerminalInfo
- Replace busyTerminals array with busyTerminalsCount to avoid type issues
- Add null-safe access when getting busy terminals length

* feat: import StandaloneTerminalManager from bundled cline-core

Replace standalone enhanced-terminal.js with import from the bundled
TypeScript version in cline-core.js. This consolidates terminal
management code and removes the need to separately include the
runtime file in the VS Code extension package.

- Re-export StandaloneTerminalManager from cline-core.ts
- Update vscode-impls.js to import from cline-core.js
- Remove .vscodeignore exception for enhanced-terminal.js

* feat: simplify standalone terminal manager initialization

Replace global injection pattern with environment variable detection
for determining terminal execution mode. The Task class now directly
instantiates StandaloneTerminalManager when IS_STANDALONE=true instead
of relying on a globally injected instance.

- Remove StandaloneTerminalManager re-export from cline-core.ts
- Simplify vscode-impls.js createTerminal to return stub object
- Use IS_STANDALONE env var for terminal manager selection in Task
- Remove global.standaloneTerminalManager injection pattern

* Fix Standalone build

* Fix Standalone build

* fix: use subagentTerminalOutputLineLimit in StandaloneTerminalManager.processOutput

Match the VSCode TerminalManager logic to properly use subagentTerminalOutputLineLimit (2000) for subagent commands instead of always falling back to terminalOutputLineLimit (500).

* feat: add TerminalManager to HostProvider for dependency injection

- Add TerminalManagerCreator type and createTerminalManager to HostProvider
- Extract ITerminalManager interface to shared/terminal/types for abstraction
- Refactor TerminalManager to implement ITerminalManager interface
- Create StandaloneTerminalManager for non-VSCode environments
- Update TerminalRegistry to use ITerminalManager via HostProvider
- Enable terminal management to work across different host environments

* feat: refactor terminal manager to use ITerminalManager interface

- Replace concrete TerminalManager/StandaloneTerminalManager types with ITerminalManager interface
- Use HostProvider.createTerminalManager() for host-agnostic terminal creation
- Simplify terminal execution mode logic in Task constructor
- Add dynamic imports for StandaloneTerminalManager when backgroundExec mode is used
- Improve logging for terminal manager selection
2025-12-07 05:10:25 -08:00
Bee 34bb95e04e refactor: require native tool call for Responses API (#7953)
Add validation to ensure native tool calling is enabled when using
OpenAI Responses API format. Previously, the code would silently fall
back to completion stream when tools were not provided, which could
lead to unexpected behavior.

- Add explicit error when tools are missing for Responses API format
- Update tools parameter type to non-optional in createResponseStream
2025-12-06 05:03:29 -08:00
Saoud Rizwan 7b65db55f1 docs: update hotfix workflow to copy Slack message instead of tag 2025-12-05 16:13:37 -08:00
Saoud Rizwan 07ebc2e4bd docs: improve hotfix release workflow
- Split shell commands to avoid parsing issues with parentheses in author names
- Clarify that hotfixes always use patch version bumps
- Add (hotfix) suffix to release notes commit message format
- Skip npm install step (automation handles lockfile)
- Add pbcopy step to copy tag to clipboard for GitHub Actions
- Add direct link to publish workflow
2025-12-05 15:58:58 -08:00
Saoud Rizwan 0193179597 v3.40.1 Release Notes
Hotfix release including:
- 4df486fa5: fix cost calculation for Anthropic API requests (#7943)
2025-12-05 15:49:42 -08:00
Saoud Rizwan 20c0783c97 feat: add hotfix release workflow documentation
Add a workflow for creating hotfix releases by cherry-picking commits
from main onto release tags. Includes steps for selecting commits,
creating release notes, version bumping, and tagging.
2025-12-05 15:43:31 -08:00
Saoud Rizwan 4df486fa5b fix: restore cost calculation for Anthropic API requests (#7943)
The taskMetrics.totalCost was incorrectly initialized to 0 instead of
undefined in commit 09692d7d3. This broke cost display for providers
like Anthropic that don't return totalCost in their usage chunks.

When totalCost is 0, the fallback to calculateApiCostAnthropic() in
updateApiReqMsg doesn't trigger because the nullish coalescing operator
(??) only falls back for null/undefined, not 0.

By initializing totalCost to undefined:
- Providers that return totalCost (like OpenRouter) use that value
- Providers that don't (like Anthropic) fall back to calculating cost
  from token counts and model pricing info
2025-12-05 13:01:02 -08:00
Zhongying Qiao 5fc6d4e9e3 feat: remote config - add vertex provider (#7913) 2025-12-05 12:58:50 -08:00
Saoud Rizwan 00d3bd8316 refactor(ui): move model capabilities to Advanced section and fix layout
- Move Images, Browser, Prompt Caching badges into collapsible Advanced section
- Use consistent row styling (label: value) for capabilities
- Fix InfoRow vertical spacing when items wrap (column-gap: 16px, row-gap: 4px)
- Add bottom padding to model picker popup for breathing room
- Remove unused Tooltip imports and badge styled components
2025-12-05 12:50:31 -08:00
Robin Newhouse 81d4ff947f Refactor openai-native.ts switch statement to use model metadata (#7920)
* refactor: Move OpenAI temperature to model metadata

- Added `temperature` field to `openAiNativeModels` in `api.ts`.

- Updated `OpenAiNativeHandler` to use `model.info.temperature` instead of hardcoded values in switch cases.

- This allows for centralized configuration of model temperatures.

* refactor: Consolidate OpenAI native streaming logic

- Simplified `createCompletionStream` in `OpenAiNativeHandler` by consolidating duplicated logic for streaming models (`gpt-5`, `o3`, `o4`).

- Introduced `systemRole`, `includeReasoning`, and `includeTools` flags to handle model-specific configurations.

- Preserved distinct handling for non-streaming `o1` models.
2025-12-05 10:48:23 -08:00
Max bcb368d097 display completion messages in processStateUpdate (#7939)
CLINE-84, ENG-1392

Co-authored-by: Max Paulus 🥪 <max@cline.bot>
2025-12-05 10:36:57 -08:00
Alex Ker c1ded819bb new model in static list (#7934) 2025-12-05 09:17:20 -08:00
CandiedUniverse de02befb2f fix(hooks): Doc said the wrong directory for global hooks dir (#7933) 2025-12-05 09:02:54 -08:00
Zhongying Qiao 6617901078 feat: remove mcp marketplace enable setting from cli (#7911)
* feat: remove mcp marketplace enable setting from cli
2025-12-05 08:41:10 -08:00
celestial-vault 31c7176de1 cleanup taskhistory recovery (#7889)
* cleanup recovering by removing unnecessary recursion; rename parameter for reconstructTaskHistory for clarity, and add stdout logging in error blocks

* Don't return empty array on IO error. Instead, continue throwing error because this is indeed an error and not something that can be corrected by data reconciliation.
2025-12-05 10:32:57 -06:00
Bee 3c97c8dc19 dev: add stories for all UI components (#7905)
* dev: add stories for all UI components

* unify styles

* update
2025-12-05 04:03:47 -08:00
Nick Baumann 187e40d2da Redesign model settings page with compact info and Advanced section (#7862)
* Redesign model settings page with compact info and Advanced section

* Fix cache pricing precision to show decimals when needed

* Address PR feedback: fix cache pricing precision, remove duplicate billing link, unify provider routing
2025-12-05 03:26:46 -08:00
Andrei Eternal 8c38b1ccf8 JB Integration Workflow: use pull_request_target to support remote remote PRs (#7917)
* JB Integration Workflow: use pull_request_target to support remote repo PRs

* also sanitize the branch name and title really hard to avoid json injections

* ok lets be extra double paranoid with the sanitization

* ok lets be even more extra safer by also not logging the head_ref

---------

Co-authored-by: Andrei Edell <andrei@nugbase.com>
2025-12-04 21:22:55 -08:00
Toshii 4947a745c2 removing unused legacy context manager (#7924) 2025-12-04 20:54:45 -08:00
Toshii 9e8c6df6b2 context rewriting test cases (#7923)
* alter equality sign

* adding tests for the new file read search
2025-12-04 20:54:36 -08:00
Bee 6586195b2d docs: add contributing guide for model family [CLIENTS-32] (#7916)
* docs: add contributing guide for model family

Add detailed CONTRIBUTING.md documentation for system prompt configuration
and model family management. The guide covers:

- Architecture overview with key concepts (model families, variants, matchers)
- Glossary of terms (native/XML tool calling, API formats, components)
- Step-by-step instructions for creating new model families
- Configuration guides for system prompts and tool calling
- API request/response shape configuration
- Testing procedures and best practices

This documentation helps contributors understand the fallback system design
principle (GENERIC fallback) and provides practical examples for extending
support to new model providers and families.

* fix typo

---------

Co-authored-by: Robin Newhouse <robin@cline.bot>
2025-12-04 14:35:07 -08:00
Toshii 1aa944eff7 fix context rewriting for native tool call format (#7882)
* enable handling of tool_result blocks to fix file read search for context rewriting

* updating loop over inner indices 0-2 inclusive

* spelling
2025-12-04 14:27:14 -08:00
Robin Newhouse 8e7b1c6884 fix(ollama): abort streaming requests when task is cancelled (#7907)
Previously, clicking cancel would break out of the stream loop but
leave the HTTP connection open. Ollama would continue generating in
the background, keeping the GPU busy and blocking subsequent requests
until completion.

Now we call the Ollama SDK's abort() method to immediately close the
connection.

Fixes #7468
2025-12-04 13:56:25 -08:00
Bee ee154826b6 feat: add OpenAI Response API support and Codex model compatibility [CLIENTS-24] (#7912)
* feat: add OpenAI Response API support and Codex model compatibility

- Add ApiFormat enum to proto definitions with OPENAI_RESPONSES format
- Update model info messages to include api_format field across providers
- Refactor OpenAI native handler to conditionally use Response API based on model's api_format
- Add Codex model support in GPT-5 and GPT-5-1 prompt variants with appropriate exclusions
- Remove hardcoded useResponseFormat parameter in favor of model-driven API selection

This enables ChatGPT Codex models to use the Response API format when tools are provided, while maintaining backward compatibility with existing chat completion models.

* add comments

* tabs
2025-12-04 13:23:48 -08:00
Saoud Rizwan 852f307268 Revert "feat(prompt): add command output limiting guidance to capabilities (#…" (#7909)
This reverts commit 7a523fbaf6.
2025-12-04 11:38:10 -08:00
Bee 4e3fe004f4 feat: enable native tool calling for deepseek 3.2 [AI-27] (#7877)
* feat: enable native tool calling for deepseek 3.2

Add isDeepSeek32ModelFamily() function to identify DeepSeek 3.2 models and integrate it into the isNextGenModelFamily() check. This classifies DeepSeek 3.2 as a next-generation model family, enabling native tool calling support.

* typo
2025-12-04 09:59:27 -08:00
Zhongying Qiao 2b63eed85e feat: remove mcp enable setting for individual users (#7879) 2025-12-04 09:36:44 -08:00
Tomás Barreiro 2ffdc50ea1 Prevent simultaneous refreshes when restoring auth info (#7835)
* Prevent multiple simultaneos refreshes when retrieving auth info

* Add changeset

* refactor
2025-12-04 14:45:10 +01:00
celestial-vault 74808431e5 add litellm provider to remote config in the extension (#7775) 2025-12-04 03:01:05 -08:00
Saoud Rizwan 7a523fbaf6 feat(prompt): add command output limiting guidance to capabilities (#7884)
* feat(prompt): add command output limiting guidance to capabilities

Add guidance in the system prompt instructing the model to proactively
limit command output when anticipating large results. Includes examples
like piping to grep/head/tail or using more specific arguments.

Idea by @AraTheBoss

* chore: add changeset

* refactor: move command output limiting guidance to execute_command tool

Move the guidance from capabilities.ts to execute_command.ts where it
belongs. Extract into a shared COMMAND_BEST_PRACTICES constant to avoid
duplication across model variants (GENERIC, NATIVE_GPT_5, NATIVE_NEXT_GEN,
GEMINI_3).
2025-12-03 21:06:07 -08:00
github-actions[bot] c22ea39dc1 v3.40.0 Release Notes (#7865)
* changeset version bump

* Updating CHANGELOG.md format

* Update CHANGELOG.md to reflect recent changes including fixes for highlighted text flashing, terminal command issues, and enhancements for slash command usage and message padding.

* Update CHANGELOG.md

---------

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: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
2025-12-03 19:24:18 -08:00
Saoud Rizwan c9f23076c2 fix: consolidate successive error retry messages in chat UI (#7880)
When API requests fail and auto-retry is enabled, multiple error_retry
messages were shown (e.g., "Attempt 1 of 3", "Attempt 2 of 3", etc.).
This change consolidates them to only show the latest retry message,
reducing visual clutter during retry sequences.
2025-12-03 19:18:17 -08:00
Bee a5f6c1d732 feat: add auto-recovery for corrupted task history state (#7875)
* feat: add auto-recovery for corrupted task history state

Add automatic reconstruction of task history when JSON parsing fails.

Changes:
- Modified `reconstructTaskHistory()` to return reconstruction result or null
- Enhanced `readTaskHistoryFromState()` with automatic corruption recovery
- Added recursive reconstruction attempt with loop prevention flag
- Wrapped JSON parsing in try-catch to handle corruption gracefully

When task history state file is corrupted, the system now automatically
attempts to reconstruct history from existing task folders, providing
better resilience against file corruption issues.

* feat: Add telemetry tracking for extension storage errors

Replace console.error logging with structured telemetry capture for extension storage operations. This change:

- Adds a new EXTENSION_STORAGE_ERROR telemetry event type to track storage-related failures
- Implements captureExtensionStorageError method with error message truncation to prevent excessive data
- Replaces three console.error calls in readTaskHistoryFromState with telemetry events

This improves error monitoring and provides better insights into extension storage failures while maintaining data efficiency through message truncation.

* fix: improve type safety and error handling in task history

Add explicit return type to reconstructTaskHistory() function and refactor error handling in readTaskHistoryFromState() with nested try-catch blocks to better distinguish between file read errors and JSON parse errors. This improves error recovery and makes error tracking more precise through separate telemetry calls.

* add param to reconstructTaskHistory for manually called action

---------

Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
2025-12-03 17:49:28 -08:00
Toshii 3c37a160ac support multi-index search over inner messages to find file mentions (#7850) 2025-12-03 15:27:08 -08:00
Saoud Rizwan 5c3294051f Revert "fix: don't return empty array on parse failure (#7773)" (#7874)
This reverts commit 14ccf33d25.
2025-12-03 14:30:58 -08:00
Tony Loehr 4c2f28f2af docs: remove Advanced Patterns and Testing & Debugging from Hooks documentation (#7869)
- Removed advanced-patterns.mdx and testing-and-debugging.mdx files
- Updated docs.json to remove these pages from navigation
- Updated hooks/index.mdx to remove corresponding Card components
- Simplified Hooks documentation to focus on core concepts: Overview, Hook Reference, and Samples
2025-12-03 12:11:43 -08:00
Ara 6e016298cb chore: bump version to 3.39.2 and update dependencies (#7851)
- Update package version from 3.39.1 to 3.39.2
- Upgrade @changesets/* packages to latest versions
- Update @inquirer/external-editor to 1.0.2
- Upgrade js-yaml from v3 to v4 in @changesets/parse
2025-12-03 11:23:29 -08:00
pashpashpash 0cd7bebfba markdown styling fix (#7840)
* markdown styling fix

* nested ul
2025-12-03 01:23:02 -08:00
Bee 363aac61fb fix: OpenAI Response API message format (#7842)
Fixed the message structure to match the OpenAI Responses API format.

Updated Message ID placement: The message id is stored and set at the message level, not inside the content array.

This fixes an error occuring in the current code when reasoning item is followed by a message text block: 400 Item 'rs_...' of type 'reasoning' was provided without its required following item."
2025-12-02 17:41:19 -08:00
Tony Loehr eeb1cc7da8 added subpages and content to hooks (#7797)
* added subpages and content to hooks

* Update docs/features/hooks/advanced-patterns.mdx

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

* Add complete hook type coverage with examples for TaskCancel, TaskComplete, TaskResume, PreCompact, UserPromptSubmit

* Fix hook documentation API mismatches and add TaskComplete

- Add missing TaskComplete hook to reference documentation
- Fix TaskCancel/TaskResume field paths to match protobuf API
- Improve security practices in hook examples
- Add proper error handling and validation

* Update hooks documentation: rename samples, remove PreCompact, improve structure

- Rename 'Real World Examples' to 'Samples' with skill-based organization
- Remove PreCompact references (feature not yet available)
- Update navigation structure in docs.json
- Add multiworkspace mention to Overview
- Create 9 comprehensive examples (beginner/intermediate/advanced)
- Clean up duplicate content and fix cross-references

* Update hooks documentation: Add Windows support

- Remove incorrect warning that hooks don't work on Windows
- Add positive cross-platform support note (Windows, macOS, Linux)
- Clarify that bash examples work with standard shells including Git Bash/WSL on Windows

* fixed hooks overview redirect

* Add UI screenshots to hooks documentation

* hooks in action

* fixed hooks overview and examples

* fixed terminology

* fixed hooks examples

* hooks groupings

* fixed appearance of hook names

* refactor hook docs

---------

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
2025-12-02 17:35:07 -08:00
Sarah Fortune f760f13de5 Don't log otel events to the console because they are really spammy (#7841) 2025-12-02 17:20:52 -08:00
canvrno dd52a4a39c feat: apply_patch auto approve (#7777)
* Added apply_patch to auto approve, strict mode, and minor prompting adjustment

* changeset
2025-12-02 15:36:01 -08:00
Toshii 639edb5db6 correctly handle new and old tool call formats for context rewriting (#7809)
* correctly handle new and old tool call formats

* spelling change
2025-12-02 15:12:05 -08:00
Jack Reinhardt 3eac9b04de fix(bedrock): add sts userAgentAppId (#7719) 2025-12-02 14:40:39 -08:00
Bee 09692d7d3a feat: add mode and token metrics info to storage messages [CLIENTS-26] (#7795)
* feat(storage): add mode and token metrics to storage messages

Add mode (plan/act) tracking to ApiProviderInfo and ClineMessageModelInfo interfaces, ensuring each storage message contains the operational mode used during API requests.

Refactor token metrics tracking by consolidating cache write/read tokens, input/output tokens, and total cost into a centralized taskMetrics object. This enables better tracking and storage of token usage and costs throughout the task lifecycle, including for partial/cancelled streams.

Updated api_req_started and api_req_finished messages to include comprehensive token metrics, allowing for accurate cost reporting even when streams are cancelled or fail mid-execution.

* update unit tests with mode

* store task metrics per assistant turn
2025-12-02 13:52:44 -08:00
Andrei Eternal c81fa0a9d6 set the cli's 'ide version' to just the cli version rather than being blank, to make environment_history work for CLI (#7712)
Co-authored-by: Andrei Edell <andrei@nugbase.com>
2025-12-02 13:21:58 -08:00
Bee 326c9c9f99 feat: set default thinking level for Gemini 3 Pro models (#7831)
- Reorder thinking level checks to prioritize high over low
- Auto-set thinking level to LOW for Gemini 3 Pro models when not specified
- Add clarifying comment for thinking budget usage
- Ensure thinking level is always defined for Gemini 3 models to prevent errors

This change ensures Gemini 3 Pro models always have a thinking level set (required by the API) and removes the thinking budget when a level is specified, as they are mutually exclusive parameters.
2025-12-02 12:54:13 -08:00
celestial-vault a4518b90c2 add atomic file write (#7754)
* add atomic write file using write to temp file + rename to avoid situations where invalid data is written to files due to process interrupt

* adjust concurrency test for windows to expect error

* Add JSON ending to temporary file and don't await unlink
2025-12-02 13:30:53 -06:00
celestial-vault 79f4d938e6 remove unused sentry dependency (#7823) 2025-12-02 13:20:30 -06:00
canvrno 37152329cd v3.39.2 Release Notes (#7829) 2025-12-02 10:44:38 -08:00
Seb Duerr 1332d1d70d feat(cerebras): add X-Cerebras-3rd-Party-Integration header (#7824)
* feat(cerebras): add X-Cerebras-3rd-Party-Integration header

* chore: add changeset
2025-12-02 09:56:41 -08:00
canvrno 6a0d92d683 Skip reasoning_details on microwave model (#7825) 2025-12-02 09:35:30 -08:00
Ara e761a8c252 fix(changesets): remove quotes from claude-dev package name (#7822)
The quotes around the package name "claude-dev" in all changeset files were removed to adhere to the correct YAML format. This ensures proper parsing and consistency across the changeset files.
2025-12-02 07:36:09 -08:00
Ara c26d0a076d v3.39.1 Release Notes (#7818)
* v3.39.1 Release Notes

* v3.39.1 Release Notes
2025-12-02 06:16:43 -08:00
Ara c037619b90 feat: enable ModelInfoView in OpenRouterModelPicker (#7817)
Uncomment the ModelInfoView component to display model information
in the OpenRouter model picker settings panel.
2025-12-02 06:06:54 -08:00
Ara a575a76e8f v3.39.0 Release Notes (#7813)
* v3.39.0 Release Notes

* v3.39.0 Release Notes

* feat: enhance Announcement component with new microwave model and account login functionality

- Updated Announcement component to include a new free microwave model button
- Adjusted active tab logic in OpenRouterModelPicker to default to "free" if a free model is selected

* Add demo link

---------

Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
2025-12-02 05:11:23 -08:00
Dominic Cooney b1d15d4fe7 fix: Standalone, ensure cwd is install dir (#7781)
Our resource loading assumes cwd is the install
dir.
2025-12-02 18:17:58 +09:00
Saoud Rizwan a0708e57ee Move notification toggle to auto-approve menu (#7812)
- Remove "Configure notification settings" link and move the toggle directly into the auto-approve menu
- Remove notification setting from General Settings since it now lives in auto-approve menu
- Remove hover:opacity-80 from icon button variant to prevent dimming on hover
- Make docs link font size inherit and separator line thinner
2025-12-01 22:44:29 -08:00
Ara ab5796fa72 Remove auto approve menu popups (#7806)
* Remove popups from auto approve settings

* feat(ui): add documentation link to auto-approve modal

Add a "Docs" link in the auto-approve modal that directs users to
the auto-approve documentation page on docs.cline.bot.

* Remove popups from auto approve settings

* Remove popups from auto approve settings

* Remove popups from auto approve settings

---------

Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
2025-12-01 22:22:53 -08:00
Saoud Rizwan b15c364a62 feat: add 'Explain Changes' feature for code review (#7765) 2025-12-01 22:02:33 -08:00
Ara 29dcc4e1e1 feat: move stealth/microwave model from recommended to free models section (#7808)
Move the stealth/microwave model entry from the recommendedModels array
to the freeModels array for better categorization of free model options.
2025-12-01 21:54:34 -08:00
Ara 126d066893 Adding Stealth model (#7764)
* Revert "Remove old models (#7118)"

This reverts commit c7c4e43322.

* Adding stealth

* Adding stealth

* Adding stealth

* Adding minor fix

* Update webview-ui/src/components/settings/OpenRouterModelPicker.tsx

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

* Apply suggestion from @abeatrix

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

* Update src/core/api/providers/cline.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>
2025-12-01 21:18:43 -08:00
Ara fa3e095a79 Enable NTC by default (#7804)
* Enable NTC by default

* Enable NTC by default

* Enable NTC by default
2025-12-01 20:40:12 -08:00
Sarah Fortune 4033c83b51 Log the name of the telemetry provider(s) enabled in the extension (#7799)
Right now we are logging the provider type by logging the name of the constructor, but in the compiled code this is obfuscated so it is just some random characters.

Add a name property to the telemetry provider interface.
2025-12-01 19:22:43 -08:00
canvrno 0b7ea86e9b Added microwave family system prompt configuration (#7798) 2025-12-01 17:29:27 -08:00
reneehuang1 1d9a0b5986 add enterprise to readme (#7589)
Co-authored-by: Renee Huang <reneehuang@Renees-MacBook-Pro.local>
2025-12-01 16:23:35 -08:00
CandiedUniverse c47ffe2861 fix(hooks): Polish for UserPromptSubmit [ENG-1345] (#7656)
* fix(hooks): Trigger UserPromptSubmit hook when continuing a completed task

* fix(hooks): Make prompt formating consistent for all UserPromptSubmit entrypoints

* fix(hooks): Code reviewing w/ Cline before submitting PR for human review

* fix(hooks): Improve type safety

* fix(hooks): Add unit tests for buildUserFeedbackContent

* fix(hooks): Minor Cline code review changes

* fix(hooks): Fix test assertion technique

* fix(hooks): Simplify PR

* feat(hooks): Consolidate constants to a shared location as per PR feedback
2025-12-01 15:36:07 -08:00
mintlify[bot] e85d918816 Add CLI context window configuration docs (#7796)
* Update docs/cline-cli/overview.mdx

* Update docs/cline-cli/cli-reference.mdx

* Update docs/cline-cli/three-core-flows.mdx

* Update docs/cline-cli/overview.mdx

---------

Co-authored-by: mintlify[bot] <109931778+mintlify[bot]@users.noreply.github.com>
2025-12-01 15:27:55 -08:00
Ara 49be10ead8 fix: move OptionsButtons outside WithCopyButton component (#7783)
Relocate OptionsButtons component to be a sibling of WithCopyButton
rather than a child. This fixes the component hierarchy for followup
and completion_result message types, ensuring proper rendering and
interaction behavior. Also adds QuoteButton support to completion_result.
2025-12-01 15:16:16 -08:00
Ara aa9573fb0a feat: add direct navigation to settings sections (#7770)
Replace delayed scroll-to-settings approach with direct section targeting.
Settings sections can now be opened directly via navigateToSettings(section)
parameter, eliminating the need for setTimeout-based scrolling workarounds.
2025-12-01 15:15:56 -08:00
Nick Baumann b913e47332 feat: add tabbed model picker with Recommended and Free tabs (#7769) 2025-12-01 14:25:27 -08:00
Zhongying Qiao 5be7a1b3cf Add support for Banner dismissal, event logging (#7642)
* feat: add banners ui, dismissal state handling and event log

* feat: add cli as ide type, clean up some code

* feat: wire up controller and UI for banners

* audit every rule check to ensure it is doing correct filtering and working locally

* seperate out frontend code

* clean up

* fix proto file

* fix quality check errors

* fix banner service tests

* feat: use json polling approach for active banners

* fix: build error

* fix ci

* fix quality check

* use BannerService.isInitialized() instead

* do not log error when banner array is empty, only when missing or not defined

* do not hash instance id
2025-12-01 15:32:51 -06:00
Toshii c2e91aa9c9 running context rewriting prior to running auto compact (#7774)
* running context rewriting prior to running auto compact

* use sample timestamp as in getNewContextMessagesAndMetadata

* clean up return var
2025-12-01 12:23:58 -08:00
Bee 68b93fcbea fix(ui): memoize highlighted text [ENG-1355] (#7786)
* fix(ui): memoize highlighted text

Optimize UserMessage and TaskHeader components by using useMemo to cache highlighted text results. This prevents unnecessary recalculations of text highlighting on every render, improving performance when text or editedText props haven't changed.

Changes:
- Add useMemo hook to UserMessage component for highlightText result
- Replace inline highlightText calls with memoized values
- Reduces redundant text processing during re-renders

* add changeset
2025-12-01 10:50:56 -08:00
Bee 0b0e8c36cb fix(ui): Add bottom padding for last message item [ENG-1354] (#7787)
* fix(ui): Add bottom padding for last message item

- Add conditional className to message wrapper div
- Apply `pb-2.5` bottom margin only when message is last in group

* add changeset
2025-12-01 10:29:54 -08:00
Juan Pablo Flores b0bd0e3974 Docs/task history recovery (#7776) 2025-12-01 09:24:40 -08:00
Ara 42b7a1e450 feat(cli): add active task check before entering follow mode (#7745)
* feat(cli): add active task check before entering follow mode

Add validation in FollowConversationUntilCompletion to check if a task
is currently running before entering follow mode. If no active task
exists, display a user-friendly message and exit gracefully instead of
waiting indefinitely.

Also includes minor whitespace formatting cleanup in related functions.

* Fix detached process conditions

* Fix detached process conditions

* Adding stealth
2025-12-01 04:57:22 -08:00
celestial-vault 14ccf33d25 fix: don't return empty array on parse failure (#7773) 2025-11-30 17:13:10 -08:00
Toshii d9a340523c add case for skipping autoCondense in truncation (#7763) 2025-11-30 16:12:27 -08:00
Saoud Rizwan 87b3e79b90 Instruct AI to prefer non-interactive commands (#7762)
Update system prompt to guide AI toward using non-interactive command variants
to avoid interrupting workflow. This includes using flags like --no-pager,
auto-confirming prompts with -y when safe, and providing input via
flags/arguments rather than stdin.
2025-11-30 00:16:18 -08:00
Saoud Rizwan 60f2e85fc7 Add find-pr-reviewers and address-pr-comments workflows (#7761)
* Add find-sme workflow for identifying subject matter experts

* Rename find-sme to find-reviewers

* Remove old find-sme.md file

* Address Copilot PR feedback: fix find syntax and add git config command

* Add address-pr-comments workflow

* Rename find-reviewers to find-pr-reviewers

* Simplify address-pr-comments workflow
2025-11-30 00:16:06 -08:00
Saoud Rizwan 1826d98019 Allow slash commands anywhere in message input (#7760)
* Allow slash commands anywhere in message input

Previously, slash commands could only be typed at the beginning of a
message. This change allows users to type slash commands anywhere in
the message, similar to how @ mentions work.

Changes:
- Update shouldShowSlashCommandsMenu() to show suggestions when slash
  is preceded by whitespace (not just at start)
- Update insertSlashCommand() to find the slash nearest to cursor
- Update extension-side parseSlashCommands() to find commands anywhere
  in tag content using a safer regex that avoids matching URLs/paths
- Update highlight layer to highlight slash commands anywhere
- Only the FIRST slash command per message is processed/highlighted
  to maintain consistency with backend behavior
- Fix backspace deletion to work for slash commands anywhere in text

* Add changeset
2025-11-30 00:07:56 -08:00
Saoud Rizwan af69b30a36 Add sticky user message header for better navigation (#7749)
* Add sticky user message header for better navigation

When users scroll down through a long conversation, a sticky header now appears showing their most recent message that has scrolled out of view. Clicking the header scrolls back to that message.

Key changes:
- New StickyUserMessage component that appears when user messages scroll past viewport
- Track scrolled-past user messages via scroll position detection in useScrollBehavior
- Add data-message-ts attributes to enable message element lookup
- Adjust TaskHeader padding for consistent alignment with sticky header
- Minor styling tweaks to UserMessage and FocusChain for visual consistency

* Fix type error: accept null for lastUserMessage prop

* Replace color-mix() with brightness filter for better compatibility

Use hover:brightness-110 instead of color-mix() for the sticky message
hover effect, as color-mix() may not be supported in all VS Code webview
contexts.

* Address Copilot review feedback for sticky user message

- Remove unused slide-down animation CSS
- Extract magic number 32 to STICKY_HEADER_HEIGHT constant
- Use cn() utility for conditional className in MessagesArea
- Add keyboard accessibility (role, tabIndex, onKeyDown) to StickyUserMessage

* Address additional Copilot review feedback

- Fix virtualized element detection: only consider missing elements as scrolled past
  if we've already found visible elements after them (fixes incorrect sticky header
  appearing when scrolling to top of long conversations)
- Rename truncatedText to messageText for accuracy (truncation happens via CSS)
2025-11-29 02:13:50 -08:00
DL Techy e62fbf6b0c Add shell option for cmd.exe to prevent double quote escaping (#7630)
* fix(terminal): Add shell option for cmd.exe to prevent double quote escaping

Added shell: true option specifically for cmd.exe to prevent double quotes
from being over escaped during command execution. This resolves Windows-specific
issues with terminal command handling while maintaining compatibility with
other shells.

* chore: Add changeset for terminal command execution fix
2025-11-28 13:02:47 -08:00
Saoud Rizwan 64254fc97a Fix API request badge causing text to wrap when hidden (#7739)
The cost badge was using opacity:0 to hide itself when there's no cost,
but still rendered "$0.0000" which took up horizontal space. This caused
the "API Request..." label to wrap to a second line unnecessarily.

Now the badge renders empty content when hidden, taking up no width
while still maintaining its height contribution to the row layout.
2025-11-28 08:05:09 -08:00
Luna c312c4aef6 Asksage usage fetch models (#7329)
* Add flagship models

* Add model fetching

* Add usage handling, tool result handling

* Update AskSageProvider.tsx

* Create eight-pants-explode.md

---------

Co-authored-by: alex-mcgraw-askSage <alex.mcgraw@asksage.ai>
2025-11-27 12:35:00 -06:00
celestial-vault fab49e810b Add fixed header to ClineRulesToggleModal (#7729)
- Add flex-shrink-0 to header section containing tabs and description text
- Keep tabs and description visible when content area scrolls
2025-11-27 12:32:17 -06:00
celestial-vault 2a20523e16 View remote rules and workflows in the editor (#7702)
* allow the user to view remote rules and workflows in the editor by creating a temp file

* add await
2025-11-27 11:37:47 -06:00
celestial-vault 06585821d1 conditionally fetch litellm models based on presence of api key and baseUrl (#7713) 2025-11-27 11:37:13 -06:00
Saoud Rizwan 9e802b11da Revert "Add Claude Code GitHub Workflow (#7717)"
This reverts commit afb77c5a8d.
2025-11-27 01:45:05 -08:00
Saoud Rizwan afb77c5a8d Add Claude Code GitHub Workflow (#7717)
* "Claude PR Assistant workflow"

* "Claude Code Review workflow"
2025-11-26 20:01:50 -08:00
Saoud Rizwan 0a4811222f fix: unblock opening a task when using cline account (#7715) 2025-11-26 18:40:51 -08:00
canvrno b4ce378e4b v3.38.3 Release Notes (#7711)
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
2025-11-26 15:59:16 -08:00
CandiedUniverse 2f60a898af fix(hooks): Fix issue identified by linter in proto file (#7707) 2025-11-26 14:50:12 -08:00
Walter Korman 8ffd82eda3 feat(context): add context window error detection for vercel ai gateway (#7623)
feat(context): add context window error detection for vercel ai gateway #7623
2025-11-26 22:58:57 +01:00
Andrei Eternal 81276fdf85 Add os/cline ver/host info to task metadata & change Task History -> EXPORT to just open the task directory (#7706)
Co-authored-by: Andrei Edell <andrei@nugbase.com>
2025-11-26 13:40:42 -08:00
celestial-vault 164e11aae1 Refresh models in the LiteLLM provider component when the base URL changes (#7705) 2025-11-26 13:03:16 -08:00
Enrico Carlesso 9792f174b1 Adding Grok 4.1 and Grok Code to Cline (#7632) 2025-11-26 12:56:25 -08:00
canvrno a590200c64 Remove native tool calling feature flag (#7704) 2025-11-26 12:41:20 -08:00
Bee 297a45d73a feat(providers): add thinking level config to Vertex and Anthropic model support (#7701)
* feat(providers): add thinking level config to Vertex and Anthropic model support

- Pass thinking level configuration (plan/act mode) to Vertex provider through VertexHandlerOptions interface
- Add support for @-versioned Anthropic model IDs (e.g., claude-haiku-4-5@20251001) in cache control logic

This enables mode-specific thinking level configuration for the Vertex provider by propagating geminiPlanModeThinkingLevel and geminiActModeThinkingLevel settings based on the current mode. Also extends Anthropic model compatibility with newer versioning format.

* reasoning

* sonnet

* yield signature delta
2025-11-26 12:14:19 -08:00
Seb Duerr e84de0ab3c feat: update Cerebras models and speed (#7631) 2025-11-26 11:08:24 -08:00
Ara 515cb81439 fix(terminal): simplify cmd.exe command arguments (#7695)
Remove /s flag and extra quoting from cmd.exe shell arguments.
The previous approach with /s /c and quoted command was causing
issues with proper command execution in Windows cmd.exe.
2025-11-26 11:05:10 -08:00
celestial-vault 550428eabd LiteLLM provider dynamic model fetching (#7679)
* add dynamic model fetching for litellm provider and get rid of manual model config; also implement dynamic modelinfo lookup

* don't clear the models list when a fetch fails
2025-11-26 10:54:51 -08:00
schardosin 22c22a1cfc Fixed SAP AI Core Deployments Mode (#7675)
* fixed sap ai core deployments not working

* isolated chunk to string in a function

* added changeset
2025-11-26 09:26:06 -06:00
Dominic Cooney 8202479cec fix: Add proxy rules, proxy support for McpHub & others (#7659) 2025-11-26 02:06:56 -08:00
Dominic Cooney bcbaa4518d docs: Document proxy settings. (#7637)
* docs: Document proxy settings.

* Update docs/troubleshooting/networking-and-proxies.mdx

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

---------

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
2025-11-26 01:30:28 -08:00
canvrno 9d799643ba npm audit fix docs + webview (#7687) 2025-11-26 00:49:40 -08:00
canvrno 6271c5da37 Remind models of new_task tool parameters when deep_planning is invoked (#7685)
* Remind models of new_task tool parameters when deep_planning is invoked

* cleanup
2025-11-25 21:59:53 -08:00
Auroter 89aeb3db3d feat(telemetry): Add OpenTelemetry metrics infrastructure (#7211)
* feat(telemetry): Add OpenTelemetry metrics infrastructure

Implement OpenTelemetry metrics support (counters, histograms, gauges) while maintaining backward compatibility with PostHog dashboards.

Changes:
- Updated ITelemetryProvider interface with recordCounter, recordHistogram, and recordGauge methods
- Implemented full OpenTelemetry metrics in OpenTelemetryTelemetryProvider with lazy instrument creation
- Added stub implementations in PostHogTelemetryProvider for backward compatibility
- Updated NoOpTelemetryProvider with metric method stubs
- Added comprehensive documentation in METRICS_IMPLEMENTATION_SUMMARY.md

Architecture:
- Dual instrumentation: existing PostHog events remain unchanged
- OpenTelemetry gets proper metrics for quantitative analysis
- Each provider handles metrics appropriately for its platform

Next steps:
- Add helper methods to TelemetryService for recording metrics with standard attributes
- Update high-priority capture methods (tokens, API performance) to call metric recording
- Validate with OpenTelemetry collector setup

* refactor(telemetry): add structured metrics and improve error handling

- Add userId and userEmail tracking to TelemetryService
- Implement helper methods (recordCounter, recordHistogram, recordGauge) with standardized attributes
- Add structured metrics for turns, tokens, costs, cache usage, and API performance
- Remove default case from TelemetryProviderFactory switch to enable exhaustive type checking
- Improve error handling by moving unsupported provider type logging outside switch
- Ensure all metric recordings include standard attributes (userId, email, metadata)

This refactoring enables better observability by recording key metrics (counters, histograms, gauges) across all telemetry providers while maintaining consistent attribute propagation and error isolation.

* fix: add logs back in to no-op provider

* fix: use Logger instead of console

* fix: remove unreachable code

* fix: satisfy compiler for config.type

* fix: remove metrics implementation summary

* chore: update telemetry to include mode in conversation turn events

- Added mode parameter to captureConversationTurnEvent in TelemetryService.
- Updated related telemetry metrics to include mode for better tracking.
- Adjusted tests to verify mode is correctly captured in telemetry events.

* fix: call signatures from merge detritus

* feat(telemetry): add optional description parameter to metric recording methods

Add optional `description` parameter to `recordCounter`, `recordHistogram`,
and `recordGauge` methods across the telemetry service layer. This enables
providers to include descriptive metadata when recording metrics.

Changes:
- Updated ITelemetryProvider interface methods to accept description parameter
- Modified TelemetryService private methods to pass description to providers
- Updated NoOpTelemetryProvider stub implementation
- Enhanced FakeProvider test implementation to capture descriptions
- Updated test assertions to verify description parameter handling

This change maintains backward compatibility as the description parameter
is optional.

* feat(telemetry): update recordGauge method to handle null values for metric retirement

- Modified the `recordGauge` method in `ITelemetryProvider` and its implementations to accept `null` as a valid value, allowing for the retirement of gauge series.
- Updated the `TelemetryService` to ensure proper cleanup of gauge entries when the series ends.
- Enhanced the `FakeProvider` test to validate the new behavior of gauge recording and retirement.
- Adjusted related tests to confirm that previous series are retired correctly when new values are recorded.

This change improves the management of gauge metrics, preventing stale entries and ensuring accurate telemetry data.

* refactor(telemetry): remove user email from telemetry service and related tests

- Removed the user email property from the TelemetryService and its associated methods, streamlining user attribute handling.
- Updated tests to reflect the removal of email, ensuring that metrics and events no longer rely on this attribute.
- Adjusted documentation in ITelemetryProvider to clarify the attributes used in metric recording.

This change enhances data privacy and simplifies the telemetry data model.

* feat(telemetry): enhance task metrics tracking with new counters and histograms

- Introduced new maps to track task turn counts, tool call counts, and error counts.
- Added methods to increment task counters and reset aggregates for better metric management.
- Updated existing telemetry capture methods to utilize the new counters and record histograms for task-related metrics.
- Enhanced tests to validate the new histogram entries for task turns, tool calls, and errors.

This change improves the granularity of telemetry data, allowing for more detailed analysis of task performance and error rates.

* refactor(telemetry): improve token usage handling in TelemetryService

- Updated conditions for recording cache write/read tokens and total cost to check for finite values, ensuring proper handling of undefined or null values.
- Introduced default values for token counts and total cost to prevent potential errors in metric recording.
- Enhanced readability by using descriptive variable names for token values.

This change enhances the robustness of telemetry data collection by ensuring that only valid numeric values are recorded.

* feat(telemetry): centralize metric definitions in TelemetryService

- Introduced a static METRICS object in TelemetryService to define all metric names, improving maintainability and readability.
- Updated existing telemetry recording methods to utilize the new METRICS constants, ensuring consistency across metric names.
- Enhanced tests to validate the use of METRICS constants in assertions for counters and histograms.

This change streamlines metric management and reduces the risk of errors due to hardcoded strings.

* refactor(telemetry): improve gauge observation handling in OpenTelemetryTelemetryProvider

- Replaced direct access to gauge values with a snapshot method to enhance data integrity during observable gauge callbacks.
- Introduced a new `snapshotGaugeSeries` method to encapsulate the logic for retrieving gauge data, improving code readability and maintainability.
- Updated the observable gauge callback to utilize the new snapshot method, ensuring that the latest values are accurately observed.

This change streamlines the process of observing gauge metrics, reducing potential errors and improving the overall telemetry data collection.

* refactor(telemetry): add required parameter to metric recording methods

- Updated `recordCounter`, `recordHistogram`, and `recordGauge` methods across the telemetry service and providers to include an optional `required` parameter, allowing for more flexible metric recording.
- Adjusted implementations in `NoOpTelemetryProvider`, `OpenTelemetryTelemetryProvider`, `PostHogTelemetryProvider`, and `FakeProvider` to handle the new parameter.
- Enhanced tests to validate the behavior of the `required` parameter in metric recording.

This change improves the control over metric recording conditions, enhancing the telemetry data collection process.

* fixed testing system

---------

Co-authored-by: NightTrek <Daniels@dual4t.com>
Co-authored-by: Daniel Steigman <35793213+NightTrek@users.noreply.github.com>
2025-11-25 18:56:30 -08:00
Saoud Rizwan 0caeea1b37 Enhance text overflow handling in TaskHeader component (#7674) 2025-11-25 14:23:39 -08:00
Saoud Rizwan 852a7c9198 Remove TaskTimeline from TaskHeader (#7670) 2025-11-25 13:09:15 -08:00
canvrno c4ef472aeb npm audit fix for glob package vulnerability (#7661) 2025-11-25 10:59:26 -08:00
Bee e22c457d19 fix: improve error property extraction from nested response objects (#7669)
- Remove intermediate response extraction to preserve full error structure
- Add fallback to error.response.message and error.response.status
- Stringify error object in logException for better console output
2025-11-25 10:58:55 -08:00
Juan Pablo Flores c15287ace0 Creates and Refactor Enterprise Docs (#7365)
* Refactor enterprise documentation: reorganize member management and roles, add AWS Bedrock configuration guides, and remove outdated security concerns section.

* Update docs/enterprise-solutions/provider-remote-config/aws-bedrock/admin-configuration.mdx

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

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: reneehuang1 <100229782+reneehuang1@users.noreply.github.com>
2025-11-24 16:49:36 -08:00
Bee d30f54a89c fix: add a refresh guard flag for auth (#7654)
* add a refresh guard flag (

* Implemented atomic refresh handling

Replaced the boolean flag with a Promise

- When a refresh is needed, the code first checks if _refreshPromise exists
- If it exists, concurrent calls wait for the same Promise to complete and then return the refreshed token
- If it doesn't exist, a new Promise is created and stored in _refreshPromise
- The Promise is cleared in the finally block after completion
2025-11-24 15:35:56 -08:00
Bee 56b913d951 fix: feature-flags cache persistence during auth transitions (#7652)
* fix: feature-flags cache persistence during auth transitions

Restructured feature flags polling and cache management to prevent empty cache states during authentication transitions:

- Move cache timestamp update to after successful population in poll() method to ensure cache validity reflects actual data availability
- Remove cache.clear() from reset() method to preserve existing flag values until new data is fetched
- Split polling logic in AuthService to explicitly handle authenticated vs unauthenticated states
- Poll feature flags immediately after reset for authenticated users to ensure cache is populated

This prevents temporary cache misses when users log in/out while maintaining cache freshness guarantees.

* remove reset method and usage in auth flow

Remove the FeatureFlagsService.reset() method and its call during user
authentication. The feature flags polling mechanism is sufficient to
keep flags up-to-date for authenticated users without requiring an
explicit cache reset on auth state changes.

Changes:
- Remove reset() method from FeatureFlagsService
- Remove featureFlagsService.reset() call from AuthService after user identification
- Rely solely on poll() to manage feature flags cache updates
2025-11-24 15:35:45 -08:00
Saoud Rizwan 55a30e0ffa Add support for opus 4.5 global endpoint in bedrock (#7653) 2025-11-24 14:49:23 -08:00
Saoud Rizwan a017f3dfd3 Add Claude Opus 4.5 (#7648) 2025-11-24 13:33:31 -08:00
Saoud Rizwan 41ebe7c9d1 Make npm installation less strict about package-lock needing to be in sync 2025-11-24 12:26:44 -08:00
Bee 4d11f0d2fa feat: implement edit tools conversion adapter [CLIENTS-23] (#7601)
* feat: implement edit tools conversion adapter

Add logic to transform `apply_patch` tool calls into specific `write_to_file` and `replace_in_file` operations. This adapter bridges the gap between patch-based model outputs and atomic file system tools.

- Implement `transformToolCallMessages` to parse patch content:
  - Converts "Add File" patches to `write_to_file`.
  - Converts "Update File" patches to `replace_in_file` with search/replace blocks.
- Add logic to reconstruct tool result messages to match the expected V4A patch format (including `<final_file_content>`).
- Add comprehensive unit tests in `src/core/api/adapters/__tests__/adapters.test.ts` covering add/update operations, multiple tool blocks, and result reconstruction.

* fix typos

* typo
2025-11-23 13:41:18 -05:00
Bee 4baa2474eb fix: ensure reasoning signature is accessible at top level (#7615)
* fix: ensure reasoning signature is accessible at top level

Extract signature from nested summary object and promote it to the top-level
reasoning structure when not already present. This ensures consistent access
to the signature field across all providers, regardless of where it's initially
provided in the reasoning details. The fomatter that each provider runs would then reconstruct the messages in the format they need.

* clean up
2025-11-21 16:36:39 -08:00
Juan Pablo Flores c94e2cf913 Upgrade/workflows docs (#7593)
* feat(workflows): restructure and enhance workflows documentation with best practices and quick start guide

* feat(workflows): enhance documentation with modular workflow practices and new PR review workflow example

* feat(workflows): improve clarity in workflow creation instructions

* Update docs/features/slash-commands/workflows/best-practices.mdx

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

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-11-21 15:45:37 -08:00
Bee dbedc6cfaa chore: clean up prompts and fix model family identifier (#7614)
- Simplified plan_mode_respond instruction text by removing redundant explanations and usage field
- Fixed incorrect MODEL_FAMILY references in native-gpt-5-1 config (was using NATIVE_GPT_5 instead of NATIVE_GPT_5_1)
- Added call_id to reasoning handler output for tracking and OpenAI Response API (unreleased)

The prompt simplification makes the response parameter instruction more concise while maintaining clarity. The model family correction ensures the GPT-5-1 variant uses the correct identifier throughout.
2025-11-21 14:25:18 -08:00
Sarah Fortune 2ac568e649 Add a setting to disable the Add Remote Servers feature in the extension. (#7612)
* Add a setting to disable the `Add Remote Servers` feature in the extension.

* Add setting to unit test

* Rename setting
2025-11-21 12:36:47 -08:00
tjandy98 b13d0e75ea Add support for Perplexity sonar and sonar-pro models to SAP AI Core Provider (#7605)
* Add perplexity models

* Add perplexity models to sap aicore

* Update api.ts

* Update sapaicore.ts

* add changeset

Signed-off-by: tjandy98 <3953059+tjandy98@users.noreply.github.com>

* update maxTokens and contextWindow

Signed-off-by: tjandy98 <3953059+tjandy98@users.noreply.github.com>

---------

Signed-off-by: tjandy98 <3953059+tjandy98@users.noreply.github.com>
2025-11-21 09:42:39 -08:00
Bee 4d395deefd fix: improve error handling and ui for auth failures (#7591) 2025-11-21 08:56:28 -08:00
CandiedUniverse 834a5b1df2 fix(compaction): Use consistent icon for compaction (#7598) 2025-11-21 05:41:58 -08:00
CandiedUniverse 3089233298 feat(hooks): Implement Hooks tab in Rules & Workflows modal [ENG-1325] (#7547)
* feat(hooks): Add hooks tab to Rules & Workflows modal

* feat(hooks): Implement hooks tab content in Rules & Workflows modal

* feat(hooks): Enable creating new hooks in modal from dropdown selection list

* feat(hooks): Change hook template scripts to use bash

* feat(hooks): Windows not yet supported for hooks, so grey-out toggle on windows

* feat(hooks): Improvements to PR as per Cline reviewing the changes before code review

* feat(hooks): Implement tests for hook management (what the UI does under the hood)

* feat(hooks): Changes as per code review feedback from humans
2025-11-20 19:47:39 -08:00
Tomás Barreiro f2b7347a5c Add ApiKeys to the remote config (#7595) 2025-11-20 18:59:49 -08:00
Bee 04bfef75cf feat: replace robot icon with custom cline-bot icon font (#7594)
- Add cline-bot icon font assets (SVG, TTF, WOFF) generated from IcoMoon
- Register custom icon font in VS Code extension manifest
- Replace PNG-based command icon with font-based cline-icon
- Update terminal icon references from generic "robot" to "cline-icon"

This provides a consistent branded icon across the extension and improves visual identity by using the official Cline bot logo instead of the generic robot icon from codicon that was updated by VS Code.
2025-11-20 18:12:44 -08:00
Bee 716e8f236b feat(storybook): add OnboardingView story (#7578)
* chore: clear onboarding models on deactivate

* feat(storybook): add OnboardingView story

- Added OnboardingView component to Storybook with new story
- Integrated onboarding models from shared constants
- Updated MockApp to conditionally render OnboardingView based on onboardingModels state
- Renamed WelcomeScreen story to Welcome for clarity
- Added interaction tests for onboarding buttons (Get Started/Use your own API key)
- Configured onboarding models in mock state to support new story

This enables visual testing and documentation of the user onboarding flow within Storybook.

* Update Storybook missing vscode theme color

* Update task name

* typo
2025-11-20 17:21:28 -08:00
Alex Ker f2ddab71f1 updated baseten docs to include kimi instructions and updated location (#7588)
Co-authored-by: AlexKer <AlexKer@users.noreply.github.com>
2025-11-20 16:04:46 -08:00
canvrno 0b56a45a65 Add thinking level setting for Gemini 3.0 Pro (#7539)
* Added thinking level setting for Gemini 3.0 Pro

* changset
2025-11-20 10:48:31 -08:00
Bee d6ebd2438a fix: parse mentions/commands in tool results and before auto-condense (#7575)
* fix: parse mentions/commands in tool results and before auto-condense

**Changes:**
- Move `loadContext` call before auto-condense check to ensure slash commands and mentions are parsed before context condensing occurs
- Extract parsing logic into reusable `parseInputBlock` helper function
- Add recursive handling for `tool_result` blocks containing nested content arrays
- Remove duplicate `loadContext` calls from conditional branches

**Why:**
Previously, mentions (@file.ts) and slash commands in tool results (like attempt_completion feedback) were not expanded because parsing only handled top-level text blocks. Tool handlers return content arrays within tool_result blocks per Anthropic's API format.

Additionally, `loadContext` was called after the auto-condense check, meaning if condensing was triggered, user commands wouldn't be parsed and could be lost during summarization.

**Result:**
- All user feedback with @mentions or /commands is properly expanded regardless of nesting level
- Commands are detected before context management operations
- Cleaner code flow with single parsing point

* preserve array structure in backward-compatible tool results

When using the backward-compatible "cline" tool use ID, spread array
content directly into userMessageContent instead of wrapping it in
createToolResultBlock. This prevents array content from being
JSON.stringify'd and losing its block structure (e.g., tool_result
blocks with array content).

Previously, array content like [{type: "tool_result", content: [...]}]
was being converted to {type: "text", text: "[...]"}, which prevented
loadContext from properly parsing tool_result blocks.

* clean up

* fix(task): preserve block structure when processing string content

Instead of returning only the processed content, now properly updates the
block.content property with the processed text wrapped in an array and
returns the complete block object. This ensures the block structure is
maintained throughout the processing pipeline rather than being discarded.
2025-11-20 10:38:27 -08:00
Alex Ker 4c07c7e5c5 added Kimi K2 Thinking to static models list and set as default (#7511)
* kimik2 thinking added to static model dropdown

* numerical separators

* don't set kimi k2 thinking as default

---------

Co-authored-by: AlexKer <AlexKer@users.noreply.github.com>
2025-11-20 00:58:19 -08:00
Bee ab66a5fd93 fix: disable switch for required rules to prevent toggling (#7580)
Update RuleRow component to use isDisabled for both the switch disabled state and tooltip visibility, ensuring required rules cannot be toggled off by users. Previously used separate logic that may have miscalibrated disabling for required remote rules.
2025-11-19 23:25:30 -08:00
celestial-vault bd1d6159fc automatically derive openrouter modelinfo based on modelId when calling getModel() (#7568) 2025-11-19 21:16:48 -08:00
Bee 7f2d28716f chore: clear onboarding models on deactivate (#7569) 2025-11-19 18:01:58 -08:00
Toshii 653727db2a updating parser for webfetch to handle current format (#7571) 2025-11-19 17:44:01 -08:00
Bee d3c2f1878d fix(api): attach reasoning details to tool blocks (#7567)
* fix: Centralize reasoning details within thinking blocks

This commit refactors how reasoning details are managed across the system, integrating them directly into `ClineAssistantThinkingBlock` to improve consistency and reduce complexity.

Previously, `reasoning_details` were often explicitly deleted or inconsistently handled, leading to their loss or difficulty in tracking. This change ensures that reasoning details are always associated with their corresponding thinking blocks.

Key changes include:
- `StreamResponseHandler`: The `ReasoningHandler`'s `getCurrentReasoning` method now directly returns a `ClineAssistantThinkingBlock` which encapsulates the reasoning content and its `summary` (formerly `details`). The separate `getThinkingBlock` method has been removed.
- `convertToOpenAiMessages`: Explicit deletion of `part.reasoning_details` for `thinking` parts is replaced by setting it to `undefined` with a comment, indicating that these details are now expected to be part of the thinking block in the stream.
- `Task`: Simplified streaming logic by directly consuming the `ClineAssistantThinkingBlock` from `reasonsHandler.getCurrentReasoning()`. Redundant temporary variables for reasoning content and details have been removed.

This refactoring centralizes the management of reasoning details, providing a more robust and streamlined approach to handling assistant thinking processes.

* fix(api): attach reasoning details to tool blocks and improve logging

Updates validity of reasoning details within tool blocks and enhances debugging visibility.

- Modify `StreamResponseHandler` to append reasoning details/summary to finalized tool use blocks.
- Update `convertToOpenAiMessages` to extract and aggregate `reasoning_details` from tool messages instead of discarding them.
- Add `Logger.debug` calls in `ClineHandler` and OpenAI transformation for better observability of message chunks and conversion.
- Remove redundant `continue` statements in `ClineHandler` stream processing loop.

* clean up

* remove Logger
2025-11-19 17:28:20 -08:00
CellenLee ba92be9401 feat: add kimi-k2-thinking and kimi-k2-thinking-turbo (#7386) 2025-11-19 15:49:46 -08:00
Bee 66eb5a62ba feat: Enable native tool calling for Baseten and Kimi K2 models (#7562)
* feat: Enable native tool calling for Baseten and Kimi K2 models

Introduces native tool calling capabilities for Baseten and Kimi K2 models, aligning with the OpenAI Chat Completions API specification for function calling.

This change includes:
- Updating the `ApiHandler` interface and `createMessage` methods to accept an optional `tools` parameter.
- Implementing a `ToolCallProcessor` to incrementally build and emit tool call payloads from streaming deltas.
- Modifying the `BasetenHandler` to pass `tools` to the Baseten API and process `tool_calls` deltas.
- Updating the `ClineHandler` to process `tool_calls` deltas received from the Kimi K2 model.
- Enhancing the `CompletionStreamChunk` to include `ToolCall` and `ToolCallDelta` types.
- Marking Baseten and Kimi K2 models in their respective definitions with `native_tool_calling: true`.
- Adjustments to streaming logic in handlers to allow multiple delta types (content, tool_calls, reasoning) to be processed from a single chunk.

* add changeset

* clean up
2025-11-19 15:37:10 -08:00
Bee 499ee22b3b fix(task): update UI with final usage after stream completion (#7552)
Ensure the UI displays accurate token usage and costs by updating the API request message when the stream completes. This commit adds a call to updateApiReqMsg followed by saving messages and posting state to the webview, which occurs before finalizing tool calls. This ensures users see the final usage statistics (input/output tokens, cache tokens, and total cost) reflected in the interface immediately after stream processing.
2025-11-19 02:54:31 -08:00
CandiedUniverse 7abeae5019 feat(hooks): Implement TaskComplete hook (#7510) 2025-11-18 23:43:57 -08:00
Bee accf47cb52 fix: await presentAssistantMessage calls to prevent race condition (#7548)
* fix: await presentAssistantMessage calls to prevent race condition

Add await to all presentAssistantMessage() calls to ensure proper
sequencing of message presentation. Previously, the method was called
without awaiting, which could cause race conditions when streaming
tool use content blocks. This ensures that message presentation
completes before continuing execution, particularly important when
handling multiple content blocks or tool interactions.

* revert pr change
2025-11-18 17:48:15 -08:00
Bee 556d3e6f79 fix: rules modal positioning (#7546)
Add overflow-y-auto to the modal container to allow scrolling when content exceeds viewport height. This fixes an issue where modal content would be inaccessible on smaller screens or with large rule sets.
2025-11-18 16:23:48 -08:00
Bee 9e35048db2 feat: add support for Responses API for openai-native provider [ENG-1227] [ENG-1311] (#7504)
* feat: add support for Responses API for openai-native provider [ENG-1227]

- Upgrade openai dependency to v6.9.0 to use the Responses API
- Implement internal handling for reasoning/thinking and redacted output
- Align Anthropic handler message types with the latest SDK interfaces
- Clean up obsolete tooling imports related to tool-use handling
- Enable newer OpenAI capabilities while keeping provider APIs consistent

* Add openai_native_response_api feature flag

* clean up

* clean up 2

* add back gpt-5.1 models

* use call_id
2025-11-18 16:20:45 -08:00
Ara 9b0f2b82ef v3.38.1 Release Notes (#7544) 2025-11-18 14:32:41 -08:00
Bee c2c23054b9 fix: Remove 'signature' from sanitizeAnthropicContentBlock (#7543)
* fix: Remove 'signature' from sanitizeAnthropicContentBlock

Remove 'signature' from sanitizeAnthropicContentBlock as the signature field is required by Anthropic when thinking is enabled.

* Add Changeset

* empty commit

---------

Co-authored-by: Arafatkatze <arafat.da.khan@gmail.com>
2025-11-18 14:10:34 -08:00
Bee 3baaa5c8b4 refactor: replace custom UI toggle with shadcn Switch component (#7308)
* refactor(webview-ui): replace custom UI toggle with shadcn Switch component

- Add @radix-ui/react-switch dependency (v1.2.6) https://ui.shadcn.com/docs/components/switch
- Refactor ClineRulesToggleModal to use Radix Switch instead of VSCode buttons
- Improve button styling with reduced padding and adjusted icon sizes
- Enhance form layout with conditional rendering based on expansion state
- Update input field styling with better focus states and border handling

This change provides a more consistent UI experience by leveraging Radix UI's
accessible Switch component while maintaining the same functionality.

* clean up

* clean up

* update switch color

* adjust

* revert unrelated changes

* size

* toggle

* Update webview-ui/src/components/cline-rules/RuleRow.tsx

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>

---------

Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
2025-11-18 12:39:50 -08:00
github-actions[bot] abafcc7290 Changeset version bump (#7473)
* v3.38.0 Release Notes

- Gemini 3 Pro Preview model
- AquaVoice Avalon model for voice-to-text dictation

- Automatic context truncation when AWS Bedrock token usage rate limits are exceeded
- SAP AI SDK JS packages upgraded to latest major version
- SAP provider OrchestrationClient now matches OrchestrationModuleConfig type and no longer uses invalid promptTemplating property
- Removed new_task tool from system prompts, updated slash command prompts, and added helper function for native tool calling validation

* Update CHANGELOG.md

---------

Co-authored-by: Arafatkatze <arafat.da.khan@gmail.com>
2025-11-18 12:15:10 -08:00
Bee d82aa0add9 feat: add Gemini 3.0 Pro to onboarding list (#7542)
- Add `google/gemini-3-pro-preview` to `CLINE_ONBOARDING_MODELS`.
- Configure model details including context window, pricing, and capabilities (images, prompt cache).
- Enable users to select the new Gemini 3.0 Pro model during setup.
2025-11-18 11:49:08 -08:00
Bee abe4721a0b feat: add thought signature support for Gemini SDK [ENG-1320] (#7536)
* feat: add thought signature support for Gemini SDK

Update @google/genai dependency from v1.15.0 to v1.30.0, including nested deps like google-auth-library. Enhance API interfaces with JSDoc comments and new fields such as signature, id, and redacted_data in ApiStreamThinkingChunk to support thought signatures from Gemini SDK as requested. This improves integration with Gemini's reasoning capabilities and ensures compatibility with updated SDK features.

* add changeset

* meaning val check

* typo

* either

* Do not use think budget with gemini-3
2025-11-18 10:57:53 -08:00
Bee 60d55b69a8 fix: Only update reasoning UI when content changes (#7540)
This commit addresses two issues related to how reasoning messages are processed and displayed.

Previously, the `say` function was called on every iteration of the reasoning stream loop, even if the current chunk contained no new reasoning content. This caused unnecessary UI updates and could lead to errors if a task was cancelled mid-stream. The `say` call is now conditional, only executing when new `chunk.reasoning` is available.

Additionally, the final reasoning block was only appended to the assistant's message history if a signature was present. This meant reasoning could be lost from the UI if the task was cancelled before a signature was generated. The logic is now updated to append the reasoning block if either a message or a signature exists.
2025-11-18 10:57:11 -08:00
Ara d18e0271d3 Fix cancellation for background terminal commands (#7521)
* refactor(task): improve background command cancellation with better error handling

Enhance the cancelBackgroundCommand method with:
- Consolidated early return conditions for cleaner code
- Proper async/await for process termination
- Comprehensive error handling with try-catch blocks for each operation
- Improved logging for termination success/failure scenarios
- Updated cancellation notification message
- Use finally block to ensure notification is always sent

Improve StandaloneTerminalProcess.terminate() with:
- Better guard clauses and early returns
- Enhanced error handling for SIGTERM and SIGKILL operations
- More detailed logging for graceful vs forced termination
- Fallback to SIGKILL if SIGTERM fails immediately

Fix critical issue where terminate() method was not accessible on the merged promise object returned by executeCommand, preventing Task.cancelBackgroundCommand() from properly killing background processes.

* Fix: add cancel ui

* Fix: add cancel ui

* Fix: add cancel ui

* Fix: add cancel ui
2025-11-18 10:41:58 -08:00
Ara af71f9da90 fix: resolve double quote escaping in Windows cmd.exe for Background Exec mode (#7523)
Fixes #7470

When Terminal Execution Mode is set to "Background Exec", commands with
double quotes were being incorrectly escaped on Windows cmd.exe, causing
commands like `echo "\""` or `type "test.txt"` to fail.

The issue was that cmd.exe requires the /s flag and outer quotes when
passing commands with special characters via spawn(). Changed from
`["/c", command]` to `["/s", "/c", `"${command}"`]` for cmd.exe only.

This is a minimal Windows-specific fix that:
- Only affects Windows cmd.exe (PowerShell and Unix shells unchanged)
- Uses standard Windows cmd.exe syntax for proper quote handling
- No changes to process execution flow or behavior
2025-11-18 10:17:37 -08:00
canvrno 2a1c8826aa Add Gemini 3.0 to featuredModels (#7537) 2025-11-18 10:13:06 -08:00
Ara 9a54f2d246 fix(auth): enable provider persistence when applying model changes (#7530)
- Change `UpdateProviderPartial` persist flag from false to true in `applyModelChange`
- Add missing newline at end of state.proto file

This ensures that model changes are properly persisted to storage when users
update their provider configuration through the wizard.
2025-11-18 10:05:01 -08:00
canvrno d928d58a40 Feat: Gemini 3.0 prompt/tool changes (#7532)
* Enhanced Gemini 3.0 support in Cline

* Updated Gemini 3.0 snapshots

* Update src/utils/model-utils.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

* Updated system prompt

* Update src/core/api/providers/gemini.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

* Pricing change, narrowed native tool spec to just gemini 3 on vertex

* Update src/core/prompts/system-prompt/registry/ClineToolSet.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

---------

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>
2025-11-18 10:02:43 -08:00
canvrno 31859b5fda Add Gemini 3.0 to Gemini provider (#7533)
* Added Gemini 3.0 to Gemnini provider

* Add thinking option for Gemini 3.0
2025-11-18 09:20:19 -08:00
Ara 0d5d89e8c7 feat(bedrock): add context window error detection and retry handling (#7515)
* feat(bedrock): add context window error detection and retry handling

Add proper context window error detection for AWS Bedrock provider to enable automatic retry with context truncation. Previously, context window errors were yielded as error text instead of being thrown, preventing the retry mechanism from handling them.

Changes:
- Detect ValidationException errors matching context window patterns in both Converse API and stream processing
- Throw context window errors instead of yielding them as text to trigger retry logic
- Add checkIsBedrockContextWindowError() function to identify Bedrock-specific context limit errors
- Support multiple error message patterns (input too long, context exceed, maximum tokens, etc.)
- Handle nested error structures from Vercel AI SDK and AWS SDK

This enables automatic context management when Bedrock models hit token limits, improving reliability and user experience.

* Fix: raise errors
2025-11-18 09:09:47 -08:00
Bee af34451eec fix: remove h-full from TaskTimeline (#7525) 2025-11-18 02:10:35 -08:00
Bee 027a4f6386 fix: remove automatic native tool calls inference (#7522)
Remove automatic enablement of native tool calls for next-gen models and providers. The feature should be controlled exclusively by explicit user settings (feature flag and global state) rather than being automatically inferred based on the model type during experimental state.

Changes:
- Removed `isNextGenModelProvider` import (no longer needed)
- Eliminated `inferredNativeToolCalls` logic that auto-enabled the feature for next-gen models
- Simplified `enableNativeToolCalls` to only check explicit feature flag and global state settings
- Makes behavior more predictable and user-controlled
2025-11-18 00:49:36 -08:00
Bee 49642882c5 fix: ensure tool arguments are streamed during native tool calling [ENG-1305] (#7508)
* fix: ensure tool arguments are streamed during file operations

- Update userMessageContentReady condition to include streaming tool arguments, not just new content blocks
- Add null check for input object in tool-use-handler to prevent errors
- Improve partial JSON parsing with better fallback handling
- Replace console.log with Logger.debug for tool call chunks
- Add clarifying comments for lock mechanism and streaming behavior

This fixes an issue where new file content was not being properly streamed to tools during write operations, causing the UI to stop updating while tool arguments were being received.

* Add changeset

* typo

* fix(task): reset content index to execute tool blocks during streaming

Reset the currentStreamingContentIndex to the first tool block position
when tool blocks are present in the assistant message. This ensures that
tool blocks are properly executed instead of being skipped when the index
advances past them or goes out of bounds during content streaming.

Previously, the index could advance beyond tool blocks, causing them to
remain unexecuted. Now, when tool blocks are detected, the index is
explicitly set to textBlocks.length (the start of tool blocks) and
userMessageContentReady is set to false to trigger execution.

* fix(task): reset stream index to enable tool block execution

Reset currentStreamingContentIndex to the first tool block position when
tool blocks are present in the assistant message. This ensures that
presentAssistantMessage processes tool blocks instead of text blocks
during streaming, allowing tool blocks to be executed properly while
streaming is in progress.

The index is set to textBlocks.length, which points to where tool blocks
start in the content array, enabling correct sequential processing of
tools during the streaming phase.

* fix(streaming): improve tool execution flow and prevent control flow fall-through

- Add continue statements after yielding content in cline provider to prevent unintended fall-through behavior
- Mark all streamed tool uses as partial to ensure proper state tracking
- Allow complete tool blocks to bypass presentation lock for immediate execution during streaming
- Simplify userMessageContentReady reset logic and remove redundant tool_call check

These changes improve tool execution responsiveness by allowing completed tools to execute without waiting for the presentation lock, while ensuring proper control flow and state management throughout the streaming process.

* revert WriteToFileToolHandler
2025-11-17 23:50:04 -08:00
Bee 21ed6bc432 fix: do not add MCP tool with invalid names as native tools (#7516)
* fix: do not add MCP tool with invalid names as native tools

- Filter out MCP tools with names >= 64 characters to avoid provider API rejection
- Reduce nanoid length from default (21) to 5 characters for server UIDs

Provider APIs reject tool registration when tool names exceed 64 characters.
This change prevents registration errors by skipping tools with long names
and generating shorter UIDs to minimize the constructed name length
(uid + identifier + tool name).

* Add Changeset

* Update src/services/mcp/McpHub.ts

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

* Update src/core/prompts/system-prompt/registry/ClineToolSet.ts

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

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2025-11-17 23:24:17 -08:00
Bee da2689f885 fix: correct TaskTimeline height (#7520)
* fix: correct TaskTimeline height

- Remove TIMELINE_HEIGHT constant in favor of h-full and h-4 utilities
- Replace inline styles with Tailwind classes for better maintainability
- Change timeline blocks from rounded-xs to rounded-full for consistency
- Fix timeline display being cut off due to incorrect height constraints

This refactor resolves the visual layout issue where timeline items were
truncated while improving code consistency by leveraging Tailwind's
utility-first approach throughout the component.

* add changeset
2025-11-17 23:05:09 -08:00
CandiedUniverse 5049326f02 fix(hooks): Fix two minor cancel-resume issues (#7502)
* fix(hooks): Fix cancel: true returned by TaskResume

* fix(hooks): Prevent TaskCancel from being triggered twice by TaskStart cancel and by TaskResume cancel scenarios
2025-11-17 14:44:16 -08:00
Ara b02ce46a57 Fix: Vercel provider token usage (#7481) 2025-11-17 14:15:32 -08:00
Saoud Rizwan de974737c8 fix: improve layout and styling in OnboardingView component for small width viewport (#7391) 2025-11-17 13:35:13 -08:00
Bee d072156e9a fix(account): memoize credits history table component (#7439)
Use React.memo to wrap CreditsHistoryTable, reducing unnecessary re-renders
when props are unchanged and improving performance of the account view that makes it looks like it glinches.
2025-11-17 11:36:19 -08:00
celestial-vault 4939309a09 fix openrouter defaulting modelId when modelInfo is not present (#7482) 2025-11-15 13:50:29 -08:00
CandiedUniverse 1a07ca7906 fix(hooks): Honor '"cancel": true' in hook JSON output (#7479) 2025-11-14 20:37:16 -08:00
Bee c1eefbad3f refactor(api): unify provider message type with ClineStorageMessage (#7478)
* refactor: replace Anthropic MessageParam with ClineStorageMessage type

Replace Anthropic SDK's MessageParam type with the new ClineStorageMessage type across API providers and tests in the effort of storing api messages in a type safe environment that we can expand from and avoid adding undocumented properties to Anthropc Message type that are not visible to the downstream services.

This change:

- Removes dependency on @anthropic-ai/sdk types in multiple providers
- Introduces ClineStorageMessage from shared messages module
- Updates method signatures in Dify, OpenAI, LiteLLM, and ClaudeCode handlers
- Updates corresponding test files to use the new type

This decouples the codebase from Anthropic-specific types and standardizes message handling using an internal storage format across all providers that  improves type-safety, preparing for the properties added by the Response API use.

As ClineStorageMessage is an extension of the Anthropic Message type, everything should work the same with no breaking changes. Green CI is expected.

* clean up
2025-11-14 20:24:56 -08:00
canvrno 1bfdce9b84 Remove new_task from system prompts (#7350)
* Removed new_task from system prompts, updated slash command prompt, added helper function for native tool calling checks

* Update src/core/prompts/system-prompt/registry/PromptBuilder.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

* Update src/core/task/index.ts

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>

* Updates with requested changes for PR #7350

* Updated package-lock.json

---------

Co-authored-by: Bee <68532117+abeatrix@users.noreply.github.com>
2025-11-14 17:57:47 -08:00
canvrno b002cdacdb Maint: package updates (#7477)
* maint: package updates

* Updated download-ripgrep script for compatability with new tar dependency
2025-11-14 16:09:03 -08:00
CandiedUniverse cf4005b25e fix(hooks): Reorder the UI elements so that PreToolUse appears above tool (#7449)
* fix(hooks): Reorder the UI elements so that PreToolUse appears above tool

* fix(hooks): Prevent PreToolUse hook from migrating down the screen

* fix(hooks): PreToolUse reordering should apply to 'tool', 'command', 'use_mcp_server', and 'browser_action_launch'  message types
2025-11-14 15:40:23 -08:00
Bee 1494d145d5 feat: support feature flag payload & remote dynamic onboarding model list (#7454)
* feat: support feature flag payload & dynamic onboarding model list

- Updated proto to use OnboardingModelGroup instead of bool flag for flexible onboarding
- Added getClineOnboardingModels function with caching and remote overrides for dynamic model fetching
- Modified controller to fetch and pass onboarding models to webview
- Updated UI to use dynamic models for selection, enabling flexible onboarding
- Enhanced feature flag service to support non-boolean payloads for better configurability

* clearOnboardingModelsCache
2025-11-14 14:49:05 -08:00
canvrno 1ab4b3cc24 fix:SAP provider type error - See PR #6547 (#7475) 2025-11-14 14:15:13 -08:00
canvrno 535b653228 Added stronger prompting around the use of act_mode_respond (#7448) 2025-11-14 12:12:34 -08:00
Igor Tceglevskii 1335fa5452 Retire firebase (#7362) 2025-11-14 09:29:47 -08:00
yuvalman b2a4395f71 feat: upgrade sap ai-sdk-js packages major version (#6547)
* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version

* feat: upgrade sap-ai-sdk major version
2025-11-14 09:11:03 -08:00
Toshii ae34a3a8c5 adding state variable for clineWebToolsEnabled (noop) (#7455)
* adding state variable for clineWebToolsEnabled

* removing console log
2025-11-14 08:20:01 -08:00
504 changed files with 35557 additions and 9835 deletions
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Add Amazon Nova 2 Lite support
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Add Codex models to OpenAI provider with Responses API support. Native tool calling must be enabled.
+6
View File
@@ -0,0 +1,6 @@
---
"claude-dev": patch
---
Make initial checkpoint commit non-blocking while ensuring safe execution of tools. This improves responsiveness when starting tasks in large repositories by allowing read-only tools to run in parallel with the initial git commit.
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
fix(security): set restrictive file permissions for secrets.json
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Add DeepSeek 3.2 to native tool calling allow list
+6
View File
@@ -0,0 +1,6 @@
---
"claude-dev": patch
---
Fix Gemini Vertex models erroring when thinking parameters are not supported. Only send thinkingConfig for models that have it defined, and only send thinkingLevel for models with supportsThinkingLevel enabled.
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Fix tool use argument handling in Claude Code provider to correctly stringify object arguments for the stream handler.
+6
View File
@@ -0,0 +1,6 @@
---
"claude-dev": patch
---
Refactor OpenAI native handler to use metadata for model capabilities (streaming, system role, tools) instead of hardcoded switch statements.
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Refactor OpenAI provider to centralize temperature configuration and fix missing GPT-5 model settings.
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
hide image from what is new modal
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Add loading state to login buttons
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Prevent simultaneuos refreshes when restoring auth info
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
show mcp output in cline cli conversation
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Xmas Special Santa Cline
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Welcome screen ui enhancements
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
fix(ollama): abort streaming requests when task is cancelled
+5
View File
@@ -0,0 +1,5 @@
---
"claude-dev": patch
---
Log session information when logging out users
+194
View File
@@ -0,0 +1,194 @@
# Hotfix Release
Create a hotfix release by cherry-picking specific commits from main onto the latest release tag.
## Overview
This workflow helps you:
1. Select specific commits from main to include in a hotfix
2. Create a release notes commit on main (changelog + version bump)
3. Cherry-pick everything onto the latest release tag
4. Tag and push the new release
## Step 1: Setup and Gather Information
First, ensure we're on main and up to date:
```bash
git checkout main && git pull origin main
```
Get the latest release tag:
```bash
git tag --sort=-v:refname | head -1
```
## Step 2: Present Commits Since Last Release
Show all commits on main since the last release tag:
```bash
LAST_TAG=$(git tag --sort=-v:refname | head -1)
git log ${LAST_TAG}..HEAD --oneline --format="%h %s (%an)"
```
Also get the commit messages already on the tag (to identify previously cherry-picked commits). Note: Run these as separate commands to avoid shell parsing issues with parentheses in author names:
```bash
LAST_TAG=$(git tag --sort=-v:refname | head -1)
PREV_TAG=$(git tag --sort=-v:refname | head -2 | tail -1)
```
```bash
git log $PREV_TAG..$LAST_TAG --oneline --format="%s"
```
**Present the list** to the user in a numbered format with commit hash, subject, and author. For any commits whose subject line already appears in the tag's history (previously cherry-picked in an earlier hotfix) or are "Release Notes" commits, add `(already in previous hotfix)` or `(release notes - skip)` after them so the user knows to skip those.
Ask which commits to include in the hotfix.
Use the ask_followup_question tool to let the user specify which commits they want (by number or hash).
## Step 3: Analyze Selected Commits
For each selected commit:
1. Get the full commit message: `git show --no-patch --format="%B" <hash>`
2. Get the diff to understand the change: `git show <hash> --stat`
3. Find the associated PR if any: `gh pr list --search "<hash>" --state merged --json number,title --jq '.[0]'`
Build a mental model of what these changes do for the changelog.
## Step 4: Determine New Version Number
Parse the current version from package.json and the last tag:
```bash
LAST_TAG=$(git tag --sort=-v:refname | head -1)
echo "Last release: $LAST_TAG"
cat package.json | grep '"version"'
```
Hotfixes always increment the patch version (e.g., 3.40.0 -> 3.40.1, or 3.40.1 -> 3.40.2).
**Ask the user to confirm the new version number.**
## Step 5: Create Release Notes Commit on Main
On the main branch, create a commit that updates:
1. **CHANGELOG.md** - Add a new section for the hotfix version at the top:
```markdown
## [3.40.1]
- Description of fix 1
- Description of fix 2
```
Write clear, user-friendly descriptions based on your analysis of the commits.
2. **package.json** - Update the version field to the new version
3. **Delete changesets** for the commits being included in the hotfix. This prevents the changeset bot from including duplicate entries in the next regular release.
Find and delete the changeset files associated with the selected commits:
```bash
ls .changeset/
```
Each changeset file in `.changeset/` corresponds to a PR. Read them to identify which ones belong to the commits you're hotfixing, then delete those files.
**Skip running `npm run install:all`** - the automation handles outdated lockfiles.
Commit with message format: `v{VERSION} Release Notes (hotfix)`
In the commit body, mention:
- This is for a hotfix release
- List the cherry-picked commits that will be included
```bash
git add CHANGELOG.md package.json .changeset/
git commit -m "v3.40.1 Release Notes (hotfix)
Hotfix release including:
- <commit1-hash>: <description>
- <commit2-hash>: <description>
"
```
Push to main:
```bash
git push origin main
```
## Step 6: Build the Hotfix on the Tag
Checkout the last release tag (detached HEAD):
```bash
LAST_TAG=$(git tag --sort=-v:refname | head -1)
git checkout $LAST_TAG
```
Cherry-pick the selected commits in order:
```bash
git cherry-pick <commit1-hash>
git cherry-pick <commit2-hash>
# ... etc
```
Finally, cherry-pick the release notes commit you just pushed to main:
```bash
# Get the hash of the release notes commit (should be HEAD of main)
RELEASE_NOTES_COMMIT=$(git rev-parse main)
git cherry-pick $RELEASE_NOTES_COMMIT
```
## Step 7: Tag and Push
After all cherry-picks are applied successfully:
```bash
# Tag the new release
git tag v{VERSION}
# Push the tag to remote
git push origin v{VERSION}
```
## Step 8: Return to Main and Summary
Return to main branch:
```bash
git checkout main
```
**Copy a Slack announcement message to clipboard** with the version and PR links for each included fix:
```
VS Code Hotfix v{VERSION} Published
- Description of fix 1 https://github.com/cline/cline/pull/{PR_NUMBER}
- Description of fix 2 https://github.com/cline/cline/pull/{PR_NUMBER}
```
Present a final summary:
- New version: v{VERSION}
- Tag pushed: yes
- Commits included: (list them)
- Slack message copied to clipboard: yes
Remind the user to:
1. Manually trigger the publish release GitHub Action at: https://github.com/cline/cline/actions/workflows/publish.yml (paste `v{VERSION}` as the tag)
2. Post the Slack message to announce the hotfix
## Important Notes
- This workflow does NOT create a release branch - only tags
- The release notes commit goes to main first, then gets cherry-picked to the tag
- This keeps main's history accurate while allowing hotfix releases from tags
- If cherry-pick conflicts occur, resolve them before continuing
+90
View File
@@ -0,0 +1,90 @@
# Networking & Proxy Support
To ensure Cline works correctly in all environments (VSCode, JetBrains, CLI) and with various network configurations (especially corporate proxies), strictly follow these guidelines for all network activity.
In extension code, do NOT use the global `fetch` or a default `axios` instance. (Note, `shared/net.ts` is exempt from these rules because it sets up the fetch wrappers.) In Webview code, you SHOULD use global `fetch`.
Global `fetch` and default `axios` do not automatically pick up proxy configurations in all environments (specifically JetBrains and CLI). You MUST use the provided utilities in `@/shared/net` which handle proxy agent configuration. In the webview, the browser/embedder handles proxies.
## Guidelines
### 1. Using `fetch`
Instead of `fetch(...)`, import the proxy-aware wrapper:
```typescript
import { fetch } from '@/shared/net'
// Usage is identical to global fetch
const response = await fetch('https://api.example.com/data')
```
### 2. Using `axios`
When using `axios`, you must apply the settings from `getAxiosSettings()`:
```typescript
import axios from 'axios'
import { getAxiosSettings } from '@/shared/net'
const response = await axios.get('https://api.example.com/data', {
headers: { 'Authorization': '...' },
...getAxiosSettings() // <--- CRITICAL: Injects the proxy agent if needed
})
```
### 3. Third-Party Clients (OpenAI, Ollama, etc.)
Most API client libraries allow you to customize the `fetch` implementation. You **MUST** pass the proxy-aware `fetch` to these clients.
**Example (OpenAI):**
```typescript
import OpenAI from "openai"
import { fetch } from "@/shared/net"
this.client = new OpenAI({
apiKey: '...',
fetch, // <--- CRITICAL: Pass our fetch wrapper
})
```
### 4. Tests
Use `mockFetchForTesting` to mock the underlying fetch implementation.
**Example (callback):**
```
import { mockFetchForTesting } from "@/shared/net"
...
let mockFetch = ...
mockFetchForTesting(mockFetch, () => {
// This calls mockFetch
fetch('https://foo.example').then(...)
})
// Original fetch is restored immediately when the call returns.
```
**Example (Promise):**
```
import { mockFetchForTesting } from "@/shared/net"
...
let mockFetch = ...
await mockFetchForTesting(mockFetch, async () => {
await ...
// This calls mockFetch
await fetch('https://foo.example')
...
})
// Original fetch is restored when the Promise from the callback settles
```
## Verification
If you are adding a new network call or integration:
1. Check `@/shared/net.ts` is imported.
2. Ensure `fetch` or `getAxiosSettings` is being used.
3. Verify that third-party clients are configured to use the custom fetch.
@@ -0,0 +1,29 @@
# Address PR Comments
Review and address all comments on the current branch's PR.
## Steps
1. Get the current branch name and find the associated PR:
```bash
gh pr view --json number,title,body
```
2. Understand the PR context:
- Get the full diff: `git diff origin/main...HEAD`
- Read the changed files to understand what the PR is doing
- Read related files if needed to understand the broader context
- Understand the intent and spirit of the changes, not just the code
3. Fetch all PR comments:
- Inline comments: `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments`
- General comments: `gh pr view {pr_number} --json comments,reviews`
4. Present a summary of all comments with your recommendation for each (apply, skip, or respond). Ignore bot noise (changeset-bot, CI status, etc.).
5. **Wait for my approval** before proceeding.
6. After approval:
- Apply code changes and commit
- Reply to comments that were addressed or intentionally skipped
- Push commits
@@ -0,0 +1,49 @@
# Find Best Reviewers for Current Branch
Analyze my current branch to find the best people to review my PR based on **domain expertise** and git history.
## Steps
1. Get the current branch name and verify it's not `main`
2. Get the diff between the current branch and `origin/main`:
- Use `git diff origin/main...HEAD --name-only` to get changed files
- Use `git diff origin/main...HEAD` to understand the nature/spirit of the changes
3. **Identify the domain/feature area** being changed:
- Read the diff carefully to understand WHAT is being changed conceptually (e.g., "slash commands", "authentication", "API client", "UI components")
- This semantic understanding is crucial for finding the right reviewers
4. Find domain experts by searching for related files and their contributors:
- Identify all files related to the feature/domain (not just the ones changed)
- Example: if changing slash commands, find ALL slash-command related files across the codebase
- Use `git log --format="%an <%ae>" -- <related-files-pattern>` to find who has expertise in that domain
5. For additional context, also gather:
- `git blame -L <start>,<end> origin/main -- <file-path>` for exact lines changed
- Recent commit activity on related files
6. Score and rank contributors by:
- **Highest weight: Domain expertise** - who has the most commits to files in this feature area (even files not touched by this PR)
- **Medium weight: Direct file expertise** - commits to the specific files being changed
- **Lower weight: Line-level ownership** - authored the exact lines being modified
7. Exclude myself (check against my git config user.email)
8. Present the top 5 reviewers as an ordered list
## Output Format
Output an ordered list:
1. **Name** - Domain expert: 15 commits to slash-command related files, authored core parsing logic
2. **Name** - 8 commits to affected files, recently added the feature being modified
3. ...
## Commands Reference
```bash
git config user.email
git diff origin/main...HEAD --name-only
git diff origin/main...HEAD
# Find related files for a domain (adjust pattern based on what you learn from the diff)
find . -type f \( -name "*slash-command*" -o -name "*SlashCommand*" \) | head -20
# Get contributors for related files
find . -type f \( -name "*slash-command*" -o -name "*SlashCommand*" \) -print0 | xargs -0 git log --format="%an <%ae>" -- | sort | uniq -c | sort -rn
git log --format="%an <%ae>" -- <file> | sort | uniq -c | sort -rn
git blame -L 10,20 origin/main -- <file>
```
Do NOT ask questions - analyze the changes, identify the domain, and output the reviewer list.
+1
View File
@@ -0,0 +1 @@
../../.claude/commands/hotfix-release.md
+1 -1
View File
@@ -58,7 +58,7 @@ jobs:
cache: "npm"
- name: Install Dependencies
run: npm install changeset
run: npm ci
# Check if there are any new changesets to process
- name: Check for changesets
+2 -2
View File
@@ -74,8 +74,8 @@ jobs:
CLINE_ENVIRONMENT: production
# OpenTelemetry production defaults (can be overridden at runtime)
OTEL_TELEMETRY_ENABLED: ${{ secrets.OTEL_TELEMETRY_ENABLED }}
OTEL_LOGS_EXPORTER: console,otlp
OTEL_METRICS_EXPORTER: console,otlp
OTEL_LOGS_EXPORTER: otlp
OTEL_METRICS_EXPORTER: otlp
OTEL_EXPORTER_OTLP_PROTOCOL: ${{ secrets.OTEL_EXPORTER_OTLP_PROTOCOL }}
OTEL_EXPORTER_OTLP_ENDPOINT: ${{ secrets.OTEL_EXPORTER_OTLP_ENDPOINT }}
OTEL_EXPORTER_OTLP_HEADERS: ${{ secrets.OTEL_EXPORTER_OTLP_HEADERS }}
+4 -4
View File
@@ -60,11 +60,11 @@ jobs:
- name: Install root dependencies
if: steps.root-cache.outputs.cache-hit != 'true'
run: npm ci --include=optional
run: npm install --include=optional
- name: Install webview-ui dependencies
if: steps.webview-cache.outputs.cache-hit != 'true'
run: cd webview-ui && npm ci --include=optional
run: cd webview-ui && npm install --include=optional
- name: Install Publishing Tools
run: npm install -g @vscode/vsce ovsx
@@ -99,8 +99,8 @@ jobs:
ERROR_SERVICE_API_KEY: ${{ secrets.ERROR_SERVICE_API_KEY }}
# OpenTelemetry production defaults (can be overridden at runtime)
OTEL_TELEMETRY_ENABLED: ${{ secrets.OTEL_TELEMETRY_ENABLED }}
OTEL_LOGS_EXPORTER: console,otlp
OTEL_METRICS_EXPORTER: console,otlp
OTEL_LOGS_EXPORTER: otlp
OTEL_METRICS_EXPORTER: otlp
OTEL_EXPORTER_OTLP_PROTOCOL: ${{ secrets.OTEL_EXPORTER_OTLP_PROTOCOL }}
OTEL_EXPORTER_OTLP_ENDPOINT: ${{ secrets.OTEL_EXPORTER_OTLP_ENDPOINT }}
OTEL_EXPORTER_OTLP_HEADERS: ${{ secrets.OTEL_EXPORTER_OTLP_HEADERS }}
+21 -5
View File
@@ -1,6 +1,6 @@
name: Trigger Jetbrains Plugin <-> Cline Tests
on:
pull_request:
pull_request_target:
types: [opened, synchronize, reopened]
permissions:
contents: read
@@ -22,7 +22,24 @@ jobs:
owner: cline
repositories: intellij-plugin
- name: Sanitize untrusted inputs
id: sanitize
env:
RAW_BRANCH_NAME: ${{ github.head_ref }}
RAW_PR_TITLE: ${{ github.event.pull_request.title }}
run: |
# Sanitize branch name for JSON
BRANCH_NAME_JSON=$(jq -n --arg b "$RAW_BRANCH_NAME" '$b')
echo "branch_name=$BRANCH_NAME_JSON" >> $GITHUB_OUTPUT
# Sanitize PR title for JSON
PR_TITLE_JSON=$(jq -n --arg t "$RAW_PR_TITLE" '$t')
echo "pr_title=$PR_TITLE_JSON" >> $GITHUB_OUTPUT
- name: Trigger IntelliJ Plugin Integration Test
env:
BRANCH_NAME: ${{ steps.sanitize.outputs.branch_name }}
PR_TITLE: ${{ steps.sanitize.outputs.pr_title }}
run: |
curl -X POST \
-H "Authorization: Bearer ${{ steps.app-token.outputs.token }}" \
@@ -35,10 +52,10 @@ jobs:
"event_type": "cline-pr-check",
"client_payload": {
"pr_number": "${{ github.event.number }}",
"branch_name": "${{ github.head_ref }}",
"branch_name": $BRANCH_NAME,
"action": "${{ github.event.action }}",
"sha": "${{ github.event.pull_request.head.sha }}",
"pr_title": ${{ toJSON(github.event.pull_request.title) }},
"pr_title": $PR_TITLE,
"pr_url": "${{ github.event.pull_request.html_url }}"
}
}
@@ -47,7 +64,6 @@ jobs:
- name: Log trigger details
run: |
echo "Triggered IntelliJ Plugin integration test for:"
echo " PR #${{ github.event.number }}: ${{ github.event.pull_request.title }}"
echo " Branch: ${{ github.head_ref }}"
echo " PR #${{ github.event.number }}"
echo " Action: ${{ github.event.action }}"
echo " SHA: ${{ github.event.pull_request.head.sha }}"
+21
View File
@@ -165,6 +165,27 @@
},
"console": "integratedTerminal",
"internalConsoleOptions": "openOnSessionStart"
},
{
"name": "Open Storybook",
"type": "node",
"request": "launch",
"runtimeExecutable": "npm",
"runtimeArgs": [
"run",
"storybook"
],
"cwd": "${workspaceFolder}/webview-ui",
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen",
"serverReadyAction": {
"pattern": "Local:.*http://localhost:([0-9]+)",
"uriFormat": "http://localhost:%s",
"action": "openExternally"
},
"env": {
"IS_DEV": "true"
}
}
]
}
+20
View File
@@ -263,6 +263,26 @@
"watch"
],
"command": "rm -rf ${workspaceFolder}/dist/tmp/user && mkdir -p ${workspaceFolder}/dist/tmp/user"
},
{
"type": "npm",
"script": "storybook",
"group": "build",
"problemMatcher": [],
"isBackground": false,
"label": "npm: storybook",
"dependsOn": [
"npm: protos",
"npm: build:webview"
],
"presentation": {
"reveal": "always"
},
"options": {
"env": {
"IS_DEV": "true"
}
}
}
],
"inputs": [
-3
View File
@@ -40,9 +40,6 @@ buf.yaml
.changeset/
.clinerules/
# Include specific file needed for Background Exec mode
!standalone/runtime-files/vscode/enhanced-terminal.js
# Ignore all webview-ui files except the build directory (https://github.com/microsoft/vscode-webview-ui-toolkit-samples/blob/main/frameworks/hello-world-react-cra/.vscodeignore)
webview-ui/src/**
webview-ui/public/**
+78 -6
View File
@@ -1,14 +1,86 @@
# Changelog
## 3.37.1
## [3.40.2]
- cf8dd1c: Comprehensive changes to better support GPT 5.1 - System prompt, tools, deep-planning, focus chain, etc.
- 02abbcf: Add AGENTS.md support
- 855db7d: feat(models): Add free minimax/mimax-m2 model to the model picker
- Fix logout on network errors during token refresh (e.g., opening laptop while offline)
## [3.40.1]
- Fix cost calculation display for Anthropic API requests
## [3.40.0]
- Fix highlighted text flashing when task header is collapsed
- Add X-Cerebras-3rd-Party-Integration header to Cerebras API requests
- Add microwave family system prompt configuration
- Remove tooltips from auto approve menu
- Fix Standalone, ensure cwd is the install dir to find resources reliably
- Fix a bug where terminal commands with double quotes are broken when "Terminal Execution Mode" is set to "Background Exec"
- Add support for slash commands anywhere in a message, not just at the beginning. This matches the behavior of @ mentions for a more flexible input experience.
- Add bottom padding to the last message to fix last response text getting cut off by auto approve settings bar.
- Add default thinking level for Gemini 3 Pro models in Gemini provider
## [3.39.2]
- Fix for microwave model and thinking settings
## [3.39.1]
- Fix Openrouter and Cline Provider model info
## [3.39.0]
- Add Explain Changes feature
- Add microwave Stealth model
- Add Tabbed Model Picker with Recommended and Free tabs
- Add support to View remote rules and workflows in the editor
- Enable NTC (Native Tool Calling) by default
- Bug fixes and improvements for LiteLLM provider
## [3.38.3]
- Task export feature now opens the task directory, allowing easy access to the full task files
- Add Grok 4.1 and Grok Code to XAI provider
- Enabled native tool calling for Baseten and Kimi K2 models
- Add thinking level to Gemini 3.0 Pro preview
- Expanded Hooks functionality
- Removed Task Timeline from Task Header
- Bug fix for slash commands
- Bug fixes for Vertex provider
- Bug fixes for thinking/reasoning issues across multiple providers when using native tool calling
- Bug fixes for terminal usage on Windows devices
## [3.38.2]
- Add Claude Opus 4.5
## [3.38.1]
### Fixed
- Fixed handling of 'signature' field in sanitizeAnthropicContentBlock to properly preserve it when thinking is enabled, as required by Anthropic's API.
## [3.38.0]
### Added
- Gemini 3 Pro Preview model
- AquaVoice Avalon model for voice-to-text dictation
### Fixed
- Automatic context truncation when AWS Bedrock token usage rate limits are exceeded
- Removed new_task tool from system prompts, updated slash command prompts, and added helper function for native tool calling validation
## [3.37.1]
- Comprehensive changes to better support GPT 5.1 - System prompt, tools, deep-planning, focus chain, etc.
- Add AGENTS.md support
- feat(models): Add free minimax/mimax-m2 model to the model picker
## [3.37.0]
## Added
### Added
- GPT-5.1 with model-specific prompting: tailored system prompts, tool usage, focus chain, and deep-planning optimizations
- Nous Research provider with Hermes 4 model family and custom system prompts
@@ -18,7 +90,7 @@
- Expanded HTTP proxy support throughout the codebase
- Improved focus chain prompting for frontier models (Anthropic, OpenAI, Gemini, xAI)
## Fixed
### Fixed
- Duplicate tool results prevention through existence checking
- XML entity escaping in model content processor
+125
View File
@@ -0,0 +1,125 @@
# CLAUDE.md
This file is the secret sauce for working effectively in this codebase. It captures tribal knowledge—the nuanced, non-obvious patterns that make the difference between a quick fix and hours of back-and-forth & human intervention.
**When to add to this file:**
- User had to intervene, correct, or hand-hold
- Multiple back-and-forth attempts were needed to get something working
- You discovered something that required reading many files to understand
- A change touched files you wouldn't have guessed
- Something worked differently than you expected
- User explicitly asks to "add this to CLAUDE.md"
**Proactively suggest additions** when any of the above happen—don't wait to be asked.
**What NOT to add:** Stuff you can figure out from reading a few files, obvious patterns, or standard practices. This file should be high-signal, not comprehensive.
## gRPC/Protobuf Communication
The extension and webview communicate via gRPC-like protocol over VS Code message passing.
**Proto files live in `proto/`** (e.g., `proto/cline/task.proto`, `proto/cline/ui.proto`)
- Each feature domain has its own `.proto` file
- For simple data, use shared types in `proto/cline/common.proto` (`StringRequest`, `Empty`, `Int64Request`)
- For complex data, define custom messages in the feature's `.proto` file
- Naming: Services `PascalCaseService`, RPCs `camelCase`, Messages `PascalCase`
- For streaming responses, use `stream` keyword (see `subscribeToAuthCallback` in `account.proto`)
**Run `npm run protos`** after any proto changes—generates types in:
- `src/shared/proto/` - Shared type definitions
- `src/generated/grpc-js/` - Service implementations
- `src/generated/nice-grpc/` - Promise-based clients
- `src/generated/hosts/` - Generated handlers
**Adding new enum values** (like a new `ClineSay` type) requires updating conversion mappings in `src/shared/proto-conversions/cline-message.ts`
**Adding new RPC methods** requires:
- Handler in `src/core/controller/<domain>/`
- Call from webview via generated client: `UiServiceClient.scrollToSettings(StringRequest.create({ value: "browser" }))`
**Example—the `explain-changes` feature touched:**
- `proto/cline/task.proto` - Added `ExplainChangesRequest` message and `explainChanges` RPC
- `proto/cline/ui.proto` - Added `GENERATE_EXPLANATION = 29` to `ClineSay` enum
- `src/shared/ExtensionMessage.ts` - Added `ClineSayGenerateExplanation` type
- `src/shared/proto-conversions/cline-message.ts` - Added mapping for new say type
- `src/core/controller/task/explainChanges.ts` - Handler implementation
- `webview-ui/src/components/chat/ChatRow.tsx` - UI rendering
## Adding Tools to System Prompt
This is tricky—multiple prompt variants and configs. **Always search for existing similar tools first and follow their pattern.** Look at the full chain from prompt definition → variant configs → handler → UI before implementing.
1. **Add to `ClineDefaultTool` enum** in `src/shared/tools.ts`
2. **Tool definition** in `src/core/prompts/system-prompt/tools/` (create file like `generate_explanation.ts`)
- Define variants for each `ModelFamily` (generic, next-gen, xs, etc.)
- Export variants array (e.g., `export const my_tool_variants = [GENERIC, NATIVE_NEXT_GEN, XS]`)
- **Fallback behavior**: If a variant isn't defined for a model family, `ClineToolSet.getToolByNameWithFallback()` automatically falls back to GENERIC. So you only need to export `[GENERIC]` unless the tool needs model-specific behavior.
3. **Register in `src/core/prompts/system-prompt/tools/init.ts`** - Import and spread into `allToolVariants`
4. **Add to variant configs** - Each model family has its own config in `src/core/prompts/system-prompt/variants/*/config.ts`. Add your tool's enum to the `.tools()` list:
- `generic/config.ts`, `next-gen/config.ts`, `gpt-5/config.ts`, `native-gpt-5/config.ts`, `native-gpt-5-1/config.ts`, `native-next-gen/config.ts`, `gemini-3/config.ts`, `glm/config.ts`, `hermes/config.ts`, `xs/config.ts`
- **Important**: If you add to a variant's config, make sure the tool spec exports a variant for that ModelFamily (or relies on GENERIC fallback)
5. **Create handler** in `src/core/task/tools/handlers/`
6. **Wire up in `ToolExecutor.ts`** if needed for execution flow
7. **Add to tool parsing** in `src/core/assistant-message/index.ts` if needed
8. **If tool has UI feedback**: add `ClineSay` enum in proto, update `src/shared/ExtensionMessage.ts`, update `src/shared/proto-conversions/cline-message.ts`, update `webview-ui/src/components/chat/ChatRow.tsx`
## Modifying System Prompt
**Read these first:** `src/core/prompts/system-prompt/README.md`, `tools/README.md`, `__tests__/README.md`
System prompt is modular: **components** (reusable sections) + **variants** (model-specific configs) + **templates** (with `{{PLACEHOLDER}}` resolution).
**Key directories:**
- `components/` - Shared sections: `rules.ts`, `capabilities.ts`, `editing_files.ts`, etc.
- `variants/` - Model-specific: `generic/`, `next-gen/`, `xs/`, `gpt-5/`, `gemini-3/`, `hermes/`, `glm/`, etc.
- `templates/` - Template engine and placeholder definitions
**Variant tiers (ask user which to modify):**
- **Next-gen** (Claude 4, GPT-5, Gemini 2.5): `next-gen/`, `native-next-gen/`, `native-gpt-5/`, `native-gpt-5-1/`, `gemini-3/`, `gpt-5/`
- **Standard** (default fallback): `generic/`
- **Local/small models**: `xs/`, `hermes/`, `glm/`
**How overrides work:** Variants can override components via `componentOverrides` in their `config.ts`, or provide a custom template in `template.ts` (e.g., `next-gen/template.ts` exports `rules_template`). If no override, the shared component from `components/` is used.
**Example: Adding a rule to RULES section**
1. Check if variant overrides rules: look for `rules_template` in `variants/*/template.ts` or `componentOverrides.RULES` in `config.ts`
2. If shared: modify `components/rules.ts`
3. If overridden: modify that variant's template
4. XS variant is special—has heavily condensed inline content in `template.ts`
**After any changes, regenerate snapshots:**
```bash
UPDATE_SNAPSHOTS=true npm run test:unit
```
Snapshots live in `__tests__/__snapshots__/`. Tests validate across model families and context variations (browser, MCP, focus chain).
## Modifying Default Slash Commands
Three places need updates:
- `src/core/slash-commands/index.ts` - Command definitions
- `src/core/prompts/commands.ts` - System prompt integration
- `webview-ui/src/utils/slash-commands.ts` - Webview autocomplete
## ChatRow Cancelled/Interrupted States
When a ChatRow displays a loading/in-progress state (spinner), you must handle what happens when the task is cancelled. This is non-obvious because cancellation doesn't update the message content—you have to infer it from context.
**The pattern:**
1. A message has a `status` field (e.g., `"generating"`, `"complete"`, `"error"`) stored in `message.text` as JSON
2. When cancelled mid-operation, the status stays `"generating"` forever—no one updates it
3. To detect cancellation, check TWO conditions:
- `!isLast` — if this message is no longer the last message, something else happened after it (interrupted)
- `lastModifiedMessage?.ask === "resume_task" || "resume_completed_task"` — task was just cancelled and is waiting to resume
**Example from `generate_explanation`:**
```tsx
const wasCancelled =
explanationInfo.status === "generating" &&
(!isLast ||
lastModifiedMessage?.ask === "resume_task" ||
lastModifiedMessage?.ask === "resume_completed_task")
const isGenerating = explanationInfo.status === "generating" && !wasCancelled
```
**Why both checks?**
- `!isLast` catches: cancelled → resumed → did other stuff → this old message is stale
- `lastModifiedMessage?.ask === "resume_task"` catches: just cancelled, hasn't resumed yet, this message is still technically "last"
**See also:** `BrowserSessionRow.tsx` uses similar pattern with `isLastApiReqInterrupted` and `isLastMessageResume`.
**Backend side:** When streaming is cancelled, clean up properly (close tabs, clear comments, etc.) by checking `taskState.abort` after the streaming function returns.
+5
View File
@@ -141,6 +141,11 @@ For example, when working with a local web server, you can use 'Restore Workspac
To contribute to the project, start with our [Contributing Guide](CONTRIBUTING.md) to learn the basics. You can also join our [Discord](https://discord.gg/cline) to chat with other contributors in the `#contributors` channel. If you're looking for full-time work, check out our open positions on our [careers page](https://cline.bot/join-us)!
## Enterprise
Get the same Cline experience with enterprise-grade controls: SSO (SAML/OIDC), global policies and configuration, observability with audit trails, private networking (VPC/private link), and self-hosted or on-prem deployments, and enterprise support. Learn more at our [enterprise page](https://cline.bot/enterprise) or [talk to us](https://cline.bot/contact-sales).
## License
[Apache 2.0 © 2025 Cline Bot Inc.](./LICENSE)
+30
View File
@@ -0,0 +1,30 @@
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" >
<svg xmlns="http://www.w3.org/2000/svg">
<metadata>
<json>
<![CDATA[
{
"fontFamily": "cline-bot",
"majorVersion": 1,
"minorVersion": 0,
"fontURL": "https://cline.bot",
"designerURL": "https://cline.bot",
"licenseURL": "https://cline.bot",
"version": "Version 1.0",
"fontId": "cline-bot",
"psName": "cline-bot",
"subFamily": "Regular",
"fullName": "cline-bot",
"description": "Font generated by IcoMoon."
}
]]>
</json>
</metadata>
<defs>
<font id="cline-bot" horiz-adv-x="1024">
<font-face units-per-em="1024" ascent="960" descent="-64" />
<missing-glyph horiz-adv-x="1024" />
<glyph unicode="&#x20;" horiz-adv-x="512" d="" />
<glyph unicode="&#xe900;" glyph-name="cline" data-tags="cline" horiz-adv-x="977" d="M964.553 383.11l-60.285 121.406v69.495c0 115.545-92.939 209.321-207.647 209.321h-102.986c7.536 15.071 11.722 32.654 11.722 51.074 0 64.471-51.912 116.383-115.545 116.383s-115.545-51.912-115.545-116.383 4.186-35.166 11.722-51.074h-102.986c-114.708 0-207.647-93.776-207.647-209.321v-69.495l-61.959-121.406c-5.861-11.722-5.861-26.793 0-38.515l61.959-119.732v-69.495c0-115.545 92.939-209.321 207.647-209.321h415.294c114.708 0 207.647 93.776 207.647 209.321v69.495l60.285 119.732c5.861 11.722 5.861 25.956 0 38.515v0zM426.178 284.311c0-52.749-42.702-95.451-94.613-95.451s-94.613 42.702-94.613 95.451v169.132c0 52.749 42.702 95.451 94.613 95.451s94.613-42.702 94.613-95.451v-169.132zM731.787 284.311c0-52.749-42.702-95.451-94.613-95.451s-94.613 42.702-94.613 95.451v169.132c0 52.749 42.702 95.451 94.613 95.451s94.613-42.702 94.613-95.451v-169.132z" />
</font></defs></svg>

After

Width:  |  Height:  |  Size: 1.7 KiB

Binary file not shown.
Binary file not shown.
+1 -1
View File
@@ -517,7 +517,7 @@ func (pw *ProviderWizard) applyModelChange(provider cline.ApiProvider, modelID s
ModelInfo: modelInfo,
}
return UpdateProviderPartial(pw.ctx, pw.manager, provider, updates, false)
return UpdateProviderPartial(pw.ctx, pw.manager, provider, updates, true)
}
// SwitchToBYOProvider switches to a BYO provider that's already configured.
+1 -1
View File
@@ -92,7 +92,6 @@ func (m *Manager) ListSettings(ctx context.Context) error {
"telemetrySetting",
"planActSeparateModelsSetting",
"enableCheckpointsSetting",
"mcpMarketplaceEnabled",
"shellIntegrationTimeout",
"terminalReuseEnabled",
"mcpResponsesCollapsed",
@@ -111,6 +110,7 @@ func (m *Manager) ListSettings(ctx context.Context) error {
"dictationSettings",
"autoCondenseThreshold",
"autoApprovalSettings",
"hooksEnabled",
}
// Render each field using the renderer
+2 -3
View File
@@ -77,10 +77,9 @@ func RenderField(key string, value interface{}, censor bool) error {
case "mode", "telemetrySetting", "preferredLanguage", "customPrompt",
"defaultTerminalProfile", "mcpDisplayMode", "openaiReasoningEffort",
"planActSeparateModelsSetting", "enableCheckpointsSetting",
"mcpMarketplaceEnabled", "terminalReuseEnabled",
"mcpResponsesCollapsed", "strictPlanModeEnabled",
"terminalReuseEnabled", "mcpResponsesCollapsed", "strictPlanModeEnabled",
"useAutoCondense", "yoloModeToggled", "shellIntegrationTimeout",
"terminalOutputLineLimit", "autoCondenseThreshold":
"terminalOutputLineLimit", "autoCondenseThreshold", "hooksEnabled":
fmt.Printf("%s: %s\n", camelToKebab(key), formatValue(value, key, censor))
return nil
+12 -3
View File
@@ -161,6 +161,14 @@ func (tr *ToolRenderer) generateToolHeader(tool *types.ToolMessage, verbTense st
}
return fmt.Sprintf("### Cline %s `%s`", action, tool.Path)
case string(types.ToolTypeWebSearch):
if verbTense == "wants to" {
action = "wants to search for"
} else {
action = "is searching for"
}
return fmt.Sprintf("### Cline %s `%s`", action, tool.Path)
case string(types.ToolTypeListCodeDefinitionNames):
if verbTense == "wants to" {
action = "wants to list code definitions in"
@@ -207,8 +215,8 @@ func (tr *ToolRenderer) GenerateToolContentPreview(tool *types.ToolMessage) stri
previewMd := fmt.Sprintf("```\n%s\n```", preview)
return tr.renderMarkdown(previewMd)
case string(types.ToolTypeReadFile), string(types.ToolTypeWebFetch), string(types.ToolTypeFileDeleted):
// No preview for read/fetch operations
case string(types.ToolTypeReadFile), string(types.ToolTypeWebFetch), string(types.ToolTypeWebSearch), string(types.ToolTypeFileDeleted):
// No preview for read/fetch/search operations
return ""
default:
@@ -243,7 +251,8 @@ func (tr *ToolRenderer) GenerateToolContentBody(tool *types.ToolMessage) string
string(types.ToolTypeListFilesRecursive),
string(types.ToolTypeListCodeDefinitionNames),
string(types.ToolTypeSearchFiles),
string(types.ToolTypeWebFetch):
string(types.ToolTypeWebFetch),
string(types.ToolTypeWebSearch):
// Use parser for structured output
preview := toolParser.ParseToolResult(tool)
return tr.renderMarkdown(preview)
+7 -76
View File
@@ -221,83 +221,12 @@ func (p *ToolResultParser) ParseCodeDefinitions(content string) string {
// ParseWebFetch formats webFetch tool results with content preview
func (p *ToolResultParser) ParseWebFetch(content, url string) string {
if content == "" {
return fmt.Sprintf("*Fetched content from %s (empty response)*", url)
}
return ""
}
lines := strings.Split(content, "\n")
var result strings.Builder
// Try to extract title
var title string
for _, line := range lines {
trimmed := strings.TrimSpace(line)
if strings.HasPrefix(trimmed, "#") && !strings.HasPrefix(trimmed, "##") {
title = strings.TrimSpace(strings.TrimPrefix(trimmed, "#"))
break
}
}
if title != "" {
result.WriteString(fmt.Sprintf("**Title:** %s\n\n", title))
}
// Show preview of content
result.WriteString("**Preview:**\n")
charCount := 0
maxChars := 500
previewLines := []string{}
for _, line := range lines {
// Skip markdown headers
if strings.HasPrefix(strings.TrimSpace(line), "#") {
continue
}
trimmed := strings.TrimSpace(line)
if trimmed == "" {
continue
}
if charCount+len(trimmed) > maxChars {
break
}
previewLines = append(previewLines, trimmed)
charCount += len(trimmed)
}
result.WriteString(strings.Join(previewLines, " "))
result.WriteString("...\n\n")
// Extract sections
sections := []string{}
for _, line := range lines {
trimmed := strings.TrimSpace(line)
if strings.HasPrefix(trimmed, "##") {
section := strings.TrimSpace(strings.TrimPrefix(trimmed, "##"))
sections = append(sections, section)
if len(sections) >= 5 {
break
}
}
}
if len(sections) > 0 {
result.WriteString("**Sections Found:**\n")
for _, section := range sections {
result.WriteString(fmt.Sprintf("- %s\n", section))
}
result.WriteString("\n")
}
// Word count estimate
wordCount := len(strings.Fields(content))
result.WriteString(fmt.Sprintf("*[Full content: ~%s]*", p.formatWordCount(wordCount)))
return result.String()
// ParseWebSearch formats webSearch tool results
func (p *ToolResultParser) ParseWebSearch(content, query string) string {
return ""
}
// detectLanguage returns syntax highlighting language based on file extension
@@ -365,6 +294,8 @@ func (p *ToolResultParser) ParseToolResult(tool *types.ToolMessage) string {
return p.ParseCodeDefinitions(tool.Content)
case "webFetch":
return p.ParseWebFetch(tool.Content, tool.Path)
case "webSearch":
return p.ParseWebSearch(tool.Content, tool.Path)
default:
return tool.Content
}
+3 -2
View File
@@ -478,8 +478,9 @@ func startClineCore(corePort, hostPort int) (*exec.Cmd, error) {
env = append(env,
fmt.Sprintf("NODE_PATH=%s", nodePath),
"GRPC_TRACE=all",
"GRPC_VERBOSITY=DEBUG",
// These control gRPC debug logging
//"GRPC_TRACE=all",
//"GRPC_VERBOSITY=DEBUG",
"NODE_ENV=development",
)
cmd.Env = env
+5 -2
View File
@@ -394,7 +394,7 @@ func newTaskViewCommand() *cobra.Command {
return taskManager.FollowConversation(ctx, taskManager.GetCurrentInstance(), false)
} else if followComplete {
// Follow until completion
return taskManager.FollowConversationUntilCompletion(ctx)
return taskManager.FollowConversationUntilCompletion(ctx, task.DefaultFollowOptions())
} else {
// Default: show snapshot
return taskManager.ShowConversation(ctx)
@@ -668,7 +668,10 @@ func CreateAndFollowTask(ctx context.Context, prompt string, opts TaskOptions) e
// If yolo mode is enabled, follow until completion (non-interactive)
// Otherwise, follow in interactive mode
if opts.Yolo {
return taskManager.FollowConversationUntilCompletion(ctx)
// Skip active task check since we just created the task
return taskManager.FollowConversationUntilCompletion(ctx, task.FollowOptions{
SkipActiveTaskCheck: true,
})
} else {
return taskManager.FollowConversation(ctx, taskManager.GetCurrentInstance(), true)
}
+15
View File
@@ -0,0 +1,15 @@
package task
// FollowOptions contains options for following a conversation
type FollowOptions struct {
// SkipActiveTaskCheck skips the check for an active task
// This is useful when following a task that was just created to avoid race conditions
SkipActiveTaskCheck bool
}
// DefaultFollowOptions returns the default options for following a conversation
func DefaultFollowOptions() FollowOptions {
return FollowOptions{
SkipActiveTaskCheck: false,
}
}
+2 -1
View File
@@ -251,7 +251,8 @@ func determineAutoApprovalAction(msg *types.ClineMessage) (string, error) {
types.ToolTypeListFilesRecursive,
types.ToolTypeListCodeDefinitionNames,
types.ToolTypeSearchFiles,
types.ToolTypeWebFetch:
types.ToolTypeWebFetch,
types.ToolTypeWebSearch:
return "read_files", nil
case types.ToolTypeEditedExistingFile,
types.ToolTypeNewFileCreated:
+54 -5
View File
@@ -280,8 +280,8 @@ func (m *Manager) CheckSendEnabled(ctx context.Context) error {
// Error types which we allow sending on
errorTypes := []string{
string(types.AskTypeAPIReqFailed), // "api_req_failed"
string(types.AskTypeMistakeLimitReached), // "mistake_limit_reached"
string(types.AskTypeAPIReqFailed), // "api_req_failed"
string(types.AskTypeMistakeLimitReached), // "mistake_limit_reached"
}
isError := false
@@ -753,7 +753,21 @@ func (m *Manager) FollowConversation(ctx context.Context, instanceAddress string
}
// FollowConversationUntilCompletion streams conversation updates until task completion
func (m *Manager) FollowConversationUntilCompletion(ctx context.Context) error {
func (m *Manager) FollowConversationUntilCompletion(ctx context.Context, opts FollowOptions) error {
// Check if there's an active task before entering follow mode
// Skip this check if we just created a task (to avoid race condition where task isn't active yet)
if !opts.SkipActiveTaskCheck {
err := m.CheckSendEnabled(ctx)
if err != nil {
if errors.Is(err, ErrNoActiveTask) {
fmt.Println("No task is currently running.")
return nil
}
// For other errors (like task busy), we can still enter follow mode
// as the user may want to observe the task
}
}
// Enable streaming mode
m.mu.Lock()
m.isStreamingMode = true
@@ -970,6 +984,33 @@ func (m *Manager) processStateUpdate(stateUpdate *cline.State, coordinator *Stre
coordinator.MarkProcessedInCurrentTurn(msgKey)
}
case msg.Say == string(types.SayTypeMcpServerResponse):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !coordinator.IsProcessedInCurrentTurn(msgKey) {
fmt.Println()
m.displayMessage(msg, false, false, i)
coordinator.MarkProcessedInCurrentTurn(msgKey)
}
case msg.Say == string(types.SayTypeMcpNotification):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !coordinator.IsProcessedInCurrentTurn(msgKey) {
fmt.Println()
m.displayMessage(msg, false, false, i)
coordinator.MarkProcessedInCurrentTurn(msgKey)
}
case msg.Say == string(types.SayTypeUseMcpServer):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !coordinator.IsProcessedInCurrentTurn(msgKey) {
fmt.Println()
m.displayMessage(msg, false, false, i)
coordinator.MarkProcessedInCurrentTurn(msgKey)
}
case msg.Say == string(types.SayTypeCheckpointCreated):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !coordinator.IsProcessedInCurrentTurn(msgKey) {
@@ -993,6 +1034,14 @@ func (m *Manager) processStateUpdate(stateUpdate *cline.State, coordinator *Stre
}
}
case msg.Say == string(types.SayTypeCompletionResult):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !msg.Partial && !coordinator.IsProcessedInCurrentTurn(msgKey) {
fmt.Println()
m.displayMessage(msg, false, false, i)
coordinator.MarkProcessedInCurrentTurn(msgKey)
}
case msg.Ask == string(types.AskTypeCommandOutput):
msgKey := fmt.Sprintf("%d", msg.Timestamp)
if !coordinator.IsProcessedInCurrentTurn(msgKey) {
@@ -1239,7 +1288,7 @@ func (m *Manager) updateMode(stateJson string) {
// UpdateTaskAutoApprovalAction enables a specific auto-approval action for the current task
func (m *Manager) UpdateTaskAutoApprovalAction(ctx context.Context, actionKey string) error {
boolPtr := func(b bool) *bool { return &b }
settings := &cline.Settings{
AutoApprovalSettings: &cline.AutoApprovalSettings{
Actions: &cline.AutoApprovalActions{},
@@ -1248,7 +1297,7 @@ func (m *Manager) UpdateTaskAutoApprovalAction(ctx context.Context, actionKey st
// Set the specific action to true based on actionKey
truePtr := boolPtr(true)
switch actionKey {
case "read_files":
settings.AutoApprovalSettings.Actions.ReadFiles = truePtr
+6
View File
@@ -290,6 +290,12 @@ func setSimpleField(settings *cline.Settings, key, value string) error {
return err
}
settings.ActModeAwsBedrockCustomSelected = boolPtr(val)
case "hooks_enabled":
val, err := parseBool(value)
if err != nil {
return err
}
settings.HooksEnabled = boolPtr(val)
// Integer fields
case "request_timeout_ms":
+1
View File
@@ -113,6 +113,7 @@ const (
ToolTypeListCodeDefinitionNames ToolType = "listCodeDefinitionNames"
ToolTypeSearchFiles ToolType = "searchFiles"
ToolTypeWebFetch ToolType = "webFetch"
ToolTypeWebSearch ToolType = "webSearch"
ToolTypeSummarizeTask ToolType = "summarizeTask"
)
+1 -1
View File
@@ -77,7 +77,7 @@ func (s *EnvService) GetHostVersion(ctx context.Context, req *cline.EmptyRequest
return &host.GetHostVersionResponse{
Platform: proto.String("Cline CLI"),
Version: proto.String(""),
Version: proto.String(global.CliVersion),
ClineType: proto.String("CLI"),
ClineVersion: proto.String(global.CliVersion),
}, nil
-48
View File
@@ -1,48 +0,0 @@
# Git
.git
.gitignore
.gitattributes
# Node modules
node_modules
npm-debug.log
# Build artifacts
dist
dist-standalone
build
*.log
# Generated code
src/generated
# CLI build artifacts
cli/bin
cli/dist
# Webview build artifacts
webview-ui/dist
webview-ui/build
# IDE
.vscode
.idea
*.swp
*.swo
# OS
.DS_Store
Thumbs.db
# Documentation
*.md
!README.md
# Tests
tests
*.test.js
*.spec.js
# CI/CD
.github
.gitlab-ci.yml
-49
View File
@@ -1,49 +0,0 @@
FROM node:22-slim
# TARGETARCH enables multi-architecture support without emulation warnings:
# - Docker automatically sets TARGETARCH to the build platform's architecture
# - On arm64 machines (Apple Silicon): TARGETARCH=arm64, uses linux-arm64 binaries
# - On amd64 machines (Intel/AMD): TARGETARCH=amd64, uses linux-x64 binaries
# The corresponding platform-specific binaries and native modules (better-sqlite3)
# are pre-built by scripts/package-standalone.mjs during the build process.
ARG TARGETARCH
# Install only runtime dependencies
RUN apt-get update && apt-get install -y \
git curl ca-certificates \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /opt/cline
# Copy the entire pre-built distribution
COPY dist-standalone/ ./
# Create symlink for Linux native modules
# Map Docker's TARGETARCH (arm64/amd64) to Node's platform naming (x64 for amd64)
RUN if [ "$TARGETARCH" = "amd64" ]; then \
ln -sf /opt/cline/binaries/linux-x64/node_modules/better-sqlite3 /opt/cline/node_modules/better-sqlite3; \
else \
ln -sf /opt/cline/binaries/linux-$TARGETARCH/node_modules/better-sqlite3 /opt/cline/node_modules/better-sqlite3; \
fi
# Set up CLI binaries
# The Linux binaries are already in /opt/cline/bin/ from dist-standalone
# Just need to create symlinks to the platform-specific ones
RUN cd /opt/cline/bin && \
ln -sf cline-linux-$TARGETARCH cline && \
ln -sf cline-host-linux-$TARGETARCH cline-host && \
chmod +x cline-linux-$TARGETARCH cline-host-linux-$TARGETARCH cline cline-host
# Add binaries to PATH
ENV PATH="/opt/cline/bin:${PATH}"
ENV NODE_ENV=production
ENV CLINE_HOME=/root/.cline
RUN mkdir -p $CLINE_HOME
WORKDIR /workspace
EXPOSE 8000
ENTRYPOINT ["/opt/cline/bin/cline"]
CMD ["--help"]
Binary file not shown.

After

Width:  |  Height:  |  Size: 27 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 94 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 93 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 141 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 187 KiB

+13
View File
@@ -254,6 +254,19 @@ COMMANDS
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
@@ -9,7 +9,7 @@ Automate GitHub issue analysis with AI. Mention `@cline` in any issue comment to
<Note>
**New to Cline CLI?** This sample assumes you understand Cline CLI basics and have completed the [Installation Guide](https://docs.cline.bot/cline-cli/installation). If you're new to Cline CLI, we recommend starting with the [GitHub RCA sample](../github-issue-rca) first, as it's simpler and will help you understand the fundamentals before setting up GitHub Actions.
**New to Cline CLI?** This sample assumes you understand Cline CLI basics and have completed the [Installation Guide](https://docs.cline.bot/cline-cli/installation). If you're new to Cline CLI, we recommend starting with the [GitHub RCA sample](./github-issue-rca) first, as it's simpler and will help you understand the fundamentals before setting up GitHub Actions.
</Note>
## The Workflow
+15 -1
View File
@@ -113,6 +113,20 @@ cline instances kill -a
Keep track of instance addresses returned by `cline instance new`. When scripting multiple agents, store these IDs and direct your tasks to the appropriate instance.
</Tip>
## Configuring context window for local providers
For Ollama and LM Studio, you can configure the model context window via CLI:
```bash
# For Ollama
cline config s ollama-api-options-ctx-num=32768
# For 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-configurable—Cline uses each model's built-in context limits automatically.
## Choosing the right flow
- **Interactive mode**: Best for exploring new problems, learning how Cline works, or when you want to review plans before execution
@@ -138,7 +152,7 @@ For in-depth commands and flags, check out the [CLI reference](/cline-cli/cli-re
Understand how YOLO mode works and when to use full automation versus manual approval.
</Card>
<Card title="Task management" icon="clipboard-check" href="/getting-started/task-management">
<Card title="Task management" icon="clipboard-check" href="/features/tasks/task-management">
Learn how Cline tracks and manages tasks, including saving and restoring state from checkpoints.
</Card>
</Columns>
+105 -16
View File
@@ -137,8 +137,16 @@
"features/dictation",
"features/drag-and-drop",
"features/editing-messages",
"features/explain-changes",
"features/focus-chain",
"features/hooks",
{
"group": "Hooks",
"pages": [
"features/hooks/index",
"features/hooks/hook-reference",
"features/hooks/samples"
]
},
"features/multiroot-workspace",
"features/plan-and-act",
{
@@ -146,12 +154,20 @@
"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"
]
},
"features/slash-commands/workflows",
{
"group": "Workflows",
"pages": [
"features/slash-commands/workflows/index",
"features/slash-commands/workflows/quickstart",
"features/slash-commands/workflows/best-practices"
]
},
{
"group": "Task Management",
"pages": [
@@ -189,6 +205,7 @@
"provider-config/fireworks",
"provider-config/zai",
"provider-config/gcp-vertex-ai",
"provider-config/baseten",
{
"group": "AWS Bedrock",
"pages": [
@@ -215,8 +232,7 @@
"provider-config/vscode-language-model-api",
"provider-config/sap-aicore",
"provider-config/vercel-ai-gateway",
"provider-config/requesty",
"provider-config/baseten"
"provider-config/requesty"
]
}
]
@@ -241,32 +257,77 @@
"exploring-clines-tools/remote-browser-support"
]
},
{
"group": "Enterprise",
"pages": [
"enterprise-solutions/overview",
"enterprise-solutions/security-concerns"
]
},
{
"group": "Reference",
"pages": [
"troubleshooting/networking-and-proxies",
"troubleshooting/terminal-quick-fixes",
"troubleshooting/terminal-integration-guide",
"troubleshooting/task-history-recovery",
"more-info/telemetry"
]
}
]
},
{
"tab": "Enterprise",
"icon": "building",
"groups": [
{
"group": "Enterprise Solutions",
"pages": [
"enterprise-solutions/overview",
"enterprise-solutions/onboarding",
"enterprise-solutions/team-management/managing-members",
{
"group": "SaaS Provider Configuration",
"pages": [
"enterprise-solutions/configuration/remote-configuration/overview",
{
"group": "AWS Bedrock",
"pages": [
"enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration",
"enterprise-solutions/configuration/remote-configuration/aws-bedrock/member-configuration"
]
},
{
"group": "LiteLLM",
"pages": [
"enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration",
"enterprise-solutions/configuration/remote-configuration/litellm/member-configuration"
]
},
{
"group": "Google Vertex AI",
"pages": [
"enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration",
"enterprise-solutions/configuration/remote-configuration/google-vertex/member-configuration"
]
}
]
},
{
"group": "Control Other Cline Features",
"pages": [
"enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode"
]
},
{
"group": "Monitoring",
"pages": [
"enterprise-solutions/monitoring/overview",
"enterprise-solutions/monitoring/telemetry",
"enterprise-solutions/monitoring/opentelemetry"
]
}
]
}
]
},
{
"tab": "Learn",
"icon": "graduation-cap",
"href": "https://cline.bot/learn"
},
{
"tab": "Blog",
"icon": "newspaper",
"href": "https://cline.bot/blog"
}
]
},
@@ -328,6 +389,34 @@
{
"source": "/cline-cli/samples",
"destination": "/cline-cli/samples/overview"
},
{
"source": "/features/hooks/real-world-examples",
"destination": "/features/hooks/samples"
},
{
"source": "/enterprise-solutions/configure-AWS-Bedrock-Admin",
"destination": "/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration"
},
{
"source": "/enterprise-solutions/configure-AWS-Bedrock-Member",
"destination": "/enterprise-solutions/configuration/remote-configuration/aws-bedrock/member-configuration"
},
{
"source": "/enterprise-solutions/configure-workOS-authkit",
"destination": "/enterprise-solutions/onboarding"
},
{
"source": "/enterprise-solutions/Onboarding your Organization",
"destination": "/enterprise-solutions/onboarding"
},
{
"source": "/enterprise-solutions/team-management/overview",
"destination": "/enterprise-solutions/team-management/managing-members"
},
{
"source": "/enterprise-solutions/team-management/roles-and-permissions",
"destination": "/enterprise-solutions/team-management/managing-members"
}
],
"search": {
@@ -0,0 +1,105 @@
---
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
@@ -0,0 +1,35 @@
---
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.
@@ -0,0 +1,233 @@
---
title: "YOLO Mode"
sidebarTitle: "YOLO Mode"
description: "Enterprise controls for YOLO Mode autonomous operation"
---
YOLO Mode enables Cline to operate with complete autonomy, auto-approving all actions without user confirmation. For Enterprise administrators, this page covers how to control access to YOLO Mode across your organization.
<Note>
For complete details about YOLO Mode functionality, risks, and best practices, see [YOLO Mode in Features](/features/yolo-mode).
</Note>
## Overview
When YOLO Mode is enabled, Cline automatically approves all operations including file changes, terminal commands, browser actions, and mode transitions. This provides maximum automation speed but removes all safety guardrails.
<Warning>
YOLO Mode is powerful but potentially dangerous. Administrators should carefully consider which teams or users should have access to this feature.
</Warning>
## Enterprise Administrator Configuration
As an Enterprise administrator, you can control whether users in your organization can enable YOLO Mode through remote configuration.
### Disabling YOLO Mode for All Users
Add the following to your remote configuration JSON:
```json
{
"yoloModeAllowed": false
}
```
When `yoloModeAllowed` is set to `false`:
- The YOLO Mode toggle is disabled in all user interfaces
- Users cannot enable YOLO Mode even in their local settings
- This policy applies immediately to all team members
- Enterprise policy takes precedence over individual preferences
### Enabling YOLO Mode for All Users
```json
{
"yoloModeAllowed": true
}
```
When `yoloModeAllowed` is set to `true` or omitted:
- Users can enable or disable YOLO Mode in their local Cline settings
- Individual users make their own decisions about using YOLO Mode
- No organizational restrictions apply
## Enterprise Policy Recommendations
### Recommended Approach
Most organizations should **disable YOLO Mode by default** for the following reasons:
<AccordionGroup>
<Accordion title="Security & Compliance" icon="shield">
YOLO Mode removes all approval gates, potentially allowing:
- Unreviewed code changes to critical systems
- Execution of commands without oversight
- Automated actions that may violate compliance policies
- Risk of data exposure through unmonitored operations
</Accordion>
<Accordion title="Code Quality Control" icon="code">
Without approval prompts:
- Changes happen too quickly to review in real-time
- Mistakes can compound before detection
- Quality gates are bypassed
- Rollback becomes more complex
</Accordion>
<Accordion title="Audit Requirements" icon="clipboard-check">
Many industries require:
- Documented approval trails for code changes
- Clear accountability for automated actions
- Traceable decision-making processes
- YOLO Mode may conflict with these requirements
</Accordion>
</AccordionGroup>
### Exceptions: When to Allow YOLO Mode
Consider enabling YOLO Mode for:
**Sandbox/Development Environments**
- Isolated testing environments
- Personal development machines
- Proof-of-concept projects
- Temporary exploratory work
**Specialized Roles**
- DevOps automation engineers (with proper monitoring)
- Research & development teams in sandboxed environments
- Teams with robust rollback and recovery procedures
**Controlled Use Cases**
- Scripted CI/CD pipelines with comprehensive logging
- Automated testing scenarios
- Demonstration or training environments
## Enterprise Considerations
### Security Implications
When YOLO Mode is enabled in your organization:
**Risk Factors:**
- All tool executions happen automatically without human review
- Potential for rapid propagation of mistakes across multiple files
- Reduced opportunity to catch security vulnerabilities before implementation
- Automated operations may bypass existing security controls
**Mitigations:**
- Implement comprehensive logging and monitoring
- Restrict YOLO Mode to non-production environments
- Require periodic security reviews for teams using YOLO Mode
- Ensure version control and rollback procedures are in place
### Monitoring Requirements
When allowing YOLO Mode in your organization, implement:
**Mandatory Monitoring:**
1. **Real-time Activity Tracking**
- Monitor which users enable YOLO Mode
- Track when YOLO Mode is active
- Log all automated actions taken
2. **Audit Trail Maintenance**
- Preserve complete history of YOLO Mode sessions
- Document what was automated and when
- Maintain records for compliance purposes
3. **Anomaly Detection**
- Alert on unusual patterns of automated actions
- Flag high-risk operations performed automatically
- Monitor for potential security incidents
### Monitoring YOLO Mode Usage
When YOLO Mode is enabled (by policy), track usage through:
**Telemetry Events:**
- Captures when users toggle YOLO Mode on/off
- Records which tasks were executed with YOLO Mode enabled
- Provides aggregate usage statistics across your organization
**Task History:**
- Task metadata indicates whether YOLO Mode was active
- Complete action logs show automated approvals
- Enables post-action review and analysis
**Audit Logs:**
- Standard logging captures all automated decisions
- Tool executions are recorded with timestamps
- Provides compliance trail for regulated environments
## Recommended Policies by Organization Size
### Small Teams (5-20 developers)
- **Default:** Disabled
- **Exceptions:** Allow for individual sandbox environments
- **Monitoring:** Basic telemetry sufficient
### Medium Organizations (20-100 developers)
- **Default:** Disabled
- **Exceptions:** Permit for designated dev/test environments only
- **Monitoring:** Required telemetry + regular audit reviews
### Large Enterprises (100+ developers)
- **Default:** Strictly disabled
- **Exceptions:** Require security approval for each use case
- **Monitoring:** Comprehensive telemetry + real-time alerting + compliance reporting
## Technical Implementation
### Configuration Management
**Centralized Control through Remote Configuration:**
```json
{
"yoloModeAllowed": false,
// Other policies...
}
```
This setting:
- Applies instantly to all connected clients
- Cannot be overridden by individual users
- Persists across Cline restarts
- Is synchronized across all team members
### Policy Enforcement
The enforcement mechanism:
1. Users authenticate with your enterprise configuration server
2. Remote configuration is downloaded and applied
3. Local UI respects enterprise policy settings
4. YOLO Mode toggle is disabled if policy forbids it
5. Users see a message explaining the enterprise restriction
## Compliance Considerations
For organizations in regulated industries:
**SOC 2 Compliance:**
- YOLO Mode may conflict with change management controls
- Document decision to allow/disallow in security policies
- Implement compensating controls if YOLO Mode is permitted
**GDPR/Data Protection:**
- Automated operations must still respect data handling policies
- Ensure YOLO Mode doesn't bypass data protection safeguards
- Maintain audit trails of automated data processing
**Industry-Specific:**
- Financial services: Generally incompatible with Reg requirements
- Healthcare: May violate HIPAA audit trail requirements
- Government: Often conflicts with approval workflow mandates
## Support & Questions
For help configuring YOLO Mode policies:
- Review [Remote Configuration Overview](/enterprise-solutions/configuration/remote-configuration/overview)
- See [Features: YOLO Mode](/features/yolo-mode) for detailed functionality
- Contact your Enterprise support representative
- Join our [Discord](https://discord.gg/cline) for community discussion
@@ -0,0 +1,565 @@
---
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.
@@ -0,0 +1,571 @@
---
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
@@ -0,0 +1,95 @@
---
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.
@@ -0,0 +1,182 @@
---
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>
@@ -0,0 +1,254 @@
---
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>
@@ -0,0 +1,185 @@
---
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>
@@ -0,0 +1,215 @@
---
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>
@@ -0,0 +1,144 @@
---
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>
@@ -0,0 +1,239 @@
---
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>
@@ -0,0 +1,324 @@
---
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>
@@ -0,0 +1,97 @@
---
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.
@@ -0,0 +1,125 @@
---
title: "Configure AWS Bedrock Provider (Admin)"
sidebarTitle: "Configure AWS Bedrock (Admin)"
description: "This guide explains how administrators configure AWS Bedrock as the organization-wide LLM provider for Cline."
---
As an administrator, you can add AWS Bedrock as the organization-wide LLM provider for all Cline users through the hosted admin console. This centralized approach ensures consistent access to Amazon's AI models while maintaining your organization's security and compliance requirements through region controls and basic configuration options.
## Before You Begin
To get started with setting up AWS Bedrock as your organization's LLM provider, you'll need a few items in place.
**Administrator access to the Cline Admin console**
You need admin privileges to enforce provider settings across your organization. If you can navigate to **Settings → Cline Settings** in the admin console at [app.cline.bot](https://app.cline.bot), you have the right access level.
**AWS Bedrock account with the right permissions**
Your AWS account needs specific Bedrock permissions to work with Cline.
<Note>
If you don't have direct AWS access, coordinate with your cloud team to get these permissions set up before proceeding.
</Note>
**Your preferred AWS region**
Choose your primary AWS region carefully since this will be enforced for all users.
<Tip>
Check which models are available in your region first. Some newer models might not be available in all regions yet.
</Tip>
<Frame>
<img
src="https://storage.googleapis.com/cline-static-assets-prod/assets/AWS%20Remote%20Config.gif"
/>
</Frame>
## Configuration Steps
<Steps>
<Step title="Access Cline Settings">
Navigate to [app.cline.bot](https://app.cline.bot) and sign in with your administrator account. Go to **Settings → Cline Settings**.
<Info>
You should see the provider configuration options if you have the correct admin access level.
</Info>
</Step>
<Step title="Enable Remote Provider Configuration">
Toggle on **Enable settings** to reveal the remote provider configuration options. This allows you to enforce provider settings across your organization.
</Step>
<Step title="Select AWS Bedrock as the API Provider">
Open the **API Provider** dropdown menu and select **Amazon Bedrock**. This will open the Bedrock configuration panel where you'll configure all your organization-wide settings.
</Step>
<Step title="Configure Bedrock Settings">
The configuration panel includes several settings that control how Bedrock works for your organization. Configure what you need:
<AccordionGroup>
<Accordion title="Region (required)">
Enter your preferred AWS region like `us-west-2` or `us-east-1`. This region will be enforced for all organization members.
[View AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)
<Tip>
For most organizations, `us-east-1` or `us-west-2` are recommended as they have the best model availability.
</Tip>
</Accordion>
<Accordion title="Custom VPC Endpoint (optional)">
If your organization uses a private VPC endpoint for Bedrock, specify it here to ensure all API calls go through your network infrastructure.
[Learn more about AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html)
</Accordion>
<Accordion title="Cross-region Inference (optional)">
Enable this to let Bedrock automatically route requests to other regions when your primary region has capacity constraints. Useful for maintaining availability during high-demand periods.
[Learn more about Inference Profiles](https://docs.aws.amazon.com/bedrock/latest/userguide/inference-profiles-support.html)
</Accordion>
<Accordion title="Global Inference Profile (optional)">
Turn this on to use AWS's global inference routing, which automatically directs requests to the optimal region based on availability and latency.
</Accordion>
<Accordion title="Prompt Caching (optional)">
Enable prompt caching to reduce costs and latency. Bedrock caches portions of prompts that remain consistent across requests, making repeated interactions faster and cheaper.
[Learn more about Prompt Caching](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html)
</Accordion>
</AccordionGroup>
</Step>
<Step title="Save Configuration">
After configuring your settings, close the provider configuration panel and click **Save** on the settings page to persist your changes.
Once saved, all organization members signed into the Cline extension will automatically use AWS Bedrock with your configured settings. They won't be able to select other providers or switch to their personal Cline accounts.
<Warning>
Members can't switch to personal Cline accounts or join other organizations once remote configuration is enabled. This ensures consistent provider usage across your team.
</Warning>
</Step>
</Steps>
## Verification
To verify the configuration:
1. Check that the provider shows as "Amazon Bedrock" in the Enabled provider field
2. Confirm the settings persist after refreshing the page
3. Test with a member account to ensure they see only Bedrock as a provider
## Troubleshooting
**Members don't see the configured provider**
Ensure you clicked Save after closing the configuration panel. Verify the member account belongs to the correct organization.
**Configuration changes don't persist**
Make sure to click the Save button on the main settings page, not just close the configuration panel.
**Need to change regions later**
You can update the region at any time. Members will need to ensure their local AWS credentials have access to the new region. For more information, refer to the [AWS Bedrock Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html).
For further details, consult the [AWS Bedrock Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) and coordinate with your internal cloud team.
@@ -0,0 +1,131 @@
---
title: "Configure AWS Bedrock in VS Code (Members)"
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 settings—you just need to add your credentials to get started.
## Before You Begin
To successfully connect to your organization's AWS Bedrock setup, you'll need a few things ready.
**Cline extension installed and configured**
The Cline extension must be installed in VS Code and you need to be signed into your organization account. If you haven't installed Cline yet, follow our [installation guide](/getting-started/installing-cline).
<Info>
**Quick Check**: Open the Cline panel in VS Code. If you see your organization name in the bottom left, you're signed in correctly.
</Info>
**AWS credentials with Bedrock access**
You need AWS credentials that have permission to access Bedrock in your organization's configured region.
<Note>
If you don't have AWS credentials yet, reach out to your IT or cloud team to get access keys or AWS CLI profiles configured with the necessary Bedrock permissions.
</Note>
<Frame>
<img
src="https://storage.googleapis.com/cline-static-assets-prod/assets/VS%20Code%20Bedrock%20API%20Key.gif"
/>
</Frame>
## Configuration Steps
<Steps>
<Step title="Open Cline Settings">
Open VS Code and access the Cline settings panel using either of these methods:
- Click the settings icon (⚙️) in the Cline panel
- Click on the API Provider dropdown located directly below the chat area (it will display as `bedrock.anthropic.claude-sonnet-4-20250514-v1:0` or similar)
</Step>
<Step title="Select Your Authentication Method">
Choose one of the following credential methods to authenticate with AWS Bedrock:
<AccordionGroup>
<Accordion title="AWS Bedrock API Key">
Use dedicated AWS access keys specifically for Bedrock access.
[Learn more about AWS Bedrock API Keys](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html)
1. Select the **API Key** radio button
2. Enter your AWS Access Key ID and Secret Access Key
3. These credentials are stored locally and used only by the VS Code extension
</Accordion>
<Accordion title="AWS Profile">
Use an existing AWS CLI profile configured on your machine.
[Learn more about AWS CLI Profiles](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html)
1. Select the **AWS Profile** radio button
2. Choose or enter the profile name from your `~/.aws/credentials` file
3. Cline will use the credentials associated with that profile
</Accordion>
<Accordion title="AWS Credentials">
Use your default AWS credential chain (environment variables, EC2 instance roles, etc.).
1. Select the **AWS Credentials** radio button
2. Cline will automatically detect credentials from your environment using the standard AWS credential provider chain
</Accordion>
</AccordionGroup>
<Note>
The AWS Region is preconfigured by your administrator and does not need to be set in the extension.
</Note>
</Step>
<Step title="Verify Configuration">
After selecting your authentication method, the extension will display checkmarks for enabled features:
- ✓ Supports images
- ✓ Supports browser use
- ✓ Supports prompt caching
Additional settings like cross-region inference and global inference profile will be locked (shown with a lock icon 🔒) as they're controlled by your administrator.
</Step>
<Step title="Test the Connection">
Send a test message in Cline to verify your credentials work correctly with the configured Bedrock region.
<Tip>
**Testing Recommendation**
It is recommended to test the connection in plan mode to verify everything works correctly before using it for actual tasks.
</Tip>
</Step>
</Steps>
## Troubleshooting
**Authentication errors ("Access Denied" or "Invalid Credentials")**
Verify your chosen credential method has the necessary IAM permissions to call Bedrock in the configured region. Required permissions include `bedrock:InvokeModel` and `bedrock:InvokeModelWithResponseStream`. For more information, refer to [AWS Bedrock IAM Permissions](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html).
**Region-related errors or "model not available"**
Ask your administrator to confirm which region is configured for your organization. Ensure your AWS credentials have access to Bedrock in that specific region. [View AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)
**Don't see AWS Bedrock as an option**
Confirm you're signed into the correct Cline organization. Verify your administrator has saved the Bedrock configuration. Try signing out and back into the extension.
**AWS Credentials option not finding credentials**
Verify AWS CLI is installed and configured with `aws configure` ([AWS CLI Installation Guide](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)). Check that credentials are present in `~/.aws/credentials`. For EC2/ECS environments, ensure IAM roles are properly attached. If using environment variables, set `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`.
## Security Best Practices
When configuring your AWS credentials, follow these security guidelines:
- Use IAM roles with minimum required permissions ([AWS IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html))
- Rotate access keys regularly if using the API Key method
- Never store credentials in code or version control
- Prefer AWS Profile method for better credential management
- Consider using AWS SSO/federated roles for enhanced security
Your organization administrator controls which models are available. The extension will automatically display available models based on your region's Bedrock configuration. For more information about available models, refer to the [AWS Bedrock Model Access documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html).
For further assistance, consult the [AWS Bedrock Documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) and coordinate with your organization's cloud administrator.
@@ -0,0 +1,112 @@
---
title: "Configure Google Vertex AI Provider (Admin)"
sidebarTitle: "Configure Google Vertex (Admin)"
description: "This guide explains how administrators configure Google Vertex AI as the organization-wide LLM provider for Cline."
---
As an administrator, you can add Google Vertex AI as the organization-wide LLM provider for all Cline users through the hosted admin console. This centralized approach ensures consistent access to Google's Gemini models while maintaining your organization's project boundaries and regional settings.
## Before You Begin
To get started with setting up Google Vertex AI as your organization's LLM provider, you'll need a few items in place.
**Administrator access to the Cline Admin console**
You need admin privileges to enforce provider settings across your organization. If you can navigate to **Settings → Cline Settings** in the admin console at [app.cline.bot](https://app.cline.bot), you have the right access level.
**Google Cloud Project with Vertex AI enabled**
You need a Google Cloud project with the Vertex AI API enabled and appropriate models accessible.
<Note>
If you haven't set up Google Cloud or Vertex AI yet, work with your cloud team to enable the Vertex AI API and ensure necessary quotas are configured.
</Note>
**Project configuration details**
You'll need your Google Cloud project ID and preferred region for Vertex AI model access.
<Tip>
Service accounts should have the minimum IAM permissions needed for Vertex AI access to follow security best practices.
</Tip>
## Configuration Steps
<Steps>
<Step title="Access Cline Settings">
Navigate to [app.cline.bot](https://app.cline.bot) and sign in with your administrator account. Go to **Settings → Cline Settings**.
<Info>
You should see the provider configuration options if you have the correct admin access level.
</Info>
</Step>
<Step title="Enable Remote Provider Configuration">
Toggle on **Enable settings** to reveal the remote provider configuration options. This allows you to enforce provider settings across your organization.
</Step>
<Step title="Select Google Vertex AI as the API Provider">
Open the **API Provider** dropdown menu and select **Google Vertex AI**. This will open the Vertex AI configuration panel where you'll configure all your organization-wide settings.
</Step>
<Step title="Configure Vertex AI Settings">
The configuration panel includes settings that control how Vertex AI works for your organization:
<AccordionGroup>
<Accordion title="Project ID (required)">
Enter your Google Cloud project ID where Vertex AI is enabled. This project will be used for all AI model requests from your organization members.
<Tip>
Use a dedicated project for AI workloads to better track usage and costs. Ensure the project has sufficient quotas for your team's expected usage.
</Tip>
</Accordion>
<Accordion title="Region (required)">
Select the Google Cloud region where your Vertex AI models should be accessed. Common options include `us-central1`, `us-east4`, or `europe-west4`.
[View Google Cloud Regions](https://cloud.google.com/docs/geography-and-regions)
<Note>
Choose a region close to your team's location for optimal performance. Some models may not be available in all regions.
</Note>
</Accordion>
</AccordionGroup>
</Step>
<Step title="Save Configuration">
After configuring your settings, close the provider configuration panel and click **Save** on the settings page to persist your changes.
Once saved, all organization members signed into the Cline extension will automatically use Google Vertex AI with your configured settings. They won't be able to select other providers or switch to their personal Cline accounts.
<Warning>
Members can't switch to personal Cline accounts or join other organizations once remote configuration is enabled. This ensures consistent provider usage across your team.
</Warning>
</Step>
</Steps>
## Verification
To verify the configuration:
1. Check that the provider shows as "Google Vertex AI" in the Enabled provider field
2. Confirm the settings persist after refreshing the page
3. Test with a member account to ensure they see only Vertex AI as a provider
4. Verify that Gemini models are available in the model dropdown
## Troubleshooting
**Members don't see the configured provider**
Ensure you clicked Save after closing the configuration panel. Verify the member account belongs to the correct organization and that your Google Cloud project has Vertex AI API enabled.
**Project access errors**
Verify the project ID is correct and that Vertex AI API is enabled. Check that the project has appropriate billing configured and hasn't exceeded quotas.
**Regional availability issues**
Confirm the selected region supports the Gemini models you want to use. Some newer models may only be available in specific regions.
**Configuration changes don't persist**
Make sure to click the Save button on the main settings page, not just close the configuration panel.
**Need to change project or region later**
You can update these settings at any time. Members will need to ensure their local Google Cloud credentials have access to the new project/region.
For further details, consult the [Google Cloud Vertex AI Documentation](https://cloud.google.com/vertex-ai/docs) and coordinate with your internal cloud team.
@@ -0,0 +1,177 @@
---
title: "Configure Google Vertex AI in VS Code (Members)"
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 settings—you just need to add your credentials to get started.
## Before You Begin
To successfully connect to your organization's Google Vertex AI setup, you'll need a few things ready.
**Cline extension installed and configured**
The Cline extension must be installed in VS Code and you need to be signed into your organization account. If you haven't installed Cline yet, follow our [installation guide](/getting-started/installing-cline).
<Info>
**Quick Check**: Open the Cline panel in VS Code. If you see your organization name in the bottom left, you're signed in correctly.
</Info>
**Google Cloud credentials with Vertex AI access**
You need Google Cloud credentials that have permission to access Vertex AI in your organization's configured project and region.
<Note>
If you're unsure which method to use, check with your administrator or IT team about how your organization has configured Google Cloud access.
</Note>
## Configuration Steps
<Steps>
<Step title="Open Cline Settings">
Open VS Code and access the Cline settings panel using either of these methods:
- Click the settings icon (⚙️) in the Cline panel
- Click on the API Provider dropdown located directly below the chat area (it will display as `vertex_ai/gemini-pro` or similar)
</Step>
<Step title="Select Your Authentication Method">
Choose one of the following credential methods to authenticate with Google Vertex AI:
<AccordionGroup>
<Accordion title="Service Account Key">
Use a service account JSON key file for Vertex AI access.
[Learn more about Service Account Keys](https://cloud.google.com/iam/docs/service-accounts)
1. Select the **Service Account Key** authentication method
2. Upload or paste your service account JSON key content
3. The key should have `aiplatform.user` or similar Vertex AI permissions
4. These credentials are stored locally and used only by the VS Code extension
</Accordion>
<Accordion title="Google Cloud SDK">
Use the Google Cloud SDK installed on your machine with your authenticated account.
[Learn more about Google Cloud SDK](https://cloud.google.com/sdk/docs/install)
1. Select the **Google Cloud SDK** authentication method
2. Ensure you've authenticated with `gcloud auth login`
3. Verify your account has access to the organization's Vertex AI project
4. Cline will use your default Google Cloud credentials automatically
</Accordion>
<Accordion title="Application Default Credentials">
Use Google Cloud's application default credentials (ADC) chain.
1. Select the **Application Default Credentials** method
2. Ensure ADC is properly configured in your environment
3. This works well for environments where Google Cloud credentials are managed centrally
4. Cline will automatically detect credentials from your environment
</Accordion>
</AccordionGroup>
<Note>
The Google Cloud Project ID and Region are preconfigured by your administrator and do not need to be set in the extension.
</Note>
</Step>
<Step title="Verify Configuration">
After selecting your authentication method, the extension will display checkmarks for enabled features:
- ✓ Supports images (for Gemini Pro Vision and similar models)
- ✓ Supports multimodal inputs
- ✓ Supports function calling (for supported models)
The project ID and region settings will be locked (shown with a lock icon 🔒) as they're controlled by your administrator.
</Step>
<Step title="Test the Connection">
Send a test message in Cline to verify your credentials work correctly with the configured Vertex AI project and region.
<Tip>
**Testing Recommendation**
Try a simple test like "Hello" first to verify basic connectivity, then test multimodal capabilities if needed by sharing an image.
</Tip>
</Step>
</Steps>
## Model Usage
### Available Model Families
The models available through your organization's Vertex AI setup typically include:
**Gemini Models:**
- **Gemini Pro**: Advanced reasoning, code generation, and multimodal capabilities
- **Gemini Pro Vision**: Image understanding and visual question answering
- **Gemini Ultra**: Most capable model for complex reasoning tasks
**PaLM Models:**
- **PaLM 2 for Text**: Text generation and completion
- **PaLM 2 for Chat**: Conversational AI interactions
- **Codey**: Specialized for code generation and explanation
**Specialized Models:**
- **Text Embedding**: For semantic search and similarity tasks
- **Custom Models**: Your organization's fine-tuned variants (if available)
### Model Selection Strategy
Choose models based on your development needs:
- **General tasks**: Use Gemini Pro for most text and reasoning tasks
- **Visual content**: Use Gemini Pro Vision when working with images
- **Code-heavy work**: Use Codey models for programming tasks
- **Complex reasoning**: Use Gemini Ultra for sophisticated problem-solving
- **Embedding tasks**: Use Text Embedding models for semantic operations
### Multimodal Capabilities
Take advantage of Vertex AI's multimodal features:
- **Image Analysis**: Upload images directly in Cline for analysis
- **Visual Question Answering**: Ask questions about images
- **Code Screenshots**: Get explanations of code from screenshots
- **Document Processing**: Analyze charts, graphs, and visual data
## Troubleshooting
**Google Vertex AI not available as provider option**
Confirm you're signed into the correct Cline organization. Verify your administrator has saved the Vertex AI configuration and that you have the latest version of the Cline extension.
**Authentication errors ("Access Denied" or "Invalid Credentials")**
Verify your chosen credential method has the necessary IAM permissions to access Vertex AI in the configured project and region. Required permissions include `aiplatform.endpoints.predict` and `aiplatform.models.predict`.
**Project access errors**
Ask your administrator to confirm which Google Cloud project is configured for your organization. Ensure your Google Cloud credentials have access to that specific project.
**Regional access errors**
Verify your credentials have access to Vertex AI in the configured region. Some models may not be available in all regions, so confirm with your administrator about the selected region.
**Google Cloud SDK authentication issues**
Ensure Google Cloud SDK is properly installed and authenticated:
```bash
gcloud auth login
gcloud config set project YOUR_PROJECT_ID
gcloud auth application-default login
```
**Service account key errors**
Verify the service account key is valid and hasn't expired. Check that the service account has the proper Vertex AI permissions in your organization's project. Ensure the JSON key file is properly formatted and contains all required fields.
**Model access errors or "model not found"**
Some models may not be enabled in your organization's project or region. Contact your administrator if specific models are not available. Verify that your organization has enabled the models you're trying to use in the Google Cloud Console.
## Security Best Practices
When configuring your Google Cloud credentials, follow these security guidelines:
- Use service accounts with minimal required permissions for Vertex AI access
- Rotate service account keys regularly (every 90 days recommended)
- Never store credentials in code or version control
- Use Google Cloud SDK where possible for better credential management
- Consider using Workload Identity for containerized development environments
- Report any suspicious activity or unauthorized access attempts
Your organization administrator controls which models and regions are available. The extension will automatically display available models based on your project's configuration and regional availability.
For more information about Google Cloud authentication and Vertex AI permissions, refer to the [Google Cloud IAM Documentation](https://cloud.google.com/iam/docs) and coordinate with your organization's cloud administrator.
@@ -0,0 +1,120 @@
---
title: "Configure LiteLLM Provider (Admin)"
sidebarTitle: "Configure LiteLLM (Admin)"
description: "This guide explains how administrators configure LiteLLM as the organization-wide LLM provider for Cline."
---
As an administrator, you can add LiteLLM as the organization-wide LLM provider for all Cline users through the hosted admin console. This centralized approach provides unified access to multiple AI models through your LiteLLM proxy interface.
## Before You Begin
To get started with setting up LiteLLM as your organization's LLM provider, you'll need a few items in place.
**Administrator access to the Cline Admin console**
You need admin privileges to enforce provider settings across your organization. If you can navigate to **Settings → Cline Settings** in the admin console at [app.cline.bot](https://app.cline.bot), you have the right access level.
<Info>
**Quick Check**: Try accessing the settings page now. If you can see the provider configuration options, you're good to go.
</Info>
**LiteLLM proxy instance running**
You need a deployed LiteLLM proxy that your team can access. This can be self-hosted or managed through a cloud provider.
<Note>
If you haven't deployed LiteLLM yet, work with your infrastructure team to set up a LiteLLM proxy instance.
</Note>
**LiteLLM endpoint details**
You'll need the base URL of your LiteLLM proxy and optionally a master key if your deployment requires authentication.
<Tip>
Ensure your LiteLLM proxy is accessible from your team's development environments and has the models you want to make available configured.
</Tip>
## Configuration Steps
<Steps>
<Step title="Access Cline Settings">
Navigate to [app.cline.bot](https://app.cline.bot) and sign in with your administrator account. Go to **Settings → Cline Settings**.
<Info>
You should see the provider configuration options if you have the correct admin access level.
</Info>
</Step>
<Step title="Enable Remote Provider Configuration">
Toggle on **Enable settings** to reveal the remote provider configuration options. This allows you to enforce provider settings across your organization.
</Step>
<Step title="Select LiteLLM as the API Provider">
Open the **API Provider** dropdown menu and select **LiteLLM**. This will open the LiteLLM configuration panel where you'll configure all your organization-wide settings.
</Step>
<Step title="Configure LiteLLM Settings">
The configuration panel includes settings that control how LiteLLM works for your organization:
<AccordionGroup>
<Accordion title="Base URL (required)">
Enter your LiteLLM proxy endpoint URL. This should be the full URL where your LiteLLM proxy is accessible, such as `https://litellm.yourcompany.com` or `http://your-proxy:4000`.
<Tip>
Use HTTPS endpoints in production for security. Make sure the URL is accessible from your team's development environments.
</Tip>
</Accordion>
<Accordion title="Master Key (optional)">
If your LiteLLM proxy requires authentication, enter the master key here. This will be used to authenticate requests from all organization members.
<Note>
**Centralized API Key Management**: By configuring the Master Key at the organization level, you enable centralized API key management. Organization members won't need to manage their own individual API keys - access is fully managed through this centralized configuration.
</Note>
<Warning>
The master key provides full access to your LiteLLM proxy. Only enter this if your proxy requires authentication and you want centralized key management.
</Warning>
</Accordion>
</AccordionGroup>
</Step>
<Step title="Save Configuration">
After configuring your settings, close the provider configuration panel and click **Save** on the settings page to persist your changes.
Once saved, all organization members signed into the Cline extension will automatically use LiteLLM with your configured settings. They won't be able to select other providers or switch to their personal Cline accounts.
<Warning>
Members can't switch to personal Cline accounts or join other organizations once remote configuration is enabled. This ensures consistent provider usage across your team.
</Warning>
</Step>
</Steps>
## Verification
To verify the configuration:
1. Check that the provider shows as "LiteLLM" in the Enabled provider field
2. Confirm the settings persist after refreshing the page
3. Test with a member account to ensure they see only LiteLLM as a provider
4. Verify that the configured models are available in the model dropdown
## Troubleshooting
**Members don't see the configured provider**
Ensure you clicked Save after closing the configuration panel. Verify the member account belongs to the correct organization and that your LiteLLM proxy is accessible from their network.
**Connection errors to LiteLLM proxy**
Verify the Base URL is correct and accessible. Check that any firewalls or security groups allow access from your team's IP addresses or development environments.
**Authentication failures**
If using a master key, verify it's correctly entered and has proper permissions in your LiteLLM deployment. Check the LiteLLM proxy logs for authentication errors.
**Models not available**
Confirm the models are properly configured in your LiteLLM proxy deployment. The available models depend on how your LiteLLM proxy is configured.
**Configuration changes don't persist**
Make sure to click the Save button on the main settings page, not just close the configuration panel.
**Need to change endpoint or key later**
You can update these settings at any time. Changes take effect immediately for all organization members.
For further details about LiteLLM deployment and configuration, consult the [LiteLLM Documentation](https://docs.litellm.ai/) and coordinate with your infrastructure team.
@@ -0,0 +1,168 @@
---
title: "Configure LiteLLM in VS Code (Members)"
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 settings—you just need to add your credentials to get started.
## Before You Begin
To successfully connect to your organization's LiteLLM proxy, you'll need a few things ready.
**Cline extension installed and configured**
The Cline extension must be installed in VS Code and you need to be signed into your organization account. If you haven't installed Cline yet, follow our [installation guide](/getting-started/installing-cline).
<Info>
**Quick Check**: Open the Cline panel in VS Code. If you see your organization name in the bottom left, you're signed in correctly.
</Info>
**Access credentials for your organization's LiteLLM proxy**
You need credentials to access your organization's LiteLLM proxy. This might be an API key, or the proxy might be configured for open access within your network.
<Note>
If you're unsure about the credentials needed, check with your administrator or IT team about how to access your organization's LiteLLM proxy.
</Note>
## Configuration Steps
<Steps>
<Step title="Open Cline Settings">
Open VS Code and access the Cline settings panel using either of these methods:
- Click the settings icon (⚙️) in the Cline panel
- Click on the API Provider dropdown located directly below the chat area (it will display as `LiteLLM` or show a specific model name)
</Step>
<Step title="Configure LiteLLM Connection">
The LiteLLM configuration options depend on how your organization has set up the proxy:
<AccordionGroup>
<Accordion title="API Key Authentication">
If your organization requires API key authentication:
1. Select or confirm the **LiteLLM** provider is selected
2. Enter your assigned API key in the **API Key** field
3. The base URL should already be configured by your administrator
4. Click **Save** to store your credentials
<Tip>
API keys are stored locally in VS Code and are only used by the Cline extension.
</Tip>
</Accordion>
<Accordion title="Open Access (No Authentication)">
If your LiteLLM proxy is configured for open access within your network:
1. Select or confirm the **LiteLLM** provider is selected
2. Leave the API key field empty
3. The extension will connect directly to the configured proxy endpoint
4. No additional authentication is required
<Info>
Open access is common when the LiteLLM proxy is deployed within a secure network environment.
</Info>
</Accordion>
<Accordion title="Custom Configuration">
If your organization uses custom authentication or specific connection parameters:
1. Follow any custom instructions provided by your administrator
2. Contact your IT team if you encounter connection issues
3. Additional configuration may be needed outside of VS Code
<Note>
Custom configurations might require specific network settings or additional authentication steps.
</Note>
</Accordion>
</AccordionGroup>
</Step>
<Step title="Select Available Models">
Once connected, you'll see the models available through your organization's LiteLLM proxy:
- View available models in the model dropdown
- Models are determined by your administrator's proxy configuration
- You can switch between models for different types of tasks
- Some models may be restricted based on your access level
<Tip>
**Model Selection**
Choose models based on your task requirements:
- **Fast models** (like GPT-3.5-turbo) for quick responses
- **Powerful models** (like GPT-4) for complex reasoning
- **Specialized models** for code generation or specific domains
</Tip>
</Step>
<Step title="Test the Connection">
Send a test message in Cline to verify your connection works correctly with the LiteLLM proxy.
<Tip>
**Testing Recommendation**
Test the connection in plan mode first to verify everything works correctly before using it for actual development tasks.
</Tip>
</Step>
</Steps>
## Model Usage
### Available Model Categories
The models available through your LiteLLM proxy typically include:
**Text Generation Models:**
- OpenAI GPT-4, GPT-3.5-turbo variants
- Anthropic Claude 3 Sonnet, Haiku, Opus
- Open source models like Llama 2, Mistral
**Code-Specific Models:**
- OpenAI GPT-4 for code
- CodeLlama variants
- Specialized code completion models
**Multimodal Models:**
- GPT-4 Vision for image analysis
- Claude 3 models with vision capabilities
### Model Selection Strategy
Choose models based on your development needs:
- **Quick iterations**: Use faster, cost-effective models
- **Complex problems**: Use more powerful models
- **Code-heavy tasks**: Use code-specialized models
- **Visual content**: Use multimodal models when working with images
## Troubleshooting
**LiteLLM not available as provider option**
Confirm you're signed into the correct Cline organization. Verify your administrator has saved the LiteLLM configuration and that you have the latest version of the Cline extension.
**Connection errors or timeouts**
Verify your network can reach the LiteLLM proxy endpoint. Check with your IT team about firewall rules or VPN requirements. Ensure the proxy endpoint is accessible from your development environment.
**Authentication failures**
If using API key authentication, verify the key is correctly entered and hasn't expired. Contact your administrator to confirm your key is active and has the proper permissions.
**Models not loading or are limited**
The available models depend on your organization's LiteLLM configuration. Contact your administrator if you need access to specific models or if expected models aren't available.
**Slow response times**
Response times depend on the models being used and proxy load. Try switching to faster models for routine tasks. Contact your administrator if performance is consistently poor.
**Error messages from specific models**
Some models may be temporarily unavailable or have specific limitations. Try alternative models or contact your administrator if specific models are consistently failing.
## Security Best Practices
When working with your organization's LiteLLM proxy:
- Keep your API credentials secure and don't share them
- Use appropriate models for the sensitivity of your data
- Follow your organization's usage guidelines
- Report any suspicious activity or unauthorized access attempts
- Regularly update the Cline extension for security patches
Your organization administrator controls which models are available and usage policies. The extension will automatically display available models based on your proxy configuration and access level.
@@ -0,0 +1,102 @@
---
title: "SaaS Provider Configuration"
sidebarTitle: "Overview"
description: "Configure inference providers through the Cline hosted admin console for centralized organization management"
---
SaaS Provider Configuration allows administrators to centrally configure inference providers for their entire organization through the Cline hosted admin console. This approach ensures consistent provider access, security policies, and cost management across all team members without requiring individual developer setup or infrastructure deployment.
## How Remote Configuration Works
Remote configuration operates through Cline's hosted service at [app.cline.bot](https://app.cline.bot), where administrators can:
<CardGroup cols={2}>
<Card title="Centralized Setup" icon="gear">
Configure providers once for the entire organization through the web-based admin console.
</Card>
<Card title="Automatic Enforcement" icon="shield-check">
Team members automatically receive the configured provider settings when signed into their organization.
</Card>
<Card title="Simplified Onboarding" icon="user-plus">
New team members get instant access to inference providers without complex individual configuration.
</Card>
<Card title="Consistent Experience" icon="users">
Ensure all team members use the same models, regions, and settings organization-wide.
</Card>
</CardGroup>
## Supported Providers
Cline supports remote configuration for the following inference providers:
| Provider | Use Case | Configuration | Member Setup |
|----------|----------|---------------|--------------|
| **Cline** | Organizations using Cline's native provider with centralized API key management | API provider selection, model access | No individual API keys needed - fully managed by organization |
| **Amazon Bedrock** | Organizations using AWS infrastructure | Region selection, VPC endpoints, cross-region inference, prompt caching | AWS credential configuration in VS Code |
| **LiteLLM** | Organizations requiring multi-model access through a unified proxy | Proxy endpoint, authentication, model routing | API key or endpoint configuration in VS Code (or centralized with Master Key) |
| **Google Vertex AI** | Organizations using Google Cloud Platform | Project ID, region selection, model access | Service account or credential configuration in VS Code |
## Configuration Process
The typical remote configuration process follows these steps:
<Steps>
<Step title="Administrator Setup">
Access the Cline admin console and configure the desired inference provider with organization-wide settings.
</Step>
<Step title="Automatic Distribution">
Provider configuration is automatically distributed to all organization members signed into Cline.
</Step>
<Step title="Member Credential Setup">
Team members add their individual credentials (API keys, AWS profiles, etc.) to connect to the configured provider.
</Step>
<Step title="Immediate Access">
Once credentials are configured, members can immediately start using the inference provider through Cline.
</Step>
</Steps>
## Benefits of Remote Configuration
### **For Administrators**
- **Centralized Control**: Manage all provider settings from one location
- **Security Compliance**: Ensure consistent security policies across the organization
- **Easy Updates**: Change provider settings organization-wide instantly
### **For Team Members**
- **Simplified Setup**: No need to research provider configuration options
- **Consistent Experience**: Same models and features available to everyone
- **Quick Onboarding**: Get started immediately with pre-configured providers
- **Focus on Development**: Spend time coding instead of configuring inference providers
## Getting Started
To get started with provider remote configuration:
1. **Choose Your Provider**: Select the inference provider that best fits your organization's needs and existing infrastructure
2. **Admin Configuration**: Follow the provider-specific admin configuration guide
3. **Member Onboarding**: Have team members complete the provider-specific member configuration
4. **Start Developing**: Begin using Cline with centrally managed inference provider access
Select your provider below to begin the configuration process:
<CardGroup cols={3}>
<Card title="Amazon Bedrock" icon="aws" href="/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration">
AWS-based AI models with enterprise security and compliance features.
</Card>
<Card title="LiteLLM" icon="layer-group" href="/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration">
Unified proxy for accessing 100+ AI models through a single interface.
</Card>
<Card title="Google Vertex AI" icon="google" href="/enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration">
Google Cloud's AI platform with advanced ML capabilities and global infrastructure.
</Card>
</CardGroup>
@@ -0,0 +1,266 @@
---
title: "OpenTelemetry Integration"
sidebarTitle: "OpenTelemetry"
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 OTEL_TELEMETRY_ENABLED=1
# Configure metrics and logs export
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
# Set your OTLP endpoint
export OTEL_EXPORTER_OTLP_ENDPOINT=https://your-collector:4317
# Optional: Set protocol (default is grpc)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
```
### Environment Variables
| Variable | Description | Default |
|----------|-------------|---------|
| `OTEL_TELEMETRY_ENABLED` | Enable OpenTelemetry (`1` or `true`) | Disabled |
| `OTEL_METRICS_EXPORTER` | Metrics exporter type (`console`, `otlp`, or both) | None |
| `OTEL_LOGS_EXPORTER` | Logs exporter type (`console`, `otlp`, or both) | None |
| `OTEL_EXPORTER_OTLP_ENDPOINT` | OTLP endpoint URL | None |
| `OTEL_EXPORTER_OTLP_PROTOCOL` | Protocol (`grpc`, `http/protobuf`, `http/json`) | `grpc` |
| `OTEL_EXPORTER_OTLP_INSECURE` | Allow insecure connections | `false` |
| `OTEL_EXPORTER_OTLP_HEADERS` | Custom headers (comma-separated `key=value` pairs) | None |
### Advanced Configuration
**Separate endpoints for metrics and logs:**
```bash
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://metrics-collector:4317
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs-collector:4317
```
**Custom headers for authentication:**
```bash
export OTEL_EXPORTER_OTLP_HEADERS="api-key=your-key,x-custom-header=value"
```
**Multiple exporters (console + OTLP):**
```bash
export OTEL_METRICS_EXPORTER=console,otlp
export OTEL_LOGS_EXPORTER=console,otlp
```
**Export intervals:**
```bash
# Metrics export interval in milliseconds (default: 60000)
export OTEL_METRIC_EXPORT_INTERVAL=30000
# Logs batch size and timeout
export OTEL_LOG_BATCH_SIZE=512
export OTEL_LOG_BATCH_TIMEOUT=5000
export OTEL_LOG_MAX_QUEUE_SIZE=2048
```
## Integration Examples
### Datadog
Export to Datadog using their OTLP endpoint:
```bash
export OTEL_TELEMETRY_ENABLED=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=https://api.datadoghq.com
export OTEL_EXPORTER_OTLP_HEADERS="dd-api-key=YOUR_DD_API_KEY"
```
### New Relic
Export to New Relic:
```bash
export OTEL_TELEMETRY_ENABLED=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp.nr-data.net:4317
export OTEL_EXPORTER_OTLP_HEADERS="api-key=YOUR_NEW_RELIC_LICENSE_KEY"
```
### Grafana Cloud
Export to Grafana Cloud:
```bash
export OTEL_TELEMETRY_ENABLED=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=https://otlp-gateway-prod-us-central-0.grafana.net/otlp
export 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 OTEL_TELEMETRY_ENABLED=1
export OTEL_METRICS_EXPORTER=console
export 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 $OTEL_TELEMETRY_ENABLED
```
Should output `1` or `true`
2. **Check exporters are configured:**
```bash
echo $OTEL_METRICS_EXPORTER
echo $OTEL_LOGS_EXPORTER
```
3. **Test with console exporter first:**
```bash
export OTEL_METRICS_EXPORTER=console
export 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 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>
@@ -0,0 +1,111 @@
---
title: "Enterprise Monitoring"
sidebarTitle: "Overview"
description: "Optional telemetry and observability for your Cline deployment"
---
Cline includes optional monitoring capabilities for organizations that want to track usage and integrate with their observability infrastructure.
## Monitoring Options
<CardGroup cols={2}>
<Card title="Cline Telemetry" icon="chart-simple" href="/enterprise-solutions/monitoring/telemetry">
Built-in anonymous usage tracking that helps improve Cline (opt-in)
</Card>
<Card title="OpenTelemetry" icon="chart-line" href="/enterprise-solutions/monitoring/opentelemetry">
Export metrics and logs to your own observability backends (advanced)
</Card>
</CardGroup>
## Cline Telemetry
Cline includes opt-in telemetry for anonymous usage tracking:
- Feature usage patterns
- Task completion rates
- Error occurrences
- Performance metrics
Users can enable or disable telemetry in Cline settings. All data is anonymous and does not include code content, file paths, or sensitive information.
See [Cline Telemetry](/enterprise-solutions/monitoring/telemetry) for configuration details.
## OpenTelemetry Integration
For advanced monitoring needs, Cline supports OpenTelemetry's OTLP (OpenTelemetry Protocol) for exporting metrics and logs to your own infrastructure.
This allows you to:
- Export telemetry to your existing observability platforms
- Integrate with tools like Datadog, New Relic, or Grafana Cloud
- Maintain full control over your monitoring data
- Aggregate metrics across your organization
<Note>
OpenTelemetry integration is **optional** and requires additional configuration. Most users don't need this feature.
</Note>
See [OpenTelemetry](/enterprise-solutions/monitoring/opentelemetry) for setup instructions.
## Use Cases
### When to Use Cline Telemetry
- You want to help improve Cline through anonymous usage data
- No additional setup required
- Suitable for most users
### When to Use OpenTelemetry
- You need granular metrics in your own systems
- You're integrating with existing observability infrastructure
- You want detailed logs and metrics for debugging
- You need custom dashboards or alerting
## Getting Started
<Steps>
<Step title="Choose Your Approach">
Decide whether basic telemetry or OpenTelemetry integration fits your needs
</Step>
<Step title="Enable Telemetry">
For basic telemetry, enable it in Cline settings. For OpenTelemetry, see the configuration guide.
</Step>
<Step title="Verify Data Collection">
Confirm telemetry is being collected as expected
</Step>
</Steps>
## Privacy & Security
All Cline monitoring features are designed with privacy in mind:
<CardGroup cols={2}>
<Card title="Anonymous" icon="user-secret">
No personal information collected
</Card>
<Card title="Optional" icon="toggle-on">
Users can disable at any time
</Card>
<Card title="Local First" icon="laptop">
Code never leaves your machine
</Card>
<Card title="Transparent" icon="code">
Open source - see what's collected
</Card>
</CardGroup>
## Next Steps
<CardGroup cols={2}>
<Card title="Configure Telemetry" icon="gear" href="/enterprise-solutions/monitoring/telemetry">
Set up basic telemetry settings
</Card>
<Card title="OpenTelemetry Setup" icon="chart-line" href="/enterprise-solutions/monitoring/opentelemetry">
Advanced monitoring with OpenTelemetry
</Card>
</CardGroup>
@@ -0,0 +1,133 @@
---
title: "Cline Telemetry"
sidebarTitle: "Cline Telemetry"
description: "Configure usage analytics and event tracking"
---
Cline includes telemetry to help understand usage patterns and improve the product. Users can control whether to share this data.
## What is Cline Telemetry?
Telemetry captures anonymous usage events such as:
- Features used (which tools, commands, workflows)
- Task completion rates
- Error occurrences
- Performance metrics
<Info>
All telemetry data is **anonymous** and does not include code content, file contents, or other sensitive information.
</Info>
## User Controls
### Enabling/Disabling Cline Telemetry
Individual users can control telemetry through Cline settings:
1. Open Cline settings
2. Find "Cline Telemetry" toggle
3. Enable or disable as preferred
Changes take effect immediately.
### What Gets Collected
When telemetry is enabled, Cline captures:
<AccordionGroup>
<Accordion title="Feature Usage" icon="cursor-click">
- Tools executed (e.g., read_file, execute_command)
- Slash commands used
- Workflows triggered
- Settings changed
</Accordion>
<Accordion title="Task Metrics" icon="tasks">
- Task started/completed events
- Mode switches (Plan/Act)
- Checkpoint usage
- Task duration
</Accordion>
<Accordion title="Error Events" icon="triangle-exclamation">
- API failures
- Tool execution errors
- System errors
- Error types and frequencies
</Accordion>
</AccordionGroup>
### What Doesn't Get Collected
Cline Telemetry **never** includes:
- Your code or file contents
- File paths or names
- Command arguments or parameters
- Conversation content
- Personal information
- API keys or credentials
## Enterprise Configuration
Administrators can set default telemetry state through remote configuration:
```json
{
"telemetryEnabled": true
}
```
<Note>
Even with enterprise configuration, individual users can still disable Cline Telemetry in their local settings.
</Note>
## Advanced Monitoring
For organizations needing detailed monitoring, Cline supports optional OpenTelemetry integration to export telemetry data to your own observability systems.
See [Enterprise Monitoring](/enterprise-solutions/monitoring/overview) for details on available monitoring options.
## Privacy
Cline's telemetry is designed with privacy in mind:
<CardGroup cols={2}>
<Card title="Anonymous" icon="user-secret">
No personal information is collected
</Card>
<Card title="Optional" icon="toggle-on">
Users can disable at any time
</Card>
<Card title="Local First" icon="laptop">
Code never leaves your machine
</Card>
<Card title="Transparent" icon="eye">
Open source - see exactly what's collected
</Card>
</CardGroup>
## Why Telemetry Matters
Anonymous usage data helps:
- **Identify bugs**: Discover issues affecting users
- **Prioritize features**: Focus on most-used capabilities
- **Improve performance**: Find and fix slow operations
- **Enhance reliability**: Track and reduce error rates
## Related
<CardGroup cols={2}>
<Card title="OpenTelemetry" icon="chart-line" href="/enterprise-solutions/monitoring/opentelemetry">
Enterprise monitoring and observability
</Card>
<Card title="Privacy" icon="shield" href="/more-info/telemetry">
Full telemetry documentation
</Card>
</CardGroup>
+128
View File
@@ -0,0 +1,128 @@
---
title: "Onboarding"
description: "This guide explains how administrators configure SSO provisioning and user management in Cline Enterprise."
---
## 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 directory—no manual invites or seat reconciliations required.
## Prerequisites
- [Cline Enterprise License](https://cline.bot/enterprise)
- Access to your identity provider (IdP) configuration (e.g., Okta, Azure AD, Google Workspace)
- Knowledge of your organization's SSO requirements
## Configuration Steps
### Step 1: Onboard to Cline Enterprise license
Your IdP administrator will receive an email with a link to register their organization with WorkOS during onboarding.
### Step 2: Configure Your Identity Provider
Connect your identity provider (IdP) to WorkOS:
1. In the WorkOS dashboard, go to **AuthKit → Connections**
2. Click **Add Connection**
3. Select your identity provider (e.g., Okta, Azure AD, Google Workspace, Generic SAML/OIDC)
4. Follow the provider-specific setup instructions
Each identity provider (IdP) will have its own setup process and required fields. Be sure to follow the specific instructions in the WorkOS dashboard for your chosen provider.
For more explicit instruction on connecting your IdP, refer to the [WorkOS SSO documentation](https://workos.com/docs/authkit/sso)
### Step 3: Configure User Provisioning
Cline Enterprise uses **just-in-time provisioning** that works automatically:
- **Organizations are created automatically**
- **Users gain access automatically** on their first SSO sign-in, once their credentials have been configured by the IdP administrator.
- **Roles sync automatically** from your IdP (Admin/Owner → Admin, Member → Member)
- **No manual user invites or seat management** required
No additional configuration is needed. Users are provisioned automatically when they sign in through SSO.
### Step 4: Configure User Attributes Mapping
User roles are mapped automatically from your IdP:
- **Admin** in IdP → **Admin** role in Cline (Note: The first Owner of the org is created manually during onboarding)
- **Member** in IdP → **Member** role in Cline
<Info>
For what each role can access, see the [Roles and Permissions](/enterprise-solutions/team-management/managing-members) page.
</Info>
If needed, you can configure additional user attributes in the Cline Admin console:
1. Go to **Settings → Authentication → User Attributes**
2. Map attributes such as email and name based on your IdP configuration
For information about available user attributes, see the [WorkOS User Object Documentation](https://workos.com/docs/authkit/user-management).
### Step 5: Test SSO Connection
Before allowing users to sign in, test the SSO flow to ensure everything is configured correctly.
**To test the connection:**
1. In the WorkOS dashboard (or Cline Admin console if available), locate and click **Test SSO Connection**
2. You'll be redirected to your IdP's login page
3. Enter valid credentials for a test user
4. After successful authentication, you should be redirected back
5. Confirm that the user's information (name, email, role) displays correctly
**Expected outcome:** The test user is authenticated, their account details are visible, and their role matches what's configured in your IdP.
**If the test fails:** Double-check your IdP configuration (redirect URIs, SAML certificates, attribute mappings). See the [WorkOS SSO documentation](https://workos.com/docs/authkit/sso) for troubleshooting guidance.
### User Access
Once SSO is configured, users in your IdP can access Cline automatically without manual invites or account setup.
**First-time sign-in flow:**
1. User navigates to Cline and clicks **Sign in with SSO**
2. User authenticates via your organization's IdP
3. Cline automatically creates their account in your Organization
4. Role is assigned based on their IdP role (see [Step 4](#step-4-configure-user-attributes-mapping))
5. User is redirected to Cline and can begin working
**What happens automatically:**
- Account creation with correct organization assignment
- Role and permission assignment
- Basic profile information (name, email) populated from IdP
**No action required:** Users don't need to request access or wait for approval. Access is granted immediately upon successful IdP authentication.
### Managing Access
All access management and revocation of users is currently handled by your IdP:
- Add users → access granted automatically on first login
- Change roles → updated on next login
- Remove users → access revoked automatically
<Info>
Role changes sync automatically on the user's next sign-in.
</Info>
### Changing your IdP
In order to change to a different IdP, please contact support and we will guide you through this process.
---
## Verification
Steps to verify successful configuration:
1. **Test User Sign-In**: Have a test user sign in through the SSO flow (access is granted automatically on first login)
2. **Verify User Provisioning**: Confirm that the user is automatically created and has appropriate role permissions
3. **Check User Attributes**: Verify that user information (name, email, organization) is correctly populated
4. **Test Role Changes**: Update a user's role in your IdP and verify it syncs on their next login
5. **Test User Deprovisioning**: Remove a user from your IdP and verify they lose access to Cline on their next login attempt
6. **Review Audit Logs**: Check WorkOS audit logs to ensure authentication events are being recorded
---
+5 -5
View File
@@ -1,7 +1,7 @@
---
title: "Cline Enterprise"
sidebarTitle: "Overview"
description: "Enterprise security, governance, and observability for the coding agent 3 million developers trust"
description: "Enterprise security, governance, and observability for the coding agent millions of developers trust"
---
Cline Enterprise brings centralized governance to the same open-source architecture that millions of developers already use. Your code stays in your environment, you use your own inference at your negotiated rates, and you get the security and observability capabilities that platform teams need for org-wide deployment.
@@ -57,10 +57,10 @@ Platform teams need central control when thousands of developers use AI. Individ
Enterprise governance provides:
- **SSO authentication**: Corporate credentials instead of personal API keys
- **Role-based access control**: Fine-grained permissions per team and project
- **Role-based access control**: Three-tier hierarchy (Member/Admin/Owner) with organization-scoped permissions
- **Model and tool controls**: Govern which models and tools each team accesses
- **Remote configuration**: Manage settings for all developers from one dashboard
- **Full audit logging**: Every AI interaction tracked with detailed logs
- **Usage tracking and observability**: OpenTelemetry integration for monitoring usage, costs, and performance with selective audit logging for administrative operations
Configure once, deploy everywhere. Developers work how they prefer while you maintain control.
@@ -77,7 +77,7 @@ The same observability standards you require for production systems.
## Deployment
Cline Enterprise connects securely to your infrastructure. Deploy in cloud environments, on-premises, or air-gapped networks. Configure to work with your existing security policies and compliance requirements.
Cline Enterprise connects securely to your infrastructure. Deploy in cloud environments. Configure to work with your existing security policies and compliance requirements.
Rolling out to your organization:
1. Configure Cline Core to connect to your infrastructure
@@ -87,7 +87,7 @@ Rolling out to your organization:
## Next Steps
- Review [security architecture](/enterprise-solutions/security-concerns)
- 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
@@ -1,61 +0,0 @@
---
title: "Security Concerns"
---
## Enterprise Security with Cline
Cline addresses enterprise security concerns through its unique client-side architecture that prioritizes data privacy, secure cloud integration, and transparent operations. Below is a comprehensive overview of how Cline maintains robust security measures for enterprise environments.
### Client-Side Architecture
Cline operates exclusively as a client-side VSCode extension with zero server-side components. This fundamental design choice ensures that your code and data remain within your secure environment at all times. Unlike traditional AI assistants that send data to external servers for processing, Cline connects directly to your chosen cloud provider's AI endpoints, keeping all sensitive information within your infrastructure boundaries.
<Frame>
<img
src="https://storage.googleapis.com/cline_public_images/docs/assets/cline-arch.png"
alt="Cline's relationship to local and remote assets"
/>
</Frame>
### Data Privacy Commitment
Cline implements a strict zero data retention policy, meaning your intellectual property never leaves your secure environment. The extension does not collect, store, or transmit your code to any central servers. This approach significantly reduces potential attack vectors that might otherwise be introduced through data transmission to third-party systems. Telemetry collection is optional and requires explicit consent.
### Cloud Provider Integration
Enterprise teams can access cutting-edge AI models through their existing cloud deployments. Cline supports seamless integration with:
- AWS Bedrock
- Google Cloud Vertex AI
- Microsoft Azure
These integrations utilize your organization's existing security credentials, including native IAM role assumption for AWS. This ensures that all AI processing occurs within your corporate cloud environment, maintaining compliance with your established security protocols.
### Open-Source Transparency
Cline's codebase is completely open-source, allowing for comprehensive security auditing by your internal teams. This transparency enables security professionals to verify exactly how the extension functions and confirm that it adheres to your organization's security requirements. Organizations can review the code to ensure it aligns with their security policies before deployment.
### Controlled Modifications
The extension implements safeguards against unauthorized changes to your codebase. Cline requires explicit user approval for all file modifications and terminal commands, preventing accidental or unwanted alterations. This approval-based workflow maintains the integrity of your projects while still providing AI assistance.
### Enterprise Deployment Support
For organizations with strict security review processes, Cline provides comprehensive documentation including detailed deployment diagrams, sequence diagrams illustrating all data flows, and complete security posture documentation. These materials facilitate thorough security reviews and help demonstrate compliance with enterprise data handling standards and regulations.
### Access Control
Enterprise editions of Cline (planned for Q2 2025) will include centralized administration features that allow organizations to:
- Manage user access with customizable permission levels
- Provision accounts with corporate credentials
- Immediately revoke access when needed
- Control which AI providers and LLM endpoints can be used
- Deploy standardized settings across the organization
- Prevent unauthorized use of personal API keys
### Compliance and Governance
Cline's architecture supports compliance with data sovereignty requirements and enterprise data handling regulations. The planned Enterprise Complete edition will further enhance governance with detailed audit logging, compliance reporting, and automated policy enforcement mechanisms.
By combining client-side processing, direct cloud provider integration, and transparent operations, Cline offers enterprise teams a secure way to leverage AI assistance while maintaining strict control over their sensitive code and data.
@@ -0,0 +1,317 @@
---
title: "Managing Members"
sidebarTitle: "Managing Members"
description: "Complete guide to managing team members, roles, and permissions in your Cline Enterprise organization"
---
Effective member management is essential for maintaining security and enabling your team to work productively. This guide covers everything you need to know about roles, permissions, and day-to-day member administration.
## Understanding Roles
Choose the right role for each team member to balance security with productivity. Here's what each role is designed for:
<CardGroup cols={3}>
<Card title="Owner" icon="crown" color="#9D4EDD">
**Primary account holder**
Unrestricted access to all settings including billing, security, and ownership transfer. Keep this limited to 1-2 key leaders.
</Card>
<Card title="Admin" icon="user-gear" color="#7209B7">
**Team leads & IT managers**
Can manage users and configure providers. Ideal for trusted managers who need operational control without billing access.
</Card>
<Card title="Member" icon="user" color="#560BAD">
**Developers & contributors**
Can use Cline with shared resources but cannot change settings. The safest default for most team members.
</Card>
</CardGroup>
## Permissions Matrix
Understand exactly what each role can do with this comprehensive permissions breakdown:
| Permission | Member | Admin | Owner |
| :--- | :---: | :---: | :---: |
| **General Usage** | | | |
| Use Cline | ✅ | ✅ | ✅ |
| Access Shared API Providers | ✅ | ✅ | ✅ |
| | | | |
| **Member Management** | | | |
| View Members | ❌ | ✅ | ✅ |
| Invite New Members | ❌ | ✅ | ✅ |
| Edit Member Roles | ❌ | ✅ | ✅ |
| Remove Members | ❌ | ✅ | ✅ |
| Remove Admins | ❌ | ❌ | ✅ |
| | | | |
| **Configuration** | | | |
| Configure API Providers | ❌ | ✅ | ✅ |
| Manage Security Settings | ❌ | ❌ | ✅ |
| | | | |
| **Billing & Ownership** | | | |
| View Billing Information | ❌ | ❌ | ✅ |
| Manage Subscription | ❌ | ❌ | ✅ |
| Transfer Ownership | ❌ | ❌ | ✅ |
<Note>
**Quick Reference:** Most users should be **Members**. Grant **Admin** only to those managing users or configs. Reserve **Owner** for 1-2 account leaders.
</Note>
## Member Management Tasks
<Tabs>
<Tab title="Adding Members">
### Inviting New Team Members
1. **Navigate to Members**
- Go to your organization dashboard at app.cline.bot
- Click on "Members" in the sidebar
2. **Send Invitation**
- Click "Invite Member"
- Enter the user's email address (must be from your verified domain)
- Select the appropriate role (Member, Admin, or Owner)
- Click "Send Invite"
3. **Invitation Status**
- Invited users will receive an email with a join link
- Pending invitations show in your member list with "Pending" status
- Each pending invitation holds one seat from your license
<Tip>
**Bulk Invitations:** Need to add multiple users? Contact support@cline.bot for assistance with bulk invite CSV imports.
</Tip>
</Tab>
<Tab title="Editing Roles">
### Changing Member Permissions
1. **Locate the Member**
- Navigate to the Members page
- Find the user you want to modify
2. **Change Role**
- Click the dropdown next to their current role
- Select the new role from the menu
- Confirm the change
3. **Effective Immediately**
- Role changes take effect instantly
- The user may need to sign out and back in to see updated permissions
<Warning>
**Admin to Member:** Downgrading an Admin to Member will immediately revoke their ability to manage users and configurations. Ensure they no longer need these permissions.
</Warning>
</Tab>
<Tab title="Removing Members">
### Offboarding Team Members
1. **Access Member List**
- Navigate to your organization's Members page
- Locate the user to remove
2. **Remove User**
- Click the menu icon (⋮) next to their name
- Select "Remove from Organization"
- Confirm the removal
3. **Immediate Effects**
- User loses access to the organization immediately
- Their seat is freed and can be assigned to someone else
- Audit logs are preserved for compliance
<Info>
**Data Retention:** Removing a member does not delete their historical activity logs. All audit trails remain intact for compliance purposes.
</Info>
</Tab>
<Tab title="Revoking Invites">
### Canceling Pending Invitations
If an invited user hasn't accepted yet, you can revoke the invitation:
1. Find the pending invitation in your Members list
2. Click "Revoke Invitation"
3. The seat is immediately freed for another user
This is useful when:
- The wrong email was used
- The user no longer needs access
- You need to reassign the seat urgently
</Tab>
</Tabs>
## Identity & Access Requirements
For users to successfully join your organization, two conditions must be met:
<Steps>
<Step title="Verified Identity Provider">
Your organization must use a verified **Identity Provider (IDP)** such as:
- Microsoft Entra ID (Azure AD)
- Okta
- Google Workspace
- AWS IAM Identity Center
Users must authenticate through your IDP to access the organization.
</Step>
<Step title="Domain Verification">
Your organization must have a **verified domain**. You'll need to verify ownership of your domain through your domain provider (e.g., Google, Microsoft, Cloudflare).
Only users with email addresses from verified domains can join.
</Step>
</Steps>
<Note>
These requirements ensure that only authenticated users from your company can access your Cline organization, preventing unauthorized access.
</Note>
## Seat Management
Understanding how seats work helps you manage your license effectively:
<AccordionGroup>
<Accordion title="How Seats Are Calculated" icon="chair">
- Each user (Owner, Admin, or Member) consumes **one seat**
- Pending invitations also hold one seat
- Removing a member or revoking an invite immediately frees the seat
- Your license determines the maximum number of seats available
</Accordion>
<Accordion title="When Seats Are Used" icon="user-plus">
A seat is consumed when:
- You send an invitation (marked as "pending")
- An invited user accepts and joins
- An existing user is granted access through SSO
</Accordion>
<Accordion title="Freeing Up Seats" icon="user-minus">
To free a seat:
- Remove an active member from the organization
- Revoke a pending invitation
- Wait for a pending invite to expire (if configured)
</Accordion>
<Accordion title="Upgrading Your License" icon="arrow-up">
Need more seats?
- **Teams Plan:** Contact your account manager or visit app.cline.bot/settings/billing to upgrade your license.
- **Enterprise Plan:** Includes unlimited seats with no per-user restrictions.
</Accordion>
</AccordionGroup>
## Security Best Practices
Follow these guidelines to maintain a secure organization:
<CardGroup cols={2}>
<Card title="Principle of Least Privilege" icon="shield-check">
Always assign the minimum role necessary. Most users should be Members. Only grant Admin or Owner privileges when required for job duties.
</Card>
<Card title="Limit Owner Roles" icon="user-lock">
Keep Owners to 1-2 key individuals who manage billing and security. This centralization prevents accidental or malicious changes to critical settings.
</Card>
<Card title="Regular Audits" icon="clipboard-check">
Review your member list quarterly. Remove inactive users promptly and verify that Admin/Owner roles are still appropriate for each user.
</Card>
<Card title="Offboarding Process" icon="door-open">
Create a standard offboarding checklist: remove from Cline, revoke IDP access, document in audit log, and reassign any critical responsibilities.
</Card>
</CardGroup>
<Warning>
**Owner Accountability:** Since Owners control billing and can transfer ownership, choose these individuals carefully and document the selection in your organization's security policies.
</Warning>
## Advanced Scenarios
<AccordionGroup>
<Accordion title="Transferring Ownership" icon="exchange">
Only the current Owner can transfer ownership:
1. Navigate to Organization Settings
2. Go to the "Ownership" section
3. Select the new Owner from the member list
4. Confirm the transfer with your authentication
5. The new Owner receives immediate control
**Important:** This action cannot be undone by the previous Owner. The new Owner must initiate a reverse transfer if needed.
</Accordion>
<Accordion title="Managing Multiple Admins" icon="users-gear">
When you have multiple Admins:
- Document each Admin's area of responsibility
- Use audit logs to track configuration changes
- Consider creating rotation schedules for large teams
- Establish escalation paths for Owner-level decisions
</Accordion>
<Accordion title="Temporary Access" icon="clock">
For contractors or temporary staff:
- Create them as Members with expiration calendar reminders
- Document their access period in your internal systems
- Set calendar reminders to remove them when the contract ends
- Consider using time-limited IDP accounts if your IDP supports it
</Accordion>
</AccordionGroup>
## Troubleshooting
<AccordionGroup>
<Accordion title="User Can't Accept Invitation" icon="circle-exclamation">
**Common causes:**
- Email domain doesn't match verified domain
- User's IDP access hasn't been granted yet
- Invitation link expired
**Solution:** Verify domain verification is complete and resend the invitation.
</Accordion>
<Accordion title="Can't Remove an Admin" icon="user-slash">
**Cause:** Only Owners can remove Admins.
**Solution:** Ask an Owner to perform the removal, or if you need to remove your organization's sole Owner, contact support@cline.bot.
</Accordion>
<Accordion title="Out of Seats" icon="triangle-exclamation">
**When you've reached your license limit:**
- Remove inactive members to free seats
- Revoke pending invitations that are no longer needed
- Upgrade your license to add more seats
</Accordion>
</AccordionGroup>
## Next Steps
Now that you understand member management, proceed with configuring your organization:
<CardGroup cols={2}>
<Card
title="Configure Providers"
icon="plug"
href="/enterprise-solutions/configuration/choosing-your-deployment"
>
Set up API providers for your team to use
</Card>
<Card
title="Monitor Usage"
icon="chart-line"
href="/enterprise-solutions/monitoring/overview"
>
Track team activity and resource consumption
</Card>
</CardGroup>
<Tip>
**Getting Started Fast?** The quickest path is: 1) Invite your team as Members, 2) Configure one API provider, 3) Let your team start using Cline. You can refine roles and settings later.
</Tip>
+24
View File
@@ -15,6 +15,30 @@ Cline creates a checkpoint after each tool use (file edits, commands, etc.). The
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:
+90
View File
@@ -0,0 +1,90 @@
---
title: "Explain Changes"
sidebarTitle: "Explain Changes"
---
Explain Changes is an AI-powered code review feature that adds inline explanations to your code changes. When Cline makes modifications to your codebase, you can click a button to get streaming, contextual explanations that appear directly in VS Code's diff view.
<Note>
Explain Changes requires **[Checkpoints](/features/checkpoints)** to be enabled. Make sure to enable checkpoints in your Cline settings before using this feature.
</Note>
<Frame>
<video
autoPlay
loop
muted
playsInline
src="https://storage.googleapis.com/cline_public_images/explain-code-button.mp4"
/>
</Frame>
## How It Works
After Cline completes a task that involves file changes, you'll see an "Explain Changes" button alongside the "View Changes" button in the completion message. Clicking this button:
1. Opens a multi-file diff view showing all changed files
2. Streams AI-generated explanations as inline comments
3. Places comments at relevant code locations to explain what changed and why
The AI uses the full conversation context to provide meaningful explanations, not just describing what code does, but explaining the reasoning behind the changes.
## Interactive Comment Threads
One of the most powerful aspects of Explain Changes is that the comments are fully interactive. You can have conversations directly within each comment thread.
### Asking Follow-up Questions
Each explanation comment has a reply input where you can ask questions about that specific piece of code:
- "Why did you use this approach instead of X?"
- "Can you explain this pattern in more detail?"
- "What would happen if we changed this to Y?"
The AI will respond with context-aware answers, understanding both the code being discussed and the original task context.
### Moving to Main Chat
If a conversation in a comment thread becomes complex or you want to continue working on that code, click the title area of the comment thread to move the entire conversation into Cline's main chat input. This lets you:
- Continue the discussion with full Cline capabilities
- Have Cline make additional changes based on the discussion
- Keep the context from your review conversation
## When to Use Explain Changes
### Learning and Onboarding
When you're new to a codebase or working with unfamiliar patterns, Explain Changes helps you understand not just what Cline did, but why. The explanations cover:
- Design decisions and trade-offs
- Technical concepts and patterns used
- Relationships between different changes
### Code Review
Use Explain Changes as part of your review process:
- Understand complex changes before committing
- Verify the AI's reasoning matches your expectations
- Catch potential issues by understanding the full context
### Knowledge Transfer
The explanations serve as documentation for your changes. When other team members review your code, they can see the reasoning behind each modification.
## Best Practices
1. **Ask specific questions**: The more specific your follow-up questions, the more useful the AI's responses will be.
2. **Use for complex changes**: Explain Changes is most valuable for multi-file changes or complex logic. For simple changes, the diff view alone may be sufficient.
3. **Move important discussions to chat**: If a comment thread reveals something that needs more work, move it to main chat to take action.
4. **Review before committing**: Use Explain Changes as a final check before committing changes to ensure you understand everything Cline did.
## Related Features
- [Checkpoints](/features/checkpoints) - Required for Explain Changes to work
- [/explain-changes](/features/slash-commands/explain-changes) - Slash command to explain any git diff
-419
View File
@@ -1,419 +0,0 @@
---
title: "Hooks"
sidebarTitle: "Hooks"
description: "Inject custom logic into Cline's workflow to validate operations, monitor tool usage, and shape AI decisions"
---
Hooks let you inject custom logic into Cline's workflow at key moments. Think of them as automated checkpoints where you can validate operations before they execute, monitor tool usage as it happens, and shape how Cline makes decisions.
Hooks run automatically when specific events happen during development. They receive detailed information about each operation, can block problematic actions before they cause issues, and can inject context that guides future AI decisions.
The real power comes from combining these capabilities. You can:
- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
- Learn from what's happening and build up project knowledge over time
- Monitor performance and catch issues as they emerge
- Track everything for analytics or compliance
- Trigger external tools or services at the right moments
<Warning>
Hooks are currently supported on macOS and Linux only. Windows support is not available.
</Warning>
## Getting Started
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/hooks.gif" alt="Hooks in action" />
</Frame>
Enabling hooks in Cline is straightforward. Here's what you need to do:
<Steps>
<Step title="Enable Hooks in Settings">
Open Cline settings and check the **"Enable Hooks"** checkbox.
You can find this setting by:
1. Opening Cline
2. Click the "Settings" button on the top right corner
3. Click the "Feature" section in the left side navigation menu.
4. Scroll down until you see the "Enable Hooks" checkbox and check it.
</Step>
<Step title="Choose Your Hook Location">
Decide where to place your hooks:
**For personal or organization-wide hooks:**
- Create hooks in `~/Documents/Cline/Rules/Hooks/`
- These apply to all workspaces automatically
**For project-specific hooks:**
- Create hooks in `.clinerules/hooks/` in your project root
- These only apply to the specific workspace
- Commit them to version control so your team can use them too
</Step>
<Step title="Create Your First Hook">
Hook files must have exact names with no file extensions. For example, to create a TaskStart hook:
```bash
# Create the hook file
vim .clinerules/hooks/TaskStart
```
Add your script (must start with shebang)
``` bash
#!/usr/bin/env bash
# Store piped input into a variable
input=$(cat)
# Dump the entire JSON payload
echo "$input" | jq .
# Get the type of a field
echo "$input" | jq -r '.timestamp | type'
```
This example script demonstrates the key mechanics of hook input/output: reading the JSON payload from stdin with `input=$(cat)`, and using `jq` to inspect the data structure and field types that your hook receives. This helps you understand what data is available before building more complex hook logic.
**Make it executable**
```bash
chmod +x .clinerules/hooks/TaskStart
```
</Step>
<Step title="Test Your Hook">
Start a task in Cline and verify your hook executes.
</Step>
</Steps>
<Tip>
Start with a simple hook that just logs information before building complex validation logic. This helps you understand the data structure and timing.
</Tip>
## What You Can Build
Once you understand the basics, hooks open up creative possibilities:
<CardGroup cols={2}>
<Card title="Intelligent Code Review" icon="code-branch">
Run linters or custom validators before files get saved. Block commits that don't pass checks. Track code quality metrics over time.
</Card>
<Card title="Security Enforcement" icon="shield-halved">
Prevent operations that violate security policies. Detect when sensitive data might be exposed. Audit all file access for compliance.
</Card>
<Card title="Development Analytics" icon="chart-line">
Measure how long different operations take. Identify patterns in how the AI works. Generate productivity reports from hook data.
</Card>
<Card title="Integration Hub" icon="plug">
Connect to issue trackers when certain keywords appear. Update project management tools. Sync with external APIs at the right moments.
</Card>
</CardGroup>
The key is combining hooks with external tools. A hook can be the glue between Cline's workflow and the rest of your development ecosystem.
## Hook Types
Cline provides multiple hook types that let you tap into different stages of the AI workflow. They're organized into categories based on their trigger points and use cases.
<Note>
The hook names below are the exact file names you need to create. For example, to use the TaskStart hook, create a file named `TaskStart` (no file extension) in your hooks directory.
</Note>
Each hook receives base fields in addition to its specific data: `clineVersion`, `hookName`, `timestamp`, `taskId`, `workspaceRoots`, `userId`.
### Tool Execution
These hooks intercept and validate tool operations before and after they execute. Use them to enforce policies, track changes, and learn from operations.
#### PreToolUse
Runs before any tool executes. Use it to block invalid operations, validate parameters, and enforce project policies before changes happen.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "PreToolUse",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"preToolUse": {
"toolName": "string",
"parameters": {}
}
}
```
#### PostToolUse
Runs after a tool completes. Use it to learn from results, track performance metrics, and build project knowledge based on operations performed.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "PostToolUse",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"postToolUse": {
"toolName": "string",
"parameters": {},
"result": "string",
"success": boolean,
"executionTimeMs": number
}
}
```
### User Interaction
These hooks monitor and enhance user communication with Cline. Use them to validate input, inject context, and track interaction patterns.
#### UserPromptSubmit
Runs when a user sends a message to Cline. Use it to validate input, inject context based on the prompt, and track interaction patterns.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "UserPromptSubmit",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"userPromptSubmit": {
"prompt": "string",
"attachments": ["string"]
}
}
```
### Task Lifecycle
These hooks monitor and respond to task state changes from start to finish. Use them to track progress, restore state, and trigger workflows.
#### TaskStart
Runs when a new task begins. Use it to detect project type, initialize tracking, and inject initial context that shapes how Cline approaches the work.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskStart",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskStart": {
"taskMetadata": {
"taskId": "string",
"ulid": "string",
"initialTask": "string"
}
}
}
```
#### TaskResume
Runs when a task resumes after interruption. Use it to restore state, refresh context, and log resumption for analytics or external system notifications.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskResume",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskResume": {
"taskMetadata": {
"taskId": "string",
"ulid": "string"
},
"previousState": {
"lastMessageTs": "string",
"messageCount": "string",
"conversationHistoryDeleted": "string"
}
}
}
```
#### TaskCancel
Runs when a task is cancelled. Use it to cleanup resources, log cancellation details, and notify external systems about interrupted work.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskCancel",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskCancel": {
"taskMetadata": {
"taskId": "string",
"ulid": "string",
"completionStatus": "string"
}
}
}
```
{/*
#### TaskComplete
Runs when a task finishes successfully. Use it for final cleanup, tracking metrics, generating reports, and triggering post-task workflows.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskComplete",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskComplete": {
"taskMetadata": {
"taskId": "string",
"ulid": "string"
}
}
}
```
*/}
### System Events
These hooks monitor internal Cline operations and system-level events. Use them to track context usage, log system behavior, and analyze performance patterns.
{/*
#### PreCompact
Runs before conversation context is truncated to fit token limits. Use it to monitor compaction frequency, log events, and track context usage patterns.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "PreCompact",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"preCompact": {
"contextSize": number,
"messagesToCompact": number,
"compactionStrategy": "string"
}
}
```
*/}
### JSON Communication
Hooks receive JSON via stdin and return JSON via stdout.
**Output structure:**
```json
{
"cancel": false,
"contextModification": "WORKSPACE_RULES: Use TypeScript",
"errorMessage": "Error details if blocking"
}
```
Your hook script can output logging or diagnostic information to stdout during execution, as long as the JSON response is the last thing written. Cline will parse only the final JSON object from stdout.
For example:
```bash
#!/usr/bin/env bash
echo "Processing hook..." # This is fine
echo "Tool: $tool_name" # This is also fine
# The JSON must be last:
echo '{"cancel": false}'
```
The `cancel` field controls whether execution continues. Set it to `true` to block an action, `false` to allow it.
The `contextModification` field injects text into the conversation. This affects future AI decisions, not the current one. Use prefixes like `WORKSPACE_RULES:` or `PERFORMANCE:` to help categorize the context.
### Understanding Context Timing
Context injection affects future decisions, not current ones. When a hook runs:
1. The AI has already decided what to do
2. The hook can block or allow it
3. Any context gets added to the conversation
4. The next AI request sees that context
This means PreToolUse hooks are for blocking bad actions, while PostToolUse hooks are for learning from completed ones.
## Troubleshooting
### Hook Not Running
- Ensure the "Enable Hooks" setting is checked
- Verify the hook file is executable (`chmod +x hookname`)
- Check the hook file has no syntax errors
- Look for errors in VSCode's Output panel (Cline channel)
### Hook Timing Out
- Reduce complexity of the hook script
- Avoid expensive operations (network calls, heavy computations)
- Consider moving complex logic to a background process
### Context Not Affecting Behavior
Remember that context modifications affect future AI decisions, not the current operation. The AI's current behavior is based on the previous "API Request..." block, and your `contextModification` gets injected into the next "API Request..." block. This means if you need immediate effect, you should use PreToolUse hooks for validation and return `cancel: true` in your hook's JSON response to block Cline from continuing.
When adding context, ensure your modifications are clear and actionable so the AI can understand and apply them effectively. Also check that your context isn't being truncated due to the 50KB limit, as this could prevent important information from reaching the AI.
### Handling Strings with Quotes in JSON Payloads
When your hook needs to include strings containing unescaped quote characters (`"`) in JSON output, use jq's `--arg` flag for proper escaping:
```bash
#!/usr/bin/env bash
# When $output contains unescaped quote characters (")...
output='{"foo":"bar"}'
# Use the --arg flag for automatic string escaping
jq -n --arg ctx "$output" '{cancel: false, contextModification: $ctx}'
# This will result in:
# {
# "cancel": false,
# "contextModification": "{\"foo\":\"bar\"}"
# }
```
The `--arg` flag automatically escapes special characters, preventing JSON parsing errors when your context modification includes complex strings or nested JSON structures.
<Warning>
Hooks run with the same permissions as VS Code. They can access all workspace files and environment variables. Review hooks from untrusted sources before enabling them.
</Warning>
## Related Features
Hooks complement other Cline features:
- [Cline Rules](/features/cline-rules) define high-level guidance that hooks can enforce
- [Checkpoints](/features/checkpoints) let you roll back changes if a hook didn't catch an issue
- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets for automated operations
+437
View File
@@ -0,0 +1,437 @@
---
title: "Hook Reference"
sidebarTitle: "Hook Reference"
description: "Complete API reference for all Cline hook types, JSON schemas, and field documentation"
---
This reference provides complete technical documentation for all hook types, their JSON schemas, input/output formats, and communication protocols.
## Hook Types
Cline provides multiple hook types that let you tap into different stages of the AI workflow. They're organized into categories based on their trigger points and use cases.
<Note>
The hook names below are the exact file names you need to create. For example, to use the TaskStart hook, create a file named `TaskStart` (no file extension) in your hooks directory.
</Note>
Each hook receives base fields in addition to its specific data: `clineVersion`, `hookName`, `timestamp`, `taskId`, `workspaceRoots`, `userId`.
### Tool Execution Hooks
These hooks intercept and validate tool operations before and after they execute. Use them to enforce policies, track changes, and learn from operations.
#### `PreToolUse`
Triggered immediately before Cline uses any tool (see the [Cline Tools Reference Guide](/cline-tools) for all available tools). Use it to block invalid operations, validate parameters, and enforce project policies before changes happen.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "PreToolUse",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"preToolUse": {
"toolName": "string",
"parameters": {}
}
}
```
**Example Usage:**
```bash
#!/usr/bin/env bash
input=$(cat)
# Block creating .js files in TypeScript projects
tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
if [[ "$tool_name" == "write_to_file" ]]; then
file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path')
if [[ "$file_path" == *.js ]] && [[ -f "tsconfig.json" ]]; then
echo '{"cancel": true, "errorMessage": "JavaScript files not allowed in TypeScript project"}'
exit 0
fi
fi
echo '{"cancel": false}'
```
#### `PostToolUse`
Triggered immediately after Cline uses any tool (see the [Cline Tools Reference Guide](/cline-tools) for all available tools). Use it to learn from results, track performance metrics, and build project knowledge based on operations performed.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "PostToolUse",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"postToolUse": {
"toolName": "string",
"parameters": {},
"result": "string",
"success": boolean,
"executionTimeMs": number
}
}
```
**Example Usage:**
```bash
#!/usr/bin/env bash
input=$(cat)
# Log slow operations for performance monitoring
execution_time=$(echo "$input" | jq -r '.postToolUse.executionTimeMs')
tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
if (( execution_time > 5000 )); then
context="PERFORMANCE: Slow operation detected - $tool_name took ${execution_time}ms"
echo "{\"cancel\": false, \"contextModification\": \"$context\"}"
else
echo '{"cancel": false}'
fi
```
### User Interaction Hooks
These hooks monitor and enhance user communication with Cline. Use them to validate input, inject context, and track interaction patterns.
#### `UserPromptSubmit`
Triggered when the user enters text into the prompt box and presses enter to start a new task, continue a completed task, or resume a cancelled task. Use it to validate input, inject context based on the prompt, and track interaction patterns.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "UserPromptSubmit",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"userPromptSubmit": {
"prompt": "string",
"attachments": ["string"]
}
}
```
**Example Usage:**
```bash
#!/usr/bin/env bash
input=$(cat)
# Inject coding standards context for certain keywords
prompt=$(echo "$input" | jq -r '.userPromptSubmit.prompt')
context=""
if echo "$prompt" | grep -qi "component\|react"; then
context="CODING_STANDARDS: Follow React functional component patterns with proper TypeScript types"
elif echo "$prompt" | grep -qi "api\|endpoint"; then
context="CODING_STANDARDS: Use consistent REST API patterns with proper error handling"
fi
if [[ -n "$context" ]]; then
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
else
echo '{"cancel": false}'
fi
```
### Task Lifecycle Hooks
These hooks monitor and respond to task state changes from start to finish. Use them to track progress, restore state, and trigger workflows.
#### `TaskStart`
Triggered once at the beginning of a new task. Use it to detect project type, initialize tracking, and inject initial context that shapes how Cline approaches the work.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskStart",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskStart": {
"taskMetadata": {
"taskId": "string",
"ulid": "string",
"initialTask": "string"
}
}
}
```
**Example Usage:**
```bash
#!/usr/bin/env bash
input=$(cat)
# Detect project type and inject relevant context
context=""
if [[ -f "package.json" ]]; then
if grep -q "react" package.json; then
context="PROJECT_TYPE: React application detected. Follow component-based architecture."
elif grep -q "express" package.json; then
context="PROJECT_TYPE: Express.js API detected. Follow RESTful patterns."
else
context="PROJECT_TYPE: Node.js project detected."
fi
elif [[ -f "requirements.txt" ]] || [[ -f "pyproject.toml" ]]; then
context="PROJECT_TYPE: Python project detected. Follow PEP 8 standards."
elif [[ -f "Cargo.toml" ]]; then
context="PROJECT_TYPE: Rust project detected. Follow Rust conventions."
fi
if [[ -n "$context" ]]; then
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
else
echo '{"cancel": false}'
fi
```
#### `TaskResume`
Triggered when the user resumes a task that has been cancelled or aborted. Use it to restore state, refresh context, and log resumption for analytics or external system notifications.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskResume",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskResume": {
"taskMetadata": {
"taskId": "string",
"ulid": "string"
},
"previousState": {
"lastMessageTs": "string",
"messageCount": "string",
"conversationHistoryDeleted": "string"
}
}
}
```
#### `TaskCancel`
Triggered when the user cancels a task or aborts a hook execution. Use it to cleanup resources, log cancellation details, and notify external systems about interrupted work.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskCancel",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskCancel": {
"taskMetadata": {
"taskId": "string",
"ulid": "string"
}
}
}
```
#### `TaskComplete`
Triggered when Cline finishes its work and successfully executes the `attempt_completion` tool to finalize the task output. Use it to track completion metrics, generate reports, log task outcomes, and trigger completion workflows.
**Input Fields:**
```json
{
"clineVersion": "string",
"hookName": "TaskComplete",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"taskComplete": {
"taskMetadata": {
"taskId": "string",
"ulid": "string"
}
}
}
```
**Example Usage:**
```bash
#!/usr/bin/env bash
input=$(cat)
# Extract task metadata
task_id=$(echo "$input" | jq -r '.taskComplete.taskMetadata.taskId // "unknown"')
ulid=$(echo "$input" | jq -r '.taskComplete.taskMetadata.ulid // "unknown"')
# Log completion
completion_log="$HOME/.cline_completions/$(date +%Y-%m-%d).log"
mkdir -p "$(dirname "$completion_log")"
echo "$(date -Iseconds): Task $task_id completed (ULID: $ulid)" >> "$completion_log"
# Provide context about completion
context="TASK_COMPLETED: Task $task_id finished successfully. Completion logged."
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
```
### System Events Hooks
These hooks monitor internal Cline operations and system-level events. Use them to track context usage, log system behavior, and analyze performance patterns.
## JSON Communication Protocol
Hooks receive JSON via stdin and return JSON via stdout.
### Input Format
All hooks receive a JSON object through stdin with this base structure:
```json
{
"clineVersion": "string",
"hookName": "string",
"timestamp": "string",
"taskId": "string",
"workspaceRoots": ["string"],
"userId": "string",
"[hookSpecificField]": {
// Hook-specific data structure
}
}
```
### Output Format
Your hook script must output a JSON response as the final stdout content:
```json
{
"cancel": false,
"contextModification": "WORKSPACE_RULES: Use TypeScript",
"errorMessage": "Error details if blocking"
}
```
**Field Descriptions:**
- **`cancel`** (required): Boolean controlling whether execution continues
- `true`: Block the current action
- `false`: Allow the action to proceed
- **`contextModification`** (optional): String that gets injected into the conversation
- Affects future AI decisions, not the current one
- Use clear prefixes like `WORKSPACE_RULES:`, `PERFORMANCE:`, `SECURITY:` for categorization
- Maximum length: 50KB
- **`errorMessage`** (optional): String shown to user when `cancel` is `true`
- Only displayed when blocking an action
- Should explain why the action was blocked
### Logging During Execution
Your hook script can output logging or diagnostic information to stdout during execution, as long as the JSON response is the last thing written:
```bash
#!/usr/bin/env bash
echo "Processing hook..." # This is fine
echo "Tool: $tool_name" # This is also fine
# The JSON must be last:
echo '{"cancel": false}'
```
Cline will parse only the final JSON object from stdout.
### Error Handling
Hook execution errors don't prevent task execution - only returning `"cancel": true` can halt a task. All other errors are treated as hook failures, not reasons to abort the task.
**Hook Status Display:**
- **Completed** (grey): Hook executed successfully, regardless of whether it returned `"cancel": false` or no JSON output
- **Failed** (red): Hook exited with non-zero status, output invalid JSON, or timed out. The UI displays the error details (e.g., exit code number)
- **Aborted** (red): Hook returned `"cancel": true`, halting the task. User must manually resume the task to continue
**Important:** Even when a hook fails (non-zero exit, invalid JSON, timeout), Cline continues with the task. Only `"cancel": true` stops execution.
### Context Modification Timing
Context injection affects future decisions, not current ones. When a hook runs:
1. The AI has already decided what to do
2. The hook can block or allow it
3. Any context gets added to the conversation
4. The next AI request sees that context
This means:
- **PreToolUse hooks**: Use for blocking bad actions + injecting context for next decision
- **PostToolUse hooks**: Use for learning from completed actions
### Helpful Tip: String Escaping in JSON
When your hook needs to include strings containing unescaped quote characters (`"`) in JSON output, use jq's `--arg` flag for proper escaping:
```bash
#!/usr/bin/env bash
# When $output contains unescaped quote characters (")...
output='{"foo":"bar"}'
# Use the --arg flag for automatic string escaping
jq -n --arg ctx "$output" '{cancel: false, contextModification: $ctx}'
# This will result in:
# {
# "cancel": false,
# "contextModification": "{\"foo\":\"bar\"}"
# }
```
The `--arg` flag automatically escapes special characters, preventing JSON parsing errors when your context modification includes complex strings or nested JSON structures.
## Hook Execution Environment
### Execution Context
Hooks are executable scripts that run with the same permissions as VS Code. They have unrestricted access to:
- The entire filesystem (any file the user can access)
- All environment variables
- System commands and tools
- Network resources
Hooks can perform any operation the user could perform in a terminal, including reading and writing files outside the workspace, making network requests, and executing system commands.
### Security Considerations
<Warning>
Hooks run with the same permissions as VS Code. They can access all workspace files and environment variables. Review hooks from untrusted sources before enabling them.
</Warning>
### Performance Guidelines
Hooks have a 30 second timeout. As long as your hook completes within this time, it can perform any operations needed, including network calls or heavy computations.
### Hook Discovery
Cline searches for hooks in this order:
1. Project-specific: `.clinerules/hooks/` in workspace root
2. User-global: `~/Documents/Cline/Hooks/`
Project-specific hooks override global hooks with the same name.
+146
View File
@@ -0,0 +1,146 @@
---
title: "Hooks Overview"
sidebarTitle: "Overview"
description: "Inject custom logic into Cline's workflow to validate operations, monitor tool usage, and shape AI decisions"
---
Hooks let you inject custom logic into Cline's workflow at key moments. Think of them as automated checkpoints where you can validate operations before they execute, monitor tool usage as it happens, and shape how Cline makes decisions.
Hooks run automatically when specific events happen during development. They receive detailed information about each operation, can block problematic actions before they cause issues, and can inject context that guides future AI decisions.
The real power comes from combining these capabilities. You can:
- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
- Learn from what's happening and build up project knowledge over time
- Monitor performance and catch issues as they emerge
- Track everything for analytics or compliance
- Trigger external tools or services at the right moments
## Getting Started
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/hooks.gif" alt="Hooks in action" />
</Frame>
<Note>
Hooks work across all platforms: Windows, macOS, and Linux. The bash examples in this documentation work with standard shells on all platforms (including Git Bash or WSL on Windows).
</Note>
Setting up hooks in Cline is user-friendly with the built-in hooks management interface. Here's how to get started:
<Steps>
<Step title="Access the Hooks Interface">
Navigate to the Hooks management interface:
<Frame>
<img src="/assets/hooks/hooks-interface-with-dropdown.png" alt="Hooks management interface showing Global Hooks and project-specific hooks with dropdown menu" />
</Frame>
1. Open Cline (ensure hooks are enabled in settings)
2. Look for the **Hooks** tab at the top (alongside Rules and Workflows)
3. Click on **Hooks** to open the hooks management panel
The interface shows you all available hook types and existing hooks organized by workspace.
</Step>
<Step title="Understand Hook Locations">
Hooks are automatically organized by location in the interface:
**Global Hooks** - Apply to all workspaces:
- Stored in `~/Documents/Cline/Hooks/`
- Perfect for personal coding standards and universal rules
**Project-Specific Hooks** - Apply only to current project:
- Stored in `.clinerules/hooks/` within your repo
- Great for project-specific validation and team workflows
- Can be committed to version control for team sharing
Multi-root workspaces run hooks from all of the repos in your open workspace, making it easy to manage and run hooks across different repos within the same workspace.
</Step>
<Step title="Create Your First Hook">
Use the intuitive interface to create hooks:
<Frame>
<img src="/assets/hooks/hooks-empty-state.png" alt="Empty hooks interface showing New hook... dropdowns for both Global Hooks and project-specific hooks before any hooks are created" />
</Frame>
1. **Choose your location**: Decide between Global Hooks or project-specific hooks
2. **Select hook type**: Click the **"New hook..."** dropdown in your chosen location
3. **Pick a hook type**: The dropdown shows all available hook types that haven't been created yet in this location. Only one of each hook type is allowed per hooks directory, so the dropdown automatically filters to show only the remaining available types.
<Frame>
<img src="/assets/hooks/new-hook-dropdown.png" alt="Creating a new hook with the dropdown menu showing UserPromptSubmit selected with description" />
</Frame>
4. **Review and edit the hook**: Click the pencil icon to review the hook's code and add your custom logic
5. **Enable the hook**: Once you understand and approve of the hook's behavior, toggle the switch to activate it
<Frame>
<img src="/assets/hooks/hook-controls.png" alt="Hook management controls showing toggle, edit, and delete buttons for each hook" />
</Frame>
<Warning>
Always review a hook's code before enabling it. Hooks execute automatically during your workflow, so it's important to understand what they do before activation.
</Warning>
</Step>
<Step title="Test Your Hook">
To develop and refine your hook, you'll need to trigger it multiple times during testing. Each hook type is triggered by different events in Cline's workflow. For example:
- **TaskStart** hooks trigger when you start a new task
- **PreToolUse** hooks trigger before Cline executes tools like file editing
- **PostToolUse** hooks trigger after tool execution completes
- **UserPromptSubmit** hooks trigger when you submit a message to Cline
For complete details on when each hook type is triggered and how to test them effectively, see the [Hook Reference](/features/hooks/hook-reference) documentation. This includes the specific conditions that trigger each hook and examples of how to invoke them during development.
</Step>
</Steps>
<Tip>
Start with a simple hook that just logs information before building complex validation logic. This helps you understand the data structure and timing.
</Tip>
## What You Can Build
Once you understand the basics, hooks open up creative possibilities:
<CardGroup cols={2}>
<Card title="Intelligent Code Review" icon="code-branch">
Run linters or custom validators before files get saved. Block commits that don't pass checks. Track code quality metrics over time.
</Card>
<Card title="Security Enforcement" icon="shield-halved">
Prevent operations that violate security policies. Detect when sensitive data might be exposed. Audit all file access for compliance.
</Card>
<Card title="Development Analytics" icon="chart-line">
Measure how long different operations take. Identify patterns in how the AI works. Generate productivity reports from hook data.
</Card>
<Card title="Integration Hub" icon="plug">
Connect to issue trackers when certain keywords appear. Update project management tools. Sync with external APIs at the right moments.
</Card>
</CardGroup>
The key is combining hooks with external tools. A hook can be the glue between Cline's workflow and the rest of your development ecosystem.
## Explore the Documentation
<CardGroup cols={2}>
<Card title="Hook Reference" icon="book" href="/features/hooks/hook-reference">
Complete API reference for all hook types, JSON schemas, and field documentation.
</Card>
<Card title="Samples" icon="code" href="/features/hooks/samples">
Practical examples and complete working scripts for common use cases.
</Card>
</CardGroup>
## Related Features
Hooks complement other Cline features:
- [Cline Rules](/features/cline-rules) define high-level guidance that hooks can enforce
- [Checkpoints](/features/checkpoints) let you roll back changes if a hook didn't catch an issue
- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets for automated operations
+755
View File
@@ -0,0 +1,755 @@
---
title: "Samples"
sidebarTitle: "Samples"
description: "Practical hook examples organized by complexity level - from beginner to advanced patterns"
---
This page provides complete, production-ready hook examples organized by skill level. Each example includes full working code, detailed explanations, and guidance on when to use each pattern.
## How to Use These Samples
Each sample is designed to be:
- **Copy-and-paste ready**: Use them directly or as starting points
- **Educational**: Learn hook concepts through progressive complexity
- **Practical**: Solve real development workflow challenges
Choose samples based on your experience level and gradually work up to more advanced patterns.
---
## Beginner Examples
Perfect for getting started with hooks. These examples demonstrate core concepts with straightforward logic.
### 1. Project Type Detection
**Hook:** `TaskStart`
```bash
#!/usr/bin/env bash
# Project Type Detection Hook
#
# Overview: Automatically detects project type at task start and injects relevant
# coding standards and best practices into the AI context. This helps Cline understand
# your project structure and apply appropriate conventions from the beginning.
#
# Demonstrates: Basic hook input/output, file system checks, conditional logic,
# and context injection to guide AI behavior.
input=$(cat)
# Read basic JSON structure and detect project type
context=""
# Check for different project indicators
if [[ -f "package.json" ]]; then
if grep -q "react" package.json; then
context="PROJECT_TYPE: React application detected. Follow component-based architecture and use functional components."
elif grep -q "express" package.json; then
context="PROJECT_TYPE: Express.js API detected. Follow RESTful patterns and proper middleware structure."
else
context="PROJECT_TYPE: Node.js project detected. Use proper npm scripts and dependency management."
fi
elif [[ -f "requirements.txt" ]] || [[ -f "pyproject.toml" ]]; then
context="PROJECT_TYPE: Python project detected. Follow PEP 8 standards and use virtual environments."
elif [[ -f "Cargo.toml" ]]; then
context="PROJECT_TYPE: Rust project detected. Follow Rust conventions and use proper error handling."
elif [[ -f "go.mod" ]]; then
context="PROJECT_TYPE: Go project detected. Follow Go conventions and use proper package structure."
fi
# Return the context to guide Cline's behavior
if [[ -n "$context" ]]; then
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
else
echo '{"cancel": false}'
fi
```
**Key Concepts:**
- Reading hook input with `input=$(cat)`
- Using file system checks to detect project type
- Returning context to influence AI behavior
- Basic JSON output with `jq`
### 2. File Extension Validator
**Hook:** `PreToolUse`
```bash
#!/usr/bin/env bash
# File Extension Validator Hook
#
# Overview: Enforces TypeScript file extensions in TypeScript projects by blocking
# creation of .js and .jsx files. This prevents common mistakes where developers
# accidentally create JavaScript files when they should be using TypeScript.
#
# Demonstrates: PreToolUse blocking, parameter extraction, conditional validation,
# and providing clear error messages to guide users toward correct file extensions.
input=$(cat)
# Extract tool information
tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
# Only process file creation tools
if [[ "$tool_name" != "write_to_file" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Check if this is a TypeScript project
if [[ ! -f "tsconfig.json" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Get the file path from tool parameters
file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
if [[ -z "$file_path" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Block .js files in TypeScript projects
if [[ "$file_path" == *.js ]]; then
echo '{"cancel": true, "errorMessage": "JavaScript files (.js) are not allowed in TypeScript projects. Use .ts extension instead."}'
exit 0
fi
# Block .jsx files, suggest .tsx
if [[ "$file_path" == *.jsx ]]; then
echo '{"cancel": true, "errorMessage": "JSX files (.jsx) are not allowed in TypeScript projects. Use .tsx extension instead."}'
exit 0
fi
# Everything is OK
echo '{"cancel": false}'
```
**Key Concepts:**
- Extracting tool name and parameters
- Conditional logic based on project state
- Blocking operations with `"cancel": true`
- Providing helpful error messages
### 3. Basic Performance Monitor
**Hook:** `PostToolUse`
```bash
#!/usr/bin/env bash
# Basic Performance Monitor Hook
#
# Overview: Monitors tool execution times and logs operations that exceed a 3-second
# threshold. This helps identify performance bottlenecks and provides feedback to
# users about system resource issues that may be slowing down Cline's operations.
#
# Demonstrates: PostToolUse hook usage, arithmetic operations in bash, simple file
# logging, and conditional context injection based on performance metrics.
input=$(cat)
# Extract performance information
tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
execution_time=$(echo "$input" | jq -r '.postToolUse.executionTimeMs // 0')
success=$(echo "$input" | jq -r '.postToolUse.success')
# Log slow operations (threshold: 3 seconds)
if (( execution_time > 3000 )); then
# Create simple log directory
mkdir -p "$HOME/.cline_logs"
# Log the slow operation
echo "$(date -Iseconds): SLOW OPERATION - $tool_name took ${execution_time}ms" >> "$HOME/.cline_logs/performance.log"
# Provide feedback to user
context="PERFORMANCE: Operation $tool_name took ${execution_time}ms. Consider checking system resources if this happens frequently."
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
else
echo '{"cancel": false}'
fi
```
**Key Concepts:**
- Processing results after tool execution
- Basic arithmetic operations in bash
- Simple file logging
- Conditional context injection
## Intermediate Examples
These examples demonstrate more advanced concepts including external tool integration, pattern matching, and structured logging.
### 4. Code Quality with Linting
**Hook:** `PreToolUse`
```bash
#!/usr/bin/env bash
# Code Quality Linting Hook
#
# Overview: Integrates ESLint and Flake8 to enforce code quality standards before
# files are written. Blocks file creation if linting errors are detected, ensuring
# all code meets quality standards. Supports TypeScript, JavaScript, and Python files.
#
# Demonstrates: External tool integration, temporary file handling, regex pattern
# matching, and comprehensive error reporting with actionable feedback.
input=$(cat)
tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
# Only lint file write operations
if [[ "$tool_name" != "write_to_file" ]]; then
echo '{"cancel": false}'
exit 0
fi
file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
# Skip non-code files
if [[ ! "$file_path" =~ \.(ts|tsx|js|jsx|py|rs)$ ]]; then
echo '{"cancel": false}'
exit 0
fi
# Get file content from the tool parameters
content=$(echo "$input" | jq -r '.preToolUse.parameters.content // empty')
if [[ -z "$content" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Create temporary file for linting
temp_file=$(mktemp)
echo "$content" > "$temp_file"
# Run appropriate linter based on file extension
lint_errors=""
if [[ "$file_path" =~ \.(ts|tsx)$ ]] && command -v eslint > /dev/null; then
lint_output=$(eslint "$temp_file" --format=json 2>/dev/null || true)
if [[ "$lint_output" != "[]" ]] && [[ -n "$lint_output" ]]; then
error_count=$(echo "$lint_output" | jq '.[0].errorCount // 0')
if (( error_count > 0 )); then
messages=$(echo "$lint_output" | jq -r '.[0].messages[] | "\(.line):\(.column) \(.message)"')
lint_errors="ESLint errors found:\n$messages"
fi
fi
elif [[ "$file_path" =~ \.py$ ]] && command -v flake8 > /dev/null; then
lint_output=$(flake8 "$temp_file" 2>/dev/null || true)
if [[ -n "$lint_output" ]]; then
lint_errors="Flake8 errors found:\n$lint_output"
fi
fi
# Cleanup
rm -f "$temp_file"
# Block if linting errors found
if [[ -n "$lint_errors" ]]; then
error_message="Code quality check failed. Please fix these issues:\n\n$lint_errors"
jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
else
echo '{"cancel": false}'
fi
```
**Key Concepts:**
- Temporary file creation and cleanup
- External tool integration (eslint, flake8)
- Complex pattern matching with regex
- Structured error reporting
### 5. Security Scanner
**Hook:** `PreToolUse`
```bash
#!/usr/bin/env bash
# Security Scanner Hook
#
# Overview: Scans file content for hardcoded secrets (API keys, tokens, passwords)
# before files are written. Blocks creation of files containing secrets except in
# safe locations like .env.example files or documentation, preventing credential leaks.
#
# Demonstrates: Pattern matching with regex arrays, file path exception handling,
# security-focused validation, and clear user guidance in error messages.
input=$(cat)
tool_name=$(echo "$input" | jq -r '.preToolUse.toolName')
# Only check file operations
if [[ "$tool_name" != "write_to_file" ]]; then
echo '{"cancel": false}'
exit 0
fi
content=$(echo "$input" | jq -r '.preToolUse.parameters.content // empty')
file_path=$(echo "$input" | jq -r '.preToolUse.parameters.path // empty')
# Skip if no content
if [[ -z "$content" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Define secret patterns (simplified for readability)
secrets_found=""
# Check for API keys
if echo "$content" | grep -qi "api[_-]*key.*[=:].*['\"][a-z0-9_-]{10,}['\"]"; then
secrets_found+="- API key pattern detected\n"
fi
# Check for tokens
if echo "$content" | grep -qi "token.*[=:].*['\"][a-z0-9_-]{10,}['\"]"; then
secrets_found+="- Token pattern detected\n"
fi
# Check for passwords
if echo "$content" | grep -qi "password.*[=:].*['\"][^'\"]{8,}['\"]"; then
secrets_found+="- Password pattern detected\n"
fi
# Allow secrets in safe files
safe_patterns=("\.env\.example$" "\.env\.template$" "/docs/" "\.md$")
is_safe_file=false
for safe_pattern in "${safe_patterns[@]}"; do
if [[ "$file_path" =~ $safe_pattern ]]; then
is_safe_file=true
break
fi
done
if [[ -n "$secrets_found" ]] && [[ "$is_safe_file" == false ]]; then
error_message="🔒 SECURITY ALERT: Potential secrets detected in $file_path
$secrets_found
Please use environment variables or a secrets management service instead."
jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
else
echo '{"cancel": false}'
fi
```
**Key Concepts:**
- Pattern arrays and iteration
- File path exception handling
- Security-focused validation
- Clear user guidance in error messages
### 6. Git Workflow Assistant
**Hook:** `PostToolUse`
```bash
#!/usr/bin/env bash
# Git Workflow Assistant Hook
#
# Overview: Analyzes file modifications and provides intelligent git workflow suggestions
# based on file types and current branch. Encourages best practices like feature branches
# for components and test branches for test files, with actionable git commands.
#
# Demonstrates: Git integration, branch analysis, file path pattern matching, and
# contextual suggestions to guide users toward better git practices.
input=$(cat)
tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
success=$(echo "$input" | jq -r '.postToolUse.success')
# Only process successful file modifications
if [[ "$success" != "true" ]] || [[ "$tool_name" != "write_to_file" && "$tool_name" != "replace_in_file" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Check if we're in a git repository
if ! git rev-parse --git-dir > /dev/null 2>&1; then
echo '{"cancel": false}'
exit 0
fi
file_path=$(echo "$input" | jq -r '.postToolUse.parameters.path // empty')
current_branch=$(git branch --show-current 2>/dev/null || echo "main")
# Analyze file type and suggest appropriate branch naming
context=""
if [[ "$file_path" == *"component"* ]] && [[ "$current_branch" == "main" || "$current_branch" == "master" ]]; then
component_name=$(basename "$file_path" .tsx .ts .jsx .js)
context="GIT_WORKFLOW: Consider creating a feature branch: git checkout -b feature/add-${component_name,,}-component"
elif [[ "$file_path" == *"test"* ]] || [[ "$file_path" == *"spec"* ]]; then
if [[ "$current_branch" == "main" || "$current_branch" == "master" ]]; then
context="GIT_WORKFLOW: Consider creating a test branch: git checkout -b test/add-tests-$(basename "$(dirname "$file_path")")"
fi
fi
# Add staging guidance
if [[ -n "$context" ]]; then
context="$context After completing changes, use 'git add $file_path' to stage for commit."
else
context="GIT_WORKFLOW: File modified: $file_path. Use 'git add $file_path' when ready to commit."
fi
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
```
**Key Concepts:**
- Git repository detection
- Branch analysis and suggestions
- File path analysis for context
- Actionable user guidance
## Advanced Examples
These examples showcase sophisticated patterns including external integrations, asynchronous processing, and complex state management.
### 7. Comprehensive Task Lifecycle Manager
**Hook:** `TaskComplete`
```bash
#!/usr/bin/env bash
# Comprehensive Task Lifecycle Manager Hook
#
# Overview: Tracks task completions by generating detailed markdown reports with
# workspace information and git state, and optionally sends webhook notifications
# to external systems. Perfect for enterprise environments requiring audit trails.
#
# Demonstrates: Complex data extraction, structured report generation, markdown
# heredocs, asynchronous webhook notifications, and robust error handling.
input=$(cat)
# Extract task metadata using proper API field paths
task_id=$(echo "$input" | jq -r '.taskId')
ulid=$(echo "$input" | jq -r '.taskComplete.taskMetadata.ulid // "unknown"')
completion_time=$(echo "$input" | jq -r '.timestamp')
# Create completion report directory with error handling
reports_dir="$HOME/.cline_reports"
if [[ ! -d "$(dirname "$reports_dir")" ]]; then
echo '{"cancel": false, "errorMessage": "Cannot access home directory"}'
exit 0
fi
mkdir -p "$reports_dir" || exit 0
# Generate safe, unique report filename
safe_task_id=$(echo "$task_id" | tr -cd '[:alnum:]_-' | head -c 50)
report_file="$reports_dir/completion_$(date +%Y%m%d_%H%M%S)_${safe_task_id}.md"
# Collect comprehensive workspace information
git_branch=$(git branch --show-current 2>/dev/null || echo "No git repository")
git_status_count=$(git status --porcelain 2>/dev/null | wc -l || echo "0")
project_name=$(basename "$PWD")
# Generate detailed completion report
cat > "$report_file" << EOF
# Cline Task Completion Report
**Task ID:** $task_id
**ULID:** $ulid
**Completed:** $(date -Iseconds)
**Completion Time:** $completion_time
## Workspace Information
- **Project:** $project_name
- **Git Branch:** $git_branch
- **Modified Files:** $git_status_count
## Completion Status
✅ Task completed successfully
## Next Steps
- Review changes made during this task
- Consider committing changes if appropriate
- Run tests to verify functionality
EOF
# Send webhook notification if configured
webhook_url="${COMPLETION_WEBHOOK_URL:-}"
if [[ -n "$webhook_url" ]]; then
payload=$(jq -n \
--arg task_id "$task_id" \
--arg ulid "$ulid" \
--arg workspace "$project_name" \
--arg timestamp "$completion_time" \
'{
event: "task_completed",
task_id: $task_id,
ulid: $ulid,
workspace: $workspace,
timestamp: $timestamp
}')
# Send notification in background with timeout
(curl -X POST \
-H "Content-Type: application/json" \
-d "$payload" \
"$webhook_url" \
--max-time 5 \
--silent > /dev/null 2>&1) &
fi
context="TASK_COMPLETED: ✅ Task $task_id finished successfully. Report saved to: $(basename "$report_file")"
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
```
**Key Concepts:**
- Complex data extraction and validation
- Structured report generation
- Asynchronous webhook notifications
- Error handling and resource management
### 8. Intelligent User Input Enhancer
**Hook:** `UserPromptSubmit`
```bash
#!/usr/bin/env bash
# Intelligent User Input Enhancer Hook
#
# Overview: Analyzes user prompts to detect potentially harmful commands, logs user
# activity for analytics, and intelligently injects project and git context based on
# prompt keywords. Provides safety guards while enhancing AI responses with relevant context.
#
# Demonstrates: UserPromptSubmit hook usage, multi-pattern safety validation, intelligent
# context detection from prompts, structured JSON logging, and dynamic suggestion generation.
input=$(cat)
user_prompt=$(echo "$input" | jq -r '.userPromptSubmit.prompt')
task_id=$(echo "$input" | jq -r '.taskId')
user_id=$(echo "$input" | jq -r '.userId')
# Log user activity for analytics
activity_log="$HOME/.cline_user_activity/$(date +%Y-%m-%d).log"
mkdir -p "$(dirname "$activity_log")"
activity_entry=$(jq -n \
--arg timestamp "$(date -Iseconds)" \
--arg task_id "$task_id" \
--arg user_id "$user_id" \
--arg prompt_length "${#user_prompt}" \
'{
timestamp: $timestamp,
task_id: $task_id,
user_id: $user_id,
prompt_length: ($prompt_length | tonumber),
workspace: env.PWD
}')
echo "$activity_entry" >> "$activity_log"
context_modifications=""
cancel_request=false
# Safety validation
harmful_patterns=("rm -rf" "delete.*all" "format.*drive" "sudo.*passwd")
for pattern in "${harmful_patterns[@]}"; do
if echo "$user_prompt" | grep -qi "$pattern"; then
cancel_request=true
error_message="🚨 SAFETY ALERT: Potentially harmful command detected. Please review your request."
break
fi
done
# Intelligent context enhancement
if [[ "$cancel_request" == false ]]; then
# Detect project context
if echo "$user_prompt" | grep -qi "file\|directory\|folder"; then
if [[ -f "package.json" ]]; then
project_name=$(jq -r '.name // "unknown"' package.json 2>/dev/null)
context_modifications+="PROJECT_CONTEXT: Working in Node.js project '$project_name'. "
elif [[ -f "requirements.txt" ]]; then
context_modifications+="PROJECT_CONTEXT: Working in Python project. "
fi
fi
# Git context enhancement
if echo "$user_prompt" | grep -qi "git\|commit\|branch" && git rev-parse --git-dir > /dev/null 2>&1; then
current_branch=$(git branch --show-current 2>/dev/null)
uncommitted=$(git status --porcelain | wc -l)
context_modifications+="GIT_CONTEXT: On branch '$current_branch' with $uncommitted uncommitted changes. "
fi
# Tool suggestions
if echo "$user_prompt" | grep -qi "search.*code\|find.*function"; then
context_modifications+="SUGGESTION: Consider using search_files tool for code exploration. "
fi
fi
# Return response
if [[ "$cancel_request" == true ]]; then
jq -n --arg msg "$error_message" '{"cancel": true, "errorMessage": $msg}'
else
if [[ -n "$context_modifications" ]]; then
jq -n --arg ctx "$context_modifications" '{"cancel": false, "contextModification": $ctx}'
else
echo '{"cancel": false}'
fi
fi
```
**Key Concepts:**
- User interaction analysis and logging
- Multi-pattern safety validation
- Intelligent context detection
- Dynamic suggestion generation
### 9. Multi-Service Integration Hub
**Hook:** `PostToolUse`
```bash
#!/usr/bin/env bash
# Multi-Service Integration Hub Hook
#
# Overview: Detects file modifications by type (dependencies, CI/CD, frontend, backend, tests)
# and sends asynchronous webhook notifications to multiple external services like Slack and
# CI/CD systems. Enables seamless integration of Cline operations into enterprise workflows.
#
# Demonstrates: Advanced pattern matching with associative arrays, multi-service webhook
# orchestration, asynchronous background processing, and enterprise notification patterns.
input=$(cat)
tool_name=$(echo "$input" | jq -r '.postToolUse.toolName')
success=$(echo "$input" | jq -r '.postToolUse.success')
file_path=$(echo "$input" | jq -r '.postToolUse.parameters.path // empty')
# Only process successful file operations
if [[ "$success" != "true" ]] || [[ "$tool_name" != "write_to_file" && "$tool_name" != "replace_in_file" ]]; then
echo '{"cancel": false}'
exit 0
fi
# Define workflow triggers
declare -A triggers=(
["package\\.json|yarn\\.lock"]="dependencies"
["\\.github/workflows/"]="ci_cd"
["src/.*component"]="frontend"
["api/.*\\.(ts|js)"]="backend"
[".*\\.(test|spec)\\."]="testing"
)
# Determine triggered workflows
triggered_workflows=""
for pattern in "${!triggers[@]}"; do
if [[ "$file_path" =~ $pattern ]]; then
workflow_type="${triggers[$pattern]}"
triggered_workflows+="$workflow_type "
fi
done
context="WORKFLOW: File modified: $file_path"
if [[ -n "$triggered_workflows" ]]; then
# Slack notification (async)
slack_webhook="${SLACK_WEBHOOK_URL:-}"
if [[ -n "$slack_webhook" ]]; then
slack_payload=$(jq -n \
--arg file "$file_path" \
--arg workflows "$triggered_workflows" \
--arg workspace "$(basename "$PWD")" \
'{
text: ("🔧 Cline modified `" + $file + "` in " + $workspace),
color: "good",
fields: [{
title: "Triggered Workflows",
value: $workflows,
short: true
}]
}')
(curl -X POST -H "Content-Type: application/json" -d "$slack_payload" "$slack_webhook" --max-time 5 --silent > /dev/null 2>&1) &
fi
# CI/CD webhook (async)
ci_webhook="${CI_WEBHOOK_URL:-}"
if [[ -n "$ci_webhook" ]]; then
ci_payload=$(jq -n \
--arg file "$file_path" \
--arg workflows "$triggered_workflows" \
'{
event: "file_modified",
file_path: $file,
workflows: ($workflows | split(" "))
}')
(curl -X POST -H "Content-Type: application/json" -d "$ci_payload" "$ci_webhook" --max-time 5 --silent > /dev/null 2>&1) &
fi
context+=" Triggered workflows: $triggered_workflows. Notifications sent to configured services."
fi
jq -n --arg ctx "$context" '{"cancel": false, "contextModification": $ctx}'
```
**Key Concepts:**
- Multi-service integration patterns
- Asynchronous webhook orchestration
- Complex workflow detection
- Enterprise notification systems
## Usage Tips
### Running Multiple Hooks
You can use multiple hooks together by creating separate files for each hook type:
```bash
# Create hooks directory
mkdir -p .clinerules/hooks
# Create multiple hooks
touch .clinerules/hooks/PreToolUse
touch .clinerules/hooks/PostToolUse
touch .clinerules/hooks/TaskStart
# Make them executable
chmod +x .clinerules/hooks/*
```
### Environment Configuration
Set up environment variables for external integrations:
```bash
# Add to your .bashrc or .zshrc
export SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..."
export JIRA_URL="https://yourcompany.atlassian.net"
export JIRA_USER="your-email@company.com"
export JIRA_TOKEN="your-api-token"
export CI_WEBHOOK_URL="https://your-ci-system.com/hooks/cline"
```
### Testing Your Hooks
Test hooks manually by simulating their input:
```bash
# Test a PreToolUse hook
echo '{
"clineVersion": "1.0.0",
"hookName": "PreToolUse",
"timestamp": "2024-01-01T12:00:00Z",
"taskId": "test",
"workspaceRoots": ["/path/to/workspace"],
"userId": "test-user",
"preToolUse": {
"toolName": "write_to_file",
"parameters": {
"path": "test.js",
"content": "console.log(\"test\");"
}
}
}' | .clinerules/hooks/PreToolUse
```
These examples provide a solid foundation for implementing hooks in your development workflow. Customize them based on your specific needs, tools, and integrations.
@@ -0,0 +1,283 @@
---
title: "Explain Changes Command"
sidebarTitle: "/explain-changes"
---
`/explain-changes` is a slash command that generates AI-powered explanations for any git diff. Unlike the [Explain Changes button](/features/explain-changes) which explains changes from a completed task, this command lets you explain changes between any two git references - commits, branches, tags, PRs, staged changes, or your working directory.
<video
src="https://storage.googleapis.com/cline_public_images/slash-code-explain.mp4"
autoPlay
loop
muted
playsInline
/>
## Requirements
<Note>
The `/explain-changes` command requires a **git repository**. Make sure you're working in a directory that has been initialized with git.
</Note>
For PR explanations, you'll need the [GitHub CLI (gh)](https://cli.github.com/) installed and authenticated. For GitLab merge request explanations, you'll need the [GitLab CLI (glab)](https://gitlab.com/gitlab-org/cli) installed and authenticated.
Unlike the Explain Changes button, this command does **not** require checkpoints to be enabled since it uses git references directly.
## Using the Command
Type `/explain-changes` in the chat input. Cline will:
1. Analyze your git history to understand what changes exist
2. Gather context by reading relevant files
3. Determine appropriate git references to compare
4. Generate a diff view with streaming inline explanations
## How It Works
When you use `/explain-changes`, Cline:
1. **Gathers context**: Runs git commands to understand your repository state
2. **Identifies changes**: Determines which files changed between references
3. **Reads relevant files**: Builds context for better explanations
4. **Calls generate_explanation**: Creates the diff view and streams explanations
5. **Displays results**: Opens a multi-file diff with inline comments
## Use Cases
### Explain the Last Commit
The most common use case - understand what changed in the most recent commit:
```
/explain-changes
```
Cline will examine HEAD and compare it to HEAD~1, explaining all the changes in that commit.
**When to use:**
- After pulling changes from a teammate
- Reviewing your own work before pushing
- Understanding what a merge commit brought in
### Explain Uncommitted Changes
Understand your work-in-progress changes before committing:
```
/explain-changes for my uncommitted work
```
Cline compares HEAD to your working directory, explaining all modified files.
**When to use:**
- Before staging changes to ensure they're complete
- After a long coding session to remember what you changed
- To verify changes before creating a commit
### Explain Staged Changes
Review exactly what you're about to commit:
```
/explain-changes for my staged changes
```
Cline examines only the changes you've staged with `git add`.
**When to use:**
- Final review before committing
- When you've staged a subset of changes and want to verify
- To ensure you haven't accidentally staged unintended files
### Explain a Specific Commit
Understand any commit in your history:
```
/explain-changes for commit abc123
```
Or by commit message:
```
/explain-changes for the commit that added authentication
```
Cline will find the commit and explain what it changed.
**When to use:**
- Investigating when a bug was introduced
- Understanding historical decisions
- Learning how a feature was implemented
### Explain a Range of Commits
Understand multiple commits at once:
```
/explain-changes for the last 3 commits
```
Or a specific range:
```
/explain-changes from v1.0.0 to v1.1.0
```
Cline compares the endpoints and explains all changes between them.
**When to use:**
- Understanding what changed in a release
- Reviewing a series of related commits
- Catching up after being away from the project
### Explain a Pull Request
Get AI explanations for any PR:
```
/explain-changes for PR #42
```
Cline uses the GitHub CLI to fetch PR details and explain the changes.
**When to use:**
- Reviewing someone else's PR
- Understanding a PR before approving
- Learning from PRs in open source projects
- Preparing to give PR feedback
### Explain Branch Differences
Compare any two branches:
```
/explain-changes between main and feature-branch
```
Or see what's changed on a feature branch:
```
/explain-changes for everything on my-feature that's not in main
```
**When to use:**
- Before merging a feature branch
- Understanding divergence between branches
- Planning a merge or rebase strategy
- Reviewing what a colleague has been working on
### Explain Changes to Specific Files
Focus on particular files or directories:
```
/explain-changes for src/auth in the last 5 commits
```
Cline filters the diff to show only relevant changes.
**When to use:**
- Understanding changes to a specific module
- Tracking modifications to critical files
- Learning how a particular feature evolved
### Explain Changes Since a Tag
Understand what's changed since a release:
```
/explain-changes since v2.0.0
```
Cline compares the tag to HEAD and explains all subsequent changes.
**When to use:**
- Preparing release notes
- Understanding what's new since a deployment
- Identifying changes for a changelog
### Explain a Merge Commit
Understand what a merge brought in:
```
/explain-changes for the merge from feature-x
```
Cline explains all the changes that were merged.
**When to use:**
- After merging a large feature branch
- Understanding what a merge conflict resolution changed
- Reviewing what others merged into main
### Explain Stashed Changes
Review what's in your stash:
```
/explain-changes for my stashed changes
```
Cline examines stash@{0} and explains its contents.
**When to use:**
- Before applying a stash
- Deciding whether to keep or drop a stash
- Remembering what you stashed days ago
## Interactive Comments
Just like the [Explain Changes](/features/explain-changes) button, the generated comments are fully interactive:
### Reply to Comments
Ask follow-up questions directly in any comment thread:
- "Why was this function refactored?"
- "What's the purpose of this new parameter?"
- "Could this cause any breaking changes?"
- "Is this change backwards compatible?"
The AI responds with context-aware explanations, understanding both the code and the broader changes.
### Move to Main Chat
Click the title area of any comment thread to move that conversation into Cline's main chat. This is useful when:
- You want Cline to make additional changes
- The discussion reveals something that needs more investigation
- You want to continue working with full Cline capabilities
- A review comment sparks an idea for improvements
### The generate_explanation Tool
Under the hood, `/explain-changes` uses the `generate_explanation` tool with these parameters:
| Parameter | Description | Example |
|-----------|-------------|---------|
| `title` | Descriptive title for the diff view | "Changes in commit abc123" |
| `from_ref` | Git reference for the "before" state | `HEAD~1`, `main`, `origin/main` |
| `to_ref` | Git reference for the "after" state (optional) | `HEAD`, `develop` |
If `to_ref` is omitted, the tool compares against the working directory.
## Tips for Better Explanations
1. **Be specific**: Instead of just `/explain-changes`, tell Cline what you want explained. "Explain the authentication changes in PR #42" gives better context than just "explain PR #42".
2. **Ask about intent**: The AI can explain not just what changed but why. Ask follow-up questions like "What problem was this solving?"
3. **Chain with other commands**: Use `/explain-changes` after investigating an issue to understand potential fixes, then continue with Cline to implement improvements.
4. **Use for learning**: When onboarding to a new codebase, use `/explain-changes` on significant PRs or commits to understand how features were built.
## Related Features
- [Explain Changes](/features/explain-changes) - The button-based version for task completions
- [Checkpoints](/features/checkpoints) - Enables the Explain Changes button
- [@git mentions](/features/at-mentions/git-mentions) - Reference git diffs in your prompts
-445
View File
@@ -1,445 +0,0 @@
---
title: "Workflows"
sidebarTitle: "Workflows"
---
Workflows allow you to define a series of steps to guide Cline through a repetitive set of tasks, such as deploying a service or submitting a PR.
To invoke a workflow, type `/[workflow-name.md]` in the chat.
## How to Create and Use Workflows
Workflows live alongside [Cline Rules](/features/cline-rules). Creating one is straightforward:
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/workflows.png" alt="Workflows tab in Cline" />
</Frame>
1. Create a markdown file with clear instructions for the steps Cline should take
2. Save it with a `.md` extension in your workflows directory
3. To trigger a workflow, just type `/` followed by the workflow filename
4. Provide any required parameters when prompted
The real power comes from how you structure your workflow files. You can:
- Leverage Cline's [built-in tools](/exploring-clines-tools/cline-tools-guide) like `ask_followup_question`, `read_file`, `search_files`, and `new_task`
- Use command-line tools you already have installed like `gh` or `docker`
- Reference external [MCP tool calls](/mcp/mcp-overview) like Slack or Whatsapp
- Chain multiple actions together in a specific sequence
## Real-world Example
I created a PR Review workflow that's already saving me tons of time.
````md pr-review.md [expandable]
You have access to the `gh` terminal command. I already authenticated it for you. Please review it to use the PR that I asked you to review. You're already in the `cline` repo.
<detailed_sequence_of_steps>
# GitHub PR Review Process - Detailed Sequence of Steps
## 1. Gather PR Information
1. Get the PR title, description, and comments:
```bash
gh pr view <PR-number> --json title,body,comments
```
2. Get the full diff of the PR:
```bash
gh pr diff <PR-number>
```
## 2. Understand the Context
1. Identify which files were modified in the PR:
```bash
gh pr view <PR-number> --json files
```
2. Examine the original files in the main branch to understand the context:
```xml
<read_file>
<path>path/to/file</path>
</read_file>
```
3. For specific sections of a file, you can use search_files:
```xml
<search_files>
<path>path/to/directory</path>
<regex>search term</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
```
## 3. Analyze the Changes
1. For each modified file, understand:
- What was changed
- Why it was changed (based on PR description)
- How it affects the codebase
- Potential side effects
2. Look for:
- Code quality issues
- Potential bugs
- Performance implications
- Security concerns
- Test coverage
## 4. Ask for User Confirmation
1. Before making a decision, ask the user if you should approve the PR, providing your assessment and justification:
```xml
<ask_followup_question>
<question>Based on my review of PR #<PR-number>, I recommend [approving/requesting changes]. Here's my justification:
[Detailed justification with key points about the PR quality, implementation, and any concerns]
Would you like me to proceed with this recommendation?</question>
<options>["Yes, approve the PR", "Yes, request changes", "No, I'd like to discuss further"]</options>
</ask_followup_question>
```
## 5. Ask if User Wants a Comment Drafted
1. After the user decides on approval/rejection, ask if they would like a comment drafted:
```xml
<ask_followup_question>
<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
</ask_followup_question>
```
2. If the user wants a comment drafted, provide a well-structured comment they can copy:
```
Thank you for this PR! Here's my assessment:
[Detailed assessment with key points about the PR quality, implementation, and any suggestions]
[Include specific feedback on code quality, functionality, and testing]
```
## 6. Make a Decision
1. Approve the PR if it meets quality standards:
```bash
# For single-line comments:
gh pr review <PR-number> --approve --body "Your approval message"
# For multi-line comments with proper whitespace formatting:
cat << EOF | gh pr review <PR-number> --approve --body-file -
Thanks @username for this PR! The implementation looks good.
I particularly like how you've handled X and Y.
Great work!
EOF
```
2. Request changes if improvements are needed:
```bash
# For single-line comments:
gh pr review <PR-number> --request-changes --body "Your feedback message"
# For multi-line comments with proper whitespace formatting:
cat << EOF | gh pr review <PR-number> --request-changes --body-file -
Thanks @username for this PR!
The implementation looks promising, but there are a few things to address:
1. Issue one
2. Issue two
Please make these changes and we can merge this.
EOF
```
Note: The `cat << EOF | ... --body-file -` approach preserves all whitespace and formatting without requiring temporary files. The `-` parameter tells the command to read from standard input.
</detailed_sequence_of_steps>
<example_review_process>
# Example PR Review Process
Let's walk through a real example of reviewing PR #3627 which fixes the thinking mode calculation for Claude 3.7 models.
## Step 1: Gather PR Information
```bash
# Get PR details
gh pr view 3627 --json title,body,comments
# Get the full diff
gh pr diff 3627
```
## Step 2: Understand the Context
```xml
# Examine the original files to understand what's being changed
<read_file>
<path>src/shared/api.ts</path>
</read_file>
# Look at the ThinkingBudgetSlider component implementation
<read_file>
<path>webview-ui/src/components/settings/ThinkingBudgetSlider.tsx</path>
</read_file>
# Check how thinking mode is currently handled in API providers
<search_files>
<path>src/api/providers</path>
<regex>reasoningOn</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
```
## Step 3: Analyze the Changes
From the PR information and code examination, we can see that:
1. The PR fixes an issue with the thinking mode budget calculation for Claude 3.7 models
2. Currently, the thinking budget is incorrectly calculated as 80% of maxTokens (8192), resulting in 6553 tokens
3. Claude 3.7 actually supports a much larger thinking budget (up to 64000 tokens)
4. The PR adds a `thinkingConfig` property with `maxBudget: 64000` to model definitions
5. It updates API handlers to use this value when reasoning mode is enabled
6. It enhances the slider component to calculate max values based on model-specific percentages
7. Comprehensive tests were added to verify the calculations
## Step 4: Ask for User Confirmation
```xml
<ask_followup_question>
<question>Based on my review of PR #3627, I recommend approving this PR. Here's my justification:
1. The PR correctly fixes the thinking mode budget calculation for Claude 3.7 models
2. It properly implements the thinkingConfig.maxBudget property (64000) for Claude 3.7 models
3. It applies the appropriate percentage (50%) for the slider calculation
4. The changes are well-tested with comprehensive unit tests
5. The implementation is clean and follows the project's coding standards
6. The PR includes helpful screenshots demonstrating the fix
Would you like me to proceed with approving this PR?</question>
<options>["Yes, approve the PR", "No, I'd like to discuss further", "Let me review it myself first"]</options>
</ask_followup_question>
```
## Step 5: Ask if User Wants a Comment Drafted
```xml
<ask_followup_question>
<question>Would you like me to draft a comment for this PR that you can copy and paste?</question>
<options>["Yes, please draft a comment", "No, I'll handle the comment myself"]</options>
</ask_followup_question>
```
## Step 6: Make a Decision
```bash
# Option 1: Simple one-line comment
gh pr review 3627 --approve --body "This PR looks good! It correctly fixes the thinking mode budget calculation for Claude 3.7 models."
# Option 2: Multi-line comment with proper whitespace formatting
cat << EOF | gh pr review 3627 --approve --body-file -
This PR looks good! It correctly fixes the thinking mode budget calculation for Claude 3.7 models.
I particularly like:
1. The proper implementation of thinkingConfig.maxBudget property (64000)
2. The appropriate percentage (50%) for the slider calculation
3. The comprehensive unit tests
4. The clean implementation that follows project coding standards
Great work!
EOF
```
</example_review_process>
<common_gh_commands>
# Common GitHub CLI Commands for PR Review
## Basic PR Commands
```bash
# List open PRs
gh pr list
# View a specific PR
gh pr view <PR-number>
# View PR with specific fields
gh pr view <PR-number> --json title,body,comments,files,commits
# Check PR status
gh pr status
```
## Diff and File Commands
```bash
# Get the full diff of a PR
gh pr diff <PR-number>
# List files changed in a PR
gh pr view <PR-number> --json files
# Check out a PR locally
gh pr checkout <PR-number>
```
## Review Commands
```bash
# Approve a PR (single-line comment)
gh pr review <PR-number> --approve --body "Your approval message"
# Approve a PR (multi-line comment with proper whitespace)
cat << EOF | gh pr review <PR-number> --approve --body-file -
Your multi-line
approval message with
proper whitespace formatting
EOF
# Request changes on a PR (single-line comment)
gh pr review <PR-number> --request-changes --body "Your feedback message"
# Request changes on a PR (multi-line comment with proper whitespace)
cat << EOF | gh pr review <PR-number> --request-changes --body-file -
Your multi-line
change request with
proper whitespace formatting
EOF
# Add a comment review (without approval/rejection)
gh pr review <PR-number> --comment --body "Your comment message"
# Add a comment review with proper whitespace
cat << EOF | gh pr review <PR-number> --comment --body-file -
Your multi-line
comment with
proper whitespace formatting
EOF
```
## Additional Commands
```bash
# View PR checks status
gh pr checks <PR-number>
# View PR commits
gh pr view <PR-number> --json commits
# Merge a PR (if you have permission)
gh pr merge <PR-number> --merge
```
</common_gh_commands>
<general_guidelines_for_commenting>
When reviewing a PR, please talk normally and like a friendly reviwer. You should keep it short, and start out by thanking the author of the pr and @ mentioning them.
Whether or not you approve the PR, you should then give a quick summary of the changes without being too verbose or definitive, staying humble like that this is your understanding of the changes. Kind of how I'm talking to you right now.
If you have any suggestions, or things that need to be changed, request changes instead of approving the PR.
Leaving inline comments in code is good, but only do so if you have something specific to say about the code. And make sure you leave those comments first, and then request changes in the PR with a short comment explaining the overall theme of what you're asking them to change.
</general_guidelines_for_commenting>
<example_comments_that_i_have_written_before>
<brief_approve_comment>
Looks good, though we should make this generic for all providers & models at some point
</brief_approve_comment>
<brief_approve_comment>
Will this work for models that may not match across OR/Gemini? Like the thinking models?
</brief_approve_comment>
<approve_comment>
This looks great! I like how you've handled the global endpoint support - adding it to the ModelInfo interface makes total sense since it's just another capability flag, similar to how we handle other model features.
The filtered model list approach is clean and will be easier to maintain than hardcoding which models work with global endpoints. And bumping the genai library was obviously needed for this to work.
Thanks for adding the docs about the limitations too - good for users to know they can't use context caches with global endpoints but might get fewer 429 errors.
</approve_comment>
<requesst_changes_comment>
This is awesome. Thanks @scottsus.
My main concern though - does this work for all the possible VS Code themes? We struggled with this initially which is why it's not super styled currently. Please test and share screenshots with the different themes to make sure before we can merge
</request_changes_comment>
<request_changes_comment>
Hey, the PR looks good overall but I'm concerned about removing those timeouts. Those were probably there for a reason - VSCode's UI can be finicky with timing.
Could you add back the timeouts after focusing the sidebar? Something like:
```typescript
await vscode.commands.executeCommand("claude-dev.SidebarProvider.focus")
await setTimeoutPromise(100) // Give UI time to update
visibleWebview = WebviewProvider.getSidebarInstance()
```
</request_changes_comment>
<request_changes_comment>
Heya @alejandropta thanks for working on this!
A few notes:
1 - Adding additional info to the environment variables is fairly problematic because env variables get appended to **every single message**. I don't think this is justifiable for a somewhat niche use case.
2 - Adding this option to settings to include that could be an option, but we want our options to be simple and straightforward for new users
3 - We're working on revisualizing the way our settings page is displayed/organized, and this could potentially be reconciled once that is in and our settings page is more clearly delineated.
So until the settings page is update, and this is added to settings in a way that's clean and doesn't confuse new users, I don't think we can merge this. Please bear with us.
</request_changes_comment>
<request_changes_comment>
Also, don't forget to add a changeset since this fixes a user-facing bug.
The architectural change is solid - moving the focus logic to the command handlers makes sense. Just don't want to introduce subtle timing issues by removing those timeouts.
</request_changes_comment>
</example_comments_that_i_have_written_before>
````
When I get a new PR to review, I used to manually gather context: checking the PR description, examining the diff, looking at surrounding files, and finally forming an opinion. Now I just:
1. Type `/pr-review.md` in chat
2. Paste in the PR number
3. Let Cline handle everything else
My workflow uses the `gh` command-line tool and Cline's built in `ask_followup_question` to:
- Pull the PR description and comments
- Examine the diff
- Check surrounding files for context
- Analyze potential issues
- Asks me if it's cool approve it if everything looks good, with justification for why it should be approved
- If I say "yes," Cline automatically approves the PR with the `gh` command
This has taken my PR review process from a manual, multi-step operation to a single command that gives me everything I need to make an informed decision.
> This is just one example of a workflow file. You can find more in our [prompts repository](https://github.com/cline/prompts) for inspiration.
## Building Your Own Workflows
The beauty of workflows is they're completely customizable to your needs. You might create workflows for all kinds of repetitive tasks:
- For releases, you could have a workflow that grabs all merged PRs, builds a changelog, and handles version bumps.
- Setting up new projects is perfect for workflows. Just run one command to create your folder structure, install dependencies, and set up configs.
- Need to create a report? Create a workflow that grabs stats from different sources and formats them exactly how you like. You can even visualize them with a charting library and then make a presentation out of it with a library like [slidev](https://sli.dev/).
- You can even use workflows to draft messages to your team using an MCP server like Slack or Whatsapp after you submit a PR.
With Workflows, your imagination is the limit. The true potential comes from spotting those annoying repetitive tasks you do all the time.
If you can describe something as "first I do X, then Y, then Z" - that's a perfect workflow candidate.
Start with something small that bugs you, turn it into a workflow, and keep refining it. You'll be shocked how much of your day can be automated this way.
@@ -0,0 +1,135 @@
---
title: "Workflows Best Practices"
sidebarTitle: "Best Practices"
description: "Tips and strategies for creating effective and reliable Cline workflows."
---
Creating effective workflows requires a balance of clear instructions, modular design, and intelligent tool usage. Follow these best practices to get the most out of Cline's automation capabilities.
## Use Cline to Build Workflows
We highly recommend using Cline to help you build your workflows. Since Cline understands your project's context and structure, it can be an invaluable partner in designing automation that fits your specific needs.
### Building your own workflows
Creating a workflow is simpler than you might think. There's actually a workflow for building workflows!
First, **save the [create-new-workflow.md](https://github.com/cline/prompts/blob/main/workflows/create-new-workflow.md) file to your workspace** (e.g., in `.clinerules/workflows/`).
Then, type `/create-new-workflow.md` and Cline guides you through it:
1. It asks for the purpose and a concise name.
2. You describe the objective and expected outputs.
3. You list the major steps (Cline can help determine details).
4. It generates the properly structured workflow file.
<Tip>
**Automate Your History:** The best workflows come from tasks you've already done. After completing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." It analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
</Tip>
Workflows live in `.clinerules/workflows/` for project-specific ones or `~/Documents/Cline/Workflows/` for global ones you use across projects. Project workflows take precedence when names match.
## Workflow Design
<Tip>
**Start Simple:** Begin with small, single-task workflows. As you get comfortable, you can combine them or create more complex sequences.
</Tip>
### Be Modular
Instead of creating one massive workflow file, break complex tasks into smaller, reusable workflows. This makes them easier to maintain and debug.
### Use Clear Comments
Just like with code, commenting your workflow steps is crucial. Explain *why* a step is happening, not just *what* is happening. This helps both you (the future maintainer) and Cline understand the intent.
### Version Control
Treat your workflows as part of your codebase. Store them in your Git repository (in `.clinerules/workflows/`) so they are versioned, reviewed, and shared with your team.
## Prompt Engineering for Cline
### Be Specific with Tool Use
Don't just say "find the file." Be explicit about which tool Cline should use.
* **Bad:** "Find the user controller."
* **Good:** "Use `search_files` to look for `UserController` in the `src/controllers` directory."
## Advanced Techniques
### Available Tools
Cline has a powerful set of tools you can use within your workflows. Here are the most common ones:
#### execute_command
Executes a CLI command on your system. Use this for running tests, builds, git commands, or any other terminal operation.
```xml
<execute_command>
<command>npm run test</command>
<requires_approval>false</requires_approval>
</execute_command>
```
#### read_file
Reads the contents of a file. Essential for analyzing code or configuration.
```xml
<read_file>
<path>src/config.json</path>
</read_file>
```
#### write_to_file
Creates or overwrites a file. Use this to generate boilerplate, config files, or documentation.
```xml
<write_to_file>
<path>src/components/Button.tsx</path>
<content>
// File content goes here...
</content>
</write_to_file>
```
#### search_files
Searches for a regex pattern across files in a directory. Great for finding TODOs, usage examples, or specific code patterns.
```xml
<search_files>
<path>src</path>
<regex>TODO</regex>
<file_pattern>*.ts</file_pattern>
</search_files>
```
#### ask_followup_question
Asks the user for input or confirmation. This makes your workflow interactive and allows for human-in-the-loop decision making.
```xml
<ask_followup_question>
<question>Do you want to deploy to production?</question>
<options>["Yes", "No"]</options>
</ask_followup_question>
```
#### browser_action
Controls a built-in browser to interact with websites or local servers. Useful for testing web UIs or scraping data.
```xml
<browser_action>
<action>launch</action>
<url>http://localhost:3000</url>
</browser_action>
```
### Leverage MCP Tools
You can use Model Context Protocol (MCP) tools within your workflows to interact with external services like GitHub, Slack, or databases. This allows you to create powerful end-to-end automations.
### Manage Context Window
Be mindful of Cline's context window. If a workflow is too long or processes too much data, it might exceed the token limit.
* **Break it down:** Split long workflows into smaller parts.
* **Be concise:** Keep instructions clear and to the point.
## Learn More
<Card title="Cline Learn" icon="lightbulb" href="https://cline.bot/learn">
Dive deeper into general prompt engineering strategies to write even better instructions for Cline.
</Card>
@@ -0,0 +1,139 @@
---
title: "Workflows Overview"
sidebarTitle: "Overview"
description: "Learn what Cline workflows are, why they are useful, and how to structure them."
---
Workflows in Cline are Markdown files that define a series of steps to guide Cline through repetitive or complex tasks. They are a powerful way to automate your development processes directly within your editor.
To invoke a workflow, you simply type `/` followed by the workflow's filename in the chat (e.g., `/deploy.md`).
## Why Use Cline Workflows?
* **Automation:** Automate repetitive tasks like setting up a new project, deploying a service, or running a specific test suite.
* **Consistency:** Ensure that tasks are performed the same way every time, reducing errors.
* **Reduced Cognitive Load:** Don't waste mental energy remembering complex sequences of commands or steps.
* **Contextual:** Workflows run within your project's context, so Cline has access to your files and can use its tools to interact with them.
## How They Work
A workflow file is a standard Markdown file with a `.md` extension. Cline reads this file and interprets the instructions step-by-step. The real power comes from Cline's ability to use its built-in tools and other capabilities within these instructions:
* **Cline Tools:** Use tools like `read_file`, `write_to_file`, `execute_command`, and `ask_followup_question`.
* **Command-Line Tools:** Instruct Cline to use any CLI tool installed on your machine (e.g., `git`, `gh`, `npm`, `docker`).
* **MCP Tools:** Reference tools from connected Model Context Protocol (MCP) servers.
## Workflows vs. Rules
It's important to understand the difference between Cline Workflows and Cline Rules, as they serve different purposes:
| Feature | Purpose | When to Use |
| :--- | :--- | :--- |
| **Cline Rules** | Define *how* Cline should behave generally. They are always active (or contextually triggered) and set the "ground rules" for your project. | Enforcing coding standards, tech stack preferences, or project-specific constraints (e.g., "Always use TypeScript", "Never edit the `db` folder"). |
| **Cline Workflows** | Define *what* specific task Cline should perform. They are sequences of steps invoked on-demand to automate a process. | Automating repetitive tasks like creating a component, running a release process, or generating a daily report. |
Think of **Rules** as the *environment* Cline works in, and **Workflows** as the *scripts* you give Cline to execute.
### Example: Automating a Release
Imagine you need to prepare a new release for your library.
**Without a workflow**, you might have to manually:
1. Open `package.json` and bump the version number.
2. Run your test suite to make sure everything is green.
3. Update `CHANGELOG.md` with the latest commits.
4. Run `git commit -am "v1.0.1"`.
5. Run `git tag v1.0.1`.
6. Run `git push origin main --tags`.
This is tedious and easy to mess up. You might forget to run the tests or format the changelog correctly.
**With a Cline workflow**, you define these steps once in a `release.md` file. Then, you just type:
```bash
/release.md
```
Cline will then meticulously follow your instructions: updating files, running tests, and executing git commands—pausing only if it encounters an error or needs your input.
## Where are Workflows Stored?
You can store workflows in two locations, depending on whether they are specific to a project or meant to be global.
<Tabs>
<Tab title="Project-Specific Workflows">
Store workflows that are specific to a single project in a `.clinerules/workflows/` directory in your project's root.
1. Create a `.clinerules` folder in your project's root directory (if it doesn't already exist).
<Note>
The `.clinerules` directory may be hidden by default on some systems. You might need to enable **Show Hidden Files** to see it.
</Note>
2. Inside `.clinerules`, create a `workflows` folder.
3. Create your Markdown workflow files (e.g., `deploy.md`) in this folder.
These workflows will only be available when you have this specific project open.
</Tab>
<Tab title="Global Workflows">
Store workflows that you want to use across all your projects in a global directory.
* **macOS/Linux:** `~/Documents/Cline/Workflows/`
* **Windows:** `C:\Users\USERNAME\Documents\Cline\Workflows\`
Create your Markdown workflow files directly in this directory. They will be available in any project you open with Cline.
</Tab>
</Tabs>
## Manage Workflows
You can easily manage your workflows directly within the extension. This feature provides a unified interface to handle all your automation needs without leaving your editor or hunting through file directories. It consolidates both project-specific rules and global workflows into one view, giving you full control over your automation environment.
1. Click the **Manage Cline Rules and Workflows** button (<Icon icon="scale-balanced" />) at the bottom of the extension.
2. This opens an interface where you can:
* **View all available workflows:** See a comprehensive list of both project-specific and global workflows.
* **Control automation:** Toggle individual workflows on and off as needed for your current task.
* **Create and Edit:** Add new workflows or modify existing ones directly within the interface.
* **Clean up:** Delete workflows you no longer need.
<Frame caption="Manage Workflows">
<img src="https://storage.googleapis.com/cline_public_images/workflow-menu.gif" alt="Manage Cline Rules and Workflows Interface" />
</Frame>
## Workflow Structure Example
Here is a simple example of a workflow file (`daily-changelog.md`) that helps you create a daily changelog.
````markdown daily-changelog.md
# Daily Changelog Generator
This workflow helps you create a changelog for your daily work.
1. **Check your recent git commits:**
I will run the following command to see your commits from today.
```bash
git log --author="$(git config user.name)" --since="yesterday" --oneline
```
2. **Summarize your work:**
I will present the commits to you and ask for a summary of your changes to be added to the `changelog.md` file.
3. **Create/Append to daily changelog:**
I will append to the `changelog.md` file. The content will include a header with the current date, the list of commits, and your summary.
````
### Breakdown of the Workflow
This workflow demonstrates that you don't always need to provide specific tool calls (like XML blocks). Cline is smart enough to interpret your high-level instructions.
1. **Step 1: Check recent git commits**
* We give Cline a specific command to run. This ensures it gets exactly the data we want (today's commits).
<Tip>
After Cline shows the git commit history, you may need to click the **Proceed While Running** button to allow the workflow to continue.
</Tip>
2. **Step 2: Summarize your work**
* Instead of forcing a specific tool, we simply tell Cline what to do: "ask for a summary".
* Cline knows it needs to use its capabilities to ask you a question.
3. **Step 3: Create/Append to daily changelog**
* We describe the desired outcome: "append to the `changelog.md` file" with specific content.
* Cline figures out how to format the file and use its file-writing tools to accomplish the task.
@@ -0,0 +1,112 @@
---
title: "Workflows Quick Start"
sidebarTitle: "Quick Start"
description: "A step-by-step guide to creating your first Cline workflow."
---
In this tutorial, you will create a powerful workflow that automates the process of reviewing a GitHub Pull Request. This example demonstrates how to combine CLI tools, file analysis, and user interaction into a seamless process.
### Prerequisites
* You have Cline installed.
* You have the [GitHub CLI (`gh`)](https://cli.github.com/) installed and authenticated.
* You have a Git repository open with a Pull Request you want to test this on.
## Creating a Pull Request Review Workflow
This workflow will automate the process of fetching PR details, analyzing the code changes for issues, and drafting a review comment.
<Steps>
<Step title="Create the Workflow File">
First, create the directory structure for your project-specific workflows.
1. In the root of your project, create a new folder named `.clinerules`.
2. Inside `.clinerules`, create another folder named `workflows`.
3. Finally, create a new file named `pr-review.md` inside the `workflows` folder.
</Step>
<Step title="Write the Workflow Content">
Open the `pr-review.md` file and add the following content. This workflow will gather PR details, analyze the changes, and help you submit a review.
````markdown pr-review.md
# Pull Request Reviewer
This workflow helps me review a pull request by analyzing the changes and drafting a review.
## 1. Gather PR Information
First, I need to understand what this PR is about. I'll fetch the title, description, and list of changed files.
```bash
gh pr view PR_NUMBER --json title,body,files
```
## 2. Examine Modified Files
Now I will examine the diff to understand the specific code changes.
```bash
gh pr diff PR_NUMBER
```
## 3. Analyze Changes
I will analyze the code changes for:
* **Bugs:** Logic errors or edge cases.
* **Performance:** Inefficient loops or operations.
* **Security:** Vulnerabilities or unsafe practices.
## 4. Confirm Assessment
Based on my analysis, I will present my findings and ask how you want to proceed.
```xml
<ask_followup_question>
<question>I've reviewed PR #PR_NUMBER. Here is my assessment:
[Insert Analysis Here]
Do you want me to approve this PR, request changes, or just leave a comment?</question>
<options>["Approve", "Request Changes", "Comment", "Do nothing"]</options>
</ask_followup_question>
```
## 5. Execute Review
Finally, I will execute the review command based on your decision.
```bash
# If approving:
gh pr review PR_NUMBER --approve --body "Looks good to me! [Summary of analysis]"
# If requesting changes:
gh pr review PR_NUMBER --request-changes --body "Please address the following: [Issues list]"
# If commenting:
gh pr review PR_NUMBER --comment --body "[Comments]"
```
````
<Note>
When you run this workflow, you will replace `PR_NUMBER` with the actual number of the pull request you want to review (e.g., `/pr-review.md 123`).
</Note>
</Step>
<Step title="Run the Workflow">
Now you're ready to run your new workflow.
1. Open the Cline chat panel.
2. Type `/pr-review.md` followed by the PR number (e.g., `/pr-review.md 42`) and press Enter.
3. Cline will fetch the PR details, analyze the code, and present you with its findings before submitting the review.
<Tip>
As Cline executes commands (like `gh pr view`), it may show you the output and pause. You will need to click the **Proceed While Running** button to allow Cline to analyze the content and continue with the workflow.
</Tip>
</Step>
</Steps>
### Other Common Use Cases
This is just one example. You can create workflows for a wide variety of tasks, such as:
* **Creating Components:** Automate the boilerplate for new files (like React components or API endpoints).
* **Running Tests:** Create a workflow that runs your test suite and summarizes the results.
* **Deploying Your Application:** Automate your deployment pipeline using tools like `docker` and `kubectl`.
* **Refactoring Code:** Guide Cline through a complex refactoring process step-by-step.
Explore Cline's capabilities and your own development processes to find repetitive tasks that can be turned into efficient workflows.
+6 -7
View File
@@ -10,7 +10,7 @@ description: "Get Cline up and running in your favorite IDE with these simple in
## Before You Begin
<CardGroup cols={1}>
<Card title="Create Your Account" icon="user-plus" href="https://app.cline.bot/signup">
<Card title="Create Your Account" icon="user-plus" href="https://app.cline.bot/login">
Sign up for a **free Cline account** to get:
- Access to multiple AI models including stealth models
- Seamless setup without managing API keys
@@ -361,10 +361,9 @@ description: "Get Cline up and running in your favorite IDE with these simple in
<Info>
You'll be redirected to [app.cline.bot](https://app.cline.bot) to authenticate. After signing in, you'll automatically return to your editor.
</Info>
<Frame>
<img src="/assets/installation/login.png" alt="Cline sign up screen"
/>
</Frame>
<Info>
You'll be redirected to the Cline authentication page to sign in with your account.
</Info>
</Step>
<Step title="You're All Set!">
@@ -403,7 +402,7 @@ description: "Get Cline up and running in your favorite IDE with these simple in
Connect with our team and community for support, tips, and discussions.
</Card>
<Card title="Read the Docs" icon="book-open" href="/getting-started/for-new-coders">
Explore guides for new coders, model selection, and advanced features.
<Card title="Read the Docs" icon="book-open" href="/getting-started/selecting-your-model">
Explore model selection guides and advanced features to get the most out of Cline.
</Card>
</CardGroup>

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