* Use the host bridge in utils/path.ts
Update utils/path.ts to use the host bridge to get the workspace folders, instead of the vscode SDK.
Update callers to use await as the functions are now async.
* Replace vscode workspaceFolders in WorkspaceTracker
Make the cwd an instance property because await cannot be used at the top level.
* Use the host bridge getWorkspacePaths in FileContextTracker
Replace the vscode SDK getWorkspaceFolders with the util function getCwd (this is already switched to the host bridge).
* Fix test failure
Update the rootDir for the tests to be "." instead of "src". The changes to path.ts pull in new dependencies from the extension, which indirectly include files from the webview-ui.
```
Run npm run pretest
> claude-dev@3.18.0 pretest
> npm run compile-tests && npm run compile && npm run compile-standalone && npm run lint
> claude-dev@3.18.0 compile-tests
> node ./scripts/build-tests.js
node:child_process:957
throw err;
^
Error: Command failed: tsc -p ./tsconfig.test.json --outDir out
at genericNodeError (node:internal/errors:983:15)
at wrappedFn (node:internal/errors:537:14)
at checkExecSyncError (node:child_process:882:11)
at execSync (node:child_process:954:15)
at Object.<anonymous> (/home/runner/work/cline/cline/scripts/build-tests.js:55:1)
at Module._compile (node:internal/modules/cjs/loader:1730:14)
at Object..js (node:internal/modules/cjs/loader:1895:10)
at Module.load (node:internal/modules/cjs/loader:1465:32)
at Function._load (node:internal/modules/cjs/loader:1282:12)
at TracingChannel.traceSync (node:diagnostics_channel:322:14) {
status: 2,
signal: null,
output: [
null,
"src/services/test/TestServer.ts(8,35): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/services/grpc-client.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n" +
"webview-ui/src/services/grpc-client-base.ts(1,24): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/utils/vscode.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n" +
"webview-ui/src/services/grpc-client.ts(4,34): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/services/grpc-client-base.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n",
''
],
pid: 2496,
stdout: "src/services/test/TestServer.ts(8,35): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/services/grpc-client.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n" +
"webview-ui/src/services/grpc-client-base.ts(1,24): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/utils/vscode.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n" +
"webview-ui/src/services/grpc-client.ts(4,34): error TS6059: File '/home/runner/work/cline/cline/webview-ui/src/services/grpc-client-base.ts' is not under 'rootDir' '/home/runner/work/cline/cline/src'. 'rootDir' is expected to contain all source files.\n",
stderr: ''
}
```
* Build the protos before compiling the tests.
The tests depend on generated files now, so compile the extension before the tests so that the protos are built.
* Set up the host providers in the integration test FileContextTracker.test.ts
* Reduce the amount of logging in grpc-service.ts
Just log the service registration, instead of every rpc.
* In the `clean` build target, also remove the compiled test code.
* Correct the alias mapping for the compiled test files.
* host bridge migration - clipboard
* changeset
* removed dev logging
* switched to empty return on clipboard write
* Moved new hostServiceNameMap entry to new proto configs
- Optimized Cline to work with the Claude 4 family of models, resulting in improved performance, reliability, and new capabilities
- Added a new Gemini CLI provider that allows you to use your local Gemini CLI authentication to access Gemini models for free (Thanks @google-gemini!)
- Optimized Cline to work with the Gemini 2.5 family of models
- Updated the default and recommended model to Claude 4 Sonnet for the best performance
- Fix race condition in Plan/Act mode switching
- Improve robustness of search and replace parsing
* Modified regex to account for trailing > characters in search and replace blocks
* added check back to other regex's
* Re-ordered regex consts for readability
* Add workspace service to the host bridge.
Add a service for workspaces to the host bridge.
The service has one rpc getWorkspacePaths that will replace vscode.workspace.workspaceFolders
* Add the vscode host implementation of getWorkspaceFolders
* Update src/hosts/vscode/workspace/getWorkspacePaths.ts
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>
* clearAllTaskHistory protobus migration
* changset
* Fixed protobuf object literal usage
* cleanup
* remove old methods + return zero when user tries to delete favorites but none exist
* Removed deleteTaskWithId from controller and removed legacy claude_messages.json code
* Handle partial messages
* Parse chunks separately
* Add changeset
* refactor
* disallow tools
* Handle incomplete chunks
* Do not log costs when using a subscription, improve error handling and refactor rl usage
* Improve output handling. Prefer returning partial data to nothing.
* Set the total cost to 0 instead of leaving it undefined
* Fix the model infos and stop supporting images
* Reduce timeout to 10 minutes
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* The standalone service should only show the Protobus services in the reflection output.
The proto descriptor set is including all the proto services, allowlist the services in the cline and health packages.
* Remove debug code
* Fix variable name
* Fixing the contributor flow for Cline to force users to make issues first
* Fixing the contributor flow for Cline to force users to make issues first
* Fixing the contributor flow for Cline to force users to make issues first
* Fixing the contributor flow for Cline to force users to make issues first
* Update feature_contribution.yml
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
---------
Co-authored-by: Cline Evaluation <cline@example.com>
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
* feat: add cline_task_id metatada to use in LiteLLM
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
* refactor: remove comment
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
* docs: add changeset
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
* refactor: apply suggestions type
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
* fix: format
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
---------
Signed-off-by: Jorge García Rey <jorgegar@inditex.com>
* Update ApiOptions.tsx
Added eu-south-1 (Milan) and eu-south-2 (Spain) to selection menu
* Update ApiOptions.tsx
Fixed names of eu-south-1 and eu-south-2 in settings menu
* move apiConversationHistory to MessageStateHandler
* move clineMessages state to MessageStateManager class
* remove unused imports
* reorganize task class state variables and refactor out utility functions in recursivelyMakeClineRequests
* move task ephemeral state to state class
* extract tool logic into tool executor class
* integrate ToolExecutor into task class
* Add ui.getWebviewHtml to the protobus
This will return the HTML content for external clients.
* Add getUri to ExternalWebviewProvider
Change getUri to return URIs for files in an appropriate format for the external web view.
Use URI from npm module in ExternalWebviewProvider.
Use a default value for the cline dir, ~/.cline
Turn off gRPC debugging
* Include node modules used as assets in the standalone package.
* Throw an error if trying to recreate webview panel in standalone app.
* cleaning up a bit
* cleaning up some more
* readme
* added max limit
* making it portable
* ignore
* committing plans for now
* strealit hooked up, multi model runs, better db torage
* docs
* VALID attempts
* logging
* more stability
* strategy
* cleaning deps
* docs
* streamlit dashboard work
* dashboard showing bad cases
* better parallelization pt1
* global worker pool for even better more robust parallelization
* bumping up default max parallel requests from 20 -> 80
* better devx
* better docs
* docs
* better devx
* better docs
* better presentation
* dark mode
* removed unused import
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Create a vscode specific webview provider, and an a generic webview provider class.
Move all the vscode specific parts in the VscodeWebviewProvider.
Create a ExternalWeviewProvider for the standalone service.
Update extension.ts to use the generic webview provider class.
* Add doc comments
* Add .create() to VscodeWebviewProvider
* Return if the message was sent when toggling plan act mode to properly clear the input
* Add changeset
* Use a common value instead of a unique response
* Add a host-provider that will provide access to all host specific things.
Right now it only has the host bridge clients, I will add a host specific web view provider in a second PR.
Check if the host provider has been set up properly when accessing the host bridge clients.
* Fix imports.
Don't generate hosts/vscode/client/host-grpc-client.ts, the code to generate this file is larger than the file; there will never be a large number of services in the host bridge.
* Fix imports
* move apiConversationHistory to MessageStateHandler
* move clineMessages state to MessageStateManager class
* remove unused imports
* reorganize task class state variables and refactor out utility functions in recursivelyMakeClineRequests
* move task ephemeral state to state class (#4273)
* Fix the error when submitting remote service form
Fix the exception caused by data structure errors when submitting remote service forms.
* fix for Prettier
* typing
---------
Co-authored-by: wangyj20 <wangyj20@asiainfo.com>
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
* move apiConversationHistory to MessageStateHandler
* move clineMessages state to MessageStateManager class
* remove unused imports
* remove redundant line
* Fix: The button which closes the currently displayed task is is now accessible with screen readers
* Fix: The button which deletes the currently displayed task is now accessible with screen readers
* Create changeset
* fix(bedrock): without any encoding
* fallback for custom model
* changeset
* Update src/api/providers/bedrock.ts
---------
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
* Do not destructure env variables
* Add changeset
* Do not set IS_DEV to true in tests
* Do not define values if it is not a production build
* Add eslint rule to prevent destructuring process.env
* Integrate Claude Code
* Add changeset
* handle exits gracefully, select models and update the path
* limit the claude-code models and update message
* expose the claudeCodePath in the apiConfiguration and proto
* remove log
* Update proto settings and properly map the provider
* Fixed issue where checkpoint commitHash was not being saved to every clineMessage in state, added handling in case checkpointTracker was not initialized (resumed tasks)
* changeset
* prettier
Add a manager class to hold all the instances of the clients. They need to be reused, unlike the vscode clients which are just static method calls.
Move the generated file src/standalone/server-setup.ts into src/generated/ directory.
Add the host bridge address env var to the vscode launch.json
In build-proto.js: path.join will normalize slashes in file paths, so use path.join(x, "a/b/c") instead of path.join(x, "a", "b", "c").
* Fix error handling for unary handler in the host bridge grpc handler for vscode.
The unary request handler was return a struct like {message: ..., error: ..., requestId: ...}
But the caller was only looking at the message field, not the error.
Simplify the unary handler and just return the response message or throw if there was an error. The caller already has the request id, it doesn't need it to be returned from handler.
* Update comments
* Return early from cancelRequest if request wasn't cancelled to reduce indent level/complexity.
* Fix bug in cancelRequest in the host bridge grpc handler where cancel message is never sent to the client.
When a request is cancelled it is removed from the registery. The cancel handler was cancelling the request, and then trying to retrieve it again to get the stream handler, but it was already removed from the active request, so the cancel message was never sent to the client.
Fix this by retrieving the stream handler first, and then cancelling the request.
* added changes over a the latest from upstream
* cleanup some comments
* fixed message mispelling and variable naming convention
* added changeset for addition of SAP AI Core provider
* fixed mispelled expires_at
* added sapAiCoreClientId to hasKey
* retrigger tests
* removed bedrock-format.ts, added smal function for message formatting in sapaicore, removed models lazy loading, simplifying the code
* reverted src/core/webview/index.ts to upstream version, once all the tailored implementation for sapaicore were removed
* removed duplicated and not used interfaces
* removed the deployments logic from ApiOptions.tsx, now it loads the list of models available only
* removed references for deployments once it is not in use anymore
* removed unused sapConfig from WebviewMessage and ExtensionMessage
* moved previous state variable according to the request'
* removed supportsComputerUse from sapaicore sonnet
* added grpc fields and updated conversion methods for sap ai core
* + Adding a global setting for mcp rich display in features settings, storing it in global storage, and using it as the starting value for each new session to still allow local toggle of mcp rich display on the tab, but let users keep the base stored default
* + adding changest
* + fxing linting post conflict merge
* fix
---------
Co-authored-by: 0xtoshii <94262432+0xToshii@users.noreply.github.com>
* Add a protobuf linter
Enforce the standard lint rules: snake case field names, snake case file names, pascal case service names etc.
Add exceptions for the lint rules we are already not following.
Fix linter failures, this only changes the proto file The generated TS types are the same, so the ts files don't need to be updated.
* Formatting
* feat: Added a configurable default terminal profile setting
* chore: format
* refactor: migrate terminal profiles to gRPC and remove legacy message handling
- rename AvailableTerminalProfilesResponse to TerminalProfiles in proto
- remove duplicate TerminalProfile type from terminal_types.ts
- update all imports to use TerminalProfile from proto/state
- remove legacy availableTerminalProfiles message handling from ExtensionStateContext
- clean up ExtensionMessage type by removing unused availableTerminalProfiles
- translate Spanish comment to English in TerminalSettingsSection
- update server-side getAvailableTerminalProfiles to use new proto type
* chore: lint
* fix: merge main
* fix: resolve errors
* chore: notify terminal profile settings
* chore: merge main
* feat: improve default terminal profile changes
* fix: update changes on save
Instead of doing a prettier check in the pre-commit, just format the staged changes.
Use the package lint-stage to handle only formatting staged changes.
* Generate clientImpls and services for grpc-js.
Generate grpc-js services and clients (as opposed to the generic service definition)
The grpc-js clients are needed to connet to external gRPC services, ie the host bridge.
Switch the standalone gRPC service to use the grpc-js service defintions, these have the correct serialize/deserialize methods and fix the camel/snake case issue.
* Formatting
* Adding real time client
* Adding real time client
* Adding real time client
* first commit
* Adding thinking Slider for Gemini models
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* migrate focusChatInput
* move subscription in with the others
* changed grpc method; fixed a bug where keybinding doesn't show chatview if in another tab
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
* Add a host bridge client that uses the appropriate underlying client (vscode or external grpc service)
Add placeholders for the external clients.
Move the hosts directory under src, add an alias in tsconfig.json for @hosts
* Update package.json
* Refactor constructNewFileContent and add tests for out-of-order replacements
- Renamed function `constructNewFileContent` to `cnfc` for clarity.
- Updated the versioning logic to default to "v1" in `constructNewFileContent`.
- Enhanced the implementation to handle out-of-order search/replace blocks.
- Added comprehensive test cases to validate the new functionality, including scenarios with overlapping content and deletions.
* Create quick-rocks-guess.md
* Add flexibility for search/replace markers matching
* Refactor tests for edge cases in diff handling
* Handle case where model doesnt include ending replace marker
* Fix search/replace counter
* Get root of the cline storage directory from an env var.
Set the cline directory env var when running the standalone app from the vscode launcher.
Add missing vscode SDK stub.
* Stop spamming the logs.
* Fix hardcoded context menu index for File option selection
The ChatTextArea component was using a hardcoded index 3 to select the "File" option by default in the context menu, but this was incorrect - the File option is actually at index 5 in the menu options array. This caused the wrong option (Git) to be selected by default when pressing Escape or when no query is provided.
Additionally, the hardcoded approach was fragile and would break if the context menu order changed in the future.
Key changes:
- Added `DEFAULT_CONTEXT_MENU_OPTIONS` array in context-mentions.ts to define the canonical menu order
- Added helper function `getDefaultContextMenuOptionIndex()` dynamically finds the correct index for any option type
- Updated ChatTextArea to use `DEFAULT_CONTEXT_MENU_OPTION` constant instead of hardcoded 3
- Updated `getContextMenuOptions()` to use the new centralized array
* changeset
* feat: the response of the mcps is represented by a collapsible
* feat: the response of the mcps is represented by a collapsible
* fix: message for error parsing response
* fix: format
* feat: added cline.mcp.defaultPanelState settings
* chore: merge
* feat: improve global state
* chore: re-trigger workflow
* chore: lint fix
* revert: unnecessary changes
* Update webview-ui/src/components/mcp/chat-display/McpResponseDisplay.tsx
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
* chore: change MCP Response Display Mode to a button
* fix: improve ui mcp response panel
* refactor: change name and type for property mcpDefaultPanelState to mcpResponsesCollapsed
* chore: rename props
---------
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
The extension doesn't like it when the workspace/workspace config is undefined.
Fix the warning about the name in package.json.
Change some logging in the gRPC server.
* Add active files to file context menu
Add support to include active files (open tabs) within the WorkspaceTracker. This enables the tracker to send the webview with a file list that has active files listed at the top.
The changes include:
- Listening for tab group changes using `vscode.window.tabGroups.onDidChangeTabs` to trigger workspace updates.
- Introducing an `activeFiles` getter that retrieves the file paths of all currently open text editor tabs.
- Modifying the `workspaceDidUpdate` function to include both `activeFiles` and `filePaths` when posting the `workspaceUpdated` message to the webview.
* use set
* add changeset
* Add a postMessage handler for standalone cline app.
If there is no vscode api defined, try to use the standalone post
Message handler.
* Imports
* Update logs
* Add type checking for protobus RPC handlers.
Add type parameters to the wrapper function when generating the server-setup file.
So that the parameters of the RPC handler will be type checked against types defined in the service.
The generated code looks like this:
```
server.addService(proto.cline.CheckpointsService.service, {
checkpointDiff: wrapper<cline.Int64Request,cline.Empty>(checkpointDiff, controller),
checkpointRestore: wrapper<cline.CheckpointRestoreRequest,cline.Empty>(checkpointRestore, controller),
});
```
Add an index.ts file to the proto directory so all the proto types can be imported without having to know which proto message is defined in which file (the proto descriptor set doesn't have this information).
* Generate index.ts with protoc instead of doing it ourselves.
Turn on the option 'dontExportCommonSymbols' in protoc, so that each generated proto file is not trying to export the same utility functions.
Generate all the protos with the same protoc command.
* cleanup
* WIP host bridge
* Run formatter
* remove tmp impl & rename host grpc client
* gitignore more files
* better layout
* host handler to make other hosts easier to add
* remove adapter pattern
* get host responses correctly
* fix streaming mode for host bridge
* first wip subscription host bridge demo for watching mcp server config
* format, comment
* add cancellation for host grpc stream
* remove unneeded functions from host-grpc-handler
* add a method for canceling request rather than using the registry
* another todo
* use StringRequest for uri.proto
* debounce new file watcher
* remove test setup
* remove some todos and logs
* remove registry use todo
* Revert "remove registry use todo"
This reverts commit 84078d3469.
* fix capitalization of uri.proto
* a better pattern for a callback based bridge without using the requestRegistry directly
---------
Co-authored-by: Andrei Edell <andrei@nugbase.com>
Co-authored-by: Sarah Fortune <sarah.fortune@gmail.com>
Co-authored-by: Andrei Eternal <eternal@cline.bot>
* feat: add all qwen3 models support and add thinking mode options
* fix: qwen model reasoning logic configuration, set the qwen model maxBudget value
* fix: correct the maxTokens in qwen3 model
* vertex model
---------
Co-authored-by: xuanqi <xuanqi.cc@alibaba-inc.com>
Co-authored-by: 0xtoshii <94262432+0xToshii@users.noreply.github.com>
* migrate chatButtonClicked
* changeset
* send targeted event to the controller
* prettier
* add test mock
* continue to fix tests
* fix test mocks once and for all
* fix test mocks once and for all
* try again please lord
* try again
* temporarily disable tests
* revert other test 'fixes'
* one more
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
* feat(lint): Add custom ESLint rules for protobuf type checking
Add two custom ESLint rules to enforce proper usage patterns when creating protobuf objects.
Using .create() to build protobufs ensures that the protobuf is type checked when it is created. Protobufs created using
object literals are not type checked, which can lead to subtle bugs and type mismatches. The linter rules detect when protobufs are created without using .create() or .fromPartial().
- no-protobuf-object-literals: Enforces the use of `.create()` or `.fromPartial()` methods instead of object literals when creating protobuf types.
```
/Users/sjf/cline/src/shared/proto-conversions/state/chat-settings-conversion.ts
9:9 warning Use ChatSettings.create() or ChatSettings.fromPartial() instead of object literal for protobuf type
Found: return {
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
}
Suggestion: ChatSettings.create({
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
})
```
- no-grpc-client-object-literals: Enforces proper protobuf creation for gRPC service client parameters. This needs a separate rule
because the type signatures of the ServiceClients methods are too generic to be detected by the previous rule.
```
/Users/sjf/cline/webview-ui/src/components/mcp/configuration/tabs/add-server/AddRemoteServerForm.tsx
41:62 warning Use the appropriate protobuf .create() or .fromPartial() method instead of object literal for gRPC client parameters.
Found: McpServiceClient.addRemoteMcpServer({
serverName: serverName.trim(),
serverUrl: serverUrl.trim(),
})
```
These rules help maintain code quality by enforcing consistent patterns for working with protocol buffers throughout the codebase, reducing potential runtime errors from improper message construction.
* Update test
* Add custom eslint rules to new webview-ui config
* formatting
* stuff
* undo protobuf fixes
* update rule
* update rule
* protobuf fixes
* rename unused params
* formatting
* use dropdown for Ollama model list when possible
Code changes by Qwen3 30B A3B, based on OpenRouterModelPicker
* Document libasound2 and libnss3 test dependencies, sort list
* add test for OllamaModelPicker
Code by Claude Sonnet 3.7
* Add changeset
* Add globalState to the standalone vscode extension context replacement.
Add a generic key-value store that can be used by different storages, and move this into vscode-context-utils file.
Move the stubs/mocks into a separate stubs file, (they have type checking turned off).
Keep the implementations in vscode-context and turn on typechecking for this file.
* Add type parameter for the values in the JsonKeyValueStore
* Optimize imports
* Add implementations for the vscode ExtensionContext in the standalone app (#4000)
* Formatting
* add package-lock.json
* docs: add xAI Grok and Mistral AI provider configs
* docs: add Anthropic Claude model configuration guide
- Add comprehensive documentation for configuring Anthropic Claude models with Cline
- Include API key setup, supported models list, and configuration steps
- Cover advanced features like prompt caching and rate limits
- Update navigation to include new Anthropic page in custom model configs section
* docs: add DeepSeek, Ollama, OpenAI, OpenAI Compatible pages and update Plan & Act
* docs: add Extended Thinking section to Anthropic configuration guide
* docs: update vscode language model api page
* docs: update vscode language model api docs
* Add model documentation pages and update navigation structure
- Add new documentation pages for model overviews (Claude, Gemini, OpenAI, XAI)
- Add general models overview page
- Update docs.json to include new model documentation in navigation
- Update OpenAI-compatible model documentation
* Remove Notes column from model documentation tables for consistency
* Fix table formatting in Gemini models documentation
* added 5 new model configurations and updated existing ones
* Update AWS Bedrock documentation with minimal IAM permissions
* modified: docs/get-to-know-the-models/claude-models.mdx
* Renamed 'custom model configuration' to 'provider configuation' to avoid providers being confused with models
* Fix dollar sign rendering in model documentation
- Escape dollar signs in pricing tables to prevent MDX parsing issues
- Fixes disappearing dollar signs in gemini-models.mdx and other model docs
- Dollar signs now display correctly as literal currency symbols
* Add feature descriptions to OpenAI and XAI model docs
- Added 'Diverse Performance for Different Tasks Across Model Tiers' section to OpenAI models
- Added 'Real-time Information Access' section to XAI models
- Maintains consistency with existing Claude and Gemini documentation format
- Highlights valuable features for agentic AI coding workflows
* removing these files due to name change in header. they're in the new docs/provider configs folder
* added 2 new issues per model page + formatting
* Update model documentation files
* Fix: Correct paths in docs.json for provider configs
* docs: update docs.json and apply formatting
* docs: fix broken links, add OpenRouter & Requesty pages
* docs: remove 'get to know the models' section and files
* Update docs/provider-config/openai-compatible.mdx
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
---------
Co-authored-by: kevinneung <94151024+kevinneung@users.noreply.github.com>
Co-authored-by: Dennise Bartlett <bartlett.dc.1@gmail.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* changeset version bump
* Updating CHANGELOG.md format
* Update CHANGELOG.md and version for patch release 3.17.9
- Change version from 3.18.0 to 3.17.9 (patch release)
- Update CHANGELOG.md with user-friendly descriptions
- Add proper attribution for external contributors
- Focus on user-facing changes and bug fixes
- Remove internal/dev-only changes from changelog
* added claude 4 stuff
---------
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: pashpashpash <nik@nugbase.com>
* adding modularized flag for new claude4 experimental tools, default OFF
* diff.ts
* responses.ts
* system.ts
* tests and prompt
* forgot some chars
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* add open disk conversation history button
* changeset
* change icon due to lack of artistic freedom
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
* fix:The POST requests of MCP's SSE server support setting headers.(#2652)
* fix:The POST requests of MCP's SSE server support setting headers.(#2652)
---------
Co-authored-by: Toshii <94262432+0xToshii@users.noreply.github.com>
* add ls file tool description, parsing, and return formatting
* add json tool definition and remove extra '.'
* changeset
* use separate function for new format
* using json
* add grep tool new format
* add editTool definition
* Map MultiEdit tool to StreamingJsonReplacer with logs
* Adding support for non streamed json
* Adding logging
* moving multiedit tool into tool defs
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
Co-authored-by: Cline Evaluation <cline@example.com>
Co-authored-by: pashpashpash <nik@nugbase.com>
* Fix undefined type when parsing response chunk in stream
* Fix undefined type when parsing response chunk in stream
* remove Cline.ts changes
---------
Co-authored-by: 0xtoshii <94262432+0xToshii@users.noreply.github.com>
* Fix linter warnings in the webview (part 2)
Replace protobus calls using object literals to use Message.create({...})
Fix incorrect property name detected after this change in webview-ui/src/components/settings/SettingsView.tsx
Optimised imports in vscode.
* formatting
* feat(lint): Add custom ESLint rules for protobuf type checking
Add two custom ESLint rules to enforce proper usage patterns when creating protobuf objects.
Using .create() to build protobufs ensures that the protobuf is type checked when it is created. Protobufs created using
object literals are not type checked, which can lead to subtle bugs and type mismatches. The linter rules detect when protobufs are created without using .create() or .fromPartial().
- no-protobuf-object-literals: Enforces the use of `.create()` or `.fromPartial()` methods instead of object literals when creating protobuf types.
```
/Users/sjf/cline/src/shared/proto-conversions/state/chat-settings-conversion.ts
9:9 warning Use ChatSettings.create() or ChatSettings.fromPartial() instead of object literal for protobuf type
Found: return {
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
}
Suggestion: ChatSettings.create({
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
})
```
- no-grpc-client-object-literals: Enforces proper protobuf creation for gRPC service client parameters. This needs a separate rule
because the type signatures of the ServiceClients methods are too generic to be detected by the previous rule.
```
/Users/sjf/cline/webview-ui/src/components/mcp/configuration/tabs/add-server/AddRemoteServerForm.tsx
41:62 warning Use the appropriate protobuf .create() or .fromPartial() method instead of object literal for gRPC client parameters.
Found: McpServiceClient.addRemoteMcpServer({
serverName: serverName.trim(),
serverUrl: serverUrl.trim(),
})
```
These rules help maintain code quality by enforcing consistent patterns for working with protocol buffers throughout the codebase, reducing potential runtime errors from improper message construction.
* Update test
* Add custom eslint rules to new webview-ui config
* Only include webview grpc ServiceClient check
* Fix lint errors
* formatting
* Update package.json
* Make the no-grpc-client-object-literals linter rule an error for the webview-ui
Fix the last occurrence of this issue.
* formatting
* Fix linter warnings in the webview (part 2)
Replace protobus calls using object literals to use Message.create({...})
Fix incorrect property name detected after this change in webview-ui/src/components/settings/SettingsView.tsx
Optimised imports in vscode.
* formatting
* feat(lint): Add custom ESLint rules for protobuf type checking
Add two custom ESLint rules to enforce proper usage patterns when creating protobuf objects.
Using .create() to build protobufs ensures that the protobuf is type checked when it is created. Protobufs created using
object literals are not type checked, which can lead to subtle bugs and type mismatches. The linter rules detect when protobufs are created without using .create() or .fromPartial().
- no-protobuf-object-literals: Enforces the use of `.create()` or `.fromPartial()` methods instead of object literals when creating protobuf types.
```
/Users/sjf/cline/src/shared/proto-conversions/state/chat-settings-conversion.ts
9:9 warning Use ChatSettings.create() or ChatSettings.fromPartial() instead of object literal for protobuf type
Found: return {
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
}
Suggestion: ChatSettings.create({
mode: chatSettings.mode === "plan" ? PlanActMode.PLAN : PlanActMode.ACT,
preferredLanguage: chatSettings.preferredLanguage,
openAiReasoningEffort: chatSettings.openAIReasoningEffort,
})
```
- no-grpc-client-object-literals: Enforces proper protobuf creation for gRPC service client parameters. This needs a separate rule
because the type signatures of the ServiceClients methods are too generic to be detected by the previous rule.
```
/Users/sjf/cline/webview-ui/src/components/mcp/configuration/tabs/add-server/AddRemoteServerForm.tsx
41:62 warning Use the appropriate protobuf .create() or .fromPartial() method instead of object literal for gRPC client parameters.
Found: McpServiceClient.addRemoteMcpServer({
serverName: serverName.trim(),
serverUrl: serverUrl.trim(),
})
```
These rules help maintain code quality by enforcing consistent patterns for working with protocol buffers throughout the codebase, reducing potential runtime errors from improper message construction.
* Update test
* Add custom eslint rules to new webview-ui config
* Only include webview grpc ServiceClient check
* Fix lint errors
* formatting
* Update package-lock.json
* Update package.json
* Fix linter warnings in the webview (part 2)
Replace protobus calls using object literals to use Message.create({...})
Fix incorrect property name detected after this change in webview-ui/src/components/settings/SettingsView.tsx
Optimised imports in vscode.
* Fix typo
* formatting
* fix(bedrock): resolve AWS credential caching issue with Identity Manager
- Add ignoreCache option for profile-based authentication to detect external credential file changes
- Implement smart caching for manual credentials with 5-minute TTL to maintain performance
- Add configuration hash-based cache invalidation for manual credential changes
- Add invalidateCredentialCache() method for error recovery scenarios
Fixes issue where AWS Identity Manager credential updates were not detected,
requiring extension restart. Profile-based authentication now always reads
fresh credentials while manual credentials maintain performance through caching.
Resolves credential refresh issues reported by users using AWS Identity Manager
with role-based authentication workflows.
* Potential fix for code scanning alert no. 66: Use of a broken or weak cryptographic algorithm
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
* merge conflict
* updated to fixe the original medrock issue
---------
Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
The webview and the cline package were using different version of eslint,
which makes it difficult to use custom rules because the webview version wants the rules as
ES modules, but the cline version wants commonJS modules.
Switch the webview to use the same version as the cline package.
Switch the webview eslint JS config to the json config file.
* add ls file tool description, parsing, and return formatting
* add json tool definition and remove extra '.'
* changeset
* use separate function for new format
* using json
* add grep tool new format
* add editTool definition
* removed changeset
* removed changeset
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
Co-authored-by: Cline Evaluation <cline@example.com>
The webview-ui has an existing eslint config, but it was not being run as part of `npm run lint` command. Start running the webview specific linter (the top level linter doesn't run on tsx files, and webview linter has react specific checks).
Fix lint errors in slash-commands file.
* warn about rosetta on osx in build-protos
* make one console log better
* format
---------
Co-authored-by: Andrei Edell <andrei@nugbase.com>
Co-authored-by: Andrei Eternal <eternal@cline.bot>
* Respect the CtxNum setting for Ollama Models
Currently since the context window size isn't respected for Ollama models - the LLM does a naive truncation which removes important details. This leads to the model entering endless loops or making unsupported edits when operating as an agent.
* small change
* changeset
---------
Co-authored-by: 0xtoshii <94262432+0xToshii@users.noreply.github.com>
* add ls file tool description, parsing, and return formatting
* add json tool definition and remove extra '.'
* changeset
* use separate function for new format
* using json
* add grep tool new format
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
Co-authored-by: Cline Evaluation <cline@example.com>
* add ls file tool description, parsing, and return formatting
* add json tool definition and remove extra '.'
* changeset
* use separate function for new format
* using json
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
Co-authored-by: Cline Evaluation <cline@example.com>
* Add secrets to the vscode extension context.
Add a secrets store backed by a file.
Compile the standalone distribtion during `npm run pretest`
* Fix type
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Remove logging
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* System prompt refactor
* Commented out model switching for now
* Claude4 system prompt switching
* cleanup
* added system.ts to prettier ignore
* workflow tips
---------
Co-authored-by: canvrno <kevin@cline.bot>
Co-authored-by: Cline Evaluation <cline@example.com>
* feat: add JSON-based diff format for Claude 4 model family
- Bump version to 3.17.5
- Add @streamparser/json dependency for streaming JSON parsing
- Implement new JSON diff format in replace_in_file tool for Claude 4 models
- Add diff-json.ts module for handling JSON-based file replacements
- Update system prompts to use JSON format when Claude 4 model detected
- Enhance DiffViewProvider to support new JSON diff format
* Adding diffs
* changeset
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Adding AGI Blog
* feat: disable quick wins feature in chat interface
Removes quick wins display by setting shouldShowQuickWins to false, cleans up related code in ChatView and simplifies component rendering logic. Also includes code cleanup in QuickWinCard component by removing redundant comments.
* Initial edit commands
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Revert "fix: Address memory leak by bypassing subscribeToState gRPC stream for state updates (#3597)"
This reverts commit 8ab35a5b06.
* memory leak console boys
* cleanup
---------
Co-authored-by: Andrei Edell <andrei@nugbase.com>
Co-authored-by: Andrei Eternal <eternal@cline.bot>
* Update zh-tw/README.md
Correct the Markdown syntax to properly display bold text.
* Update zh-tw/README.md
Insert line breaks for each item listed under ### 新增上下文.
This type was changed from a union to a discriminated union based on
transportType. It seems like this is an internal implementation detail
that end users shouldn't really care about. This change reverts that
type back to a union.
Co-authored-by: Adil Riazudeen <adiriazu@amazon.com>
* when the assistant says to act mode we render a custom highlight with hotkey suggestion
* changeset
* console
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Integration with Nebius AI Studio added
* changeset added
* tests fixed
* Nebius naming changed
* bugs fixed
* styling fixed
* minor bug fixed
* Remove obsolete ClineProvider.ts file that was causing build errors
* redundant 'Model' section removed for Nebius
* feat: add Nebius AI Studio to the list of inference providers (#2789)
- replace `nebiusModelId` to `apiModelId`
- add our latest models
- fix `getModel` method
- fix spaces and the link to Nebius AI Studio api keys
- delete extra code
- add a couple of tests
---------
Co-authored-by: Akim Tsvigun <aktsvigun@nebius.com>
Co-authored-by: Albert Abdulmanov <albertworks@nebius.com>
* Fix: edge case of changing language in settings
* Fix: Temporary revert protobus changes for Toggle plan and act mode
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Fix: Temporary revert protobus changes for Toggle plan and act mode
* Fix: Temporary revert protobus changes for Toggle plan and act mode
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
* Focus cline when on update
---------
Co-authored-by: Cline Evaluation <cline@example.com>
* add a matrix strategy for testing
* Handle EOL on Windows
* use bash as shell on every os and run the test-ci script
* fix tsconfig path resolution using the __dirnname
* print test results regardless of status
* Limit artifact upload to Linux
* update the test-cli
* Add windows-specific dependencies as optional dependencies
lightningcss-win32-x64-msvc
rollup-win32-x64-msvc
* Do not collect coverage on Windows
* Use UTF-8 on the Python Scripts
* force the ubuntu-latest name to be `test`
* Feat: Display API auto-retry status in chat UI
This commit enhances user experience by providing real-time feedback
on automatic API request retries directly within the chat interface.
When an API request encounters a retriable error (e.g., 429), the UI
will now indicate that a retry is in progress, showing the current
attempt, maximum attempts, and delay until the next attempt.
Key changes:
- Modified the `withRetry` decorator in `src/api/retry.ts` to accept
an `onRetryAttempt` callback. This callback is invoked before each
retry, passing details like attempt number, max retries, delay, and
the error that triggered the retry.
- `Task` (`src/core/task/index.ts`) now provides this callback to API
handlers. It updates the `api_req_started` message in `clineMessages`
with `retryStatus` information and posts the updated state to the
webview. It also clears retry status if retries are exhausted.
- The `ChatRow.tsx` component in the webview UI has been updated to
display this retry status (e.g., "Retrying (attempt X of Y, next in Zs)...").
If retries are exhausted, the standard error display is shown.
- Data structures in `src/shared/` (ExtensionMessage, api, proto/file)
were updated to include `retryStatus` and the `onRetryAttempt` callback.
- Added test code to `GeminiHandler` (`src/api/providers/gemini.ts`) to
simulate 429 errors, allowing for easier testing and verification of
the retry feedback mechanism.
* Remove TaskTimeLine altogether
* Remove TaskTimeLine altogether
* Update src/core/task/index.ts
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
---------
Co-authored-by: Cline Evaluation <cline@example.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* feat: Enhance HistoryPreview component with collapsible/expandable task history view
* fix: Update font size for empty state/'No recent tasks' message in HistoryPreview component
* Add standalone cline server.
Add directory standalone/ with the scripts to generate
a cline instance that runs a gRPC service for the proto bus.
* Rm unused dependencies
* Build standalone extension
Build stubs for the whole vscode SDK.
Import extension.js instead of putting everything in one file.
Move all the files the extension needs at runtime in files/
Use local packages for vscode and stub-utils instead of module alias.
Move vscode-impls into the vscode module.
Create separate package.json for the standalone extension in files/.
* Handlers for gRPC requests
Add code to the bottom of extension.js to export the gRPC handlers.
Add a wrapper to the handlers to catch and log extensions, otherwise the whole server process fails.
Fix use of open module.
* Standalone gRPC server
Export handers from the extension.
Add reflection and healthcheck to the server.
Add vscode launch file for standalone server.
* Fix formatting
* Better error handling in the server template.
Exit if the server could not bind to the port.
Use internal error code if exception is thrown.
* Formatting
* Stop using google-protobuf npm module to generate JS for protos
The code generated by google-protobuf cannot serialize protos from plain objects. It needs the protos to be class instances created with ProtoExample.create().
But, the protos created in the extension are just POJOs.
Use protoLoader instead which is fine with plain objects.
Protoloader is also the method used in the grpc JS documentation: https://grpc.io/docs/languages/node/basics/#loading-service-descriptors-from-proto-files
* Rm proto that was removed in cline/cline
* Rm old protos when building standalone extension.
* Log gRPC requests
* feat(standalone): implement TypeScript gRPC-based standalone extension
The major improvement is that the gRPC implementation is now written in TypeScript instead of JavaScript, and the standalone extension is compiled together with the original extension rather than using the compiled JS output. This provides full type safety throughout the codebase and prevents issues with the TypeScript compiler renaming handlers during compilation, making the system more robust and maintainable.
- Add new standalone implementation files in src/standalone/ directory using TypeScript
- Implement gRPC server setup in extension-standalone.ts with full type safety
- Generate server setup code with service registrations
- Update build script to support the new standalone architecture
- Reorganize runtime files from standalone/files/ to standalone/runtime-files/
- Replace template-based server generation with gRPC service registration
* Fix issues when doing clean build
Use correct build dir in esbuild.js
Remove undefined type.
* Add handler for gRPC methods with streaming response.
Add a handler-wrapper for rpc's with streaming responses.
Fix issue where grpc-js won't deserialize protos in camelcase. It is the default
for generated code for protos to use camelcase (keepCase: false), but I cannot find
where is being set for the proto serializations to keep the case. For now, just convert the
properties of the proto messages to snake case. This is not a good
solution, but trying to fix this is time sink.
* Formatting
* Add streaming response support to the script that generates setup-server.ts
Add types for the handlers.
* Formatting
* Fix case conversion for gRPC requset protos as well.
Convert snake case to camelcase for incoming request protos.
* formatting
* Improve build process / building for standalone extension
Add separate configs for the extension and the standalone in the esbuild config.
Modules that use __dirname to load files at runtime are marked as external in the build config.
Rename vscode-impls to vscode-context.
Remove unecessary files from the standalone runtime.
* Rename extension-standalone.js to standalone.js
* Move generate-server-setup script to protos dir.
Add the script the npm target `protos`, so it is run when the protos are regenerated.
* formatting
* Add a post build step for the npm run target `protos` to format the generated files.
* Move generate-server-setup to scripts directory
* Add a JS script to package the standalone build, replacing the shell script.
Add a post build step for the standalone target that:
* copies the vscode module files into the output directory.
* checks that native modules are not included in the output
* creates a zip of the build.
* Rm files that were included from merge by mistake
* Move scripts from standalone in scripts directory
Remove unused package.json files from standalone/
* Update scripts and launch.json to use correct paths
* During build install external modules in the dist directory.
Add package.json for the distribution.
Set the node path for the vscode launch config.
Make the prettier silent during `npm run protos`
* Fix ellipsis suggestions
• Replace "o3MiniReasoningEffort" with "reasoningEffort" in API providers
• Remove deprecated configuration properties from package.json
• Guard checkpoint tracker initialization and saving using the enableCheckpoints flag
Co-authored-by: Cline Evaluation <cline@example.com>
* Create proto descriptor set in build-protos.js script.
Create the descriptor set that will be used by the standalone cline service.
Add the standalone dist directory to the gitignore.
Only call protoc once when generating typescript files, instead of for each file separately.
* Fix undefined var in error message
* Inline the exec options
* fix: Add required --user-data-dir flag when launching Chrome with remote debugging port
When Chrome is launched with the --remote-debugging-port flag, it requires a non-default user data directory to be specified using the --user-data-dir flag. Without this flag, Chrome shows the error 'DevTools remote debugging requires a non-default data directory' and the debug port is not opened.
This fix adds the --user-data-dir flag when launching Chrome with the remote debugging port, which resolves the 'Chrome was launched but debug port is not responding' error.
* Add changeset for Chrome remote debugging fix
* fix: Add required --user-data-dir flag when launching Chrome with remote debugging port
* Update src/services/browser/BrowserSession.ts
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Revert "Update src/services/browser/BrowserSession.ts"
This reverts commit 5dbd82aea2.
* import os, quote path arg
* apparently quotes are bad
* probably dont need the whole warning and relaunch flow now
* rename button labels to launch browser
---------
Co-authored-by: Andrei Eternal <garoth@gmail.com>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
Co-authored-by: Andrei Edell <andrei@nugbase.com>
* Enhance copy functionality in ChatView to handle selections within code blocks. If the selection is inside a <pre><code> block, copy plain text; otherwise, convert HTML to Markdown before copying. This improves user experience when copying code snippets.
* Make jumps better please
---------
Co-authored-by: Cline Evaluation <cline@example.com>
This commit introduces `parseAssistantMessageV2`, a new function designed to parse assistant message strings containing text and XML-like tool usage tags (`<tool_name>...</tool_name>`, `<param_name>...</param_name>`).
Motivation:
The original parser (`V1`) used a character-by-character accumulator, which could lead to performance overhead due to repeated string concatenations and checks (`endsWith`). V2 aims to improve parsing efficiency.
Implementation Details (V2 vs V1):
- V2 iterates through the string using an index and checks for tags using `startsWith` with calculated offsets, avoiding the V1 accumulator.
- It tracks start indices for text, tools, and parameters, performing `slice` operations only when a block is completed or the string ends.
- Known tool and parameter opening tags are precomputed into Maps for potentially faster lookups.
- Special handling for nested tags within `write_to_file`/`new_rule` content parameters is preserved using `indexOf`/`lastIndexOf`.
Other Changes:
- The original parser implementation has been renamed to `parseAssistantMessageV1`.
* simplified home header
* changeset
* add variable color logo for different themes
* random slash
---------
Co-authored-by: Elephant Lumps <celestial_vault@Elephants-MacBook-Pro.local>
* slash command report bug
* nits
* nits
* sigh, portible way to open urls with proper escaping because vs code api is broken
* only asking for non-algorithmically derived info
* Update webview-ui/src/components/chat/ChatView.tsx
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* gather user system info
* Revert "gather user system info"
This reverts commit fb16c72224.
---------
Co-authored-by: Cline Evaluation <cline@example.com>
Co-authored-by: pashpashpash <nik@cline.bot>
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
This guide outlines how to add new gRPC endpoints for communication between the webview (frontend) and the extension host (backend).
## Overview
Cline uses [Protobuf](https://protobuf.dev/) to define a strongly-typed API, ensuring efficient and type-safe communication. All definitions are in the `/proto` directory. The compiler and plugins are included as project dependencies, so no manual installation is needed.
## Key Concepts & Best Practices
-**File Structure**: Each feature domain should have its own `.proto` file (e.g., `account.proto`, `task.proto`).
-**Message Design**:
- For simple, single-value data, use the shared types in `proto/common.proto` (e.g., `StringRequest`, `Empty`, `Int64Request`). This promotes consistency.
- For complex data structures, define custom messages within the feature's `.proto` file (see `task.proto` for examples like `NewTaskRequest`).
-**Streaming**: For server-to-client streaming, use the `stream` keyword on the response type. See `subscribeToAuthCallback` in `account.proto` for an example.
---
## 4-Step Development Workflow
Here’s how to add a new RPC, using `scrollToSettings` as an example.
### 1. Define the RPC in a `.proto` File
Add your service method to the appropriate file in the `proto/` directory.
**File: `proto/ui.proto`**
```proto
serviceUiService{
// ... other RPCs
// Scrolls to a specific settings section in the settings view
Here, we use the common `StringRequest` and `KeyValuePair` types.
### 2. Compile Definitions
After editing a `.proto` file, regenerate the TypeScript code. From the project root, run:
```bash
npm run protos
```
This command compiles all `.proto` files and outputs the generated code to `src/generated/` and `src/shared/`. Do not edit these generated files manually.
### 3. Implement the Backend Handler
Create the RPC implementation in the backend. Handlers are located in `src/core/controller/[service-name]/`.
The goal of this workflow is to take a changeset for a release of Cline, an autonomous coding agent extension that plugs right into your IDE, and write the updated announcement component, and the updated changelog.
For reference, here are some examples of how we converted previous changesets to announcement components / changelogs.
- 3.14
<changeset>
This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
Releases
claude-dev@3.14.0
Minor Changes
77c9863: create clinerules folder if its currently a file and creating new rule
0ffb7dd: disabling shift hint for now & improving tooltip behavior
79b76fd: Add support for custom model ID in AWS Bedrock provider, enabling use of Application Inference Profile.
eb6e481: Full support for LaTeX rendering
df37f29: Add support for custom API request timeout. Previously, timeouts were hardcoded to 30 seconds for providers like Ollama or 15 seconds for OpenRouter and Cline. Now users can set a custom timeout value in milliseconds through the settings interface.
e4d26be: allow cursorrules and windsurfrules
c5de50f: Fix Handle @withRetry() SyntaxError when running extension locally issue
61d2f42: enabled pricing calculation for gemini and vertex + more robust caching & cache tracking for gemini & vertex
aed152b: add truncation notice when truncating manually
2fe2405: Migrate Cline Tools Section to new docs
19cc8bc: Add a timeout setting for the terminal connection, allowing users to adjust this if they are having timeout issues
03d4410: Added copy button to code blocks.
c78fe23: addressed race condition in terminal command usage
91e222f: add checkpoints after more messages
14230e7: add newrule slash command
1c7d33a: Add remote config with posthog allowing for disabling new features until they're reading, making for a better developer experience.
4196c14: add cache ui for open router and cline provider
d97424f: showing expanded task by default
5294e78: Refactor to not pass a message for showing the MCP View from the servers modal
70cc437: Fix Windows path issue: Correct handling of import.meta.url to avoid leading slash in pathname
4b697d8: Migrate the addRemoteServer to protobus
Patch Changes
c63d9a1: updated drag and drop text to say "drop" instead of "drag"
459adf0: Add markdown copy to chat
74ec823: Minor UX improvement to drag and drop ux
b0961f4: Remove linear pull request action
e9ce384: searchCommits protobus migration
5802b68: createRuleFile protobus migration
df7f9fc: Add dependsOn to more blocks in the tasks.json
41ae732: Fix for git commit mentions in repos with no git commits
7e78445: Adding args to allow Cursor to open workspaces (for checkpoint testing/development)
bdfda6f: feat(bedrock): Introduce Amazon Nova Premier
65243ad: Introduce UI library for future UI development
4565e06: checkIsImageURL migrated to protobus
5a8e9d8: protobus migration for openImage
deeda6e: Lowering Gemini cache TTL time
db0b022: Adding UI to show openrouter balance next to provider
4650ffa: deleteRuleFile protobus migration
d4bd755: fix cost calculation
</changeset>
<changelog>
## [3.14.0]
- Add UI to show openrouter balance next to provider
- Add support for custom model ID in AWS Bedrock provider, enabling use of Application Inference Profile (Thanks @clicube!)
- Add more robust caching & cache tracking for gemini & vertex providers
- Add support for LaTeX rendering
- Add support for custom API request timeout. Timeouts were 15-30s, but can now be configured via settings for OpenRouter/Cline & Ollama (Thanks @WingsDrafterwork!)
- Add truncation notice when truncating manually
- Add a timeout setting for the terminal connection, allowing users to set a time to wait for terminal startup
- Add copy button to code blocks
- Add copy button to markdown blocks (Thanks @weshoke!)
- Add checkpoints to more messages
- Add slash command to create a new rules file (/newrule)
- Add cache ui for open router and cline provider
- Add Amazon Nova Premier model to Bedrock (Thanks @watany!)
- Add support for cursorrules and windsurfrules
- Add support for batch history deletion (Thanks @danix800!)
- Improve Drag & Drop experience
- Create clinerules folder creating new rule if it's needed
- Enable pricing calculation for gemini and vertex providers
- Refactor message handling to not show the MCP View of the server modal
- Migrate the addRemoteServer to protobus (Thanks @DaveFres!)
- Update task header to be expanded by default
- Update Gemini cache TTL time to 15 minutes
- Fix race condition in terminal command usage
- Fix to correctly handle `import.meta.url`, avoiding leading slash in pathname for Windows (Thanks @DaveFres!)
2964388: Added copy button to MermaidBlock component
75143a7: Add the ability to fetch from global cline rules files
Patch Changes
a0252e7: convert inline style to tailwind css of file SettingsView.tsx
ab59bd9: Add stream options back to xai provider
7276f50: Icons to indicate an action is occuring outside of the users workspace
0b19ba6: update to NEW model
</changeset>
<changelog>
## [3.13.0]
- Add Cline rules popover under the chat field, allowing you to easily add, enable & disable workspace level or global rule files
- Add new slash command menu letting you type “/“ to do quick actions like creating new tasks
- Add ability to edit past messages, with options to restore your workspace back to that point
- Allow sending a message when selecting an option provided by the question or plan tool
- Add command to jump to Cline's chat input
- Add support for OpenAI o3 & 4o-mini (Thanks @PeterDaveHello and @arafatkatze!)
- Add baseURL option for Google Gemini provider (Thanks @owengo and @olivierhub!)
- Add support for Azure's DeepSeek model. (Thanks @yt3trees!)
- Add ability for models that support it to receive image responses from MCP servers (Thanks @rikaaa0928!)
- Improve search and replace diff editing by making it more flexible with models that fail to follow structured output instructions. (Thanks @chi-cat!)
- Add detection of Ctrl+C termination in terminal, improving output reading issues
- Fix issue where some commands with large output would cause UI to freeze
We have a changeset PR that automatically generated as new unreleased PRs are merged into main, the PR is always called "Changeset version bump" and the author is github-actions.
The Changeset PR description looks something like this:
<changeset-pr-description>
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.
# Releases
## claude-dev@3.16.0
### Minor Changes
- c6e8b04: Recent task list is now collapsible, allowing users to hide their recent tasks (e.g. when sharing their screen).
- aabe4ae: Add detection for new users to display special components
- 6c18d51: adds global endpoint for vertex ai users
- 080ed7c: Add Tailwind CSS IntelliSense to the the recommended extensions list
- 5147e28: new workflow feature
### Patch Changes
- c0b3c69: fix eternal loading states when the last message is a checkpoint
- 570ece3: selectImages protos migration
- 8d8452e: askResponse protobus migration
- cd1ff2a: Finishing the migration of Vscode Advanced settings to Settings Webview
</changeset-pr-description>
The changeset pr is ALWAYS on the following branch: `changeset-release/main`.
I have the `gh` command line tool set up and authenticated, so you have everything you need.
The first step is to get the full diff from the changeset PR to look at the changes that were automatically made to the `CHANGELOG.md` file. By default it will automatically add a new section to the changelog.md file with the new version. The problem with the automatically generated section is that it just takes the text that the developers threw into their changeset files for each corresponding PR, and they can be pretty vague and bad. Additionally there's some stuff that is totally irrelevant for the end user, like minor refactoring changes. So I manually typically go in and update this section to be a proper changelog that will show up in our patchnotes. You can look at how the rest of the file is done because those are all good examples of us updating this to use good language for the end user. We usually put new features up top (and the most exciting flagship features at the very top), and then bug fixes/improvements at the bottom. Having some basic organization to the ordering of the bullet points by content is nice. But use common sense.
To handle this process effectively, do the following:
For each of the automatically generated bullet points in the Changelog.md, you should
1. Take the commit hash at the start of the bullet point, and use the `gh` command line tool find the PR that it was associated with.
2. Use the `gh` command to get the PR title/description/discussion to understand the context surrounding the PR.
3. Use the `gh` command line tool to get the full PR diff to fully understand the changes made in the code.
4. Synthesize that knowledge to determine (a) whether or not this change is relevant to end users and (b) what the text & ordering of the line should be.
5. Update the `CHANGELOG.md` accordingly
Do this for every single item in the list from the autogenerated bullet points. We want to be diligent and have a full understanding of every feature so we can make the best changelog ever!
Here are some principles for good changelogs from keepchangelog.com, a handy guide:
<keepachangelog-pinciples-for-good-changelogs>
### Guiding Principles
- Changelogs are for humans, not machines.
- There should be an entry for every single version.
- The same types of changes should be grouped.
- The latest version comes first.
### Bullet points in the changelog should follow these principles:
- Types of changes
- Added for new features.
- Changed for changes in existing functionality.
- Deprecated for soon-to-be removed features.
- Removed for now removed features.
- Fixed for any bug fixes.
- Security in case of vulnerabilities.
</keepachangelog-pinciples-for-good-changelogs>
Lastly, when developers make a PR, they typically make a changeset. And they have 3 options when making the changeset:
1. Patch
2. Minor
3. Major
Sometimes they label something as minor when really it should just be a patch. Or vice versa. Because of this, the automatic version bump may be incorrect. So when starting out this workflow, you should use the <ask_followup_question> tool to confirm with me whether or not this should be a patch bump (show the old version number and what the proposed new version number would be) or a minor bump. Part of the release process is making sure the version in package.json that is automatically changed actually corresponds with what we decided the bump should actually be based on the features. ALL these modifications happen in the `changeset-release/main` branch btw.
<important_note>
Before doing any of this, make sure you check out the `changeset-release/main` and pull the most recent up to date changes. Then perform all this work in that branch.
New announcement banners should ONLY be made for minor version bumps or higher. That's another reason why double checking if the changelog warrants the bump is important.
Also, SUPER important: For any external contributors that aren't part of the cline github organization, we always want to add a (Thanks @username!) at the end of the changelog to attribute them properly. We're an open source project and it's ethical to do this.
</important_note>
Once the changelog looks good, and the version number looks good, we gotta double check that the version number in the changelog has the brackets around it. And as a final step, double check the package.json version number matches the latest number in the changelog. And as the ultimate final step we run `npm run install:all` to make sure the package version number permiates through the lock file.
<detailed_sequence_of_steps>
# Cline Release Process - Detailed Sequence of Steps
## Before Starting
1. First, examine the changeset PR without checking it out:
```bash
gh pr view changeset-release/main
```
2. View the PR diff to see the auto-generated CHANGELOG.md changes:
# Check if user is a member of the Cline organization
# this command is a bit finnicky, but it 100% works.
# if you see a `Error executing command: The command ran successfully, but we couldn't capture its output. Please proceed accordingly.` error, just retry it until you actually get the output
# don't make any assumptions, just retry the command to actually get the output and determine if they're external or not.
# no output means they are an external contributor, otherwise if there is output they are an internal contributor (part of our github org)
gh api "orgs/cline/members" --jq "map(.login)" | grep -i "pashpashpash"
```
d. View the full PR diff to understand code changes:
```bash
gh pr diff <PR-number> > pr-diff-<PR-number>.txt
cat pr-diff-<PR-number>.txt
```
## Updating the Changelog
5. Based on PR analysis, update the CHANGELOG.md with user-friendly descriptions:
- Use the `<replace_in_file>` tool to edit the CHANGELOG.md file
- Group by feature type (Added, Changed, Fixed)
- Put most exciting features at the top
- Move bug fixes and small improvements to the bottom
- Use clear, end-user focused language
- For external contributors, add attribution at the end of the relevant entry: `(Thanks @username!)`
## Version Number Verification
6. Confirm the version bump is appropriate:
- Check package.json to verify the auto-generated version number:
```bash
cat package.json | grep "\"version\""
```
- If the feature set doesn't warrant a minor bump, use the `<replace_in_file>` tool to modify package.json
7. Ensure the version in CHANGELOG.md has brackets around it:
```
## [3.16.0]
```
## Creating the Announcement (for minor/major versions only)
8. If this is a minor version bump, create/update the announcement component:
- Use the `<replace_in_file>` tool to edit the src/views/components/announcement.tsx file
- Update the highlights based on key features
- Move previous version highlights to the "Previous Updates" section
- Use the previous announcement components as reference for structure
## Finalizing the Release
9. Update dependencies with the new version number:
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]
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
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:
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.
description:Propose a new feature or improvement, and optionally offer to implement feature as a contributor
labels:["proposal"]
body:
- type:markdown
attributes:
value:|
**Feature Proposal & Contribution for Cline**
Thank you for proposing a feature or improvement for Cline! This template helps us understand the problem, evaluate the solution, and coordinate implementation.
**For detailed proposals:** Please provide comprehensive information to enable fast prioritization and discussion.
**For contribution offers:** You can indicate your willingness to implement the feature yourself.
Before submitting:
- Search existing [Issues](https://github.com/cline/cline/issues) and [Discussions](https://github.com/cline/cline/discussions) to avoid duplicates
- Read the [Contributing Guide](https://github.com/cline/cline/blob/main/CONTRIBUTING.md) if you plan to contribute
- Don't start implementation until the proposal is reviewed and approved
- type:textarea
id:problem-description
attributes:
label:What problem does this solve?
description:|
Describe the problem clearly from a user's point of view. Focus on why this matters, who it affects, and when it occurs.
✅ Good examples:
- "LLM provider returns 400 error when nearing the context window instead of truncating"
- "Submit button is invisible in dark mode"
- "Users can't easily share their Cline configurations with team members"
❌ Avoid vague descriptions:
- "Performance is bad"
- "UI needs work"
Your description should include:
- Who is affected?
- When does it happen?
- What's the current vs expected behavior?
- What is the impact?
placeholder:Be specific about the problem, who it affects, and the impact.
validations:
required:true
- type:textarea
id:proposed-solution
attributes:
label:What's the proposed solution?
description:|
Describe how the problem should be solved. Be specific about UX, system behavior, and any flows that would change.
✅ Good examples:
- "Add error handling immediately after attempting to create the llm stream and retry after manually truncating"
- "Update button styling to ensure contrast in all themes"
- "Add export/import functionality in settings with JSON format"
❌ Avoid vague solutions:
- "Improve performance"
- "Fix the bug"
Your solution should include:
- What exactly will change?
- How will users interact with it?
- What's the expected outcome?
placeholder:Describe the proposed changes and how they solve the problem.
validations:
required:false
- type:dropdown
id:contribution-intent
attributes:
label:Are you interested in implementing this?
description:Let us know if you'd like to contribute to this feature
options:
- "No, just proposing the idea"
- "Yes, I'd like to implement this myself"
- "Yes, I'd like to collaborate with others"
- "Maybe, depending on complexity and guidance"
validations:
required:false
- type:textarea
id:implementation-approach
attributes:
label:Implementation approach (if contributing)
description:|
**Only fill this out if you selected "Yes" above.**
How do you plan to implement this? Include:
- High-level technical approach
- Files/components that would be affected
- Any new dependencies required
- Potential challenges or considerations you've identified
This helps us provide better guidance and ensures alignment before you start coding.
placeholder:"My implementation approach would be..."
- type:checkboxes
id:checklist
attributes:
label:Proposal checklist
options:
- label:I've checked for existing issues or related proposals
required:true
- label:I understand this needs review before implementation can start
required:true
- type:checkboxes
id:contribution-checklist
attributes:
label:Contribution checklist (if contributing)
description:Only check these if you plan to contribute
options:
- label:I've read the [Contributing Guide](https://github.com/cline/cline/blob/main/CONTRIBUTING.md)
- label:I'm willing to make changes based on feedback
- label:I understand the code review process and requirements
⚠️ Important: Before submitting this PR, please ensure you have:
- Opened an issue and discussed your proposed changes with the community / contributors
- Received approval from a core Cline contributor prior to proceeding with the implementation
- Link the associated issue in the "Related Issue" section
Limited exceptions:
Small bug fixes, typo corrections, minor wording improvements, or simple type fixes that don't change functionality may be submitted directly.
Why this requirement?
We deeply appreciate all community contributions - they are the core reason we're able to operate successfully and keep innovating! We welcome community input and want to make it as easy as possible for people to submit quality work. This process helps our core maintainers review new ideas faster and saves contributor time by ensuring you have the go-ahead before spending time on implementation.
-->
### Related Issue
<!-- Replace XXXX with the issue number that this PR addresses -->
**Issue:**#XXXX
### Description
<!-- Describe your changes in detail. What problem does this PR solve? -->
<!--
Help reviewers understand your changes by making this PR readable and well-organized:
- What problem does this PR solve?
- Why were these changes introduced and what purpose do they serve?
- For larger changes, provide context about your approach and reasoning
Small PRs may need minimal description, but larger changes benefit from explaining where you're coming from. Much of this context can be in the linked issue above, so feel free to reference it rather than repeating everything here.
-->
### Test Procedure
<!-- How did you test this? Are you confident that it will not introduce bugs? If so, why? -->
<!--
Please walk us through your testing approach and thought process. This helps reviewers understand that you've thoroughly considered the impact of your changes:
- How did you test this change?
- What could potentially break and how did you verify it doesn't?
- What existing functionality might be affected and how did you check it still works?
- Why are you confident this is ready for merge?
We're not looking for exhaustive documentation - just evidence that you've thought through the implications of your changes and tested accordingly.
-->
### Type of Change
@@ -29,7 +66,15 @@
### Screenshots
<!-- For UI changes, add screenshots here -->
<!--
Help reviewers quickly understand your changes:
- **UI Changes**: Please include screenshots showing before/after states
- **Complex Workflows**: Consider uploading a screen recording (video) if your changes involve multiple steps or state transitions
- **Backend Changes**: Not required, but feel free to include terminal output or other evidence that demonstrates functionality
This helps reviewers see what you've built without having to pull down and test your branch first.
stale-issue-message:"This issue is stale because it has been open for ${{ github.event.inputs.days-before-stale }} days with no activity."
close-issue-message:"This issue was closed because it has been inactive for ${{ github.event.inputs.days-before-close }} days since being marked as stale."
- Optimized Cline to work with the Claude 4 family of models, resulting in improved performance, reliability, and new capabilities
- Added a new Gemini CLI provider that allows you to use your local Gemini CLI authentication to access Gemini models for free (Thanks @google-gemini!)
- Optimized Cline to work with the Gemini 2.5 family of models
- Updated the default and recommended model to Claude 4 Sonnet for the best performance
- Fix race condition in Plan/Act mode switching
- Improve robustness of search and replace parsing
## [3.17.16]
- Fix Claude Code provider error handling for incomplete messages during long-running tasks (Thanks @BarreiroT!)
- Add taskId as metadata to LiteLLM API requests for better request tracing (Thanks @jorgegarciarey!)
## [3.17.15]
- Fix LiteLLM provider to properly respect selected model IDs when switching between Plan and Act modes (Thanks @sammcj!)
- Fix chat input being cleared when switching between Plan/Act modes without sending a message (Thanks @BarreiroT!)
- Fix MCP server name display to avoid showing "undefined" for SSE servers, preventing tool/resource invocation failures (Thanks @ramybenaroya!)
- Fix AWS Bedrock provider by removing deprecated custom model encoding (Thanks @watany-dev!)
- Fix timeline tooltips for followup messages and improve color retrieval code (Thanks @char8x!)
- Improve accessibility by making task header buttons properly announced by screen readers (Thanks @yncat!)
- Improve accessibility by adding proper state reporting for Plan/Act mode switch for screen readers (Thanks @yncat!)
- Prevent reading development environment variables from user's environment (Thanks @BarreiroT!)
## [3.17.14]
- Add Claude Code as a new API provider, allowing integration with Anthropic's Claude Code CLI tool and Claude Max Plan (Thanks @BarreiroT!)
- Add SAP AI Core as a new API provider with support for Claude and GPT models (Thanks @schardosin!)
- Add configurable default terminal profile setting, allowing users to specify which terminal Cline should use (Thanks @valinha!)
- Add terminal output size constraint setting to limit how much terminal output is processed
- Add MCP Rich Display settings to the settings page for persistent configuration (Thanks @Vl4diC0de!)
- Fix menu display issue for terminal timeout settings
- Improve chat input field styling and behavior
## [3.17.12]
-**Free Grok Model Available!** Access Grok 3 completely free through the Cline provider
- Add collapsible MCP response panels to keep conversations focused on the main AI responses while still allowing access to detailed MCP output (Thanks @valinha!)
- Prioritize active files (open tabs) at the top of the file context menu when using @ mentions (Thanks @abeatrix!)
- Fix context menu to properly default to "File" option instead of incorrectly selecting "Git Commits"
- Fix diff editing to handle out-of-order SEARCH/REPLACE blocks, improving reliability with models that don't follow strict ordering
- Fix telemetry warning popup appearing repeatedly for users who have telemetry disabled
## [3.17.11]
- Add support for Gemini 2.5 Pro Preview 06-05 model to Vertex AI and Google Gemini providers
## [3.17.10]
- Add support for Qwen 3 series models with thinking mode options (Thanks @Jonny-china!)
- Add new AskSage models: Claude 4 Sonnet, Claude 4 Opus, GPT 4.1, Gemini 2.5 Pro (Thanks @swhite24!)
- Add VSCode walkthrough to help new users get started with Cline
- Add support for streamable MCP servers
- Improve Ollama model selection with filterable dropdown instead of radio buttons (Thanks @paulgear!)
- Add setting to disable aggressive terminal reuse to help users experiencing task lockout issues
- Fix settings dialog applying changes even when cancel button is clicked
## [3.17.9]
- Aligning Cline to work with Claude 4 model family (Experimental)
- Add task timeline scrolling feature
- Add support for uploading CSV and XLSX files for data analysis and processing
- Add stable Grok-3 models to xAI provider (grok-3, grok-3-fast, grok-3-mini, grok-3-mini-fast) and update default model from grok-3-beta to grok-3 (Thanks @PeterDaveHello!)
- Add new models to Vertex AI provider
- Add new model to Nebius AI Studio
- Remove hard-coded temperature from LM Studio API requests and add support for reasoning_content in LM Studio responses
- Display delay information when retrying API calls for better user feedback
- Fix AWS Bedrock credential caching issue where externally updated credentials (e.g., by AWS Identity Manager) were not detected, requiring extension restart (Thanks @DaveFres!)
- Fix search tool overloading conversation with massive outputs by setting maximum byte limit for responses
- Fix checkpoints functionality
- Fix token counting for xAI provider
- Fix Ollama provider issues
- Fix window title display for Windows users
- Improve chat box UI
## [3.17.8]
- Fix bug where terminal would get stuck and output "capture failure"
## [3.17.7]
- Fix diff editing reliability for Claude 4 family models by adding constraints to prevent errors with large replacements
## [3.17.6]
- Add Cerebras as a new API provider with 5 high-performance models including reasoning-capable models (Thanks @kevint-cerebras!)
- Add support for uploading various file types (XML, JSON, TXT, LOG, MD, DOCX, IPYNB, PDF) alongside images
- Add improved onboarding experience for new users with guided setup
- Add prompt cache indicator for Gemini 2.5 Flash models
- Update SambaNova provider with new model list and documentation links (Thanks @luisfucros!)
- Fix diff editing support for Claude 4 family of models
- Improve telemetry and analytics for better user experience insights
## [3.17.5]
- Fix issue with Claude 4 models where after several conversation turns, it would start making invalid diff edits
## [3.17.4]
- Fix thinking budget slider for Claude 4
## [3.17.3]
- Fix diff edit errors with Claude 4 models
## [3.17.2]
- Add support for Claude 4 models (Sonnet 4 and Opus 4) in AWS Bedrock and Vertex AI providers
- Add support for global workflows, allowing workflows to be shared across workspaces with local workflows taking precedence
@@ -10,16 +10,77 @@ Bug reports help make Cline better for everyone! Before creating a new issue, pl
🔐 <b>Important:</b> If you discover a security vulnerability, please use the <a href="https://github.com/cline/cline/security/advisories/new">Github security tool to report it privately</a>.
</blockquote>
## Before Contributing
All contributions must begin with a GitHub Issue, unless the change is for small bug fixes, typo corrections, minor wording improvements, or simple type fixes that don't change functionality.
- **Contributions:** Use the "Contribution Request" template to propose what you'd like to work on.
- **Bugs:** "Bug Report" template for reporting issues.
- **Features:** "Detailed Feature Proposal" template for suggesting new features.
- **Wait for approval**: A core Cline contributor must approve your contribution request before you start implementation.
- **Claim issues**: Once approved, the issue will be assigned to you.
**PRs without approved issues may be closed.**
## Deciding What to Work On
Looking for a good first contribution? Check out issues labeled ["good first issue"](https://github.com/cline/cline/labels/good%20first%20issue) or ["help wanted"](https://github.com/cline/cline/labels/help%20wanted). These are specifically curated for new contributors and areas where we'd love some help!
We also welcome contributions to our [documentation](https://github.com/cline/cline/tree/main/docs)! Whether it's fixing typos, improving existing guides, or creating new educational content - we'd love to build a community-driven repository of resources that helps everyone get the most out of Cline. You can start by diving into `/docs` and looking for areas that need improvement.
If you're planning to work on a bigger feature, please create a [feature request](https://github.com/cline/cline/discussions/categories/feature-requests?discussions_q=is%3Aopen+category%3A%22Feature+Requests%22+sort%3Atop) first so we can discuss whether it aligns with Cline's vision.
## Development Setup
### Local Development Instructions
1. Clone the repository _(Requires [git-lfs](https://git-lfs.com/))_:
```bash
git clone https://github.com/cline/cline.git
```
2. Open the project in VSCode:
```bash
code cline
```
3. Install the necessary dependencies for the extension and webview-gui:
```bash
npm run install:all
```
4. Launch by pressing `F5` (or `Run`->`Start Debugging`) to open a new VSCode window with the extension loaded. (You may need to install the [esbuild problem matchers extension](https://marketplace.visualstudio.com/items?itemName=connor4312.esbuild-problem-matchers) if you run into issues building the project.)
### Creating a Pull Request
1. Before creating a PR, generate a changeset entry:
```bash
npm run changeset
```
This will prompt you for:
- Type of change (major, minor, patch)
- `major` → breaking changes (1.0.0 → 2.0.0)
- `minor` → new features (1.0.0 → 1.1.0)
- `patch` → bug fixes (1.0.0 → 1.0.1)
- Description of your changes
2. Commit your changes and the generated `.changeset` file
3. Push your branch and create a PR on GitHub. Our CI will:
- Run tests and checks
- Changesetbot will create a comment showing the version impact
- When merged to main, changesetbot will create a Version Packages PR
- When the Version Packages PR is merged, a new release will be published
4. Testing
- Run `npm run test` to run tests locally.
- Before submitting PR, run `npm run format:fix` to format your code
- Run `npm run test:ci` to run tests locally
### Extension
1. **VS Code Extensions**
- When opening the project, VS Code will prompt you to install recommended extensions
@@ -29,23 +90,26 @@ If you're planning to work on a bigger feature, please create a [feature request
2. **Local Development**
- Run `npm run install:all` to install dependencies
- Run `npm run test` to run tests locally
- Run → Start Debugging or `>Debug: Select and Start Debugging` and wait for a new VS Code instance to open
- Before submitting PR, run `npm run format:fix` to format your code
3. **Linux-specific Setup**
VS Code extension tests on Linux require the following system libraries:
-`libatk1.0-0`
- `dbus`
- `libasound2`
- `libatk-bridge2.0-0`
-`libxkbfile1`
- `libatk1.0-0`
- `libdrm2`
- `libgbm1`
- `libgtk-3-0`
- `libnss3`
- `libx11-xcb1`
- `libxcomposite1`
- `libxdamage1`
- `libxfixes3`
- `libxkbfile1`
- `libxrandr2`
-`libgbm1`
-`libdrm2`
-`libgtk-3-0`
-`dbus`
- `xvfb`
These libraries provide necessary GUI components and system services for the test environment.
@@ -54,13 +118,23 @@ If you're planning to work on a bigger feature, please create a [feature request
@@ -30,7 +30,7 @@ English | <a href="https://github.com/cline/cline/blob/main/locales/es/README.md
</table>
</div>
Meet Cline, an AI assistant that can use your **CLI** a**N**d **E**ditor.
Meet Cline (pronounced /klaɪn/, like "Klein"), an AI assistant that can use your **CLI** a**N**d **E**ditor.
Thanks to[Claude 3.7 Sonnet's agentic coding capabilities](https://www.anthropic.com/claude/sonnet),Cline can handle complex software development tasks step-by-step. With tools that let him create & edit files, explore large projects, use the browser, and execute terminal commands (after you grant permission), he can assist you in ways that go beyond code completion or tech support. Cline can even use the Model Context Protocol (MCP) to create new tools and extend his own capabilities. While autonomous AI scripts traditionally run in sandboxed environments, this extension provides a human-in-the-loop GUI to approve every file change and terminal command, providing a safe and accessible way to explore the potential of agentic AI.
Cline supports API providers like OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, and GCP Vertex. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using OpenRouter, the extension fetches their latest model list, allowing you to use the newest models as soon as they're available.
Cline supports API providers like OpenRouter, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, and Cerebras. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using OpenRouter, the extension fetches their latest model list, allowing you to use the newest models as soon as they're available.
The extension also keeps track of total tokens and API usage cost for the entire task loop and individual requests, keeping you informed of spend every step of the way.
@@ -141,50 +141,6 @@ 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)!
<details>
<summary>Local Development Instructions</summary>
1. Clone the repository _(Requires [git-lfs](https://git-lfs.com/))_:
```bash
git clone https://github.com/cline/cline.git
```
2. Open the project in VSCode:
```bash
code cline
```
3. Install the necessary dependencies for the extension and webview-gui:
```bash
npm run install:all
```
4. Launch by pressing `F5` (or `Run`->`Start Debugging`) to open a new VSCode window with the extension loaded. (You may need to install the [esbuild problem matchers extension](https://marketplace.visualstudio.com/items?itemName=connor4312.esbuild-problem-matchers) if you run into issues building the project.)
</details>
<details>
<summary>Creating a Pull Request</summary>
1. Before creating a PR, generate a changeset entry:
```bash
npm run changeset
```
This will prompt you for:
- Type of change (major, minor, patch)
- `major` → breaking changes (1.0.0 → 2.0.0)
- `minor` → new features (1.0.0 → 1.1.0)
- `patch` → bug fixes (1.0.0 → 1.0.1)
- Description of your changes
2. Commit your changes and the generated `.changeset` file
3. Push your branch and create a PR on GitHub. Our CI will:
- Run tests and checks
- Changesetbot will create a comment showing the version impact
- When merged to main, changesetbot will create a Version Packages PR
- When the Version Packages PR is merged, a new release will be published
description: "When working with AI coding assistants, it's easy to lose control as they make rapid changes to your codebase. That's why we built Checkpoints - your safety net for experimenting confidently."
---
Checkpoints automatically save snapshots of your workspace after each step in a task. This powerful feature lets you:
- Track and review changes made during a task
- Roll back to any previous point if needed
- Experiment confidently with auto-approve mode
- Maintain full control over your workspace
### ⚙️ How Checkpoints Work
Cline creates a checkpoint after each tool use (file edits, commands, etc.). These checkpoints:
- Work alongside your Git workflow without interference
- Maintain context between restores
- Use a shadow Git repository to track changes
For example, if you're working on a feature and Cline makes multiple file changes, each change creates a checkpoint. This means you can review each modification and, if needed, roll back to any point without affecting your main Git repository.
#### Viewing Changes & Restoring to Checkpoint
After each tool use, you can:
1. Click the "Compare" button to see modified files
2. Click the "Restore" button to open restore options
- **Restore Workspace Only**: Reset codebase while preserving task context
Example: If Cline makes changes you don't like while styling a component, you can use "Restore Workspace Only" to revert the code changes while keeping the conversation context, allowing you to try a different approach.
### 💡 Use Cases
Checkpoints let you be more experimental with Cline. While human coding is often methodical and iterative, AI can make substantial changes quickly. Checkpoints help you track these changes and revert if needed.
#### 1. Using Auto-Approve Mode
- Provides safety net for rapid iterations
- Makes it easy to undo unexpected results
#### 2. Testing Different Approaches
- Try multiple solutions confidently
- Compare different implementations
- Quickly revert to working states
- Ideal for exploring different design patterns or architectural approaches
<Frame caption="In this case, I didn't like the changes Cline made to my robot dog-walking website (still working on the robots) and I wanted to revert both the codebase and the task to before any changes were made so I could start fresh.">
1. Use checkpoints as safety nets when experimenting
2. Leverage auto-approve mode more confidently, knowing you can always roll back
3. Restore selectively based on needs:
- Use "Restore Task and Workspace" for a fresh start, reversing changes to files and the task conversation.
- Use "Restore Task Only" to try different prompts, but leave all files as they exist
- Use "Restore Workspace Only" to attempt different implementations, or prune context from the task
🛟 Checkpoints are your safety net when working with Cline, enabling you to experiment freely while maintaining full control over your codebase. Whether you're refactoring a complex component, trying different implementation approaches, or using auto-approve mode for rapid development, checkpoints ensure you can always review changes and roll back if needed.
#### 🗑️ Deleting Checkpoints
You can delete all checkpoints by using the **"Delete All History"** button in the task history menu. Note that this will also delete all tasks. Checkpoints are stored in VS Code's globalStorage.
---
## Editing Messages
Cline allows you to edit chat messages in a task after they've been submitted (with the exception of the message that started the task).
Perhaps you didn't get the results you wanted, thought of a better way to phrase your request, or need to add more information. Editing your message allows you to re-submit a request without starting over or restoring your files or workspace with checkpoints. There are two Restore options:
- **"Restore Chat"** restores just the task state and re-submits an API request to your provider with your edited message.
- **"Restore All"** restores both the task state and workspace state before re-submitting an API request. "Workspace state" refers to the condition of your workspace (files, content, etc.) at different points in the conversation.
**Interactive Editing:**
- Messages can be clicked to enter edit mode
- Cline automatically selects all text when entering edit mode
**Keyboard Shortcuts:**
- Escape: Exit edit mode
- Enter: Restore just the task
- Cmd/Ctrl + Enter: Restore the task and workspace
@@ -29,6 +29,11 @@ As a quick alternative to Cline suggesting the `newtask` tool or defining comple
- **Action:** Cline will propose creating a new task, typically suggesting context based on the current session (similar to its default behavior when using the tool). You will still get the `ask_followup_question` prompt to confirm and potentially modify the context before the new task is created.
- **Benefit:** Provides a fast, user-initiated way to leverage the `new_task` functionality for branching explorations or managing long sessions without waiting for Cline to suggest it.
<Note>
For more details on using the `/newtask` slash command, see the [New Task Command](/features/slash-commands/new-task)
documentation.
</Note>
#### Default Behavior (Without `.clinerules`)
By default, without specific `.clinerules` dictating its behavior:
@@ -115,7 +120,7 @@ Example of context window usage over 50% with a 200K context window:
Cline provides slash commands as a quick way to invoke specific tools or actions directly from the chat input, offering shortcuts for common operations. This page details the available slash commands and their usage.
#### /newtask
The `/newtask` slash command provides a fast, user-initiated way to leverage the `new_task` tool's functionality for branching explorations or managing long sessions without waiting for Cline to suggest it.
**Functionality:**
1. **Initiation:** Typing `/newtask` in the chat input signals Cline to prepare for starting a new task session.
2. **Context Proposal:** Cline proposes creating a new task and typically suggests context to preload based on the current session (summarizing key aspects like current work, technical concepts, relevant files, problems solved, and next steps).
3. **User Confirmation:** You will receive a confirmation prompt (via the `ask_followup_question` tool) displaying the proposed context. You can approve it directly or modify the context before the new task begins.
4. **New Session:** Upon confirmation, Cline ends the current task session and immediately starts a new one, preloaded with the approved context.
**Benefit:** Allows you to cleanly branch your work or start a new phase while carrying over essential background information ("knowledge transfer") without manual copying or losing the thread of the previous session.
#### /smol (alias /compact)
The `/smol` slash command (with `/compact` as an alias) allows you to condense the chat history **within your current task**. This is useful when a conversation becomes very long, potentially impacting performance or making it harder for the model to maintain focus.
**Functionality:**
1. **Initiation:** Typing `/smol` or `/compact` tells Cline you want to condense the current chat history. You can optionally add instructions after the command to guide the summarization process (e.g., `/smol focus only on the database changes` or `/smol be concise, use bullet points`).
2. **Summarization:** Cline analyzes the conversation history, considering any additional instructions provided, and generates a summary focusing on key elements: recent discussion points, important decisions, technical concepts, relevant files, problems solved, and planned next steps. Cline determines the appropriate length and detail for the summary. It retains the beginning and very recent parts of the chat while summarizing the middle sections.
3. **User Confirmation:** Cline presents this generated summary to you via a confirmation prompt and asks if it accurately reflects the essential context.
4. **Condensing:** If you approve the summary, Cline replaces the summarized middle portion of the chat history in its active context with the generated summary. This reduces the overall token count for subsequent interactions within the _same task_.
5. **Feedback:** If you reject the summary or provide feedback, Cline will retain the original history and incorporate your feedback for future actions.
**Benefit:** Helps maintain focus and manage token usage during very long, continuous tasks (like deep debugging or extended feature development) without needing to start an entirely new task session. Allows user guidance on the summarization focus.
#### When to Use Which?
Choosing between `/newtask` and `/smol` depends on your goal:
- Use `/smol` (or `/compact`) when:
- You want to continue the **same task**, but the chat history has become very long or costly.
- You need to reduce token usage for upcoming interactions within the current workflow.
- Example: Deep debugging session where you want to summarize previous steps before continuing.
- Use `/newtask` when:
- You have finished one phase of work and want to start a **fresh, related task**.
- You want to branch your exploration while preserving key context from the previous session.
- Example: Moving from developing Feature A to starting work on Feature B, carrying over relevant architectural decisions.
#### Why Manage Context?
While Cline supports large context windows, actively managing context using tools and commands like `/newtask` and `/smol` is often beneficial:
- **Performance:** Large language models can sometimes experience performance degradation or lose focus when context windows become extremely full (e.g., over 50-75% capacity, depending on the model). Condensing or resetting context can help maintain optimal performance.
- **Relevance:** Summarizing or starting fresh ensures the most relevant information is prioritized in the context window.
- **Cost:** Reducing the number of tokens sent to the model in each turn can help manage costs, especially with more expensive models.
Using `/newtask` and `/smol` provides you with direct control over the conversation context, allowing for more efficient and effective interaction with Cline.
File mentions let you pull any file from your workspace directly into your conversation with Cline. No more copying and pasting code snippets - just type `@/` and point to the file you need help with.
When you type `@/` in the chat, Cline shows your workspace files. Navigate through folders, select the file you want, and it's instantly available to Cline - complete with all imports, related functions, and surrounding context.
I use file mentions constantly when debugging. Instead of trying to figure out which parts of my code to copy over, I just reference the file directly:
```
I'm getting this error when my form submits: @terminal
Here's my component: @/src/components/ContactForm.jsx
And the API endpoint: @/src/api/contact.js
What am I missing?
```
This gives Cline everything it needs - the error message, the component code, and the API endpoint - all without me having to copy anything. Cline can see imports, dependencies, and all the surrounding context that might be causing the issue.
File mentions shine when you're dealing with complex bugs that span multiple files. Before, I'd have to carefully copy each relevant file, making sure I didn't miss anything important. Now I just reference each file with `@/` and Cline gets the complete picture.
Next time you're stuck on a problem, try using file mentions instead of copying code. You'll save time and get better answers because Cline has all the context it needs.
## How It Works Under the Hood
When you use a file mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@/path/to/file` pattern in your text
2. The extension resolves the file path relative to your workspace root
3. It checks if the file is binary (like an image) or text-based
4. For text files, it reads the complete file content
5. The file content is appended to your message in a structured format:
```
<file_content path="path/to/file">
[Complete file content]
</file_content>
```
6. This enhanced message with the embedded file content is sent to the AI
7. The AI can now "see" the complete file content as if you had copied and pasted it
This seamless process happens automatically whenever you use a file mention, giving the AI full context without you having to manually copy anything.
Folder mentions let you bring entire directories into your conversation with Cline. Just type `@/` followed by a folder path ending with a slash, and Cline gets access to the folder structure and its contents.
When you type `@/` in chat, Cline shows your workspace files and folders. Navigate to the folder you want, make sure to include the trailing slash, and Cline will see the folder's structure and contents.
I use folder mentions when I need help understanding or refactoring a whole section of my codebase. Instead of referencing individual files one by one, I can just point to the entire directory:
```
I'm trying to understand how the authentication flow works in my app.
Can you explain the structure and relationships between the files in @/src/auth/?
```
Cline can then see all the files in the auth directory, their contents, and how they relate to each other. This gives it the full context to explain complex interactions between multiple files.
Folder mentions are also perfect for getting help with project organization. When I'm unsure if my project structure makes sense, I'll ask Cline to review it:
```
I'm setting up a new React project. Does this folder structure make sense? @/src/
What would you change to make it more maintainable as the project grows?
```
Next time you're working with multiple related files, try using folder mentions instead of referencing each file individually. You'll get more comprehensive help because Cline can see the bigger picture of how everything fits together.
## How It Works Under the Hood
When you use a folder mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@/path/to/folder/` pattern (with trailing slash) in your text
2. The extension resolves the folder path relative to your workspace root
3. It calls `fs.readdir()` to get a list of all files and subdirectories in that folder
4. For each file in the directory, it checks if it's binary or text-based
5. For text files, it extracts the complete content
6. The folder structure and file contents are appended to your message in a structured format:
```
<folder_content path="path/to/folder">
├── file1.txt
├── file2.js
└── subfolder/
<file_content path="path/to/folder/file1.txt">
[File content]
</file_content>
<file_content path="path/to/folder/file2.js">
[File content]
</file_content>
</folder_content>
```
7. This enhanced message with the embedded folder structure and file contents is sent to the AI
8. The AI can now "see" both the directory structure and the content of files within that directory
This process happens automatically whenever you use a folder mention, giving the AI a comprehensive view of your project structure and file contents.
Git mentions let you bring your repository's history and changes directly into your conversation with Cline. You can reference uncommitted changes with `@git-changes` or specific commits with `@[commit-hash]`.
When you type `@` in chat, you can select "Git Changes" from the menu or type `@git-changes` directly. For specific commits, type `@` followed by the commit hash (at least 7 characters). Cline will immediately see the git status, diffs, commit messages, and other relevant information.
I use git mentions constantly when I'm trying to understand code changes or troubleshoot issues introduced by recent commits. Instead of trying to copy and paste diffs or commit logs, I just ask:
```
I think this commit broke our authentication flow: @a1b2c3d
Can you explain what changed and why it might be causing the issue?
```
This gives Cline the complete commit information, including the commit message, author, date, and the full diff. Cline can then analyze exactly what changed and how it might affect other parts of the codebase.
The `@git-changes` mention is perfect when you're working on changes and want feedback before committing:
```
Here are my current changes: @git-changes
I'm trying to implement a new feature for user profiles. Does my approach make sense?
Are there any potential issues or improvements you'd suggest?
```
This shows Cline all your uncommitted changes, including new files, modified files, and their diffs. Cline can then review your changes and provide feedback on your implementation.
Git mentions are especially powerful when combined with file mentions. When I'm investigating a bug, I'll often reference both:
```
I think this commit introduced a bug: @a1b2c3d
Here's the current implementation: @/src/components/Auth.jsx
How can I fix the issue while preserving the intended functionality?
```
Next time you're working with code changes or investigating issues, try using git mentions instead of manually describing or copying changes. You'll get more accurate help because Cline can see exactly what changed and in what context.
## How It Works Under the Hood
When you use git mentions in your message, here's what happens behind the scenes:
### For Git Changes (`@git-changes`)
1. When you send your message, Cline detects the `@git-changes` pattern in your text
2. The extension runs git commands to get the current working state of your repository
3. It captures the output of `git status` and `git diff` to see all uncommitted changes
4. This information is appended to your message in a structured format:
```
<git_working_state>
On branch main
Changes not staged for commit:
modified: src/components/Button.jsx
modified: src/styles/main.css
[Complete diff output with all changes]
</git_working_state>
```
### For Specific Commits (`@[commit-hash]`)
1. When you send your message, Cline detects the `@` followed by a commit hash pattern
2. The extension runs `git show` and related commands to get information about that commit
3. It retrieves the commit message, author, date, and the complete diff
4. This information is appended to your message in a structured format:
```
<git_commit hash="a1b2c3d">
commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t
Author: Developer Name <dev@example.com>
Date: Mon May 20 14:30:45 2025 -0700
Fix authentication bug in login form
[Complete diff output showing all changes in the commit]
</git_commit>
```
This process happens automatically whenever you use git mentions, giving the AI complete visibility into your code changes without you having to copy and paste diffs or commit logs.
@ mentions are one of Cline's most powerful features, letting you seamlessly bring external context into your conversations. Instead of copying and pasting code, error messages, or documentation, you can simply reference them with an @ symbol.
When you type `@` in the chat input, Cline shows a menu of available mention types. These mentions let you reference files, folders, problems, terminal output, git changes, and even web content directly in your conversations.
## Available @ Mentions
Cline supports several types of @ mentions, each designed to bring different kinds of context into your conversations:
Reference web content with `@https://example.com`. Cline fetches and sees the complete webpage content, perfect for
referencing documentation or GitHub issues.
</Card>
</Columns>
## Why @ Mentions Matter
@ mentions transform how you interact with Cline by:
1. **Eliminating copy-paste**: No more copying and pasting code, error messages, or terminal output. Just reference them directly.
2. **Preserving context**: Cline sees the complete context, including imports, related functions, and surrounding code that might be relevant.
3. **Maintaining formatting**: Terminal output, error messages, and web content keep their formatting, making them easier to understand.
4. **Enabling complex workflows**: Combine multiple @ mentions to give Cline a complete picture of your problem:
```
I'm getting these errors: @problems
Here's my component: @/src/components/Form.jsx
And the API endpoint: @/src/api/users.js
The error happens when I submit: @terminal
I think this commit might have caused it: @a1b2c3d
```
## Getting Started
To use @ mentions:
1. Type `@` in the chat input
2. Select the type of mention from the menu or continue typing
3. For files and folders, navigate through your workspace structure
4. Send your message as usual
Cline will automatically process the mentions and include the referenced content in the context sent to the AI.
Try using @ mentions in your next conversation with Cline - you'll be amazed at how much more efficient and effective your interactions become when you can seamlessly bring in external context.
## How It Works Under the Hood
When you use @ mentions in your messages, there's a sophisticated process happening behind the scenes:
1. **Detection**: When you send a message, Cline scans the text for @ mention patterns using regular expressions
2. **Processing**: For each detected mention, Cline:
- Determines the mention type (file, folder, problems, terminal, git, URL)
- Fetches the relevant content (file contents, terminal output, etc.)
- Formats the content appropriately
3. **Enhancement**: The original message is enhanced with structured data:
```
Your original message with @/path/to/file
<file_content path="/path/to/file">
[Complete file content]
</file_content>
```
4. **Context Inclusion**: This enhanced message with all the embedded content is sent to the AI model
5. **Seamless Response**: The AI can now "see" all the referenced content as if you had manually copied and pasted it
This entire process happens automatically and seamlessly whenever you use @ mentions, giving the AI complete context without you having to manually copy anything.
Each type of @ mention has its own specific implementation details, which you can find in their respective documentation pages.
The problems mention gives Cline instant access to all the errors and warnings in your workspace. Just type `@problems` and Cline can see every diagnostic issue VSCode has detected.
When you type `@` in chat, select "Problems" from the menu or just type `@problems` directly. Cline will immediately see all the errors and warnings from your workspace, complete with file locations and error messages.
I use the problems mention constantly when I'm stuck on build errors or TypeScript issues. Instead of trying to describe the errors or copy them one by one, I just ask:
```
I'm getting these TypeScript errors and I'm not sure how to fix them: @problems
Can you help me understand what's wrong and how to fix it?
```
This gives Cline the complete list of errors with their exact locations and messages. Cline can then analyze the patterns across multiple errors and suggest comprehensive solutions.
The problems mention is especially powerful when combined with file mentions. When I'm dealing with complex type errors, I'll reference both:
```
I'm getting these type errors: @problems
Here's my component: @/src/components/DataTable.tsx
And the types file: @/src/types/api.ts
How can I fix these issues?
```
This approach gives Cline everything it needs - the exact errors, the component code, and the type definitions - all without me having to copy anything manually.
Next time you're stuck on errors, try using `@problems` instead of copying error messages. You'll get more accurate help because Cline can see the complete error context and locations.
## How It Works Under the Hood
When you use the problems mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@problems` pattern in your text
2. The extension calls VSCode's built-in `vscode.languages.getDiagnostics()` API to get all errors and warnings
3. It formats these diagnostics into a structured text representation with file paths, line numbers, and error messages
4. The formatted problems list is appended to your message in a structured format:
```
<workspace_diagnostics>
/path/to/file.js:10:5 - error TS2322: Type 'string' is not assignable to type 'number'.
/path/to/file.js:15:3 - warning: This variable is never used.
</workspace_diagnostics>
```
5. This enhanced message with the embedded diagnostics is sent to the AI
6. The AI can now "see" all the errors and warnings in your workspace, complete with their locations and messages
This process happens automatically whenever you use the problems mention, giving the AI a comprehensive view of all the issues in your workspace without you having to copy them manually.
The terminal mention lets you bring your terminal output directly into your conversation with Cline. Just type `@terminal` and Cline can see the recent output from your terminal.
When you type `@` in chat, select "Terminal" from the menu or just type `@terminal` directly. Cline will immediately see the recent output from your active terminal, including error messages, build logs, or command results.
I use the terminal mention all the time when I'm dealing with build errors, test failures, or debugging output. Instead of trying to copy and paste terminal output (which often loses formatting), I just ask:
```
I'm getting this error when running my tests: @terminal
What's causing this and how can I fix it?
```
This gives Cline the complete terminal output with all its formatting intact. Cline can then analyze the error messages, stack traces, and surrounding context to provide more accurate help.
The terminal mention is especially powerful when combined with file mentions. When I'm debugging a failed API call, I'll reference both:
```
I'm getting this error when calling my API: @terminal
Here's my API client code: @/src/api/client.js
And the endpoint implementation: @/src/server/routes/users.js
What am I doing wrong?
```
This approach gives Cline everything it needs - the exact error output, the client code, and the server implementation - all without me having to copy anything manually.
Next time you're running into issues with command output or build errors, try using `@terminal` instead of copying the output. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
## How It Works Under the Hood
When you use the terminal mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@terminal` pattern in your text
2. The extension calls `getLatestTerminalOutput()` which accesses VSCode's terminal API
3. It captures the recent output buffer from your active terminal
4. The terminal output is appended to your message in a structured format:
```
<terminal_output>
$ npm run test
> project@1.0.0 test
> jest
FAIL src/components/__tests__/Button.test.js
● Button component › renders correctly
[Complete terminal output with formatting preserved]
</terminal_output>
```
5. This enhanced message with the embedded terminal output is sent to the AI
6. The AI can now "see" the complete terminal output with all formatting preserved
This process happens automatically whenever you use the terminal mention, giving the AI access to your command results, error messages, and other terminal output without you having to copy it manually.
URL mentions let you bring web content directly into your conversation with Cline. Just type `@` followed by any URL, and Cline can see the content of that webpage without you having to copy and paste anything.
When you type `@` in chat followed by a URL (like `@https://example.com`), Cline will fetch the content of that webpage and include it in the context. This works for documentation pages, GitHub issues, Stack Overflow questions, or any other web content you want to reference.
I use URL mentions constantly when I'm working with external APIs or libraries. Instead of trying to explain how an API works or copying documentation snippets, I just reference the docs directly:
```
I'm trying to implement authentication with this API: @https://api.example.com/docs/auth
Can you help me write the code to get an access token based on these docs?
```
This gives Cline the complete documentation page, so it can see all the authentication requirements, endpoints, parameters, and examples. Cline can then provide more accurate and comprehensive help based on the official documentation.
URL mentions are especially useful for referencing GitHub issues or discussions:
```
I'm trying to fix this issue in our project: @https://github.com/our-org/our-repo/issues/123
Here's my current implementation: @/src/components/Feature.jsx
What changes do I need to make to address the issue?
```
This shows Cline the complete GitHub issue, including the description, comments, and any code snippets or screenshots. Cline can then help you implement a solution that directly addresses the reported issue.
Next time you're working with external documentation or online resources, try using URL mentions instead of copying and pasting content. You'll get more accurate help because Cline can see the complete context of the webpage, including formatting, code examples, and surrounding information.
## How It Works Under the Hood
When you use a URL mention in your message, here's what happens behind the scenes:
1. When you send your message, Cline detects the `@http://...` or `@https://...` pattern in your text
2. The extension launches a headless browser (Puppeteer) in the background
3. It navigates to the URL and waits for the page to load completely
4. The browser captures the page content, including text, formatting, and code examples
5. The content is converted to a Markdown format that preserves the structure
6. This content is appended to your message in a structured format:
```
<url_content url="https://example.com/docs">
# Example API Documentation
## Authentication
To authenticate with the API, you need to...
const token = await api.authenticate({
username: 'user',
password: 'pass'
});
[Complete webpage content in Markdown format]
</url_content>
```
7. The browser is then closed to free up resources
8. This enhanced message with the embedded webpage content is sent to the AI
This process happens automatically whenever you use a URL mention, giving the AI access to the complete content of the webpage without you having to copy and paste anything.
By default, Cline will ask for your permission before calling any tool, including reading or writing files.
If you want to allow Cline to do something without asking, you can set the Auto Approve permission for that tool.
## Permission Options
- **Read project files**
- Allows Cline to read files within your current workspace without asking
- **Read all files**
- Extends read permission to files outside your workspace (system files, config files, etc.)
- **Edit project files**
- Allows Cline to modify files within your current workspace without confirmation
- **Edit all files**
- Extends modification permission to files outside your workspace
- **Execute safe commands**
- Allows execution of terminal commands that the model deems non-destructive
- **Execute all commands**
- Permits execution of any terminal command without asking
- **Use the browser**
- Allows Cline to use the browser tool to fetch web content
- **Use MCP servers**
- Permits connection to and usage of MCP servers for extended functionality
- **Maximum requests**
- Sets the number of consecutive automated actions Cline can take before requiring your input
## Best Practices
Personally, I like to keep auto-editing disabled because it gives me a chance to review changes every step of the way.
For most serious development workflows, I recommend starting with:
- Auto-approving read access to project files
- Setting a reasonable maximum request limit (10-20)
This gives Cline enough freedom to explore your codebase without constant interruptions, while still requiring permission for edits or potentially destructive actions.
As you build more trust in Cline's capabilities with your specific projects, you can gradually increase the permissions to match your comfort level.
Remember that you can always adjust these settings as your needs change - tighten permissions for critical production work, or loosen them when prototyping and exploring.
You can even use the quick "star" actions to quickly toggle your auto-approved selections on and off as you go.
Checkpoints automatically save snapshots of your workspace after each step in a task. This feature lets you track changes, roll back when needed, and experiment confidently with your code.
## How Checkpoints Work
Cline creates a checkpoint after each tool use (file edits, commands, etc.). These checkpoints:
- Work alongside your Git workflow without interference
- Maintain context between restores
- Use a shadow Git repository to track changes
For example, if you're working on a feature and Cline makes multiple file changes, each change creates a checkpoint. This means you can review each modification and, if needed, roll back to any point without affecting your main Git repository.
## Viewing Changes & Restoring
After each tool use, you can:
1. Click the "Compare" button to see modified files
2. Click the "Restore" button to open restore options
- **Restore Workspace Only**: Reset codebase while preserving task context
Example: If Cline makes changes you don't like while styling a component, you can use "Restore Workspace Only" to revert the code changes while keeping the conversation context, allowing you to try a different approach.
<Frame caption="Reverting both codebase and task to before any changes were made to start fresh">
Checkpoints let you be more experimental with Cline. While human coding is often methodical and iterative, AI can make substantial changes quickly. Checkpoints help you track these changes and revert if needed.
### Using Auto-Approve Mode
- Provides safety net for rapid iterations
- Makes it easy to undo unexpected results
### Testing Different Approaches
- Try multiple solutions confidently
- Compare different implementations
- Quickly revert to working states
- Ideal for exploring different design patterns or architectural approaches
## Best Practices
1. Use checkpoints as safety nets when experimenting
2. Leverage auto-approve mode more confidently, knowing you can always roll back
3. Restore selectively based on needs:
- Use "Restore Task and Workspace" for a fresh start
- Use "Restore Task Only" to try different prompts, but keep file changes
- Use "Restore Workspace Only" to attempt different implementations while preserving conversation context
## Relationship with Message Editing
The [message editing feature](/features/editing-messages) uses checkpoints under the hood when you select the "Restore All" option. This allows you to not only edit and resubmit your message but also restore your workspace to the state it was in at that point in the conversation.
## Deleting Checkpoints
You can delete all checkpoints by using the **"Delete All History"** button in the task history menu. Note that this will also delete all tasks. Checkpoints are stored in VS Code's globalStorage.
Cline Rules allow you to provide Cline with system-level guidance. Think of them as a persistent way to include context and preferences for your projects or globally for every conversation.
## Creating a Rule
You can create a rule by clicking the `+` button in the Rules tab. This will open a new file in your IDE which you can use to write your rule.
<Frame>
<img src="https://storage.googleapis.com/cline_public_images/docs/assets/cline-rules.png" alt="Create a Rule" />
</Frame>
Once you save the file:
- Your rule will be stored in the `.clinerules/` directory in your project (if it's a Workspace Rule)
- Or in the `Documents/Cline/Rules` directory (if it's a Global Rule).
You can also have Cline create a rule for you by using the [`/newrule` slash command](/features/slash-commands/new-rule) in the chat.
```markdown Example Cline Rule Structure [expandable]
# Project Guidelines
## Documentation Requirements
- Update relevant documentation in /docs when modifying features
- Keep README.md in sync with new capabilities
- Maintain changelog entries in CHANGELOG.md
## Architecture Decision Records
Create ADRs in /docs/adr for:
- Major dependency changes
- Architectural pattern changes
- New integration patterns
- Database schema changes
Follow template in /docs/adr/template.md
## Code Style & Patterns
- Generate API clients using OpenAPI Generator
- Use TypeScript axios template
- Place generated code in /src/generated
- Prefer composition over inheritance
- Use repository pattern for data access
- Follow error handling pattern in /src/utils/errors.ts
## Testing Standards
- Unit tests required for business logic
- Integration tests for API endpoints
- E2E tests for critical user flows
```
### Key Benefits
1. **Version Controlled**: The `.clinerules` file becomes part of your project's source code
2. **Team Consistency**: Ensures consistent behavior across all team members
3. **Project-Specific**: Rules and standards tailored to each project's needs
4. **Institutional Knowledge**: Maintains project standards and practices in code
Place the `.clinerules` file in your project's root directory:
```
your-project/
├── .clinerules
├── src/
├── docs/
└── ...
```
Cline's system prompt, on the other hand, is not user-editable ([here's where you can find it](https://github.com/cline/cline/blob/main/src/core/prompts/system.ts)). For a broader look at prompt engineering best practices, check out [this resource](https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview).
### Tips for Writing Effective Cline Rules
- Be Clear and Concise: Use simple language and avoid ambiguity.
- Focus on Desired Outcomes: Describe the results you want, not the specific steps.
- Test and Iterate: Experiment to find what works best for your workflow.
│ └── current-sprint.md # Rules specific to current work
├── src/
└── ...
```
Cline automatically processes **all Markdown files** inside the `.clinerules/` directory, combining them into a unified set of rules. The numeric prefixes (optional) help organize files in a logical sequence.
#### Using a Rules Bank
For projects with multiple contexts or teams, maintain a rules bank directory:
```
your-project/
├── .clinerules/ # Active rules - automatically applied
│ ├── 01-coding.md
│ └── client-a.md
│
├── clinerules-bank/ # Repository of available but inactive rules
│ ├── clients/ # Client-specific rule sets
│ │ ├── client-a.md
│ │ └── client-b.md
│ ├── frameworks/ # Framework-specific rules
│ │ ├── react.md
│ │ └── vue.md
│ └── project-types/ # Project type standards
│ ├── api-service.md
│ └── frontend-app.md
└── ...
```
#### Benefits of the Folder Approach
1. **Contextual Activation**: Copy only relevant rules from the bank to the active folder
2. **Easier Maintenance**: Update individual rule files without affecting others
3. **Team Flexibility**: Different team members can activate rules specific to their current task
4. **Reduced Noise**: Keep the active ruleset focused and relevant
- Keep individual rule files focused on specific concerns
- Use descriptive filenames that clearly indicate the rule's purpose
- Consider git-ignoring the active `.clinerules/` folder while tracking the `clinerules-bank/`
- Create team scripts to quickly activate common rule combinations
The folder system transforms your Cline rules from a static document into a dynamic knowledge system that adapts to your team's changing contexts and requirements.
### Managing Rules with the Toggleable Popover
To make managing both single `.clinerules` files and the folder system even easier, Cline v3.13 introduces a dedicated popover UI directly accessible from the chat interface.
Located conveniently under the chat input field, this popover allows you to:
- **Instantly See Active Rules:** View which global rules (from your user settings) and workspace rules (`.clinerules` file or folder contents) are currently active.
- **Quickly Toggle Rules:** Enable or disable specific rule files within your workspace `.clinerules/` folder with a single click. This is perfect for activating context-specific rules (like `react-rules.md` or `memory-bank.md`) only when needed.
- **Easily Add/Manage Rules:** Quickly create a workspace `.clinerules` file or folder if one doesn't exist, or add new rule files to an existing folder.
This UI significantly simplifies switching contexts and managing different sets of instructions without needing to manually edit files or configurations during a conversation.
Cline's code commands bring AI assistance directly into your editor, letting you interact with your code without leaving your workflow. With a simple right-click, you can add code to Cline, and through the lightbulb menu, you can fix errors, get explanations, or improve your code.
## Available Code Commands
When you interact with code in your editor, you can access Cline commands in two ways:
### Right-Click Context Menu
When you right-click on selected code, you'll see:
The "Fix with Cline" command appears in the lightbulb menu when your code has errors or warnings. This command:
1. Captures the selected code
2. Identifies the errors or warnings from VSCode's diagnostics
3. Sends both to Cline with a request to fix the issues
4. Provides a solution that addresses the specific problems
This is incredibly useful for quickly resolving syntax errors, linter warnings, or type issues without having to manually describe the problem.
#### Explain with Cline
The "Explain with Cline" command helps you understand complex code. When you select code and use this command from the lightbulb menu, Cline:
1. Analyzes the selected code
2. Provides a clear explanation of what the code does
3. Breaks down complex logic into understandable parts
4. Highlights important patterns or techniques used
#### Improve with Cline
The "Improve with Cline" command helps you enhance your code. When you select code and use this command from the lightbulb menu, Cline:
1. Analyzes the selected code for potential improvements
2. Suggests optimizations, refactorings, or better practices
3. Explains the reasoning behind the suggested changes
4. Provides improved code that maintains the original functionality
## How to Use Code Commands
Using Cline's code commands is simple:
### For Right-Click Commands:
1. Select the code you want to work with
2. Right-click to open the context menu
3. Choose "Add to Cline"
4. View the result in the Cline chat panel
### For Lightbulb Menu Commands:
1. Select the code you want to work with
2. Look for the lightbulb icon that appears in the editor gutter
3. Click the lightbulb to see available actions
4. Choose the appropriate Cline command (Fix, Explain, or Improve)
5. View the result in the Cline chat panel
After using any command, you can:
- Ask follow-up questions
- Request modifications to the solution
- Apply the changes back to your code
## How It Works Under the Hood
When you use a code command, here's what happens behind the scenes:
1. **Code Selection**: The extension captures your selected code and its context
2. **Metadata Collection**: Cline gathers important metadata:
- File path and name
- Programming language
- Any associated diagnostics (errors/warnings)
- Surrounding code context when relevant
3. **Command Processing**:
- For "Add to Cline," the code is formatted and sent to the chat panel
- For "Fix with Cline," the code and diagnostics are analyzed and a fix is generated
- For "Explain with Cline," the code is analyzed to provide a clear explanation
- For "Improve with Cline," the code is analyzed for potential optimizations and improvements
4. **Integration with Chat**: The results appear in the Cline chat panel, where you can:
- See the AI's response
- Ask follow-up questions
- Apply suggested changes
This seamless integration between your editor and Cline's AI capabilities makes it easy to get assistance without disrupting your coding flow.
## Tips for Effective Use
- **Select complete logical units**: When possible, select entire functions, classes, or modules to give Cline complete context
- **Include imports**: For language-specific help, include relevant imports so Cline understands dependencies
- **Combine with @ mentions**: For complex issues, use code commands along with file or problem mentions for more context
- **Use keyboard shortcuts**: Speed up your workflow by [assigning keyboard shortcuts](/features/commands-and-shortcuts/keyboard-shortcuts) to common code commands
Next time you're struggling with a piece of code, try using Cline's code commands instead of switching to a separate chat interface. You'll be amazed at how much more efficient your workflow becomes when AI assistance is integrated directly into your editor.
When you use Cline's commit message generation feature, here's what happens behind the scenes:
1. Cline retrieves the current Git diff using `getWorkingState()`
2. It formats this diff into a specialized prompt for the AI
3. The AI analyzes the changes and generates an appropriate commit message
4. The message is extracted and inserted into the Git commit message input box
This process uses your current Cline API configuration, so the quality of the generated messages matches your chosen AI model.
## Tips for Effective Use
- **Generate commit messages for complex changes**: The AI excels at summarizing multiple related changes into a coherent message.
- **Review and edit generated messages**: While the AI generates high-quality messages, it's always good practice to review and adjust them if needed.
- **Stage related changes together**: For the best results, stage related changes together so the AI can generate a cohesive message.
- **Use for consistent commit history**: Using the generate commit message feature helps maintain a consistent style across your commit history.
## How It Works Under the Hood
The commit message generation leverages VSCode's Git extension API to access repository information:
1. When you trigger the command:
- Cline gets the current diff
- It sends this to the AI with specific instructions for commit message formatting
- It parses the AI's response
- It accesses the Git extension API to set the commit message
This integration with Git makes it easy to generate high-quality commit messages without disrupting your workflow.
Next time you're struggling to write a good commit message, try using Cline's commit message generation. You'll save time and improve your version control workflow with AI assistance right where you need it.
Cline's keyboard shortcuts let you access AI assistance without taking your hands off the keyboard. Speed up your workflow by using hotkeys for common Cline actions.
## Default Keyboard Shortcuts
Cline comes with the following built-in keyboard shortcuts to streamline your workflow:
| Open Cline Sidebar | `Ctrl+Shift+C` / `Cmd+Shift+C` | `claude-dev.SidebarProvider.focus` | Opens the Cline sidebar panel |
| New Task | `Alt+N` | `cline.plusButtonClicked` | Starts a new Cline task |
| Add Terminal to Cline | `Alt+T` | `cline.addTerminalOutputToChat` | Adds terminal output to Cline |
| Clear Current Task | `Alt+C` | (Requires custom keybinding to UI action) | Clears the current task |
## Keyboard-Only Workflow
With the right shortcuts, you can use Cline without ever touching the mouse:
1. Select code with keyboard navigation (`Shift+Arrow` keys)
2. Send to Cline with `Ctrl+'` / `Cmd+'`
3. Type your question and press Enter
4. Review the response and apply suggestions
## Editor Integration Shortcuts
Cline's keyboard shortcuts integrate seamlessly with VSCode's built-in shortcuts:
- Use VSCode's selection shortcuts (`Ctrl+L` / `Cmd+L` to select line, etc.) before sending code to Cline
- Combine with VSCode's split editor shortcuts to view code and Cline side by side
- Use VSCode's terminal focus shortcut (`` Ctrl+` `` / `` Cmd+` ``) before capturing terminal output
## Tips for Effective Use
- **Learn the default shortcut first**: The `Ctrl+'` / `Cmd+'` shortcut is versatile - it adds selected code to chat when text is selected, or focuses the chat input when nothing is selected
- **Create muscle memory**: Use keyboard shortcuts consistently to build habits
- **Customize for your workflow**: Assign shortcuts to commands you use frequently
- **Consider ergonomics**: Choose shortcuts that are comfortable for your keyboard layout
Keyboard shortcuts may seem like a small optimization, but they can significantly speed up your workflow when using Cline regularly. By keeping your hands on the keyboard, you maintain your coding flow while still getting AI assistance exactly when you need it.
## How to Find All Available Commands
To see all Cline commands that can be assigned shortcuts:
1. Open the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`)
Cline integrates directly into VSCode's interface, letting you access AI assistance without disrupting your workflow. These integrations appear as commands in context menus, keyboard shortcuts, and quick fixes throughout the editor.
Editor integrations are commands and shortcuts that let you use Cline right where you're working. Instead of switching to the Cline panel first, you can select code, right-click, and immediately send it to Cline for help.
These integrations appear in different places throughout VSCode:
- In the editor context menu (right-click menu) - "Add to Cline"
- In the terminal context menu - "Add to Cline"
- In the Source Control view - "Generate Commit Message"
- As keyboard shortcuts - Various Cline commands
- As Quick Fix options (lightbulb menu) - "Fix with Cline", "Explain with Cline", "Improve with Cline"
### Available Editor Integrations
Cline offers several editor integrations, each designed to enhance different aspects of your development workflow:
Right-click on code to add it to Cline, or use the lightbulb menu to fix errors, explain code, or improve it. Cline sees the complete code context, including imports and surrounding functions.
Cline's terminal integration lets you bring your terminal output directly into your conversations with Cline. Instead of copying and pasting error messages or command results, you can send them to Cline with a simple right-click in the terminal.
When you're working in the VSCode terminal and see output you want to discuss with Cline:
1. Right-click in the terminal
2. Select "Add to Cline" from the context menu
3. The terminal output is immediately sent to the Cline chat panel
This is perfect for:
- Debugging build errors
- Understanding test failures
- Analyzing command output
- Getting help with error messages
The right-click terminal integration is especially useful when you're already working in the terminal and encounter an issue.
Instead of switching context to the Cline chat panel and typing a description of the problem, you can send the terminal output directly to Cline with just a couple of clicks.
Alternatively, you can use the [`@terminal`](/features/at-mentions/terminal-mentions) mention to send the full terminal output to Cline.
<Tip>
For information about using `@terminal` mentions in your chat messages, see the [Terminal
When you use the right-click terminal integration, Cline:
1. Captures the terminal output with all formatting preserved
2. Includes the complete context, including command history and results
3. Formats it appropriately for the AI to understand
4. Enables the AI to see exactly what you're seeing
This gives Cline the full context it needs to provide accurate help with terminal-related issues.
## Behind the Scenes
The terminal integration uses a clever technique to capture terminal output:
1. When you trigger the integration, Cline:
- Temporarily saves your current clipboard content
- Selects all terminal content (or uses your existing selection)
- Copies it to the clipboard
- Reads the clipboard to get the terminal content
- Restores your original clipboard content
2. The terminal content is then:
- Formatted with proper syntax highlighting
- Added to your message or sent as a new message
- Enhanced with additional context when needed
This approach ensures that all terminal output, including colors and formatting, is accurately captured without affecting your clipboard.
## Tips for Effective Use
- **Use terminal integration for error messages**: When you encounter an error in the terminal, sending it to Cline often results in faster resolution than trying to describe the error.
- **Select specific output when needed**: By default, the integration captures all terminal content, but you can also select specific lines before right-clicking to focus on just the relevant output.
- **Combine with file mentions**: After sending terminal output to Cline, you can enhance your question by mentioning relevant files using the @ mentions feature.
- **Use for build and test output**: Terminal integration is particularly useful for understanding complex build errors or test failures that span multiple lines.
Next time you're staring at a cryptic error message in your terminal, try using Cline's terminal integration instead of copying and pasting. You'll get more accurate help because Cline can see the complete terminal context with proper formatting.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
celestial-vault