* since npm nightly worked, make npm main
* fix ripgrep, split npm and jetbrains packaging
* cli nightly package version update
---------
Co-authored-by: Andrei Edell <andrei@nugbase.com>
* style(docs): update background color scheme to neutral tones
Update documentation background colors from purple-tinted theme to neutral gray tones. Changed light mode from lavender (#F0E6FF) to off-white (#fafaf9) and dark mode from pure black (#000000) to dark gray (#0f0f0f) for improved visual consistency.
* refactor(docs): remove gradient decoration from theme config
Remove the "decoration": "gradient" property from the documentation
theme configuration. This simplifies the theme settings by removing
the gradient decoration option from the color configuration object.
* docs: change documentation font family to Geist Mono
Replace Roboto with Geist Mono as the default font family in the documentation configuration. This updates the visual styling of the documentation to use a monospace font, which may improve readability for code-heavy content.
* docs: update branding and restructure navigation
- Replace robot panel logos with new Cline brand logos
- Add icons to navbar links (Docs, GitHub, Discord)
- Restructure navigation from groups to tabs format
- Add icons to navigation items for improved UX
- Include new Docs link in navbar with book icon
This update modernizes the documentation appearance and improves navigation hierarchy for better user experience.
* docs: restructure navigation with hierarchical groups and pages
Restructured documentation navigation from flat menu to organized groups:
- Removed redundant "Docs" link from navbar
- Migrated from "menu" to "groups/pages" structure
- Added comprehensive page organization with nested groups:
* Introduction, Getting Started, Features
* Prompting Skills, Cline's Tools, Enterprise Solutions
* MCP Servers, Provider Configuration
- Organized features into logical subgroups (@ Mentions, Commands,
Customization, Slash Commands)
- Improved documentation discoverability and hierarchy
This change provides better content organization and easier navigation
for users exploring different aspects of Cline documentation.
* docs: remove contextual options from documentation config
Remove the contextual configuration section containing the "copy" option from docs.json. This simplifies the documentation configuration by removing unused contextual menu options.
* docs(multiroot): improve workspace documentation with limitations and technical details
- Add important note about experimental limitations affecting Cline rules and checkpoints
- Add "How it works" section explaining automatic workspace detection and tracking
- Reorganize technical behavior section with detailed subsections for workspace detection, path resolution, and command execution
- Document workspace hint syntax for explicit file references (@workspaceName:path)
- Standardize heading capitalization to sentence case for consistency
- Improve overall content organization and clarity for better user understanding
This update provides users with clearer information about the multiroot feature's current state, its limitations, and how to effectively use workspace hints when working with multiple project folders.
* docs: restructure overview page with enhanced visual layout
- Convert plain markdown sections to CardGroup and Card components with icons
- Add tabbed interface for Plan & Act Mode explanation
- Update description from "development assistant" to "coding agent"
- Reorganize content for improved readability and visual hierarchy
- Enhance feature presentations with icon-based cards
Improves user experience by transforming the overview documentation into a more visually appealing and scannable format using modern documentation components.
* docs: improve installation guide with enhanced structure and UX
Restructure the Cline installation documentation to improve readability and user experience:
- Add prominent note highlighting 2-minute installation time
- Convert prerequisites into visual card components for better clarity
- Transform installation steps into structured Step components for easier following
- Add manual installation instructions for JetBrains IDEs
- Include feature compatibility accordion for JetBrains users
- Enhance visual hierarchy with improved component usage (CardGroup, Steps, Accordion)
- Simplify language and improve descriptions throughout
This makes the installation process clearer for new users and reduces friction during onboarding.
* style(docs): remove text opacity reduction for better readability
* docs: refactor model selection guide with visual step-by-step instructions
- Replace tab-based layout with linear step-by-step flow
- Add screenshots for each configuration step (config, provider, API, model)
- Reorganize content structure for improved clarity and user experience
- Add quickstart options and streamlined provider recommendations
- Improve navigation with visual aids to help users configure Cline faster
* docs: add installation screenshots and context management guide
* docs: flatten provider config structure in documentation
Remove the "Alternative Providers" grouping and move all provider configuration pages (OpenRouter, Cerebras, DeepSeek, Groq, xAI Grok, Mistral AI, Doubao, Fireworks, and ZAI) to the main provider configuration list. This simplifies the documentation navigation by treating all providers equally rather than categorizing some as alternatives.
* docs: restructure context management docs and improve content clarity
**Changes:**
- Reorganized documentation structure by moving context management from
`/best-practices` to `/prompting` section for better categorization
- Added URL redirect to maintain backward compatibility for old links
- Updated navigation references in welcome page to point to new location
- Improved readability of context management explanations with more
narrative, conversational prose
- Enhanced context window documentation by adding cache tokens indicator
and using emoji-based formatting for better visual clarity
- Streamlined Cline Memory Bank setup instructions from 4 to 3 steps
- Updated context bar screenshot to use newer image asset
**Why:**
Better documentation organization and improved user experience through
clearer explanations of how Cline builds and manages context during tasks.
* docs(context-management): convert Quick Reference to Info component
Replace blockquote formatting with Info component for the Quick Reference
section in the context management documentation. This improves visual
presentation and maintains consistency with documentation standards.
Also removes trailing whitespace at the end of the file for cleaner
formatting.
* docs: add Cline Enterprise overview and restructure enterprise section
- Add comprehensive enterprise overview documentation covering security,
governance, observability, and developer experience features
- Rename "Enterprise & Security" navigation group to "Enterprise"
- Consolidate enterprise documentation by replacing 4 pages with 2:
new overview page and security concerns
- Document BYOI (Bring Your Own Inference), SSO authentication, and
role-based access control capabilities
This restructuring provides a clearer entry point for enterprise users
and consolidates previously scattered enterprise information into a
cohesive overview document.
* docs(enterprise): streamline enterprise overview and update font
- Change documentation font from Geist Mono to Geist Sans
- Add enterprise website link card for detailed information
- Remove Developer Experience, Proven at Scale, and Pricing sections
- Consolidate Flexible Inference section content
- Simplify enterprise overview to focus on core capabilities
These changes reduce redundancy by directing users to the enterprise
website for pricing and detailed features while keeping the docs
focused on technical implementation and core capabilities.
* clean-images
* Update docs/getting-started/installing-cline.mdx
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* Update docs/styles.css
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* docs(cline-cli): add platform availability warning to overview
Add a prominent warning callout indicating that Cline CLI is currently in preview and only supports macOS and Linux, with Windows support coming soon. This sets clear expectations for users about platform compatibility.
Also remove redundant introductory text in the "What you can build with this" section to improve content clarity.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
* WIP npm publish setup
* verbose startup + error if cline core not found
* working npm release
* modifications for linux npm package to work
* remove publish npm workflow for now
* readme & package.json tweaks
* fix old reference to compile-standalone-cli in test workflow
---------
Co-authored-by: Andrei Edell <andrei@nugbase.com>
* Fix check for debug build in package-standalone script
* Support node modules that include binaries
Add support to the scripts/package-standalone.js for node modules that use platform-specific binary modules.
By default the script bundles the module for all platforms, this can be disabled with -s for single platform builds.
The module for each platform will be bundled into standalone.zip in platform specific directories:
```
binaries/linux-arm64/node_modules
binaries/darwin-x64/node_modules
binaries/win32-x64/node_modules
binaries/darwin-arm64/node_modules
binaries/linux-x64/node_modules
```
When running cline-core add the correct directory to the NODE_PATH, e.g.
```
$ export NODE_PATH=./node_modules/:./binaries/darwin-arm64/node_modules/
cline:/tmp/1$ node cline-core.js
Loading stubs...
Finished loading stubs
Loading stub impls...
Finished loading stub impls...
Cline environment: production
XS variant configuration warnings: [
'Component overrides for unused components: TOOL_USE_SECTION, TOOLS_SECTION, MCP_SECTION, TODO_SECTION, FEEDBACK_SECTION',
'Missing recommended components: TOOL_USE_SECTION'
]
[2025-09-05T19:53:00.853] #bot.cline.server.ts Running standalone cline 0.0.1
[2025-09-05T19:53:00.854] #bot.cline.server.ts Using settings dir: /Users/sjf/.cline/data
Finished loading vscode context...
[2025-09-05T19:53:00.858] #bot.cline.server.ts
Starting cline-core service...
sjfsjf created DBBBBBBBBB: Database {
name: '/tmp/db.sql',
open: true,
inTransaction: false,
readonly: false,
memory: false
}
```
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Support node modules that include binaries
Add support to the scripts/package-standalone.js for node modules that use platform-specific binary modules.
By default the script bundles the module for all platforms, this can be disabled with -s for single platform builds.
The module for each platform will be bundled into standalone.zip in platform specific directories:
```
binaries/linux-arm64/node_modules
binaries/darwin-x64/node_modules
binaries/win32-x64/node_modules
binaries/darwin-arm64/node_modules
binaries/linux-x64/node_modules
```
When running cline-core add the correct directory to the NODE_PATH, e.g.
```
$ export NODE_PATH=./node_modules/:./binaries/darwin-arm64/node_modules/
cline:/tmp/1$ node cline-core.js
Loading stubs...
Finished loading stubs
Loading stub impls...
Finished loading stub impls...
Cline environment: production
XS variant configuration warnings: [
'Component overrides for unused components: TOOL_USE_SECTION, TOOLS_SECTION, MCP_SECTION, TODO_SECTION, FEEDBACK_SECTION',
'Missing recommended components: TOOL_USE_SECTION'
]
[2025-09-05T19:53:00.853] #bot.cline.server.ts Running standalone cline 0.0.1
[2025-09-05T19:53:00.854] #bot.cline.server.ts Using settings dir: /Users/sjf/.cline/data
Finished loading vscode context...
[2025-09-05T19:53:00.858] #bot.cline.server.ts
Starting cline-core service...
sjfsjf created DBBBBBBBBB: Database {
name: '/tmp/db.sql',
open: true,
inTransaction: false,
readonly: false,
memory: false
}
```
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Apply suggestion from @ellipsis-dev[bot]
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Remove test code
* Use the correct target directory for the binaries
The directory structure that the JB host expects is does
not exactly match ${arch}-${os}
* Update package-standalone script
Warn if there is module that needs binaries, but it is not being used.
Reset the binaries dir before packaging.
---------
Co-authored-by: ellipsis-dev[bot] <65095814+ellipsis-dev[bot]@users.noreply.github.com>
* Migrate to Biome for linting/formatting and simplify hooks
- Add biome.jsonc and @biomejs CLI; configure VS Code to use Biome for format/fix and imports
- Replace verbose Husky pre-commit with lint-staged runner
- Remove ESLint setup and custom rule package (no-direct-vscode-api) and its tests
- Update package.json/package-lock and webview-ui package to reflect tooling change
- Add VS Code host typings and grit definitions under src/hosts
Rationale: unify lint/format tooling, speed up pre-commit checks, and reduce maintenance overhead from custom ESLint rules.
* remove eslint dependencies
* preserve eslint rules
* clean up
* update files list
* add docs
* fix build
* clean up
* update VSCode API usage detection in Grit rule
This commit updates the Grit rule for detecting VSCode API usage:
- Narrow down the list of monitored VSCode API methods
- Add more specific diagnostic messages for direct API usage
- Introduce a new check for `workspaceFolders` property
- Exclude `src/extension.ts` from the Grit rule in Biome configuration
The changes aim to improve code abstraction and provide clearer guidance for replacing direct VSCode API calls.
* adds new cacheService rule
* add back pre-commit
* Remove ESLint custom rule and update linting references
Remove custom ESLint rule for VSCode state API enforcement along with its tests, remove ESLint extension recommendation, and update documentation to use generic "linter" terminology instead of ESLint-specific references.
* update vscode.d.ts for IntelliSense
* remove format on save
* clean up default values
* update to 2.1.4
* buf lint
* format
The vscode packager VCE has different logic that the npm module `ignore`, so it was not including the same files as VCE.
Just copy how VCE uses the .vscodeignore file in the packaging script.
Fix the ignore for demo.gif, it was still getting included because it was only matching demo.gif at the top level.
Also ignore .github and .husky.
* Package the same files for the standalone app and the extension
When packaging the standalone app use the same .vscodeignore that the vscode packager uses to decide which files to include.
Exclude extra files from the vscode extension that aren't needed: dist-standalone, old_docs and eslint-rules.
* Ignore the whole directory, not just the contents.
* Don't package .DS_Store files
* Update comment
* 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.
* 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
* 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
