mirror of
https://github.com/cline/cline.git
synced 2026-09-03 12:14:00 +08:00
Compare commits
77 Commits
v2.2.2-cli
...
v2.4.3-cli
| Author | SHA1 | Date | |
|---|---|---|---|
| ea65383e16 | |||
| b97d1487a7 | |||
| 091cf945e4 | |||
| df4f551ba7 | |||
| 88da4ddf89 | |||
| 93eb607e6d | |||
| 810b5b78f5 | |||
| 38ea422f6a | |||
| a7a35c0138 | |||
| 01547ba1f4 | |||
| 7f1632f09f | |||
| 1b0ab3d01b | |||
| dce0902596 | |||
| 9e7a30bd34 | |||
| 2b1b1d1cf2 | |||
| fcf3792f63 | |||
| 0e833ade82 | |||
| 4455db5198 | |||
| 03ab2968a6 | |||
| a0d52d4d59 | |||
| 75fbeb4aad | |||
| 70db6bde34 | |||
| 02c2601e0e | |||
| 94692b5091 | |||
| a2794c680f | |||
| 6d3f8e1d5d | |||
| 3e5847890b | |||
| 0eab54ab12 | |||
| 7fa0a4924b | |||
| 8680218e0e | |||
| 8787ab35b9 | |||
| 6ed3944f04 | |||
| 1dd8e763d1 | |||
| 28e6297769 | |||
| 5a2a5d1c0a | |||
| 113039a259 | |||
| 4023c18257 | |||
| 7c95b53892 | |||
| 9fd2b99be4 | |||
| 7c782abaf4 | |||
| 3a14a88f4f | |||
| 28d60a83a4 | |||
| ae6468b161 | |||
| af93e31862 | |||
| ca154eb8f5 | |||
| 1d8497c6bf | |||
| 5871fd02b1 | |||
| 2d81c310d2 | |||
| 0c691f72d2 | |||
| a8409137b3 | |||
| 34a21b8e26 | |||
| eb9f53edf4 | |||
| c60f18d907 | |||
| 36c68a6ab9 | |||
| 80dfce0f60 | |||
| 955ae2f62f | |||
| 8cb0c6d236 | |||
| bb05b2f7b0 | |||
| 1a911f4232 | |||
| 1cfd560921 | |||
| 203ff8f549 | |||
| e920f1de02 | |||
| b266475d0a | |||
| 402361c482 | |||
| e884699d24 | |||
| f59d950ac6 | |||
| d2e4f1c7b9 | |||
| 49975fd0a3 | |||
| c0020e10b1 | |||
| 8dc5e15ee0 | |||
| 276cb4c3a4 | |||
| 8169abbc74 | |||
| a47ad46824 | |||
| 7896e6d896 | |||
| 166ec38d26 | |||
| e44ea9d772 | |||
| fcca1d4fe3 |
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: create-pull-request
|
||||
description: Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, and PR creation using the gh CLI tool.
|
||||
description: Create a GitHub pull request following project conventions. Use when the user asks to create a PR, submit changes for review, or open a pull request. Handles commit analysis, branch management, PR template usage, and PR creation using the gh CLI tool.
|
||||
---
|
||||
|
||||
# Create Pull Request
|
||||
@@ -1,8 +0,0 @@
|
||||
# Changesets
|
||||
|
||||
Hello and welcome! This folder has been automatically generated by `@changesets/cli`, a build tool that works
|
||||
with multi-package repos, or single-package repos to help you version and publish your code. You can
|
||||
find the full documentation for it [in our repository](https://github.com/changesets/changesets)
|
||||
|
||||
We have a quick list of common questions to get you started engaging with this project in
|
||||
[our documentation](https://github.com/changesets/changesets/blob/main/docs/common-questions.md)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"cline": minor
|
||||
---
|
||||
|
||||
Adds Messages API support to Oracle Code Assist, adding functionality for Claude models
|
||||
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"$schema": "https://unpkg.com/@changesets/config@3.0.5/schema.json",
|
||||
"changelog": "@changesets/cli/changelog",
|
||||
"commit": false,
|
||||
"fixed": [],
|
||||
"linked": [],
|
||||
"access": "restricted",
|
||||
"baseBranch": "main",
|
||||
"updateInternalDependencies": "patch",
|
||||
"ignore": []
|
||||
}
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"cline": patch
|
||||
---
|
||||
|
||||
Add /q command to quit CLI
|
||||
@@ -1,5 +0,0 @@
|
||||
---
|
||||
"claude-dev": patch
|
||||
---
|
||||
|
||||
Add .agents/skills as default skill directory (global and local)
|
||||
@@ -1,10 +0,0 @@
|
||||
---
|
||||
"claude-dev": patch
|
||||
---
|
||||
|
||||
Add comprehensive LLM evaluation framework with CI integration
|
||||
|
||||
- Smoke tests: 7 curated scenarios testing tools across providers (Claude, GPT-5, Gemini)
|
||||
- Analysis framework: pass@k metrics for measuring reliability
|
||||
- CI workflow: Parallel smoke tests on PRs with ~3min execution time
|
||||
- E2E runner: cline-bench integration for real-world task evaluation (local only for now)
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"claude-dev": patch
|
||||
---
|
||||
|
||||
Fix a streaming crash when a chunk has usage data but no `delta` by guarding reasoning field checks in provider handlers. Add regression tests for OpenRouter, Cline, Vercel AI Gateway, and Fireworks handlers to cover usage-only chunks.
|
||||
@@ -0,0 +1,4 @@
|
||||
"claude-dev": patch
|
||||
---
|
||||
|
||||
Add missing smoke evaluation npm scripts so documented commands like `npm run eval:smoke:run` work from the repository root.
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"cline": patch
|
||||
---
|
||||
|
||||
Add automatic retries (up to 3 attempts) for smoke test CI jobs to reduce flaky failures
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"cline": patch
|
||||
---
|
||||
|
||||
fix acp auth check so acp mode can be used with more providers
|
||||
@@ -0,0 +1,5 @@
|
||||
---
|
||||
"claude-dev": patch
|
||||
---
|
||||
|
||||
Update SambaNova Provider models list and add temperature for models
|
||||
@@ -1,26 +0,0 @@
|
||||
changesDir: .changes
|
||||
unreleasedDir: unreleased
|
||||
headerPath: header.tpl.md
|
||||
changelogPath: CHANGELOG.md
|
||||
versionExt: md
|
||||
versionFormat: '## {{.Version}} - {{.Time.Format "2006-01-02"}}'
|
||||
kindFormat: "### {{.Kind}}"
|
||||
changeFormat: "* {{.Body}}"
|
||||
kinds:
|
||||
- label: Added
|
||||
auto: minor
|
||||
- label: Changed
|
||||
auto: major
|
||||
- label: Deprecated
|
||||
auto: minor
|
||||
- label: Removed
|
||||
auto: major
|
||||
- label: Fixed
|
||||
auto: patch
|
||||
- label: Security
|
||||
auto: patch
|
||||
newlines:
|
||||
afterChangelogHeader: 1
|
||||
beforeChangelogVersion: 1
|
||||
endOfVersion: 1
|
||||
envPrefix: CHANGIE_
|
||||
@@ -14,7 +14,7 @@ This file is the secret sauce for working effectively in this codebase. It captu
|
||||
|
||||
## Miscellaneous
|
||||
- This is a VS Code extension—check `package.json` for available scripts before trying to verify builds (e.g., `npm run compile`, not `npm run build`).
|
||||
- When creating PRs, if the change is user-facing and significant enough to warrant a changelog entry, run `npm run changeset` and create a patch changeset. Never create minor or major version bumps. Skip changesets for trivial fixes, internal refactors, or minor UI tweaks that users wouldn't notice.
|
||||
- When creating PRs, contributors should not create changelog-entry files. Maintainers handle release versioning and changelog curation during the release process.
|
||||
- When adding new feature flags, see this PR as a reference https://github.com/cline/cline/pull/7566
|
||||
- Additional instructions about making requests: @.clinerules/network.md
|
||||
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
# Storage Architecture
|
||||
|
||||
Global settings, secrets and workspace state are stored in **file-backed JSON stores** under `~/.cline/data/`. This is the shared storage layer used by VSCode, CLI, and JetBrains.
|
||||
|
||||
## Key Abstractions
|
||||
|
||||
### `StorageContext` (src/shared/storage/storage-context.ts)
|
||||
The entry point. Created via `createStorageContext()` and passed to `StateManager.initialize()`. Contains three `ClineFileStorage` instances:
|
||||
- `globalState` → `~/.cline/data/globalState.json`
|
||||
- `secrets` → `~/.cline/data/secrets.json` (mode 0o600)
|
||||
- `workspaceState` → `~/.cline/data/workspaces/<hash>/workspaceState.json`
|
||||
|
||||
### `ClineFileStorage` (src/shared/storage/ClineFileStorage.ts)
|
||||
Synchronous JSON key-value store backed by a single file. Supports `get()`, `set()`, `setBatch()`, `delete()`. Writes are atomic (write-then-rename).
|
||||
|
||||
### `StateManager` (src/core/storage/StateManager.ts)
|
||||
In-memory cache on top of `StorageContext`. All runtime reads hit the cache; writes update cache immediately and debounce-flush to disk.
|
||||
|
||||
## ⚠️ Do NOT Use VSCode's ExtensionContext for Storage
|
||||
|
||||
**Do not** read from or write to `context.globalState`, `context.workspaceState`, or `context.secrets` for persistent data. These are VSCode-specific and not available on CLI or JetBrains.
|
||||
|
||||
Instead, use:
|
||||
```typescript
|
||||
// Reading state
|
||||
StateManager.get().getGlobalStateKey("myKey")
|
||||
StateManager.get().getSecretKey("mySecretKey")
|
||||
StateManager.get().getWorkspaceStateKey("myWsKey")
|
||||
|
||||
// Writing state
|
||||
StateManager.get().setGlobalState("myKey", value)
|
||||
StateManager.get().setSecret("mySecretKey", value)
|
||||
StateManager.get().setWorkspaceState("myWsKey", value)
|
||||
```
|
||||
|
||||
Remember that your data may be read by a different client than the one that wrote it. For example, a value written by Cline in JetBrains may be read by Cline CLI.
|
||||
|
||||
## VSCode Migration (src/hosts/vscode/vscode-to-file-migration.ts)
|
||||
|
||||
On VSCode startup, a migration copies data from VSCode's `ExtensionContext` storage into the file-backed stores. This runs in `src/common.ts` before `StateManager.initialize()`.
|
||||
|
||||
- **Sentinel**: `__vscodeMigrationVersion` key in global state and workspace state — prevents re-migration.
|
||||
- **Merge strategy**: File store wins. Existing values are never overwritten.
|
||||
- **Safe downgrade**: VSCode storage is NOT cleared, so older extension versions still work.
|
||||
|
||||
## Adding New Storage Keys
|
||||
|
||||
1. Add to `src/shared/storage/state-keys.ts` (see existing patterns)
|
||||
2. Read/write via `StateManager` (NOT via `context.globalState`)
|
||||
3. If adding a secret, add to `SecretKeys` array in `state-keys.ts`
|
||||
|
||||
## File Layout
|
||||
|
||||
```
|
||||
~/.cline/
|
||||
data/
|
||||
globalState.json # Global settings & state
|
||||
secrets.json # API keys (mode 0o600)
|
||||
tasks/
|
||||
taskHistory.json # Task history (separate file)
|
||||
workspaces/
|
||||
<hash>/
|
||||
workspaceState.json # Per-workspace toggles
|
||||
```
|
||||
@@ -19,7 +19,7 @@ Review and address all comments on the current branch's PR.
|
||||
- Inline comments: `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments`
|
||||
- General comments: `gh pr view {pr_number} --json comments,reviews`
|
||||
|
||||
4. Present a summary of all comments with your recommendation for each (apply, skip, or respond). Ignore bot noise (changeset-bot, CI status, etc.).
|
||||
4. Present a summary of all comments with your recommendation for each (apply, skip, or respond). Ignore bot noise (release automation, CI status, etc.).
|
||||
|
||||
5. **Wait for my approval** before proceeding.
|
||||
|
||||
|
||||
@@ -1,549 +0,0 @@
|
||||
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!)
|
||||
- Fix @withRetry() decoration syntax error when running extension locally (Thanks @DaveFres!)
|
||||
- Fix for git commit mentions in repos with no git commits
|
||||
- Fix cost calculation (Thanks @BarreiroT!)
|
||||
</changelog>
|
||||
|
||||
|
||||
<announcement-component>
|
||||
const Announcement = ({ version, hideAnnouncement }: AnnouncementProps) => {
|
||||
const minorVersion = version.split(".").slice(0, 2).join(".") // 2.0.0 -> 2.0
|
||||
return (
|
||||
<div style={containerStyle}>
|
||||
<VSCodeButton appearance="icon" onClick={hideAnnouncement} style={closeIconStyle}>
|
||||
<span className="codicon codicon-close"></span>
|
||||
</VSCodeButton>
|
||||
<h3 style={h3TitleStyle}>
|
||||
🎉{" "}New in v{minorVersion}
|
||||
</h3>
|
||||
<ul style={ulStyle}>
|
||||
<li>
|
||||
<b>Gemini prompt caching:</b> Gemini and Vertex providers now support prompt caching and price tracking for
|
||||
Gemini models.
|
||||
</li>
|
||||
<li>
|
||||
<b>Copy Buttons:</b> Buttons were added to Markdown and Code blocks that allow you to copy their contents
|
||||
easily.
|
||||
</li>
|
||||
<li>
|
||||
<b>/newrule command:</b> New slash command to have cline write your .clinerules for you based on your
|
||||
workflow.
|
||||
</li>
|
||||
<li>
|
||||
<b>Drag and drop improvements:</b> Don't forget to hold shift while dragging files!
|
||||
</li>
|
||||
<li>Added more checkpoints across the task, allowing you to restore from more than just file changes.</li>
|
||||
<li>Added support for rendering LaTeX in message responses. (Try asking Cline to show the quadratic formula)</li>
|
||||
</ul>
|
||||
<Accordion isCompact className="pl-0">
|
||||
<AccordionItem
|
||||
key="1"
|
||||
aria-label="Previous Updates"
|
||||
title="Previous Updates:"
|
||||
classNames={{
|
||||
trigger: "bg-transparent border-0 pl-0 pb-0 w-fit",
|
||||
title: "font-bold text-(--vscode-foreground)",
|
||||
indicator:
|
||||
"text-(--vscode-foreground) mb-0.5 -rotate-180 data-[open=true]:-rotate-90 rtl:rotate-0 rtl:data-[open=true]:-rotate-90",
|
||||
}}>
|
||||
<ul style={ulStyle}>
|
||||
<li>
|
||||
<b>Global Cline Rules:</b> store multiple rules files in Documents/Cline/Rules to share between
|
||||
projects.
|
||||
</li>
|
||||
<li>
|
||||
<b>Cline Rules Popup:</b> New button in the chat area to view workspace and global cline rules files
|
||||
to plug and play specific rules for the task
|
||||
</li>
|
||||
<li>
|
||||
<b>Slash Commands:</b> Type <code>/</code> in chat to see the list of quick actions, like starting a
|
||||
new task (more coming soon!)
|
||||
</li>
|
||||
<li>
|
||||
<b>Edit Messages:</b> You can now edit a message you sent previously by clicking on it. Optionally
|
||||
restore your project when the message was sent!
|
||||
</li>
|
||||
</ul>
|
||||
</AccordionItem>
|
||||
</Accordion>
|
||||
|
||||
{/*
|
||||
// Leave this here for an example of how to structure the announcement
|
||||
<ul style={{ margin: "0 0 8px", paddingLeft: "12px" }}>
|
||||
<li>
|
||||
OpenRouter now supports prompt caching! They also have much higher rate limits than other providers,
|
||||
so I recommend trying them out.
|
||||
<br />
|
||||
{!apiConfiguration?.openRouterApiKey && (
|
||||
<VSCodeButtonLink
|
||||
href={getOpenRouterAuthUrl(vscodeUriScheme)}
|
||||
style={{
|
||||
transform: "scale(0.85)",
|
||||
transformOrigin: "left center",
|
||||
margin: "4px -30px 2px 0",
|
||||
}}>
|
||||
Get OpenRouter API Key
|
||||
</VSCodeButtonLink>
|
||||
)}
|
||||
{apiConfiguration?.openRouterApiKey && apiConfiguration?.apiProvider !== "openrouter" && (
|
||||
<VSCodeButton
|
||||
onClick={() => {
|
||||
vscode.postMessage({
|
||||
type: "apiConfiguration",
|
||||
apiConfiguration: { ...apiConfiguration, apiProvider: "openrouter" },
|
||||
})
|
||||
}}
|
||||
style={{
|
||||
transform: "scale(0.85)",
|
||||
transformOrigin: "left center",
|
||||
margin: "4px -30px 2px 0",
|
||||
}}>
|
||||
Switch to OpenRouter
|
||||
</VSCodeButton>
|
||||
)}
|
||||
</li>
|
||||
<li>
|
||||
<b>Edit Cline's changes before accepting!</b> When he creates or edits a file, you can modify his
|
||||
changes directly in the right side of the diff view (+ hover over the 'Revert Block' arrow button in
|
||||
the center to undo "<code>{"// rest of code here"}</code>" shenanigans)
|
||||
</li>
|
||||
<li>
|
||||
New <code>search_files</code> tool that lets Cline perform regex searches in your project, letting
|
||||
him refactor code, address TODOs and FIXMEs, remove dead code, and more!
|
||||
</li>
|
||||
<li>
|
||||
When Cline runs commands, you can now type directly in the terminal (+ support for Python
|
||||
environments)
|
||||
</li>
|
||||
</ul>*/}
|
||||
<div style={hrStyle} />
|
||||
<p style={linkContainerStyle}>
|
||||
Join us on{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://x.com/cline">
|
||||
X,
|
||||
</VSCodeLink>{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://discord.gg/cline">
|
||||
discord,
|
||||
</VSCodeLink>{" "}
|
||||
or{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://www.reddit.com/r/cline/">
|
||||
r/cline
|
||||
</VSCodeLink>
|
||||
for more updates!
|
||||
</p>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
</announcement-component>
|
||||
|
||||
- 3.13
|
||||
|
||||
<changeset>
|
||||
Minor Changes
|
||||
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
|
||||
- Fix token usage tracking issues with vertex provider (Thanks @mzsima!)
|
||||
- Fix issue with xAI reasoning content not being parsed (Thanks @mrubens!)
|
||||
</changelog>
|
||||
|
||||
<announcement-component>
|
||||
const Announcement = ({ version, hideAnnouncement }: AnnouncementProps) => {
|
||||
const minorVersion = version.split(".").slice(0, 2).join(".") // 2.0.0 -> 2.0
|
||||
return (
|
||||
<div style={containerStyle}>
|
||||
<VSCodeButton appearance="icon" onClick={hideAnnouncement} style={closeIconStyle}>
|
||||
<span className="codicon codicon-close"></span>
|
||||
</VSCodeButton>
|
||||
<h3 style={h3TitleStyle}>
|
||||
🎉{" "}New in v{minorVersion}
|
||||
</h3>
|
||||
<ul style={ulStyle}>
|
||||
<li>
|
||||
<b>Global Cline Rules:</b> store multiple rules files in Documents/Cline/Rules to share between projects.
|
||||
</li>
|
||||
<li>
|
||||
<b>Cline Rules Popup:</b> New button in the chat area to view workspace and global cline rules files to plug
|
||||
and play specific rules for the task
|
||||
</li>
|
||||
<li>
|
||||
<b>Slash Commands:</b> Type <code>/</code> in chat to see the list of quick actions, like starting a new task
|
||||
(more coming soon!)
|
||||
</li>
|
||||
<li>
|
||||
<b>Edit Messages:</b> You can now edit a message you sent previously by clicking on it. Optionally restore
|
||||
your project when the message was sent!
|
||||
</li>
|
||||
</ul>
|
||||
<h4 style={{ margin: "5px 0 5px" }}>Previous Updates:</h4>
|
||||
<ul style={ulStyle}>
|
||||
<li>
|
||||
<b>Model Favorites:</b> You can now mark your favorite models when using Cline & OpenRouter providers for
|
||||
quick access!
|
||||
</li>
|
||||
<li>
|
||||
<b>Faster Diff Editing:</b> Improved animation performance for large files, plus a new indicator in chat
|
||||
showing the number of edits Cline makes.
|
||||
</li>
|
||||
<li>
|
||||
<b>New Auto-Approve Options:</b> Turn off Cline's ability to read and edit files outside your workspace.
|
||||
</li>
|
||||
</ul>
|
||||
{/*
|
||||
// Leave this here for an example of how to structure the announcement
|
||||
<ul style={{ margin: "0 0 8px", paddingLeft: "12px" }}>
|
||||
<li>
|
||||
OpenRouter now supports prompt caching! They also have much higher rate limits than other providers,
|
||||
so I recommend trying them out.
|
||||
<br />
|
||||
{!apiConfiguration?.openRouterApiKey && (
|
||||
<VSCodeButtonLink
|
||||
href={getOpenRouterAuthUrl(vscodeUriScheme)}
|
||||
style={{
|
||||
transform: "scale(0.85)",
|
||||
transformOrigin: "left center",
|
||||
margin: "4px -30px 2px 0",
|
||||
}}>
|
||||
Get OpenRouter API Key
|
||||
</VSCodeButtonLink>
|
||||
)}
|
||||
{apiConfiguration?.openRouterApiKey && apiConfiguration?.apiProvider !== "openrouter" && (
|
||||
<VSCodeButton
|
||||
onClick={() => {
|
||||
vscode.postMessage({
|
||||
type: "apiConfiguration",
|
||||
apiConfiguration: { ...apiConfiguration, apiProvider: "openrouter" },
|
||||
})
|
||||
}}
|
||||
style={{
|
||||
transform: "scale(0.85)",
|
||||
transformOrigin: "left center",
|
||||
margin: "4px -30px 2px 0",
|
||||
}}>
|
||||
Switch to OpenRouter
|
||||
</VSCodeButton>
|
||||
)}
|
||||
</li>
|
||||
<li>
|
||||
<b>Edit Cline's changes before accepting!</b> When he creates or edits a file, you can modify his
|
||||
changes directly in the right side of the diff view (+ hover over the 'Revert Block' arrow button in
|
||||
the center to undo "<code>{"// rest of code here"}</code>" shenanigans)
|
||||
</li>
|
||||
<li>
|
||||
New <code>search_files</code> tool that lets Cline perform regex searches in your project, letting
|
||||
him refactor code, address TODOs and FIXMEs, remove dead code, and more!
|
||||
</li>
|
||||
<li>
|
||||
When Cline runs commands, you can now type directly in the terminal (+ support for Python
|
||||
environments)
|
||||
</li>
|
||||
</ul>*/}
|
||||
<div style={hrStyle} />
|
||||
<p style={linkContainerStyle}>
|
||||
Join us on{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://x.com/cline">
|
||||
X,
|
||||
</VSCodeLink>{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://discord.gg/cline">
|
||||
discord,
|
||||
</VSCodeLink>{" "}
|
||||
or{" "}
|
||||
<VSCodeLink style={linkStyle} href="https://www.reddit.com/r/cline/">
|
||||
r/cline
|
||||
</VSCodeLink>
|
||||
for more updates!
|
||||
</p>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
</announcement-component>
|
||||
|
||||
|
||||
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:
|
||||
```bash
|
||||
gh pr diff changeset-release/main > changeset-diff.txt
|
||||
cat changeset-diff.txt | grep -A 50 "CHANGELOG.md"
|
||||
```
|
||||
|
||||
## Initial Setup
|
||||
3. Once you're ready to start, checkout and update the changeset release branch:
|
||||
```bash
|
||||
git checkout changeset-release/main
|
||||
git pull origin changeset-release/main
|
||||
```
|
||||
|
||||
## Analyzing Each Change
|
||||
4. For each commit hash in the auto-generated changelog entries:
|
||||
|
||||
a. Find the PR number associated with a commit hash:
|
||||
```bash
|
||||
gh pr list --search "<commit-hash>" --state merged
|
||||
```
|
||||
|
||||
b. Get PR details for better context:
|
||||
```bash
|
||||
gh pr view <PR-number>
|
||||
```
|
||||
|
||||
c. Check if the contributor is external to determine if attribution is needed:
|
||||
```bash
|
||||
# Extract username from PR
|
||||
USERNAME=$(gh pr view <PR-number> --json author --jq .author.login)
|
||||
|
||||
# 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:
|
||||
```bash
|
||||
npm run install:all
|
||||
```
|
||||
|
||||
10. Commit your changes:
|
||||
```bash
|
||||
git add CHANGELOG.md package.json package-lock.json src/views/components/announcement.tsx
|
||||
git commit -m "Update CHANGELOG.md and announcement for version 3.16.0"
|
||||
```
|
||||
|
||||
11. Push your changes to the changeset branch:
|
||||
```bash
|
||||
git push origin changeset-release/main
|
||||
```
|
||||
|
||||
12. Check that your changes pushed successfully:
|
||||
```bash
|
||||
git status
|
||||
```
|
||||
</detailed_sequence_of_steps>
|
||||
@@ -89,16 +89,9 @@ On the main branch, create a commit that updates:
|
||||
|
||||
2. **package.json** - Update the version field to the new version
|
||||
|
||||
3. **Delete changesets** for the commits being included in the hotfix. This prevents the changeset bot from including duplicate entries in the next regular release.
|
||||
3. No changelog-entry file cleanup is needed. Contributors do not create changelog-entry files in this repo.
|
||||
|
||||
Find and delete the changeset files associated with the selected commits:
|
||||
```bash
|
||||
ls .changeset/
|
||||
```
|
||||
|
||||
Each changeset file in `.changeset/` corresponds to a PR. Read them to identify which ones belong to the commits you're hotfixing, then delete those files.
|
||||
|
||||
**Skip running `npm run install:all`** - the automation handles outdated lockfiles.
|
||||
**Skip running `npm run install:all`** - release automation handles lockfile consistency as needed.
|
||||
|
||||
Commit with message format: `v{VERSION} Release Notes (hotfix)`
|
||||
|
||||
@@ -107,7 +100,7 @@ In the commit body, mention:
|
||||
- List the cherry-picked commits that will be included
|
||||
|
||||
```bash
|
||||
git add CHANGELOG.md package.json .changeset/
|
||||
git add CHANGELOG.md package.json
|
||||
git commit -m "v3.40.1 Release Notes (hotfix)
|
||||
|
||||
Hotfix release including:
|
||||
|
||||
@@ -347,8 +347,6 @@ A few notes:
|
||||
So until the settings page is update, and this is added to settings in a way that's clean and doesn't confuse new users, I don't think we can merge this. Please bear with us.
|
||||
</request_changes_comment>
|
||||
<request_changes_comment>
|
||||
Also, don't forget to add a changeset since this fixes a user-facing bug.
|
||||
|
||||
The architectural change is solid - moving the focus logic to the command handlers makes sense. Just don't want to introduce subtle timing issues by removing those timeouts.
|
||||
</request_changes_comment>
|
||||
</example_comments_that_i_have_written_before>
|
||||
|
||||
@@ -1,232 +1,64 @@
|
||||
# Release
|
||||
|
||||
Prepare and publish a release from the open changeset PR.
|
||||
Prepare and publish a release directly from `main`.
|
||||
|
||||
## Overview
|
||||
|
||||
This workflow helps you:
|
||||
1. Find and checkout the open changeset PR
|
||||
2. Clean up the changelog (fix version format, wordsmith entries)
|
||||
3. Push changes back to the PR branch
|
||||
4. Merge with proper commit message format
|
||||
5. Tag and push the release (after verifying the commit)
|
||||
6. Trigger the publish workflow
|
||||
7. Update GitHub release notes
|
||||
8. Provide final summary with Slack announcement
|
||||
1. Select/confirm the target version
|
||||
2. Curate `CHANGELOG.md` entries manually for end users
|
||||
3. Ensure `package.json` version matches the changelog
|
||||
4. Create and push a release commit + tag
|
||||
5. Trigger publish workflow
|
||||
6. Update GitHub release notes and share a summary
|
||||
|
||||
## Step 1: Find the Changeset PR
|
||||
## Process
|
||||
|
||||
Look for the open changeset PR:
|
||||
|
||||
```bash
|
||||
gh pr list --search "Changeset version bump" --state open --json number,title,headRefName,url
|
||||
```
|
||||
|
||||
If no PR is found, inform the user there's no changeset PR ready. They may need to:
|
||||
- Merge PRs with changesets to main first
|
||||
- Manually trigger the Changeset Converter workflow at: https://github.com/cline/cline/actions/workflows/changeset-converter.yml
|
||||
|
||||
## Step 2: Gather PR Information
|
||||
|
||||
Get the PR details:
|
||||
|
||||
```bash
|
||||
PR_NUMBER=<number from step 1>
|
||||
gh pr view $PR_NUMBER --json body,files,headRefName
|
||||
```
|
||||
|
||||
Checkout the PR branch:
|
||||
|
||||
```bash
|
||||
git fetch origin changeset-release/main
|
||||
git checkout changeset-release/main
|
||||
```
|
||||
|
||||
If the branch has diverged from remote, reset to the remote version:
|
||||
|
||||
```bash
|
||||
git reset --hard origin/changeset-release/main
|
||||
```
|
||||
|
||||
## Step 3: Analyze the Changes
|
||||
|
||||
Read the current CHANGELOG.md to see what the automation generated:
|
||||
|
||||
```bash
|
||||
head -50 CHANGELOG.md
|
||||
```
|
||||
|
||||
Get the version from package.json:
|
||||
|
||||
```bash
|
||||
cat package.json | grep '"version"'
|
||||
```
|
||||
|
||||
**Present to the user:**
|
||||
- The version number that will be released
|
||||
- The raw changelog entries from the changeset PR
|
||||
- Whether this is a patch, minor, or major release
|
||||
|
||||
## Step 4: Clean Up the Changelog
|
||||
|
||||
The changelog needs these fixes:
|
||||
|
||||
1. **Add brackets to version number**: Change `## 3.44.1` to `## [3.44.1]`
|
||||
|
||||
2. **No category headers**: Don't use `### Added`, `### Fixed`, etc. Just a flat list of bullet points.
|
||||
|
||||
3. **Order entries from most important to least important**:
|
||||
- Lead with major new features or significant fixes users care about
|
||||
- End with minor fixes or internal changes
|
||||
|
||||
4. **Write user-friendly descriptions**:
|
||||
- This is for end users, not developers—explain what changed in plain language
|
||||
- Remove commit hashes from the beginning of lines (the automation adds these)
|
||||
- Look at the actual commit diffs (`git show <hash>`) and PRs to understand what changed
|
||||
- Write colorful descriptions that explain the value and impact, not just technical details
|
||||
- Consolidate related changes into single entries when appropriate
|
||||
|
||||
**Ask the user** to review the proposed changelog changes before applying them. Show them:
|
||||
- Current (raw) changelog section
|
||||
- Proposed (cleaned) changelog section
|
||||
|
||||
Once approved, apply the changes to CHANGELOG.md.
|
||||
|
||||
## Step 5: Commit and Push Changes
|
||||
|
||||
After making changelog edits:
|
||||
|
||||
```bash
|
||||
git add CHANGELOG.md
|
||||
git commit -m "Clean up changelog formatting"
|
||||
git push origin changeset-release/main
|
||||
```
|
||||
|
||||
## Step 6: Merge the PR
|
||||
|
||||
**Ask the user to confirm** they're ready to merge.
|
||||
|
||||
Merge the PR with the proper commit message format:
|
||||
|
||||
```bash
|
||||
VERSION=<version from package.json>
|
||||
gh pr merge $PR_NUMBER --squash --subject "v${VERSION} Release Notes" --body ""
|
||||
```
|
||||
|
||||
**If merge is blocked by branch protection:**
|
||||
- Users with admin privileges can add the `--admin` flag to bypass
|
||||
- Users without admin privileges need to get the PR approved through normal review first before merging
|
||||
|
||||
## Step 7: Tag the Release
|
||||
|
||||
After the merge completes, checkout main and pull:
|
||||
### 1) Sync and determine version
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull origin main
|
||||
cat package.json | grep '"version"'
|
||||
```
|
||||
|
||||
**IMPORTANT: Verify the latest commit is the release commit before tagging:**
|
||||
Confirm the release version with the maintainer (patch/minor/major).
|
||||
|
||||
### 2) Curate changelog and version
|
||||
|
||||
- Edit `CHANGELOG.md` for the target version using human-friendly release notes.
|
||||
- Ensure version headers use bracket format, e.g. `## [3.66.1]`.
|
||||
- Update `package.json` version to the same value.
|
||||
|
||||
### 3) Commit and tag
|
||||
|
||||
```bash
|
||||
git log -1 --oneline
|
||||
git add CHANGELOG.md package.json package-lock.json
|
||||
git commit -m "v<version> Release Notes"
|
||||
git push origin main
|
||||
git tag v<version>
|
||||
git push origin v<version>
|
||||
```
|
||||
|
||||
Confirm the commit message matches `v{VERSION} Release Notes` (e.g., `v3.44.1 Release Notes`). Do NOT blindly tag HEAD without verification.
|
||||
### 4) Trigger publish workflow
|
||||
|
||||
Once verified, tag and push:
|
||||
Tell the maintainer to run:
|
||||
https://github.com/cline/cline/actions/workflows/publish.yml
|
||||
|
||||
Use `v<version>` as the release tag.
|
||||
|
||||
### 5) Update GitHub release notes
|
||||
|
||||
After publish completes:
|
||||
|
||||
```bash
|
||||
VERSION=<version>
|
||||
git tag v${VERSION}
|
||||
git push origin v${VERSION}
|
||||
gh release view v<version> --json body --jq '.body'
|
||||
gh release edit v<version> --notes "<final curated release notes>"
|
||||
```
|
||||
|
||||
## Step 8: Trigger Publish Workflow
|
||||
### 6) Final summary
|
||||
|
||||
**Copy the tag to clipboard** so the user can easily paste it into the GitHub Actions workflow:
|
||||
|
||||
```bash
|
||||
echo -n "v{VERSION}" | pbcopy
|
||||
```
|
||||
|
||||
**Tell the user to trigger the publish workflow:**
|
||||
1. Go to: https://github.com/cline/cline/actions/workflows/publish.yml
|
||||
2. Select **"release"** for release-type
|
||||
3. Paste **`v{VERSION}`** as the tag (already in clipboard)
|
||||
|
||||
**Wait for the user** to confirm the publish workflow has completed before proceeding.
|
||||
|
||||
## Step 9: Update GitHub Release Notes
|
||||
|
||||
Once the user confirms the publish workflow is done, fetch the auto-generated release content:
|
||||
|
||||
```bash
|
||||
VERSION=<version>
|
||||
gh release view v${VERSION} --json body --jq '.body'
|
||||
```
|
||||
|
||||
The auto-generated release has:
|
||||
- `## What's Changed` - PR list (we'll replace this with our changelog)
|
||||
- `## New Contributors` - First-time contributors (keep this if present)
|
||||
- `**Full Changelog**` - Comparison link (keep this)
|
||||
|
||||
Build the new release body:
|
||||
1. Start with `## What's Changed` header
|
||||
2. Add our changelog content (from CHANGELOG.md for this version)
|
||||
3. Keep the `## New Contributors` section if it exists
|
||||
4. Keep the `**Full Changelog**` link
|
||||
|
||||
Update the release:
|
||||
|
||||
```bash
|
||||
gh release edit v${VERSION} --notes "<new body content>"
|
||||
```
|
||||
|
||||
Verify the release was updated:
|
||||
|
||||
```bash
|
||||
gh release view v${VERSION}
|
||||
```
|
||||
|
||||
## Step 10: Final Summary
|
||||
|
||||
**Copy a Slack announcement message to clipboard** (include the full changelog, not just highlights):
|
||||
|
||||
```bash
|
||||
echo "VS Code v{VERSION} Released
|
||||
|
||||
- Changelog entry 1
|
||||
- Changelog entry 2
|
||||
- Changelog entry 3" | pbcopy
|
||||
```
|
||||
|
||||
**Present a final summary:**
|
||||
- Version released: v{VERSION}
|
||||
- PR merged: #{PR_NUMBER}
|
||||
- Tag pushed: v{VERSION}
|
||||
- Release: https://github.com/cline/cline/releases/tag/v{VERSION}
|
||||
- Slack message copied to clipboard
|
||||
|
||||
**Final reminder:**
|
||||
Post the Slack message to announce the release
|
||||
|
||||
## Handling Edge Cases
|
||||
|
||||
### No changesets found
|
||||
If the changeset PR body shows no changes, inform the user they need to merge PRs with changesets first.
|
||||
|
||||
### Merge conflicts
|
||||
If there are conflicts on the changeset branch, help the user resolve them:
|
||||
```bash
|
||||
git fetch origin main
|
||||
git rebase origin/main
|
||||
# resolve conflicts
|
||||
git push origin changeset-release/main --force-with-lease
|
||||
```
|
||||
|
||||
### User wants to add more changes
|
||||
If the user wants to include additional PRs before releasing:
|
||||
1. Ask them to merge those PRs to main first
|
||||
2. The changeset automation will update the PR automatically
|
||||
3. Re-run this workflow after the PR is updated
|
||||
Provide:
|
||||
- Released version/tag
|
||||
- Link to release page
|
||||
- Summary of top end-user changes
|
||||
|
||||
@@ -60,7 +60,6 @@ We're not looking for exhaustive documentation - just evidence that you've thoug
|
||||
|
||||
- [ ] Changes are limited to a single feature, bugfix or chore (split larger changes into separate PRs)
|
||||
- [ ] Tests are passing (`npm test`) and code is formatted and linted (`npm run format && npm run lint`)
|
||||
- [ ] I have created a changeset using `npm run changeset` (required for user-facing changes)
|
||||
- [ ] I have reviewed [contributor guidelines](https://github.com/cline/cline/blob/main/CONTRIBUTING.md)
|
||||
|
||||
### Screenshots
|
||||
|
||||
@@ -1,79 +0,0 @@
|
||||
"""
|
||||
This script updates a specific version's release notes section in CHANGELOG.md with new content
|
||||
or reformats existing content.
|
||||
|
||||
The script:
|
||||
1. Takes a version number, changelog path, and optionally new content as input from environment variables
|
||||
2. Finds the section in the changelog for the specified version
|
||||
3. Either:
|
||||
a) Replaces the content with new content if provided, or
|
||||
b) Reformats existing content by:
|
||||
- Removing the first two lines of the changeset format
|
||||
- Ensuring version numbers are wrapped in square brackets
|
||||
4. Writes the updated changelog back to the file
|
||||
|
||||
Environment Variables:
|
||||
CHANGELOG_PATH: Path to the changelog file (defaults to 'CHANGELOG.md')
|
||||
VERSION: The version number to update/format
|
||||
PREV_VERSION: The previous version number (used to locate section boundaries)
|
||||
NEW_CONTENT: Optional new content to insert for this version
|
||||
"""
|
||||
|
||||
#!/usr/bin/env python3
|
||||
|
||||
import os
|
||||
|
||||
CHANGELOG_PATH = os.environ.get("CHANGELOG_PATH", "CHANGELOG.md")
|
||||
VERSION = os.environ['VERSION']
|
||||
PREV_VERSION = os.environ.get("PREV_VERSION", "")
|
||||
NEW_CONTENT = os.environ.get("NEW_CONTENT", "")
|
||||
|
||||
def overwrite_changelog_section(changelog_text: str, new_content: str):
|
||||
# Find the section for the specified version
|
||||
version_pattern = f"## {VERSION}\n"
|
||||
unformmatted_prev_version_pattern = f"## {PREV_VERSION}\n"
|
||||
prev_version_pattern = f"## [{PREV_VERSION}]\n"
|
||||
print(f"latest version: {VERSION}")
|
||||
print(f"prev_version: {PREV_VERSION}")
|
||||
|
||||
notes_start_index = changelog_text.find(version_pattern) + len(version_pattern)
|
||||
notes_end_index = changelog_text.find(prev_version_pattern, notes_start_index) if PREV_VERSION and (prev_version_pattern in changelog_text or unformmatted_prev_version_pattern in changelog_text) else len(changelog_text)
|
||||
|
||||
if new_content:
|
||||
return changelog_text[:notes_start_index] + f"{new_content}\n" + changelog_text[notes_end_index:]
|
||||
else:
|
||||
changeset_lines = changelog_text[notes_start_index:notes_end_index].split("\n")
|
||||
filtered_lines = []
|
||||
for line in changeset_lines:
|
||||
# If the previous line is a changeset format
|
||||
if len(filtered_lines) > 1 and filtered_lines[-1].startswith("### "):
|
||||
# Remove the last two lines from the filted_lines
|
||||
filtered_lines.pop()
|
||||
filtered_lines.pop()
|
||||
else:
|
||||
filtered_lines.append(line.strip())
|
||||
|
||||
# Prepend a new line to the first line of filtered_lines
|
||||
if filtered_lines:
|
||||
filtered_lines[0] = "\n" + filtered_lines[0]
|
||||
|
||||
# Print filted_lines wiht a "\n" at the end of each line
|
||||
for line in filtered_lines:
|
||||
print(line.strip())
|
||||
|
||||
parsed_lines = "\n".join(line for line in filtered_lines)
|
||||
updated_changelog = changelog_text[:notes_start_index] + parsed_lines + changelog_text[notes_end_index:]
|
||||
return updated_changelog
|
||||
|
||||
with open(CHANGELOG_PATH, 'r') as f:
|
||||
changelog_content = f.read()
|
||||
|
||||
new_changelog = overwrite_changelog_section(changelog_content, NEW_CONTENT)
|
||||
# print("----------------------------------------------------------------------------------")
|
||||
# print(new_changelog)
|
||||
# print("----------------------------------------------------------------------------------")
|
||||
# Write back to CHANGELOG.md
|
||||
with open(CHANGELOG_PATH, 'w') as f:
|
||||
f.write(new_changelog)
|
||||
|
||||
print(f"{CHANGELOG_PATH} updated successfully!")
|
||||
@@ -1,113 +0,0 @@
|
||||
name: Changeset Converter
|
||||
run-name: Changeset Conversion
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
pull_request:
|
||||
types: [closed]
|
||||
|
||||
env:
|
||||
REPO_PATH: ${{ github.repository }}
|
||||
GIT_REF: ${{ github.event_name == 'pull_request' && github.event.pull_request.head.sha || 'main' }}
|
||||
NODE_VERSION: 20.18.1
|
||||
|
||||
jobs:
|
||||
# Job 1: Create version bump PR when changesets are merged to main
|
||||
changeset-pr-version-bump:
|
||||
if: |
|
||||
github.event_name == 'workflow_dispatch' ||
|
||||
(
|
||||
github.event_name == 'pull_request' &&
|
||||
github.event.pull_request.merged == true &&
|
||||
github.event.pull_request.base.ref == 'main' &&
|
||||
github.actor != 'github-actions'
|
||||
)
|
||||
runs-on: ubuntu-latest
|
||||
permissions:
|
||||
contents: write
|
||||
pull-requests: write
|
||||
steps:
|
||||
- name: Check user for team affiliation
|
||||
id: team_check
|
||||
if: github.event_name == 'workflow_dispatch'
|
||||
uses: morfien101/actions-authorized-user@4a3cfbf0bcb3cafe4a71710a278920c5d94bb38b
|
||||
with:
|
||||
username: ${{ github.actor }}
|
||||
org: ${{ github.repository_owner }}
|
||||
team: "deployer"
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
- name: Check if user is authorized
|
||||
if: github.event_name == 'workflow_dispatch'
|
||||
run: |
|
||||
if [ "${{ steps.team_check.outputs.authorized }}" != "true" ]; then
|
||||
echo "User is not authorized to run this workflow."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
- name: Git Checkout
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
ref: ${{ env.GIT_REF }}
|
||||
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: ${{ env.NODE_VERSION }}
|
||||
cache: "npm"
|
||||
|
||||
- name: Install Dependencies
|
||||
run: npm ci
|
||||
|
||||
# Check if there are any new changesets to process
|
||||
- name: Check for changesets
|
||||
id: check-changesets
|
||||
run: |
|
||||
NEW_CHANGESETS=$(find .changeset -name "*.md" ! -name "README.md" | wc -l | tr -d ' ')
|
||||
echo "Changesets diff with previous version: $NEW_CHANGESETS"
|
||||
echo "new_changesets=$NEW_CHANGESETS" >> $GITHUB_OUTPUT
|
||||
|
||||
# Create version bump PR using changesets/action if there are new changesets
|
||||
- name: Create Changeset Pull Request
|
||||
if: steps.check-changesets.outputs.new_changesets != '0'
|
||||
uses: changesets/action@v1
|
||||
with:
|
||||
commit: "changeset version bump"
|
||||
title: "Changeset version bump"
|
||||
version: npm run version-packages # This performs the changeset version bump
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
# Get current and previous versions to edit changelog entry
|
||||
- name: Get version
|
||||
id: get_version
|
||||
run: |
|
||||
VERSION=$(git show HEAD:package.json | jq -r '.version')
|
||||
echo "version=$VERSION" >> $GITHUB_OUTPUT
|
||||
PREV_VERSION=$(git show origin/main:package.json | jq -r '.version')
|
||||
echo "prev_version=$PREV_VERSION" >> $GITHUB_OUTPUT
|
||||
echo "version=$VERSION"
|
||||
echo "prev_version=$PREV_VERSION"
|
||||
|
||||
# Update CHANGELOG.md with proper format
|
||||
- name: Update Changelog Format
|
||||
env:
|
||||
VERSION: ${{ steps.get_version.outputs.version }}
|
||||
PREV_VERSION: ${{ steps.get_version.outputs.prev_version }}
|
||||
run: python .github/scripts/overwrite_changeset_changelog.py
|
||||
|
||||
# Commit and push changelog updates
|
||||
- name: Push Changelog updates to Pull Request
|
||||
run: |
|
||||
git config user.name "github-actions"
|
||||
git config user.email github-actions@github.com
|
||||
echo "Running git add and commit..."
|
||||
git add CHANGELOG.md
|
||||
git commit -m "Updating CHANGELOG.md format"
|
||||
git status
|
||||
echo "--------------------------------------------------------------------------------"
|
||||
echo "Pushing to remote..."
|
||||
echo "--------------------------------------------------------------------------------"
|
||||
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
|
||||
git push origin $CURRENT_BRANCH
|
||||
@@ -55,7 +55,22 @@ jobs:
|
||||
CLINE_API_KEY: ${{ secrets.CLINE_API_KEY }}
|
||||
run: |
|
||||
cline auth -p cline -k "$CLINE_API_KEY" -m "anthropic/claude-sonnet-4.5"
|
||||
npx tsx evals/smoke-tests/run-smoke-tests.ts --trials 1 --parallel
|
||||
max_attempts=3
|
||||
for attempt in $(seq 1 $max_attempts); do
|
||||
echo "::group::Attempt $attempt of $max_attempts"
|
||||
if npx tsx evals/smoke-tests/run-smoke-tests.ts --trials 1 --parallel; then
|
||||
echo "::endgroup::"
|
||||
echo "Smoke tests passed on attempt $attempt"
|
||||
exit 0
|
||||
fi
|
||||
echo "::endgroup::"
|
||||
if [ $attempt -lt $max_attempts ]; then
|
||||
echo "::warning::Smoke tests failed on attempt $attempt, retrying..."
|
||||
sleep 10
|
||||
fi
|
||||
done
|
||||
echo "::error::Smoke tests failed after $max_attempts attempts"
|
||||
exit 1
|
||||
|
||||
- name: Generate summary
|
||||
if: always()
|
||||
|
||||
@@ -39,6 +39,7 @@ jobs:
|
||||
!endsWith(github.actor, '[bot]')
|
||||
)
|
||||
uses: ./.github/workflows/npm-main.yaml
|
||||
secrets: inherit
|
||||
with:
|
||||
confirm_publish: ${{ github.event.inputs.confirm_publish }}
|
||||
|
||||
@@ -49,5 +50,6 @@ jobs:
|
||||
(github.event_name == 'workflow_dispatch' && github.event.inputs.publish_target == 'nightly')
|
||||
)
|
||||
uses: ./.github/workflows/npm-nightly.yaml
|
||||
secrets: inherit
|
||||
with:
|
||||
force_publish: ${{ github.event_name == 'workflow_dispatch' && github.event.inputs.force_nightly_publish == 'true' }}
|
||||
|
||||
@@ -36,7 +36,9 @@ jobs:
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: "lts/*"
|
||||
# Keep publish environment aligned with test workflow/tooling lockfile expectations.
|
||||
# Newer LTS (Node 24 / npm 11) can make `npm list` fail with ELSPROBLEMS during vsce packaging.
|
||||
node-version: 22
|
||||
|
||||
- name: Install root dependencies
|
||||
run: npm ci --include=optional
|
||||
|
||||
@@ -42,7 +42,7 @@ jobs:
|
||||
- name: Setup Node.js
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: "lts/*"
|
||||
node-version: 22
|
||||
|
||||
- name: Install root dependencies
|
||||
run: npm install --include=optional
|
||||
|
||||
Vendored
+2
-1
@@ -16,7 +16,8 @@
|
||||
"saoudrizwan.claude-dev", // Avoid conflicts with installed Cline
|
||||
"--disable-extension",
|
||||
"saoudrizwan.cline-nightly", // Avoid conflicts with installed Cline Nightly
|
||||
"${workspaceFolder}"
|
||||
"${workspaceFolder}",
|
||||
"--disable-extensions"
|
||||
],
|
||||
"outFiles": [
|
||||
"${workspaceFolder}/dist/**/*.js"
|
||||
|
||||
@@ -35,11 +35,9 @@ cli/**
|
||||
eslint-rules/
|
||||
old_docs/
|
||||
evals/
|
||||
.changie.yaml
|
||||
.codespellrc
|
||||
.mocharc.json
|
||||
buf.yaml
|
||||
.changeset/
|
||||
.clinerules/
|
||||
|
||||
# Ignore all webview-ui files except the build directory (https://github.com/microsoft/vscode-webview-ui-toolkit-samples/blob/main/frameworks/hello-world-react-cra/.vscodeignore)
|
||||
|
||||
+92
-13
@@ -1,5 +1,81 @@
|
||||
# Changelog
|
||||
|
||||
## [3.67.0]
|
||||
|
||||
### Added
|
||||
|
||||
- Add support for skills and optional modelId in subagent configuration
|
||||
- Add AgentConfigLoader for file-based agent configs
|
||||
- Add Responses API support for OpenAI native provider
|
||||
- Preconnect websocket to reduce response latency
|
||||
- Fetch featured models from backend with local fallback
|
||||
- Add /q command to quit CLI
|
||||
- Add MCP enterprise configuration details
|
||||
- Pull Cline's recommended models from internal endpoint
|
||||
- Add dynamic flag to adjust banner cache duration
|
||||
|
||||
### Fixed
|
||||
|
||||
- Fix reasoning delta crash on usage-only stream chunks
|
||||
- Fix OpenAI tool ID transformation restricted to native provider only
|
||||
- Fix auth check for ACP mode
|
||||
- Fix CLI yolo mode to not persist yolo setting to disk
|
||||
- Fix inline focus-chain slider within its feature row
|
||||
- Fix Gemini 3.1 Pro compatibility
|
||||
- Fix Cline auth with ACP flag
|
||||
|
||||
### Changed
|
||||
|
||||
- Move PR skill to .agents/skills
|
||||
- SambaNova provider: update models list
|
||||
- Remove changeset-converter GitHub Action and npm run changeset
|
||||
|
||||
## [3.66.0]
|
||||
|
||||
### Added
|
||||
|
||||
- Gemini-3.1 Pro Preview
|
||||
|
||||
|
||||
## [3.65.0]
|
||||
|
||||
### Added
|
||||
|
||||
- Add /skills slash command to CLI for viewing and managing installed skills
|
||||
|
||||
### Fixed
|
||||
|
||||
- Fix aggressive context compaction caused by accidental clicks on the context window progress bar silently setting a very low auto-condense threshold
|
||||
- Fix infinite retry loop when write_to_file fails with missing content parameter.
|
||||
- Fixed default claude model
|
||||
|
||||
## [3.64.0]
|
||||
|
||||
### Added
|
||||
- Added sonnet 4.6
|
||||
|
||||
|
||||
## [3.63.0]
|
||||
|
||||
### Added
|
||||
|
||||
- added zai GLM 5 Free promo
|
||||
|
||||
### Fixed
|
||||
|
||||
- Restore reasoning trace visibility in chat and improve the thinking row UX so reasoning is visible, then collapsible after completion.
|
||||
|
||||
## [3.62.0]
|
||||
|
||||
### Fixed
|
||||
|
||||
- Banners now display immediately when opening the extension instead of requiring user interaction first
|
||||
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
|
||||
|
||||
## [3.61.0]
|
||||
|
||||
- UI/UX fixes with minimax model family
|
||||
|
||||
## [3.60.0]
|
||||
|
||||
- Fixes for Minimax model family
|
||||
@@ -7,11 +83,12 @@
|
||||
## [3.59.0]
|
||||
|
||||
- Added Minimax 2.5 Free Promo
|
||||
- Fixed Response chaining for OpenAI's Responses API
|
||||
- Fixed Response chaining for OpenAI's Responses API
|
||||
|
||||
## [3.58.0]
|
||||
|
||||
### Added
|
||||
|
||||
- Subagent: replace legacy subagents with the native `use_subagents` tool
|
||||
- Bundle `endpoints.json` support so packaged distributions can ship required endpoints out-of-the-box
|
||||
- Amazon Bedrock: support parallel tool calling
|
||||
@@ -22,6 +99,7 @@
|
||||
- ZAI/GLM: add GLM-5
|
||||
|
||||
### Fixed
|
||||
|
||||
- CLI: handle stdin redirection correctly in CI/headless environments
|
||||
- CLI: preserve OAuth callback paths during auth redirects
|
||||
- VS Code Web: generate auth callback URLs via `vscode.env.asExternalUri` (OAuth callback reliability)
|
||||
@@ -33,6 +111,7 @@
|
||||
- CI: increase Windows E2E test timeout to reduce flakiness
|
||||
|
||||
### Changed
|
||||
|
||||
- Settings/model UX: move "reasoning effort" into model configuration and expose it in settings
|
||||
- CLI provider selection: limit provider list to those remotely configured
|
||||
- UI: consolidate ViewHeader component/styling across views
|
||||
@@ -50,7 +129,7 @@
|
||||
### Added
|
||||
|
||||
- Cline CLI 2.0 now available. Install with `npm install -g cline`
|
||||
- Anthopic Opus 4.6
|
||||
- Anthopic Opus 4.6
|
||||
- Minimax-2.1 and Kimi-k2.5 now available for free for a limited time promo
|
||||
- Codex-5.3 through ChatGPT subscription
|
||||
|
||||
@@ -70,23 +149,23 @@
|
||||
|
||||
### Added
|
||||
|
||||
- __CLI authentication:__ Added Vercel AI Gateway and Cline API key provider support for headless CI/automation workflows
|
||||
- __New model:__ Added Kimi-K2.5 model to Moonshot provider (262K context, image support, prompt caching)
|
||||
- __Prompt variant:__ Added Trinity Large prompt variant for improved tool-calling support
|
||||
- __OpenTelemetry:__ Added support for custom headers on metrics and logs endpoints
|
||||
- __Social links:__ Added community icons (X, Discord, GitHub, Reddit, LinkedIn) to the What's New modal
|
||||
- **CLI authentication:** Added Vercel AI Gateway and Cline API key provider support for headless CI/automation workflows
|
||||
- **New model:** Added Kimi-K2.5 model to Moonshot provider (262K context, image support, prompt caching)
|
||||
- **Prompt variant:** Added Trinity Large prompt variant for improved tool-calling support
|
||||
- **OpenTelemetry:** Added support for custom headers on metrics and logs endpoints
|
||||
- **Social links:** Added community icons (X, Discord, GitHub, Reddit, LinkedIn) to the What's New modal
|
||||
|
||||
### Fixed
|
||||
|
||||
- __LiteLLM:__ Fixed thinking configuration not appearing for reasoning-capable models
|
||||
- __OpenTelemetry:__ Fixed endpoint path handling (no longer incorrectly appends `/v1/logs` or `/v1/metrics`) and ensured logs are sent regardless of VSCode telemetry settings
|
||||
- __CLI auth:__ Fixed `cline auth` displaying incorrect provider information after configuration
|
||||
- **LiteLLM:** Fixed thinking configuration not appearing for reasoning-capable models
|
||||
- **OpenTelemetry:** Fixed endpoint path handling (no longer incorrectly appends `/v1/logs` or `/v1/metrics`) and ensured logs are sent regardless of VSCode telemetry settings
|
||||
- **CLI auth:** Fixed `cline auth` displaying incorrect provider information after configuration
|
||||
|
||||
### Changed
|
||||
|
||||
- __Hooks:__ Hook scripts now run from the workspace repository root instead of filesystem root
|
||||
- __Default settings:__ Enabled multi-root workspaces, parallel tool calling, and skills by default; disabled strict plan mode by default
|
||||
- __Settings UI:__ Refreshed feature settings section with collapsible design
|
||||
- **Hooks:** Hook scripts now run from the workspace repository root instead of filesystem root
|
||||
- **Default settings:** Enabled multi-root workspaces, parallel tool calling, and skills by default; disabled strict plan mode by default
|
||||
- **Settings UI:** Refreshed feature settings section with collapsible design
|
||||
|
||||
## [3.55.0]
|
||||
|
||||
|
||||
+6
-25
@@ -57,25 +57,11 @@ We also welcome contributions to our [documentation](https://github.com/cline/cl
|
||||
|
||||
### 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
|
||||
1. Commit your changes.
|
||||
|
||||
2. Commit your changes and the generated `.changeset` file
|
||||
|
||||
3. Push your branch and create a PR on GitHub. Our CI will:
|
||||
2. 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
|
||||
3. Testing
|
||||
- Run `npm run test` to run tests locally.
|
||||
- Before submitting PR, run `npm run format:fix` to format your code
|
||||
|
||||
@@ -192,15 +178,10 @@ Anyone can contribute code to Cline, but we ask that you follow these guidelines
|
||||
- Temporary workspaces with test fixtures
|
||||
- Video recording for failed tests
|
||||
|
||||
4. **Version Management with Changesets**
|
||||
4. **Versioning & Changelog Notes**
|
||||
|
||||
- Create a changeset for any user-facing changes using `npm run changeset`
|
||||
- Choose the appropriate version bump:
|
||||
- `major` for breaking changes (1.0.0 → 2.0.0)
|
||||
- `minor` for new features (1.0.0 → 1.1.0)
|
||||
- `patch` for bug fixes (1.0.0 → 1.0.1)
|
||||
- Write clear, descriptive changeset messages that explain the impact
|
||||
- Documentation-only changes don't require changesets
|
||||
- Contributors do not need to create changelog-entry files as part of PRs.
|
||||
- Maintainers handle release versioning and changelog curation during the release process.
|
||||
|
||||
5. **Commit Guidelines**
|
||||
|
||||
|
||||
+27
@@ -0,0 +1,27 @@
|
||||
# Security Policy
|
||||
|
||||
## Supported Versions
|
||||
|
||||
We actively patch only the most recent minor release of Cline. Older versions receive fixes at our discretion.
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.
|
||||
|
||||
To report a security issue, please use the GitHub Security Advisory ["Report a Vulnerability"](https://github.com/cline/cline/security/advisories/new) tab.
|
||||
|
||||
The team will send a response indicating the next steps in handling your report. After the initial reply, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance.
|
||||
|
||||
When reporting, please include:
|
||||
|
||||
- A short summary of the issue
|
||||
- Steps to reproduce or a proof of concept
|
||||
- Any logs, stack traces, or screenshots that might help us understand the problem
|
||||
|
||||
We acknowledge reports within 48 hours and aim to release a fix or mitigation within 30 days. While we work on a resolution, please keep the details private.
|
||||
|
||||
## Escalation
|
||||
|
||||
If you do not receive an acknowledgement of your report within 5 business days, you may send an email to security@cline.bot.
|
||||
|
||||
Thank you for helping us keep Cline users safe.
|
||||
+44
-1
@@ -1,8 +1,51 @@
|
||||
# cline
|
||||
|
||||
## 2.4.3
|
||||
|
||||
### Added
|
||||
|
||||
- Add /q command to quit CLI
|
||||
- Fetch featured models from backend with local fallback
|
||||
|
||||
### Fixed
|
||||
|
||||
- Fix auth check for ACP mode
|
||||
- Fix Cline auth with ACP flag
|
||||
- Fix yolo mode to not persist yolo setting to disk
|
||||
|
||||
## 2.4.2
|
||||
|
||||
### Added
|
||||
|
||||
- Gemini-3.1 Pro Preview
|
||||
|
||||
### Patch Changes
|
||||
|
||||
- VSCode uses shared files for global, workspace and secret state.
|
||||
|
||||
## [2.4.1]
|
||||
|
||||
### Fixed
|
||||
|
||||
- Fix infinite retry loop when write_to_file fails with missing content parameter. Provides progressive guidance to the model, escalating from suggestions to hard stops, with context window awareness to break the loop.
|
||||
|
||||
## [2.4.0]
|
||||
|
||||
### Added
|
||||
|
||||
- Adding Anthropic Sonnet 4.6
|
||||
- Allows users to enter custom aws region when selecting bedrock as a provider in CLI
|
||||
- Keep reasoning rows visible when low-stakes tool groups start immediately after reasoning.
|
||||
- Restore reasoning trace visibility in chat and improve the thinking row UX so streamed reasoning is visible, then collapsible after completion.
|
||||
|
||||
### Fixed
|
||||
|
||||
- Banners now display immediately when opening the extension instead of requiring user interaction first
|
||||
- Resolved 17 security vulnerabilities including high-severity DoS issues in dependencies (body-parser, axios, qs, tar, and others)
|
||||
|
||||
## [2.2.2]
|
||||
|
||||
- Allows users to enter custom aws region when selecting bedrock as a provider
|
||||
- Allows users to enter custom aws region when selecting bedrock as a provider
|
||||
- Prevent Parent Container Scrolling In Dropdowns
|
||||
|
||||
## [2.2.1]
|
||||
|
||||
+1
-2
@@ -45,7 +45,7 @@ cline
|
||||
|
||||
### Use any API and Model
|
||||
|
||||
Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras and Groq. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.
|
||||
Cline supports API providers like ChatGPT, Anthropic, OpenAI, Google Gemini, AWS Bedrock, Azure, GCP Vertex, Cerebras, Groq, and Moonshot. You can also configure any OpenAI compatible API, or use a local model through LM Studio/Ollama. If you're using a Cline Account, you'll always have access to the newest models as soon as they're available.
|
||||
|
||||
<!-- Transparent pixel to create line break after floating image -->
|
||||
|
||||
@@ -79,4 +79,3 @@ Get the same Cline experience with enterprise-grade controls: SSO (SAML/OIDC), g
|
||||
## License
|
||||
|
||||
[Apache 2.0 © 2026 Cline Bot Inc.](./LICENSE)
|
||||
|
||||
|
||||
+8
-2
@@ -125,13 +125,13 @@ authentication wizard, or use quick setup flags.
|
||||
Options:
|
||||
.PP
|
||||
\f[B]\-p\f[R], \f[B]\-\-provider\f[R] \f[I]id\f[R] : Provider ID for
|
||||
quick setup (e.g., openai\-native, anthropic, openrouter)
|
||||
quick setup (e.g., openai\-native, anthropic, openrouter, moonshot)
|
||||
.PP
|
||||
\f[B]\-k\f[R], \f[B]\-\-apikey\f[R] \f[I]key\f[R] : API key for the
|
||||
provider
|
||||
.PP
|
||||
\f[B]\-m\f[R], \f[B]\-\-modelid\f[R] \f[I]id\f[R] : Model ID to
|
||||
configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929)
|
||||
configure (e.g., gpt\-4o, claude\-sonnet\-4\-5\-20250929, kimi\-k2.5)
|
||||
.PP
|
||||
\f[B]\-b\f[R], \f[B]\-\-baseurl\f[R] \f[I]url\f[R] : Base URL (optional,
|
||||
for OpenAI\-compatible providers)
|
||||
@@ -242,6 +242,9 @@ cline \-m claude\-sonnet\-4\-5\-20250929 \(dqRefactor this function\(dq
|
||||
|
||||
\f[I]# Quick auth setup with model\f[R]
|
||||
cline auth \-p anthropic \-k sk\-ant\-xxxxx \-m claude\-sonnet\-4\-5\-20250929
|
||||
|
||||
\f[I]# Quick auth setup for Moonshot\f[R]
|
||||
cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
|
||||
.EE
|
||||
.SS Including Images
|
||||
.IP
|
||||
@@ -309,6 +312,9 @@ cline auth \-p anthropic \-k sk\-ant\-api\-xxxxx
|
||||
\f[I]# Quick setup for OpenAI\f[R]
|
||||
cline auth \-p openai\-native \-k sk\-xxxxx \-m gpt\-4o
|
||||
|
||||
\f[I]# Quick setup for Moonshot\f[R]
|
||||
cline auth \-p moonshot \-k sk\-xxxxx \-m kimi\-k2.5
|
||||
|
||||
\f[I]# OpenAI\-compatible provider with custom base URL\f[R]
|
||||
cline auth \-p openai \-k your\-api\-key \-b https://api.example.com/v1
|
||||
.EE
|
||||
|
||||
@@ -56,6 +56,8 @@ Run a new task with a prompt.
|
||||
|
||||
**-y**, **\--yolo** : Enable yolo/yes mode (auto-approve all actions, output in plain mode, exit process automatically when task complete)
|
||||
|
||||
**-t**, **\--timeout** *seconds* : Optional timeout in seconds. Only applied when explicitly provided.
|
||||
|
||||
**-m**, **\--model** *model* : Model to use for the task
|
||||
|
||||
**-i**, **\--images** *paths...* : Image file paths to include with the task
|
||||
@@ -144,6 +146,8 @@ When running **cline** with just a prompt (no subcommand), these options are ava
|
||||
|
||||
**-y**, **\--yolo** : Enable yolo mode (auto-approve all actions). Also forces plain text output mode.
|
||||
|
||||
**-t**, **\--timeout** *seconds* : Optional timeout in seconds. Only applied when explicitly provided.
|
||||
|
||||
**-m**, **\--model** *model* : Model to use for the task
|
||||
|
||||
**-v**, **\--verbose** : Show verbose output
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "cline",
|
||||
"version": "2.2.2",
|
||||
"version": "2.4.3",
|
||||
"description": "Autonomous coding agent CLI - capable of creating/editing files, running commands, using the browser, and more",
|
||||
"main": "dist/cli.mjs",
|
||||
"bin": {
|
||||
|
||||
@@ -28,6 +28,8 @@ import {
|
||||
groqModels,
|
||||
mistralDefaultModelId,
|
||||
mistralModels,
|
||||
moonshotDefaultModelId,
|
||||
moonshotModels,
|
||||
openAiCodexDefaultModelId,
|
||||
openAiNativeDefaultModelId,
|
||||
openAiNativeModels,
|
||||
@@ -36,7 +38,6 @@ import {
|
||||
} from "@shared/api"
|
||||
import type { ClineAsk, ClineMessage as ClineMessageType } from "@shared/ExtensionMessage"
|
||||
import { CLI_ONLY_COMMANDS, VSCODE_ONLY_COMMANDS } from "@shared/slashCommands"
|
||||
import { ProviderToApiKeyMap } from "@shared/storage"
|
||||
import { getProviderModelIdKey } from "@shared/storage/provider-keys"
|
||||
import { ClineEndpoint } from "@/config.js"
|
||||
import { Controller } from "@/core/controller"
|
||||
@@ -51,12 +52,12 @@ import { openAiCodexOAuthManager } from "@/integrations/openai-codex/oauth"
|
||||
import { StandaloneTerminalManager } from "@/integrations/terminal/index.js"
|
||||
import { AuthService } from "@/services/auth/AuthService.js"
|
||||
import { Logger } from "@/shared/services/Logger.js"
|
||||
import { secretStorage } from "@/shared/storage/ClineSecretStorage"
|
||||
import type { Mode } from "@/shared/storage/types"
|
||||
import { openExternal } from "@/utils/env"
|
||||
import { ACPDiffViewProvider } from "../acp/ACPDiffViewProvider.js"
|
||||
import { ACPHostBridgeClientProvider } from "../acp/ACPHostBridgeClientProvider.js"
|
||||
import { AcpTerminalManager } from "../acp/AcpTerminalManager.js"
|
||||
import { isAuthConfigured } from "../index.js"
|
||||
import { fetchOpenRouterModels, usesOpenRouterModels } from "../utils/openrouter-models"
|
||||
import { CliContextResult, initializeCliContext } from "../vscode-context.js"
|
||||
import { ClineSessionEmitter } from "./ClineSessionEmitter.js"
|
||||
@@ -72,6 +73,7 @@ const providerModels: Record<string, { models: Record<string, unknown>; defaultI
|
||||
bedrock: { models: bedrockModels, defaultId: bedrockDefaultModelId },
|
||||
deepseek: { models: deepSeekModels, defaultId: deepSeekDefaultModelId },
|
||||
mistral: { models: mistralModels, defaultId: mistralDefaultModelId },
|
||||
moonshot: { models: moonshotModels, defaultId: moonshotDefaultModelId },
|
||||
groq: { models: groqModels, defaultId: groqDefaultModelId },
|
||||
xai: { models: xaiModels, defaultId: xaiDefaultModelId },
|
||||
}
|
||||
@@ -174,7 +176,7 @@ export class ClineAgent implements acp.Agent {
|
||||
this.clientCapabilities = params.clientCapabilities
|
||||
this.initializeHostProvider(this.clientCapabilities, connection)
|
||||
await ClineEndpoint.initialize(this.ctx.EXTENSION_DIR)
|
||||
await StateManager.initialize(this.ctx.extensionContext)
|
||||
await StateManager.initialize(this.ctx.storageContext)
|
||||
|
||||
return {
|
||||
protocolVersion: PROTOCOL_VERSION,
|
||||
@@ -263,7 +265,7 @@ export class ClineAgent implements acp.Agent {
|
||||
*/
|
||||
async newSession(params: acp.NewSessionRequest): Promise<acp.NewSessionResponse> {
|
||||
// Check if authentication is required
|
||||
const isAuthenticated = await this.isAuthConfigured()
|
||||
const isAuthenticated = await isAuthConfigured()
|
||||
if (!isAuthenticated) {
|
||||
throw RequestError.authRequired()
|
||||
}
|
||||
@@ -1004,13 +1006,14 @@ export class ClineAgent implements acp.Agent {
|
||||
const startTime = Date.now()
|
||||
|
||||
while (Date.now() - startTime < AUTH_TIMEOUT_MS) {
|
||||
const stateManager = StateManager.get()
|
||||
|
||||
// Check if auth data has been stored
|
||||
const authData = await secretStorage.get("cline:clineAccountId")
|
||||
const authData = stateManager.getSecretKey("cline:clineAccountId")
|
||||
if (authData) {
|
||||
Logger.debug("[ClineAgent] Authentication successful")
|
||||
|
||||
// Set up the provider configuration for cline
|
||||
const stateManager = StateManager.get()
|
||||
stateManager.setGlobalState("actModeApiProvider", "cline")
|
||||
stateManager.setGlobalState("planModeApiProvider", "cline")
|
||||
await stateManager.flushPendingState()
|
||||
@@ -1143,48 +1146,6 @@ export class ClineAgent implements acp.Agent {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* Check if the user has authentication configured.
|
||||
* Returns true if they have either:
|
||||
* - Cline provider with stored auth data
|
||||
* - OpenAI Codex provider with OAuth credentials
|
||||
* - BYO provider with an API key configured
|
||||
*/
|
||||
private async isAuthConfigured(): Promise<boolean> {
|
||||
const stateManager = StateManager.get()
|
||||
const mode = stateManager.getGlobalSettingsKey("mode") as string
|
||||
const providerKey = mode === "act" ? "actModeApiProvider" : "planModeApiProvider"
|
||||
const currentProvider = (stateManager.getGlobalSettingsKey(providerKey) as string) || "cline"
|
||||
|
||||
if (currentProvider === "cline") {
|
||||
// For Cline provider, check if we have stored auth data
|
||||
const values = await Promise.all(["clineApiKey", "clineAccountId"].map((key) => secretStorage.get(key)))
|
||||
return values.some(Boolean)
|
||||
}
|
||||
|
||||
// For OpenAI Codex provider, check OAuth credentials
|
||||
if (currentProvider === "openai-codex") {
|
||||
openAiCodexOAuthManager.initialize(this.ctx.extensionContext)
|
||||
return await openAiCodexOAuthManager.isAuthenticated()
|
||||
}
|
||||
|
||||
// For BYO providers, check if the API key is configured
|
||||
const keyField = ProviderToApiKeyMap[currentProvider as keyof typeof ProviderToApiKeyMap]
|
||||
if (!keyField) {
|
||||
return false
|
||||
}
|
||||
|
||||
const fields = Array.isArray(keyField) ? keyField : [keyField]
|
||||
for (const field of fields) {
|
||||
const value = await secretStorage.get(field)
|
||||
if (value) {
|
||||
return true
|
||||
}
|
||||
}
|
||||
|
||||
return false
|
||||
}
|
||||
|
||||
/**
|
||||
* Handle OpenAI Codex OAuth authentication flow.
|
||||
*
|
||||
@@ -1198,9 +1159,6 @@ export class ClineAgent implements acp.Agent {
|
||||
Logger.debug("[ClineAgent] Starting OpenAI Codex OAuth flow...")
|
||||
|
||||
try {
|
||||
// Initialize the OAuth manager with extension context
|
||||
openAiCodexOAuthManager.initialize(this.ctx.extensionContext)
|
||||
|
||||
// Get the authorization URL and start the callback server
|
||||
const authUrl = openAiCodexOAuthManager.startAuthorizationFlow()
|
||||
|
||||
|
||||
@@ -15,6 +15,7 @@ import { StringRequest } from "@/shared/proto/cline/common"
|
||||
import { openExternal } from "@/utils/env"
|
||||
import { COLORS } from "../constants/colors"
|
||||
import { useStdinContext } from "../context/StdinContext"
|
||||
import { useClineFeaturedModels } from "../hooks/useClineFeaturedModels"
|
||||
import { useOcaAuth } from "../hooks/useOcaAuth"
|
||||
import { useScrollableList } from "../hooks/useScrollableList"
|
||||
import { type DetectedSources, detectImportSources, type ImportSource } from "../utils/import-configs"
|
||||
@@ -23,6 +24,7 @@ import { applyBedrockConfig, applyProviderConfig } from "../utils/provider-confi
|
||||
import { useValidProviders } from "../utils/providers"
|
||||
import { ApiKeyInput } from "./ApiKeyInput"
|
||||
import { StaticRobotFrame } from "./AsciiMotionCli"
|
||||
import { BedrockCustomModelFlow } from "./BedrockCustomModelFlow"
|
||||
import { type BedrockConfig, BedrockSetup } from "./BedrockSetup"
|
||||
import {
|
||||
FeaturedModelPicker,
|
||||
@@ -31,7 +33,7 @@ import {
|
||||
isBrowseAllSelected,
|
||||
} from "./FeaturedModelPicker"
|
||||
import { ImportView } from "./ImportView"
|
||||
import { getDefaultModelId, hasModelPicker, ModelPicker } from "./ModelPicker"
|
||||
import { CUSTOM_MODEL_ID, getDefaultModelId, hasModelPicker, ModelPicker } from "./ModelPicker"
|
||||
import { OcaEmployeeCheck } from "./OcaEmployeeCheck"
|
||||
import { getProviderLabel } from "./ProviderPicker"
|
||||
|
||||
@@ -51,6 +53,7 @@ type AuthStep =
|
||||
| "openai_codex_auth"
|
||||
| "bedrock"
|
||||
| "import"
|
||||
| "bedrock_custom"
|
||||
|
||||
interface AuthViewProps {
|
||||
controller: any
|
||||
@@ -76,7 +79,7 @@ const Select: React.FC<{
|
||||
const [selectedIndex, setSelectedIndex] = useState(0)
|
||||
|
||||
useInput(
|
||||
(input, key) => {
|
||||
(_, key) => {
|
||||
if (key.upArrow) {
|
||||
setSelectedIndex((prev) => (prev > 0 ? prev - 1 : items.length - 1))
|
||||
} else if (key.downArrow) {
|
||||
@@ -142,7 +145,11 @@ const TextInput: React.FC<{
|
||||
|
||||
return (
|
||||
<Box>
|
||||
<Text color="white">{displayValue || placeholder || ""}</Text>
|
||||
{!displayValue && placeholder ? (
|
||||
<Text color="gray">e.g. {placeholder}</Text>
|
||||
) : (
|
||||
<Text color="white">{displayValue || ""}</Text>
|
||||
)}
|
||||
<Text inverse> </Text>
|
||||
</Box>
|
||||
)
|
||||
@@ -166,6 +173,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
const [providerSearch, setProviderSearch] = useState("")
|
||||
const [providerIndex, setProviderIndex] = useState(0)
|
||||
const [clineModelIndex, setClineModelIndex] = useState(0)
|
||||
const featuredModels = useClineFeaturedModels()
|
||||
const [importSources, setImportSources] = useState<DetectedSources>({ codex: false, opencode: false })
|
||||
const [importSource, setImportSource] = useState<ImportSource | null>(null)
|
||||
const [bedrockConfig, setBedrockConfig] = useState<BedrockConfig | null>(null)
|
||||
@@ -248,6 +256,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
}, [])
|
||||
|
||||
// Reset provider index when search changes
|
||||
// biome-ignore lint/correctness/useExhaustiveDependencies: we want to reset here
|
||||
useEffect(() => {
|
||||
setProviderIndex(0)
|
||||
}, [providerSearch])
|
||||
@@ -273,7 +282,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
return
|
||||
}
|
||||
|
||||
if (authState.user && authState.user.email) {
|
||||
if (authState.user?.email) {
|
||||
// Auth succeeded - save configuration and transition to model selection
|
||||
await applyProviderConfig({ providerId: "cline", controller })
|
||||
setSelectedProvider("cline")
|
||||
@@ -389,6 +398,33 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
[selectedProvider],
|
||||
)
|
||||
|
||||
// Save custom Bedrock ARN configuration with base model for capability detection
|
||||
const saveCustomBedrockConfiguration = useCallback(
|
||||
async (arn: string, baseModelId: string) => {
|
||||
try {
|
||||
if (!bedrockConfig) {
|
||||
throw new Error("Bedrock configuration is missing")
|
||||
}
|
||||
await applyBedrockConfig({
|
||||
bedrockConfig,
|
||||
modelId: arn,
|
||||
customModelBaseId: baseModelId,
|
||||
controller,
|
||||
})
|
||||
|
||||
const stateManager = StateManager.get()
|
||||
stateManager.setGlobalState("welcomeViewCompleted", true)
|
||||
await stateManager.flushPendingState()
|
||||
|
||||
setStep("success")
|
||||
} catch (error) {
|
||||
setErrorMessage(error instanceof Error ? error.message : String(error))
|
||||
setStep("error")
|
||||
}
|
||||
},
|
||||
[bedrockConfig, controller],
|
||||
)
|
||||
|
||||
const saveConfiguration = useCallback(
|
||||
async (model: string, base: string) => {
|
||||
try {
|
||||
@@ -423,6 +459,12 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
|
||||
const handleModelIdSubmit = useCallback(
|
||||
(value: string) => {
|
||||
// Intercept "Custom" selection for Bedrock — redirect to custom ARN input flow
|
||||
if (value === CUSTOM_MODEL_ID && selectedProvider === "bedrock") {
|
||||
setStep("bedrock_custom")
|
||||
return
|
||||
}
|
||||
|
||||
if (value.trim()) {
|
||||
setModelId(value)
|
||||
}
|
||||
@@ -530,6 +572,9 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
// Go back to cline_model if we came from there (Cline provider)
|
||||
if (selectedProvider === "cline") {
|
||||
setStep("cline_model")
|
||||
} else if (selectedProvider === "bedrock") {
|
||||
// Bedrock skips the API key step — go back to Bedrock setup
|
||||
setStep("bedrock")
|
||||
} else {
|
||||
setStep("apikey")
|
||||
}
|
||||
@@ -646,7 +691,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
<Box flexDirection="column">
|
||||
<Text color="white">Model ID</Text>
|
||||
<Text> </Text>
|
||||
<Text color="gray">e.g., claude-sonnet-4-20250514, gpt-4o</Text>
|
||||
<Text color="gray">e.g., claude-sonnet-4-6, gpt-4o</Text>
|
||||
<Text> </Text>
|
||||
<TextInput onChange={setModelId} onSubmit={handleModelIdSubmit} placeholder="model-id" value={modelId} />
|
||||
<Text> </Text>
|
||||
@@ -724,7 +769,7 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
<Box flexDirection="column">
|
||||
<Text color="white">Choose a model</Text>
|
||||
<Text> </Text>
|
||||
<FeaturedModelPicker selectedIndex={clineModelIndex} />
|
||||
<FeaturedModelPicker featuredModels={featuredModels} selectedIndex={clineModelIndex} />
|
||||
</Box>
|
||||
)
|
||||
}
|
||||
@@ -741,6 +786,18 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
/>
|
||||
)
|
||||
|
||||
case "bedrock_custom":
|
||||
return (
|
||||
<BedrockCustomModelFlow
|
||||
isActive={step === "bedrock_custom"}
|
||||
onCancel={() => setStep("modelid")}
|
||||
onComplete={(arn, baseModelId) => {
|
||||
setStep("saving")
|
||||
saveCustomBedrockConfiguration(arn, baseModelId)
|
||||
}}
|
||||
/>
|
||||
)
|
||||
|
||||
case "import":
|
||||
if (!importSource) {
|
||||
return null
|
||||
@@ -814,17 +871,17 @@ export const AuthView: React.FC<AuthViewProps> = ({ controller, onComplete, onEr
|
||||
setProviderSearch((prev) => prev + input)
|
||||
}
|
||||
} else if (step === "cline_model") {
|
||||
const maxIndex = getFeaturedModelMaxIndex()
|
||||
const maxIndex = getFeaturedModelMaxIndex(featuredModels)
|
||||
|
||||
if (key.upArrow) {
|
||||
setClineModelIndex((prev) => (prev > 0 ? prev - 1 : maxIndex))
|
||||
} else if (key.downArrow) {
|
||||
setClineModelIndex((prev) => (prev < maxIndex ? prev + 1 : 0))
|
||||
} else if (key.return) {
|
||||
if (isBrowseAllSelected(clineModelIndex)) {
|
||||
if (isBrowseAllSelected(clineModelIndex, featuredModels)) {
|
||||
setStep("modelid")
|
||||
} else {
|
||||
const selectedModel = getFeaturedModelAtIndex(clineModelIndex)
|
||||
const selectedModel = getFeaturedModelAtIndex(clineModelIndex, featuredModels)
|
||||
if (selectedModel) {
|
||||
handleClineModelSelect(selectedModel.id)
|
||||
}
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
/**
|
||||
* Bedrock Custom Model Flow component
|
||||
* Two-step flow: ARN/custom model ID input → base model selection for capability detection.
|
||||
* Used by both AuthView (onboarding) and SettingsPanelContent (/settings).
|
||||
*/
|
||||
|
||||
import { Box, Text, useInput } from "ink"
|
||||
// biome-ignore lint/correctness/noUnusedImports: React is needed for JSX at runtime
|
||||
import React, { useCallback, useState } from "react"
|
||||
import { COLORS } from "../constants/colors"
|
||||
import { useStdinContext } from "../context/StdinContext"
|
||||
import { getModelList } from "./ModelPicker"
|
||||
import { SearchableList } from "./SearchableList"
|
||||
|
||||
type FlowStep = "arn_input" | "base_model"
|
||||
|
||||
interface BedrockCustomModelFlowProps {
|
||||
/** Whether this component should capture keyboard input */
|
||||
isActive: boolean
|
||||
/** Called when the user completes both steps (ARN + base model selection) */
|
||||
onComplete: (arn: string, baseModelId: string) => void
|
||||
/** Called when the user presses Escape on the first step (ARN input) */
|
||||
onCancel: () => void
|
||||
}
|
||||
|
||||
export const BedrockCustomModelFlow: React.FC<BedrockCustomModelFlowProps> = ({ isActive, onComplete, onCancel }) => {
|
||||
const { isRawModeSupported } = useStdinContext()
|
||||
const [step, setStep] = useState<FlowStep>("arn_input")
|
||||
const [customArn, setCustomArn] = useState("")
|
||||
|
||||
const handleArnSubmit = useCallback(() => {
|
||||
if (customArn.trim()) {
|
||||
setStep("base_model")
|
||||
}
|
||||
}, [customArn])
|
||||
|
||||
const handleBaseModelCancel = useCallback(() => {
|
||||
setStep("arn_input")
|
||||
}, [])
|
||||
|
||||
useInput(
|
||||
(input, key) => {
|
||||
if (step === "arn_input") {
|
||||
if (key.escape) {
|
||||
onCancel()
|
||||
} else if (key.return) {
|
||||
handleArnSubmit()
|
||||
} else if (key.backspace || key.delete) {
|
||||
setCustomArn((prev) => prev.slice(0, -1))
|
||||
} else if (input && !key.ctrl && !key.meta) {
|
||||
setCustomArn((prev) => prev + input)
|
||||
}
|
||||
return
|
||||
}
|
||||
|
||||
if (step === "base_model") {
|
||||
if (key.escape) {
|
||||
handleBaseModelCancel()
|
||||
}
|
||||
// Other input is handled by SearchableList
|
||||
}
|
||||
},
|
||||
{ isActive: isActive && isRawModeSupported },
|
||||
)
|
||||
|
||||
if (step === "arn_input") {
|
||||
return (
|
||||
<Box flexDirection="column">
|
||||
<Text bold color={COLORS.primaryBlue}>
|
||||
Custom Model ID
|
||||
</Text>
|
||||
<Box marginTop={1}>
|
||||
<Text color="gray">Enter your Application Inference Profile ARN or custom model ID</Text>
|
||||
</Box>
|
||||
<Box marginTop={1}>
|
||||
{customArn ? (
|
||||
<Text color="white">{customArn}</Text>
|
||||
) : (
|
||||
<Text color="gray">e.g. arn:aws:bedrock:region:account:application-inference-profile/...</Text>
|
||||
)}
|
||||
<Text inverse> </Text>
|
||||
</Box>
|
||||
<Box marginTop={1}>
|
||||
<Text color="gray">Enter to continue, Esc to go back</Text>
|
||||
</Box>
|
||||
</Box>
|
||||
)
|
||||
}
|
||||
|
||||
// step === "base_model"
|
||||
return (
|
||||
<Box flexDirection="column">
|
||||
<Text bold color={COLORS.primaryBlue}>
|
||||
Base Inference Model
|
||||
</Text>
|
||||
<Text color="gray">Select the base model your inference profile uses (for capability detection)</Text>
|
||||
<Box marginTop={1}>
|
||||
<SearchableList
|
||||
isActive={isActive && step === "base_model"}
|
||||
items={getModelList("bedrock").map((id) => ({ id, label: id }))}
|
||||
onSelect={(item) => {
|
||||
onComplete(customArn, item.id)
|
||||
}}
|
||||
/>
|
||||
</Box>
|
||||
<Box marginTop={1}>
|
||||
<Text color="gray">Type to search, arrows to navigate, Enter to select, Esc to go back</Text>
|
||||
</Box>
|
||||
</Box>
|
||||
)
|
||||
}
|
||||
@@ -114,8 +114,11 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
|
||||
// Filtered regions
|
||||
const filteredRegions = useMemo(() => {
|
||||
const search = regionSearch.toLowerCase()
|
||||
return search ? AWS_REGIONS.filter((r) => r.includes(search)) : AWS_REGIONS
|
||||
const search = regionSearch.toLowerCase().trim()
|
||||
if (!search) {
|
||||
return AWS_REGIONS
|
||||
}
|
||||
return AWS_REGIONS.filter((r) => r.toLowerCase().includes(search))
|
||||
}, [regionSearch])
|
||||
|
||||
const {
|
||||
@@ -170,10 +173,18 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
}
|
||||
}, [step, authMethod, onCancel])
|
||||
|
||||
const getSelectedRegion = useCallback(() => {
|
||||
if (filteredRegions.length > 0 && regionIndex >= 0 && regionIndex < filteredRegions.length) {
|
||||
return filteredRegions[regionIndex]
|
||||
}
|
||||
// If no matches, use the search term as custom region
|
||||
return regionSearch.trim() || "us-east-1"
|
||||
}, [filteredRegions, regionIndex, regionSearch])
|
||||
|
||||
const finish = useCallback(() => {
|
||||
const config: BedrockConfig = {
|
||||
awsAuthentication: authMethod === "default" ? "credentials" : authMethod,
|
||||
awsRegion: filteredRegions[regionIndex] || "us-east-1",
|
||||
awsRegion: getSelectedRegion(),
|
||||
awsUseCrossRegionInference: crossRegion,
|
||||
}
|
||||
if (authMethod === "profile") {
|
||||
@@ -184,7 +195,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
if (sessionToken) config.awsSessionToken = sessionToken
|
||||
}
|
||||
onComplete(config)
|
||||
}, [authMethod, profileName, accessKey, secretKey, sessionToken, filteredRegions, regionIndex, crossRegion, onComplete])
|
||||
}, [authMethod, profileName, accessKey, secretKey, sessionToken, getSelectedRegion, crossRegion, onComplete])
|
||||
|
||||
// Handle input for auth_method, region, and options steps
|
||||
useInput(
|
||||
@@ -204,11 +215,11 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
} else if (step === "region") {
|
||||
if (key.escape) {
|
||||
goBack()
|
||||
} else if (key.upArrow) {
|
||||
} else if (key.upArrow && filteredRegions.length > 0) {
|
||||
setRegionIndex((prev) => (prev > 0 ? prev - 1 : filteredRegions.length - 1))
|
||||
} else if (key.downArrow) {
|
||||
} else if (key.downArrow && filteredRegions.length > 0) {
|
||||
setRegionIndex((prev) => (prev < filteredRegions.length - 1 ? prev + 1 : 0))
|
||||
} else if (key.return && filteredRegions.length > 0) {
|
||||
} else if (key.return && (filteredRegions.length > 0 || regionSearch.trim())) {
|
||||
setStep("options")
|
||||
} else if (key.backspace || key.delete) {
|
||||
setRegionSearch((prev) => prev.slice(0, -1))
|
||||
@@ -330,7 +341,7 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
<Text color="white">AWS Region</Text>
|
||||
<Text> </Text>
|
||||
<Box>
|
||||
<Text color="gray">Search: </Text>
|
||||
<Text color="gray">Search or enter custom region: </Text>
|
||||
<Text color="white">{regionSearch}</Text>
|
||||
<Text inverse> </Text>
|
||||
</Box>
|
||||
@@ -350,7 +361,6 @@ export const BedrockSetup: React.FC<BedrockSetupProps> = ({ isActive, onComplete
|
||||
{showRegionBottom && (
|
||||
<Text color="gray">... {filteredRegions.length - regionVisibleStart - regionVisibleCount} more below</Text>
|
||||
)}
|
||||
{filteredRegions.length === 0 && <Text color="gray">No regions match "{regionSearch}"</Text>}
|
||||
<Text> </Text>
|
||||
<Text color="gray">Type to search, arrows to navigate, Enter to select, Esc to go back</Text>
|
||||
</Box>
|
||||
|
||||
@@ -150,6 +150,7 @@ import { HighlightedInput } from "./HighlightedInput"
|
||||
import { HistoryPanelContent } from "./HistoryPanelContent"
|
||||
import { providerModels } from "./ModelPicker"
|
||||
import { SettingsPanelContent } from "./SettingsPanelContent"
|
||||
import { SkillsPanelContent } from "./SkillsPanelContent"
|
||||
import { SlashCommandMenu } from "./SlashCommandMenu"
|
||||
import { ThinkingIndicator } from "./ThinkingIndicator"
|
||||
|
||||
@@ -412,6 +413,7 @@ export const ChatView: React.FC<ChatViewProps> = ({
|
||||
| { type: "settings"; initialMode?: "model-picker" | "featured-models"; initialModelKey?: "actModelId" | "planModelId" }
|
||||
| { type: "history" }
|
||||
| { type: "help" }
|
||||
| { type: "skills" }
|
||||
| null
|
||||
>(null)
|
||||
|
||||
@@ -1156,13 +1158,21 @@ export const ChatView: React.FC<ChatViewProps> = ({
|
||||
setSlashMenuDismissed(true)
|
||||
return
|
||||
}
|
||||
if (cmd.name === "skills") {
|
||||
setActivePanel({ type: "skills" })
|
||||
setTextInput("")
|
||||
setCursorPos(0)
|
||||
setSelectedSlashIndex(0)
|
||||
setSlashMenuDismissed(true)
|
||||
return
|
||||
}
|
||||
if (cmd.name === "clear") {
|
||||
clearViewAndResetTask()
|
||||
setSelectedSlashIndex(0)
|
||||
setSlashMenuDismissed(true)
|
||||
return
|
||||
}
|
||||
if (cmd.name === "exit") {
|
||||
if (cmd.name === "exit" || cmd.name === "q") {
|
||||
handleExit()
|
||||
return
|
||||
}
|
||||
@@ -1545,6 +1555,19 @@ export const ChatView: React.FC<ChatViewProps> = ({
|
||||
{/* Help panel */}
|
||||
{activePanel?.type === "help" && <HelpPanelContent onClose={() => setActivePanel(null)} />}
|
||||
|
||||
{/* Skills panel */}
|
||||
{activePanel?.type === "skills" && ctrl && (
|
||||
<SkillsPanelContent
|
||||
controller={ctrl}
|
||||
onClose={() => setActivePanel(null)}
|
||||
onUseSkill={(skillPath) => {
|
||||
setActivePanel(null)
|
||||
setTextInput(`@${skillPath} `)
|
||||
setCursorPos(skillPath.length + 2)
|
||||
}}
|
||||
/>
|
||||
)}
|
||||
|
||||
{/* Slash command menu - below input (takes priority over file menu) */}
|
||||
{showSlashMenu && !activePanel && (
|
||||
<Box paddingLeft={1} paddingRight={1}>
|
||||
|
||||
@@ -7,13 +7,14 @@
|
||||
import { Box, Text } from "ink"
|
||||
import React from "react"
|
||||
import { COLORS } from "../constants/colors"
|
||||
import { type FeaturedModel, getAllFeaturedModels } from "../constants/featured-models"
|
||||
import type { FeaturedModel } from "../constants/featured-models"
|
||||
|
||||
interface FeaturedModelPickerProps {
|
||||
selectedIndex: number
|
||||
title?: string
|
||||
showBrowseAll?: boolean
|
||||
helpText?: string
|
||||
featuredModels: FeaturedModel[]
|
||||
}
|
||||
|
||||
export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
|
||||
@@ -21,8 +22,9 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
|
||||
title,
|
||||
showBrowseAll = true,
|
||||
helpText = "Arrows to navigate, Enter to select",
|
||||
featuredModels,
|
||||
}) => {
|
||||
const featuredModels = getAllFeaturedModels()
|
||||
const models = featuredModels
|
||||
|
||||
return (
|
||||
<Box flexDirection="column">
|
||||
@@ -35,11 +37,11 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
|
||||
</Text>
|
||||
)}
|
||||
|
||||
{featuredModels.map((model, i) => {
|
||||
{models.map((model, i) => {
|
||||
const isSelected = i === selectedIndex
|
||||
|
||||
return (
|
||||
<Box flexDirection="column" key={model.id} marginBottom={1}>
|
||||
<Box flexDirection="column" key={`${model.id}-${model.labels[0] || "default"}`} marginBottom={1}>
|
||||
<Box>
|
||||
<Text color={isSelected ? COLORS.primaryBlue : undefined}>{isSelected ? "❯ " : " "}</Text>
|
||||
<Text bold color={isSelected ? COLORS.primaryBlue : "white"}>
|
||||
@@ -64,8 +66,8 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
|
||||
|
||||
{showBrowseAll && (
|
||||
<Box>
|
||||
<Text color={selectedIndex === featuredModels.length ? COLORS.primaryBlue : "white"}>
|
||||
{selectedIndex === featuredModels.length ? "❯ " : " "}
|
||||
<Text color={selectedIndex === models.length ? COLORS.primaryBlue : "white"}>
|
||||
{selectedIndex === models.length ? "❯ " : " "}
|
||||
Browse all models...
|
||||
</Text>
|
||||
</Box>
|
||||
@@ -81,24 +83,21 @@ export const FeaturedModelPicker: React.FC<FeaturedModelPickerProps> = ({
|
||||
* Get the maximum valid index for the featured model picker
|
||||
* (includes "Browse all" option if showBrowseAll is true)
|
||||
*/
|
||||
export function getFeaturedModelMaxIndex(showBrowseAll: boolean = true): number {
|
||||
const featuredModels = getAllFeaturedModels()
|
||||
export function getFeaturedModelMaxIndex(featuredModels: FeaturedModel[], showBrowseAll = true): number {
|
||||
return showBrowseAll ? featuredModels.length : featuredModels.length - 1
|
||||
}
|
||||
|
||||
/**
|
||||
* Check if the selected index is the "Browse all" option
|
||||
*/
|
||||
export function isBrowseAllSelected(selectedIndex: number): boolean {
|
||||
const featuredModels = getAllFeaturedModels()
|
||||
export function isBrowseAllSelected(selectedIndex: number, featuredModels: FeaturedModel[]): boolean {
|
||||
return selectedIndex === featuredModels.length
|
||||
}
|
||||
|
||||
/**
|
||||
* Get the featured model at the given index, or null if "Browse all" is selected
|
||||
*/
|
||||
export function getFeaturedModelAtIndex(index: number): FeaturedModel | null {
|
||||
const featuredModels = getAllFeaturedModels()
|
||||
export function getFeaturedModelAtIndex(index: number, featuredModels: FeaturedModel[]): FeaturedModel | null {
|
||||
if (index >= 0 && index < featuredModels.length) {
|
||||
return featuredModels[index]
|
||||
}
|
||||
|
||||
@@ -88,6 +88,10 @@ export const HelpPanelContent: React.FC<HelpPanelContentProps> = ({ onClose }) =
|
||||
{" "}
|
||||
<Text color="white">/clear</Text> - Start a fresh task
|
||||
</Text>
|
||||
<Text>
|
||||
{" "}
|
||||
<Text color="white">/q</Text> - Quit Cline
|
||||
</Text>
|
||||
</Box>
|
||||
|
||||
<Text>
|
||||
|
||||
@@ -71,6 +71,9 @@ import { COLORS } from "../constants/colors"
|
||||
import { getOpenRouterDefaultModelId, usesOpenRouterModels } from "../utils/openrouter-models"
|
||||
import { SearchableList, SearchableListItem } from "./SearchableList"
|
||||
|
||||
// Special ID used to indicate the user wants to enter a custom model ID / ARN
|
||||
export const CUSTOM_MODEL_ID = "__custom__"
|
||||
|
||||
// Map providers to their static model lists and defaults
|
||||
export const providerModels: Record<string, { models: Record<string, unknown>; defaultId: string }> = {
|
||||
anthropic: { models: anthropicModels, defaultId: anthropicDefaultModelId },
|
||||
@@ -169,12 +172,23 @@ export const ModelPicker: React.FC<ModelPickerProps> = ({ provider, controller,
|
||||
return getModelList(provider)
|
||||
}, [provider, asyncModels])
|
||||
|
||||
// Providers that support custom model IDs (e.g., Bedrock Application Inference Profiles)
|
||||
const supportsCustomModel = provider === "bedrock"
|
||||
|
||||
const items: SearchableListItem[] = useMemo(() => {
|
||||
return modelList.map((modelId) => ({
|
||||
const list = modelList.map((modelId) => ({
|
||||
id: modelId,
|
||||
label: modelId,
|
||||
}))
|
||||
}, [modelList])
|
||||
// Add "Custom" option at the end for providers that support it
|
||||
if (supportsCustomModel) {
|
||||
list.push({
|
||||
id: CUSTOM_MODEL_ID,
|
||||
label: "Custom (ARN / Inference Profile)",
|
||||
})
|
||||
}
|
||||
return list
|
||||
}, [modelList, supportsCustomModel])
|
||||
|
||||
// For providers without a model picker, render nothing
|
||||
if (!hasModelPicker(provider)) {
|
||||
|
||||
@@ -0,0 +1,112 @@
|
||||
import { render } from "ink-testing-library"
|
||||
// biome-ignore lint/correctness/noUnusedImports: React must be in scope for JSX in this test file.
|
||||
import React from "react"
|
||||
import { beforeEach, describe, expect, it, vi } from "vitest"
|
||||
|
||||
// Mock ink's useApp
|
||||
const mockExit = vi.fn()
|
||||
vi.mock("ink", async (importOriginal) => {
|
||||
const actual = await importOriginal<typeof import("ink")>()
|
||||
return {
|
||||
...actual,
|
||||
useApp: () => ({ exit: mockExit }),
|
||||
}
|
||||
})
|
||||
|
||||
// Mock child_process
|
||||
vi.mock("child_process", () => ({
|
||||
execSync: vi.fn().mockReturnValue(""),
|
||||
exec: vi.fn(),
|
||||
}))
|
||||
|
||||
// Mock dependencies
|
||||
vi.mock("@/core/controller/slash/getAvailableSlashCommands", () => ({
|
||||
getAvailableSlashCommands: vi.fn().mockResolvedValue({ commands: [] }),
|
||||
}))
|
||||
|
||||
vi.mock("@/core/storage/StateManager", () => ({
|
||||
StateManager: {
|
||||
get: () => ({
|
||||
getGlobalSettingsKey: vi.fn().mockReturnValue("act"),
|
||||
getGlobalStateKey: vi.fn().mockReturnValue([]),
|
||||
getApiConfiguration: vi.fn().mockReturnValue({}),
|
||||
}),
|
||||
},
|
||||
}))
|
||||
|
||||
vi.mock("@/services/telemetry", () => ({
|
||||
telemetryService: {
|
||||
captureHostEvent: vi.fn(),
|
||||
},
|
||||
}))
|
||||
|
||||
vi.mock("@shared/services/Session", () => ({
|
||||
Session: {
|
||||
get: () => ({
|
||||
getStats: vi.fn().mockReturnValue({}),
|
||||
}),
|
||||
},
|
||||
}))
|
||||
|
||||
vi.mock("../context/TaskContext", () => ({
|
||||
useTaskContext: () => ({
|
||||
controller: {},
|
||||
clearState: vi.fn(),
|
||||
}),
|
||||
useTaskState: () => ({
|
||||
clineMessages: [],
|
||||
}),
|
||||
}))
|
||||
|
||||
vi.mock("../hooks/useStateSubscriber", () => ({
|
||||
useIsSpinnerActive: () => ({ isActive: false, startTime: 0 }),
|
||||
}))
|
||||
|
||||
import { ChatView } from "./ChatView"
|
||||
|
||||
// Helper to wait for async state updates
|
||||
const delay = (ms = 60) => new Promise((resolve) => setTimeout(resolve, ms))
|
||||
|
||||
describe("Quit Command (/q and /exit)", () => {
|
||||
const mockOnExit = vi.fn()
|
||||
|
||||
beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
})
|
||||
|
||||
it("should exit the application when /q is selected from slash menu", async () => {
|
||||
const { stdin } = render(<ChatView onExit={mockOnExit} />)
|
||||
await delay()
|
||||
|
||||
// Type /q
|
||||
stdin.write("/q")
|
||||
await delay()
|
||||
|
||||
// Press Enter
|
||||
stdin.write("\r")
|
||||
|
||||
// handleExit has a 150ms timeout
|
||||
await delay(200)
|
||||
|
||||
expect(mockExit).toHaveBeenCalled()
|
||||
expect(mockOnExit).toHaveBeenCalled()
|
||||
})
|
||||
|
||||
it("should exit the application when /exit is selected from slash menu", async () => {
|
||||
const { stdin } = render(<ChatView onExit={mockOnExit} />)
|
||||
await delay()
|
||||
|
||||
// Type /exit
|
||||
stdin.write("/exit")
|
||||
await delay()
|
||||
|
||||
// Press Enter
|
||||
stdin.write("\r")
|
||||
|
||||
// handleExit has a 150ms timeout
|
||||
await delay(200)
|
||||
|
||||
expect(mockExit).toHaveBeenCalled()
|
||||
expect(mockOnExit).toHaveBeenCalled()
|
||||
})
|
||||
})
|
||||
@@ -25,10 +25,12 @@ import { supportsReasoningEffortForModel } from "@/utils/model-utils"
|
||||
import { version as CLI_VERSION } from "../../package.json"
|
||||
import { COLORS } from "../constants/colors"
|
||||
import { useStdinContext } from "../context/StdinContext"
|
||||
import { useClineFeaturedModels } from "../hooks/useClineFeaturedModels"
|
||||
import { useOcaAuth } from "../hooks/useOcaAuth"
|
||||
import { isMouseEscapeSequence } from "../utils/input"
|
||||
import { applyBedrockConfig, applyProviderConfig } from "../utils/provider-config"
|
||||
import { ApiKeyInput } from "./ApiKeyInput"
|
||||
import { BedrockCustomModelFlow } from "./BedrockCustomModelFlow"
|
||||
import { type BedrockConfig, BedrockSetup } from "./BedrockSetup"
|
||||
import { Checkbox } from "./Checkbox"
|
||||
import {
|
||||
@@ -38,7 +40,7 @@ import {
|
||||
isBrowseAllSelected,
|
||||
} from "./FeaturedModelPicker"
|
||||
import { LanguagePicker } from "./LanguagePicker"
|
||||
import { hasModelPicker, ModelPicker } from "./ModelPicker"
|
||||
import { CUSTOM_MODEL_ID, hasModelPicker, ModelPicker } from "./ModelPicker"
|
||||
import { OcaEmployeeCheck } from "./OcaEmployeeCheck"
|
||||
import { OrganizationPicker } from "./OrganizationPicker"
|
||||
import { Panel, PanelTab } from "./Panel"
|
||||
@@ -160,6 +162,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
)
|
||||
const [isPickingFeaturedModel, setIsPickingFeaturedModel] = useState(initialMode === "featured-models")
|
||||
const [featuredModelIndex, setFeaturedModelIndex] = useState(0)
|
||||
const featuredModels = useClineFeaturedModels()
|
||||
const [isPickingProvider, setIsPickingProvider] = useState(false)
|
||||
const [isPickingLanguage, setIsPickingLanguage] = useState(false)
|
||||
const [isEnteringApiKey, setIsEnteringApiKey] = useState(false)
|
||||
@@ -171,6 +174,9 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
const [apiKeyValue, setApiKeyValue] = useState("")
|
||||
const [editValue, setEditValue] = useState("")
|
||||
|
||||
// Bedrock custom ARN flow state
|
||||
const [isBedrockCustomFlow, setIsBedrockCustomFlow] = useState(false)
|
||||
|
||||
// Settings state - single object for feature toggles
|
||||
const [features, setFeatures] = useState<Record<FeatureKey, boolean>>(() => {
|
||||
const initial: Record<string, boolean> = {}
|
||||
@@ -944,10 +950,56 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
setReasoningEffortForMode,
|
||||
])
|
||||
|
||||
// Handle completion of the Bedrock custom ARN flow (ARN + base model selected)
|
||||
const handleBedrockCustomFlowComplete = useCallback(
|
||||
async (arn: string, baseModelId: string) => {
|
||||
if (!pickingModelKey) return
|
||||
const apiConfig = stateManager.getApiConfiguration()
|
||||
|
||||
// Build a minimal BedrockConfig from current state for applyBedrockConfig
|
||||
const bedrockConfig: BedrockConfig = {
|
||||
awsRegion: apiConfig.awsRegion ?? "us-east-1",
|
||||
awsAuthentication: apiConfig.awsUseProfile ? "profile" : "credentials",
|
||||
awsUseCrossRegionInference: Boolean(apiConfig.awsUseCrossRegionInference),
|
||||
}
|
||||
|
||||
await applyBedrockConfig({
|
||||
bedrockConfig,
|
||||
modelId: arn,
|
||||
customModelBaseId: baseModelId,
|
||||
controller,
|
||||
})
|
||||
|
||||
// Flush pending state to ensure everything is persisted
|
||||
await stateManager.flushPendingState()
|
||||
|
||||
// Rebuild API handler if there's an active task
|
||||
rebuildTaskApi()
|
||||
|
||||
refreshModelIds()
|
||||
setIsBedrockCustomFlow(false)
|
||||
setPickingModelKey(null)
|
||||
|
||||
// If opened from /models command, close the entire settings panel
|
||||
if (initialMode) {
|
||||
onClose()
|
||||
}
|
||||
},
|
||||
[pickingModelKey, stateManager, controller, rebuildTaskApi, refreshModelIds, initialMode, onClose],
|
||||
)
|
||||
|
||||
// Handle model selection from picker
|
||||
const handleModelSelect = useCallback(
|
||||
async (modelId: string) => {
|
||||
if (!pickingModelKey) return
|
||||
|
||||
// Intercept "Custom" selection for Bedrock — redirect to custom ARN input flow
|
||||
if (modelId === CUSTOM_MODEL_ID && provider === "bedrock") {
|
||||
setIsPickingModel(false)
|
||||
setIsBedrockCustomFlow(true)
|
||||
return
|
||||
}
|
||||
|
||||
const apiConfig = stateManager.getApiConfiguration()
|
||||
const actProvider = apiConfig.actModeApiProvider
|
||||
const planProvider = apiConfig.planModeApiProvider || actProvider
|
||||
@@ -1008,7 +1060,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
onClose()
|
||||
}
|
||||
},
|
||||
[pickingModelKey, separateModels, stateManager, controller, refreshModelIds, initialMode, onClose],
|
||||
[pickingModelKey, separateModels, stateManager, controller, provider, refreshModelIds, initialMode, onClose],
|
||||
)
|
||||
|
||||
// Handle language selection from picker
|
||||
@@ -1242,7 +1294,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
|
||||
// Featured model picker mode (Cline provider)
|
||||
if (isPickingFeaturedModel) {
|
||||
const maxIndex = getFeaturedModelMaxIndex()
|
||||
const maxIndex = getFeaturedModelMaxIndex(featuredModels)
|
||||
|
||||
if (key.escape) {
|
||||
setIsPickingFeaturedModel(false)
|
||||
@@ -1256,12 +1308,12 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
} else if (key.downArrow) {
|
||||
setFeaturedModelIndex((prev) => (prev < maxIndex ? prev + 1 : 0))
|
||||
} else if (key.return) {
|
||||
if (isBrowseAllSelected(featuredModelIndex)) {
|
||||
if (isBrowseAllSelected(featuredModelIndex, featuredModels)) {
|
||||
// Switch to full ModelPicker
|
||||
setIsPickingFeaturedModel(false)
|
||||
setIsPickingModel(true)
|
||||
} else {
|
||||
const selectedModel = getFeaturedModelAtIndex(featuredModelIndex)
|
||||
const selectedModel = getFeaturedModelAtIndex(featuredModelIndex, featuredModels)
|
||||
if (selectedModel && pickingModelKey) {
|
||||
handleModelSelect(selectedModel.id)
|
||||
setIsPickingFeaturedModel(false)
|
||||
@@ -1332,6 +1384,11 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
return
|
||||
}
|
||||
|
||||
// Bedrock custom flow - input handled by BedrockCustomModelFlow component
|
||||
if (isBedrockCustomFlow) {
|
||||
return
|
||||
}
|
||||
|
||||
if (isEditing) {
|
||||
if (key.escape) {
|
||||
setIsEditing(false)
|
||||
@@ -1467,6 +1524,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
const label = pickingModelKey === "actModelId" ? "Model ID (Act)" : "Model ID (Plan)"
|
||||
return (
|
||||
<FeaturedModelPicker
|
||||
featuredModels={featuredModels}
|
||||
helpText="Arrows to navigate, Enter to select, Esc to cancel"
|
||||
selectedIndex={featuredModelIndex}
|
||||
title={`Select: ${label}`}
|
||||
@@ -1584,6 +1642,20 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
)
|
||||
}
|
||||
|
||||
// Bedrock custom model flow (ARN input + base model selection)
|
||||
if (isBedrockCustomFlow) {
|
||||
return (
|
||||
<BedrockCustomModelFlow
|
||||
isActive={isBedrockCustomFlow}
|
||||
onCancel={() => {
|
||||
setIsBedrockCustomFlow(false)
|
||||
setIsPickingModel(true)
|
||||
}}
|
||||
onComplete={handleBedrockCustomFlowComplete}
|
||||
/>
|
||||
)
|
||||
}
|
||||
|
||||
// Account tab - loading state
|
||||
if (currentTab === "account" && isAccountLoading) {
|
||||
return (
|
||||
@@ -1748,6 +1820,7 @@ export const SettingsPanelContent: React.FC<SettingsPanelContentProps> = ({
|
||||
isWaitingForClineAuth ||
|
||||
isShowingOcaEmployeeCheck ||
|
||||
isWaitingForOcaAuth ||
|
||||
isBedrockCustomFlow ||
|
||||
isEditing
|
||||
|
||||
return (
|
||||
|
||||
@@ -0,0 +1,230 @@
|
||||
/**
|
||||
* Tests for SkillsPanelContent component
|
||||
*
|
||||
* Tests keyboard interactions and callbacks.
|
||||
* Rendering tests are limited due to ink-testing-library constraints with nested components.
|
||||
*/
|
||||
|
||||
import { render } from "ink-testing-library"
|
||||
// biome-ignore lint/correctness/noUnusedImports: React must be in scope for JSX in this test file.
|
||||
import React from "react"
|
||||
import { beforeEach, describe, expect, it, vi } from "vitest"
|
||||
|
||||
// Mock refreshSkills
|
||||
const mockRefreshSkills = vi.fn()
|
||||
vi.mock("@/core/controller/file/refreshSkills", () => ({
|
||||
refreshSkills: () => mockRefreshSkills(),
|
||||
}))
|
||||
|
||||
// Mock toggleSkill
|
||||
const mockToggleSkill = vi.fn()
|
||||
vi.mock("@/core/controller/file/toggleSkill", () => ({
|
||||
toggleSkill: (...args: unknown[]) => mockToggleSkill(...args),
|
||||
}))
|
||||
|
||||
// Mock child_process exec
|
||||
const mockExec = vi.fn()
|
||||
vi.mock("node:child_process", () => ({
|
||||
exec: (...args: unknown[]) => mockExec(...args),
|
||||
}))
|
||||
|
||||
// Mock StdinContext
|
||||
vi.mock("../context/StdinContext", () => ({
|
||||
useStdinContext: () => ({ isRawModeSupported: true }),
|
||||
}))
|
||||
|
||||
import { SkillsPanelContent } from "./SkillsPanelContent"
|
||||
|
||||
// Helper to wait for async state updates
|
||||
const delay = (ms = 60) => new Promise((resolve) => setTimeout(resolve, ms))
|
||||
|
||||
describe("SkillsPanelContent", () => {
|
||||
const mockController = {} as any
|
||||
const mockOnClose = vi.fn()
|
||||
const mockOnUseSkill = vi.fn()
|
||||
|
||||
const defaultProps = {
|
||||
controller: mockController,
|
||||
onClose: mockOnClose,
|
||||
onUseSkill: mockOnUseSkill,
|
||||
}
|
||||
|
||||
beforeEach(() => {
|
||||
vi.clearAllMocks()
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [],
|
||||
localSkills: [],
|
||||
})
|
||||
})
|
||||
|
||||
describe("keyboard interactions", () => {
|
||||
it("should call onClose when Escape is pressed", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
stdin.write("\x1B") // Escape
|
||||
await delay()
|
||||
|
||||
expect(mockOnClose).toHaveBeenCalled()
|
||||
})
|
||||
|
||||
it("should call onUseSkill with skill path when Enter is pressed on a skill", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
stdin.write("\r") // Enter
|
||||
await delay()
|
||||
|
||||
expect(mockOnUseSkill).toHaveBeenCalledWith("/test/path/SKILL.md")
|
||||
})
|
||||
|
||||
it("should call toggleSkill when Space is pressed on a skill", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
stdin.write(" ") // Space
|
||||
await delay()
|
||||
|
||||
expect(mockToggleSkill).toHaveBeenCalledWith(
|
||||
mockController,
|
||||
expect.objectContaining({
|
||||
skillPath: "/test/path/SKILL.md",
|
||||
isGlobal: true,
|
||||
enabled: false, // toggled from true to false
|
||||
}),
|
||||
)
|
||||
})
|
||||
|
||||
it("should open marketplace URL when Enter is pressed on marketplace item", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [{ name: "skill", description: "desc", path: "/path", enabled: true }],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
// Navigate down to marketplace (past the one skill)
|
||||
stdin.write("\x1B[B") // Down arrow
|
||||
await delay()
|
||||
|
||||
stdin.write("\r") // Enter
|
||||
await delay()
|
||||
|
||||
// Should have called exec with open command
|
||||
expect(mockExec).toHaveBeenCalled()
|
||||
const execCall = mockExec.mock.calls[0][0]
|
||||
expect(execCall).toContain("https://skills.sh/")
|
||||
})
|
||||
|
||||
it("should navigate through skills with arrow keys", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [
|
||||
{ name: "skill-1", description: "First", path: "/path1", enabled: true },
|
||||
{ name: "skill-2", description: "Second", path: "/path2", enabled: true },
|
||||
],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
// Navigate down
|
||||
stdin.write("\x1B[B") // Down arrow
|
||||
await delay()
|
||||
|
||||
// Press Enter - should use second skill
|
||||
stdin.write("\r")
|
||||
await delay()
|
||||
|
||||
expect(mockOnUseSkill).toHaveBeenCalledWith("/path2")
|
||||
})
|
||||
|
||||
it("should navigate with vim keys (j/k)", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [
|
||||
{ name: "skill-1", description: "First", path: "/path1", enabled: true },
|
||||
{ name: "skill-2", description: "Second", path: "/path2", enabled: true },
|
||||
],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
// Navigate down with j
|
||||
stdin.write("j")
|
||||
await delay()
|
||||
|
||||
// Press Enter - should use second skill
|
||||
stdin.write("\r")
|
||||
await delay()
|
||||
|
||||
expect(mockOnUseSkill).toHaveBeenCalledWith("/path2")
|
||||
})
|
||||
|
||||
it("should revert optimistic toggle on failure", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [{ name: "test-skill", description: "Test", path: "/test/path/SKILL.md", enabled: true }],
|
||||
localSkills: [],
|
||||
})
|
||||
mockToggleSkill.mockRejectedValueOnce(new Error("toggle failed"))
|
||||
|
||||
const { stdin, lastFrame } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
stdin.write(" ") // Space to toggle
|
||||
await delay(100)
|
||||
|
||||
// toggleSkill was called with enabled: false (toggled from true)
|
||||
expect(mockToggleSkill).toHaveBeenCalledWith(mockController, expect.objectContaining({ enabled: false }))
|
||||
const frame = lastFrame() || ""
|
||||
expect(frame).toContain("● test-skill")
|
||||
expect(frame).not.toContain("○ test-skill")
|
||||
})
|
||||
|
||||
it("should wrap navigation at list boundaries", async () => {
|
||||
mockRefreshSkills.mockResolvedValue({
|
||||
globalSkills: [{ name: "only-skill", description: "Only", path: "/only", enabled: true }],
|
||||
localSkills: [],
|
||||
})
|
||||
|
||||
const { stdin } = render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
// Navigate up from first item (should wrap to last - marketplace)
|
||||
stdin.write("\x1B[A") // Up arrow
|
||||
await delay()
|
||||
|
||||
stdin.write("\r") // Enter
|
||||
await delay()
|
||||
|
||||
// Should have opened marketplace (wrapped to last item)
|
||||
expect(mockExec).toHaveBeenCalled()
|
||||
})
|
||||
})
|
||||
|
||||
describe("skill loading", () => {
|
||||
it("should call refreshSkills on mount", async () => {
|
||||
render(<SkillsPanelContent {...defaultProps} />)
|
||||
await delay()
|
||||
|
||||
expect(mockRefreshSkills).toHaveBeenCalled()
|
||||
})
|
||||
})
|
||||
})
|
||||
@@ -0,0 +1,257 @@
|
||||
/**
|
||||
* Skills panel content for inline display in ChatView
|
||||
* Shows installed skills with toggle and use functionality
|
||||
*/
|
||||
|
||||
import { exec } from "node:child_process"
|
||||
import os from "node:os"
|
||||
import { Box, Text, useInput } from "ink"
|
||||
import React, { useCallback, useEffect, useMemo, useState } from "react"
|
||||
import type { Controller } from "@/core/controller"
|
||||
import { refreshSkills } from "@/core/controller/file/refreshSkills"
|
||||
import { toggleSkill } from "@/core/controller/file/toggleSkill"
|
||||
import { COLORS } from "../constants/colors"
|
||||
import { useStdinContext } from "../context/StdinContext"
|
||||
import { isMouseEscapeSequence } from "../utils/input"
|
||||
import { Panel } from "./Panel"
|
||||
|
||||
const SKILLS_MARKETPLACE_URL = "https://skills.sh/"
|
||||
|
||||
interface SkillInfo {
|
||||
name: string
|
||||
description: string
|
||||
path: string
|
||||
enabled: boolean
|
||||
}
|
||||
|
||||
interface SkillsPanelContentProps {
|
||||
controller: Controller
|
||||
onClose: () => void
|
||||
onUseSkill: (skillPath: string) => void
|
||||
}
|
||||
|
||||
const MAX_VISIBLE = 8
|
||||
|
||||
export const SkillsPanelContent: React.FC<SkillsPanelContentProps> = ({ controller, onClose, onUseSkill }) => {
|
||||
const { isRawModeSupported } = useStdinContext()
|
||||
const [globalSkills, setGlobalSkills] = useState<SkillInfo[]>([])
|
||||
const [localSkills, setLocalSkills] = useState<SkillInfo[]>([])
|
||||
const [selectedIndex, setSelectedIndex] = useState(0)
|
||||
const [isLoading, setIsLoading] = useState(true)
|
||||
|
||||
// Load skills on mount
|
||||
useEffect(() => {
|
||||
const loadSkills = async () => {
|
||||
try {
|
||||
const skillsData = await refreshSkills(controller)
|
||||
setGlobalSkills(skillsData.globalSkills || [])
|
||||
setLocalSkills(skillsData.localSkills || [])
|
||||
} catch (_error) {
|
||||
// Skills loading failed, show empty state
|
||||
} finally {
|
||||
setIsLoading(false)
|
||||
}
|
||||
}
|
||||
loadSkills()
|
||||
}, [controller])
|
||||
|
||||
// Build flat list of skills with source info (global first, then local, alphabetical within each)
|
||||
const skillEntries = useMemo(() => {
|
||||
const entries: { skill: SkillInfo; isGlobal: boolean }[] = []
|
||||
globalSkills.forEach((skill) => entries.push({ skill, isGlobal: true }))
|
||||
localSkills.forEach((skill) => entries.push({ skill, isGlobal: false }))
|
||||
return entries.sort((a, b) => {
|
||||
if (a.isGlobal !== b.isGlobal) return a.isGlobal ? -1 : 1
|
||||
return a.skill.name.localeCompare(b.skill.name)
|
||||
})
|
||||
}, [globalSkills, localSkills])
|
||||
|
||||
// Handle toggle
|
||||
const handleToggle = useCallback(async () => {
|
||||
const entry = skillEntries[selectedIndex]
|
||||
if (!entry) return
|
||||
|
||||
const newEnabled = !entry.skill.enabled
|
||||
const setter = entry.isGlobal ? setGlobalSkills : setLocalSkills
|
||||
const update = (enabled: boolean) =>
|
||||
setter((prev) => prev.map((s) => (s.path === entry.skill.path ? { ...s, enabled } : s)))
|
||||
|
||||
// Optimistic update
|
||||
update(newEnabled)
|
||||
|
||||
try {
|
||||
await toggleSkill(controller, {
|
||||
metadata: undefined,
|
||||
skillPath: entry.skill.path,
|
||||
isGlobal: entry.isGlobal,
|
||||
enabled: newEnabled,
|
||||
})
|
||||
} catch {
|
||||
// Revert on failure
|
||||
update(!newEnabled)
|
||||
}
|
||||
}, [controller, skillEntries, selectedIndex])
|
||||
|
||||
// Handle use skill (insert @ mention)
|
||||
const handleUse = useCallback(() => {
|
||||
const entry = skillEntries[selectedIndex]
|
||||
if (!entry) return
|
||||
onUseSkill(entry.skill.path)
|
||||
}, [skillEntries, selectedIndex, onUseSkill])
|
||||
|
||||
// Handle opening the marketplace URL
|
||||
const openMarketplace = useCallback(() => {
|
||||
const platform = os.platform()
|
||||
let command: string
|
||||
if (platform === "darwin") {
|
||||
command = `open "${SKILLS_MARKETPLACE_URL}"`
|
||||
} else if (platform === "win32") {
|
||||
command = `start "${SKILLS_MARKETPLACE_URL}"`
|
||||
} else {
|
||||
command = `xdg-open "${SKILLS_MARKETPLACE_URL}"`
|
||||
}
|
||||
exec(command, (err) => {
|
||||
if (err) {
|
||||
// Fallback: show URL in terminal if browser open fails
|
||||
console.error(`Visit: ${SKILLS_MARKETPLACE_URL}`)
|
||||
}
|
||||
})
|
||||
}, [])
|
||||
|
||||
// Total items = skills + 1 for marketplace link
|
||||
const totalItems = skillEntries.length + 1
|
||||
const isMarketplaceSelected = selectedIndex === skillEntries.length
|
||||
|
||||
useInput(
|
||||
(input, key) => {
|
||||
if (isMouseEscapeSequence(input)) {
|
||||
return
|
||||
}
|
||||
if (key.escape) {
|
||||
onClose()
|
||||
return
|
||||
}
|
||||
|
||||
// Navigation
|
||||
if (key.upArrow || input === "k") {
|
||||
setSelectedIndex((i) => (i > 0 ? i - 1 : totalItems - 1))
|
||||
return
|
||||
}
|
||||
if (key.downArrow || input === "j") {
|
||||
setSelectedIndex((i) => (i < totalItems - 1 ? i + 1 : 0))
|
||||
return
|
||||
}
|
||||
|
||||
// Actions
|
||||
if (key.return) {
|
||||
if (isMarketplaceSelected) {
|
||||
openMarketplace()
|
||||
} else {
|
||||
handleUse()
|
||||
}
|
||||
return
|
||||
}
|
||||
if (input === " " && !isMarketplaceSelected) {
|
||||
handleToggle()
|
||||
return
|
||||
}
|
||||
},
|
||||
{ isActive: isRawModeSupported },
|
||||
)
|
||||
|
||||
// Scrolling window (includes marketplace row)
|
||||
const halfVisible = Math.floor(MAX_VISIBLE / 2)
|
||||
const startIndex = Math.max(0, Math.min(selectedIndex - halfVisible, totalItems - MAX_VISIBLE))
|
||||
|
||||
if (isLoading) {
|
||||
return (
|
||||
<Panel label="Skills">
|
||||
<Text color="gray">Loading skills...</Text>
|
||||
</Panel>
|
||||
)
|
||||
}
|
||||
|
||||
// Check if marketplace row is in visible window
|
||||
const marketplaceIndex = skillEntries.length
|
||||
const showMarketplace = marketplaceIndex >= startIndex && marketplaceIndex < startIndex + MAX_VISIBLE
|
||||
|
||||
return (
|
||||
<Panel label="Skills">
|
||||
<Box flexDirection="column" gap={1}>
|
||||
{skillEntries.length === 0 ? (
|
||||
<Box flexDirection="column" gap={1}>
|
||||
<Text color="gray">No skills installed.</Text>
|
||||
<Text>
|
||||
Install skills with: <Text color="white">npx skills add owner/repo</Text>
|
||||
</Text>
|
||||
</Box>
|
||||
) : (
|
||||
<Box flexDirection="column">
|
||||
{skillEntries
|
||||
.slice(startIndex, Math.min(startIndex + MAX_VISIBLE, skillEntries.length))
|
||||
.map((entry, idx) => {
|
||||
const actualIndex = startIndex + idx
|
||||
const prevEntry = skillEntries[actualIndex - 1]
|
||||
const showHeader = actualIndex === 0 || (prevEntry && prevEntry.isGlobal !== entry.isGlobal)
|
||||
|
||||
return (
|
||||
<React.Fragment key={entry.skill.path}>
|
||||
{showHeader && (
|
||||
<Box marginTop={actualIndex > 0 ? 1 : 0}>
|
||||
<Text bold color="gray">
|
||||
{entry.isGlobal ? "Global Skills:" : "Workspace Skills:"}
|
||||
</Text>
|
||||
</Box>
|
||||
)}
|
||||
<SkillRow isSelected={actualIndex === selectedIndex} skill={entry.skill} />
|
||||
</React.Fragment>
|
||||
)
|
||||
})}
|
||||
</Box>
|
||||
)}
|
||||
|
||||
{/* Marketplace link - selectable */}
|
||||
{showMarketplace && (
|
||||
<Box marginTop={1}>
|
||||
<Text color={isMarketplaceSelected ? "cyan" : undefined}>
|
||||
{isMarketplaceSelected ? "❯ " : " "}
|
||||
<Text color={COLORS.primaryBlue}>Browse more skills at https://skills.sh/</Text>
|
||||
</Text>
|
||||
</Box>
|
||||
)}
|
||||
|
||||
{/* Help text */}
|
||||
<Box marginTop={1}>
|
||||
<Text color="gray">
|
||||
↑/↓ Navigate • Enter {isMarketplaceSelected ? "Open" : "Use"}
|
||||
{!isMarketplaceSelected && " • Space Toggle"}
|
||||
</Text>
|
||||
</Box>
|
||||
</Box>
|
||||
</Panel>
|
||||
)
|
||||
}
|
||||
|
||||
const SkillRow: React.FC<{ skill: SkillInfo; isSelected: boolean }> = ({ skill, isSelected }) => {
|
||||
return (
|
||||
<Box flexDirection="column">
|
||||
<Box>
|
||||
<Text color={isSelected ? "cyan" : undefined}>
|
||||
{isSelected ? "❯ " : " "}
|
||||
<Text color={skill.enabled ? "green" : "red"}>{skill.enabled ? "●" : "○"}</Text>
|
||||
<Text> </Text>
|
||||
<Text bold color="white">
|
||||
{skill.name}
|
||||
</Text>
|
||||
</Text>
|
||||
</Box>
|
||||
{skill.description && (
|
||||
<Box marginLeft={4}>
|
||||
<Text color="gray">
|
||||
{skill.description.length > 60 ? skill.description.slice(0, 57) + "..." : skill.description}
|
||||
</Text>
|
||||
</Box>
|
||||
)}
|
||||
</Box>
|
||||
)
|
||||
}
|
||||
@@ -1,5 +1,5 @@
|
||||
import { describe, expect, it } from "vitest"
|
||||
import { getAllFeaturedModels } from "./featured-models"
|
||||
import { getAllFeaturedModels, mapRecommendedModelsToFeaturedModels } from "./featured-models"
|
||||
|
||||
describe("featured models", () => {
|
||||
it("includes display names for all featured models", () => {
|
||||
@@ -9,4 +9,15 @@ describe("featured models", () => {
|
||||
expect(model.name).toBeTruthy()
|
||||
}
|
||||
})
|
||||
|
||||
it("fills free model metadata from fallback when upstream payload is sparse", () => {
|
||||
const models = mapRecommendedModelsToFeaturedModels({
|
||||
recommended: [],
|
||||
free: [{ id: "trinity-large-preview:free", name: "trinity-large-preview:free", description: "", tags: [] }],
|
||||
})
|
||||
|
||||
expect(models.free[0]?.name).toBe("Arcee AI Trinity Large Preview")
|
||||
expect(models.free[0]?.description).toBe("Arcee AI's advanced large preview model in the Trinity series")
|
||||
expect(models.free[0]?.labels).toContain("FREE")
|
||||
})
|
||||
})
|
||||
|
||||
@@ -2,6 +2,7 @@
|
||||
* Featured models shown in the Cline model picker during onboarding
|
||||
* These are curated models that work well with Cline
|
||||
*/
|
||||
import { CLINE_RECOMMENDED_MODELS_FALLBACK } from "@shared/cline/recommended-models"
|
||||
|
||||
export interface FeaturedModel {
|
||||
id: string
|
||||
@@ -10,49 +11,81 @@ export interface FeaturedModel {
|
||||
labels: string[]
|
||||
}
|
||||
|
||||
export const FEATURED_MODELS: { recommended: FeaturedModel[]; free: FeaturedModel[] } = {
|
||||
recommended: [
|
||||
{
|
||||
id: "anthropic/claude-opus-4.6",
|
||||
name: "Claude Opus 4.6",
|
||||
description: "State-of-the-art for complex coding",
|
||||
labels: ["BEST"],
|
||||
},
|
||||
{
|
||||
id: "openai/gpt-5.2-codex",
|
||||
name: "GPT 5.2 Codex",
|
||||
description: "OpenAI's latest with strong coding abilities",
|
||||
labels: ["NEW"],
|
||||
},
|
||||
{
|
||||
id: "google/gemini-3-pro-preview",
|
||||
name: "Gemini 3 Pro",
|
||||
description: "1M context window for large codebases",
|
||||
labels: ["TRENDING"],
|
||||
},
|
||||
],
|
||||
free: [
|
||||
{
|
||||
id: "minimax/minimax-m2.5",
|
||||
name: "MiniMax M2.5",
|
||||
description: "MiniMax-M2.5 is a lightweight, state-of-the-art LLM optimized for coding and agentic workflows",
|
||||
labels: ["FREE"],
|
||||
},
|
||||
{
|
||||
id: "kwaipilot/kat-coder-pro",
|
||||
name: "KAT Coder Pro",
|
||||
description: "KwaiKAT's most advanced agentic coding model in the KAT-Coder series",
|
||||
labels: ["FREE"],
|
||||
},
|
||||
{
|
||||
id: "arcee-ai/trinity-large-preview:free",
|
||||
name: "Trinity Large Preview",
|
||||
description: "Arcee AI's advanced large preview model in the Trinity series",
|
||||
labels: ["FREE"],
|
||||
},
|
||||
],
|
||||
type RecommendedModelLike = {
|
||||
id: string
|
||||
name: string
|
||||
description: string
|
||||
tags: string[]
|
||||
}
|
||||
|
||||
export function getAllFeaturedModels(): FeaturedModel[] {
|
||||
return [...FEATURED_MODELS.recommended, ...FEATURED_MODELS.free]
|
||||
export interface FeaturedModelsByTier {
|
||||
recommended: FeaturedModel[]
|
||||
free: FeaturedModel[]
|
||||
}
|
||||
|
||||
interface RecommendedModelsByTier {
|
||||
recommended: RecommendedModelLike[]
|
||||
free: RecommendedModelLike[]
|
||||
}
|
||||
|
||||
function toFeaturedModel(model: RecommendedModelLike): FeaturedModel {
|
||||
return {
|
||||
id: model.id,
|
||||
name: model.name,
|
||||
description: model.description,
|
||||
labels: model.tags,
|
||||
}
|
||||
}
|
||||
|
||||
function getModelIdSuffix(id: string): string {
|
||||
const lastSlashIndex = id.lastIndexOf("/")
|
||||
return lastSlashIndex >= 0 ? id.slice(lastSlashIndex + 1) : id
|
||||
}
|
||||
|
||||
function findFallbackFeaturedModelById(models: FeaturedModel[], id: string): FeaturedModel | undefined {
|
||||
const idSuffix = getModelIdSuffix(id)
|
||||
return models.find((model) => model.id === id || getModelIdSuffix(model.id) === idSuffix)
|
||||
}
|
||||
|
||||
function mapRecommendedModelToFeaturedModelWithFallback(
|
||||
model: RecommendedModelLike,
|
||||
fallbackModels: FeaturedModel[],
|
||||
defaultLabels: string[] = [],
|
||||
): FeaturedModel {
|
||||
const fallbackModel = findFallbackFeaturedModelById(fallbackModels, model.id)
|
||||
const upstreamNameLooksLikeFallback = model.name === model.id || model.name.trim().length === 0
|
||||
const name = upstreamNameLooksLikeFallback ? (fallbackModel?.name ?? model.name) : model.name
|
||||
const description = model.description.trim().length > 0 ? model.description : (fallbackModel?.description ?? "")
|
||||
const labels = model.tags.length > 0 ? model.tags : (fallbackModel?.labels ?? defaultLabels)
|
||||
|
||||
return {
|
||||
id: model.id,
|
||||
name,
|
||||
description,
|
||||
labels,
|
||||
}
|
||||
}
|
||||
|
||||
export const FEATURED_MODELS: FeaturedModelsByTier = {
|
||||
recommended: CLINE_RECOMMENDED_MODELS_FALLBACK.recommended.map(toFeaturedModel),
|
||||
free: CLINE_RECOMMENDED_MODELS_FALLBACK.free.map(toFeaturedModel),
|
||||
}
|
||||
|
||||
export function getAllFeaturedModels(modelsByTier: FeaturedModelsByTier = FEATURED_MODELS): FeaturedModel[] {
|
||||
return [...modelsByTier.recommended, ...modelsByTier.free]
|
||||
}
|
||||
|
||||
export function mapRecommendedModelsToFeaturedModels(data: RecommendedModelsByTier): FeaturedModelsByTier {
|
||||
return {
|
||||
recommended: data.recommended.map((model) =>
|
||||
mapRecommendedModelToFeaturedModelWithFallback(model, FEATURED_MODELS.recommended),
|
||||
),
|
||||
free: data.free.map((model) => mapRecommendedModelToFeaturedModelWithFallback(model, FEATURED_MODELS.free, ["FREE"])),
|
||||
}
|
||||
}
|
||||
|
||||
export function withFeaturedModelFallback(modelsByTier: FeaturedModelsByTier): FeaturedModelsByTier {
|
||||
const recommended = modelsByTier.recommended.length > 0 ? modelsByTier.recommended : FEATURED_MODELS.recommended
|
||||
const free = modelsByTier.free.length > 0 ? modelsByTier.free : FEATURED_MODELS.free
|
||||
return { recommended, free }
|
||||
}
|
||||
|
||||
@@ -0,0 +1,34 @@
|
||||
import { useEffect, useState } from "react"
|
||||
import { refreshClineRecommendedModels } from "@/core/controller/models/refreshClineRecommendedModels"
|
||||
import {
|
||||
type FeaturedModel,
|
||||
getAllFeaturedModels,
|
||||
mapRecommendedModelsToFeaturedModels,
|
||||
withFeaturedModelFallback,
|
||||
} from "../constants/featured-models"
|
||||
|
||||
export function useClineFeaturedModels(): FeaturedModel[] {
|
||||
const [featuredModels, setFeaturedModels] = useState<FeaturedModel[]>(() => getAllFeaturedModels())
|
||||
|
||||
useEffect(() => {
|
||||
let cancelled = false
|
||||
void (async () => {
|
||||
try {
|
||||
const recommendedModels = await refreshClineRecommendedModels()
|
||||
const mappedModels = mapRecommendedModelsToFeaturedModels(recommendedModels)
|
||||
const modelsWithFallback = withFeaturedModelFallback(mappedModels)
|
||||
if (!cancelled) {
|
||||
setFeaturedModels(getAllFeaturedModels(modelsWithFallback))
|
||||
}
|
||||
} catch {
|
||||
// Keep local fallback models on error.
|
||||
}
|
||||
})()
|
||||
|
||||
return () => {
|
||||
cancelled = true
|
||||
}
|
||||
}, [])
|
||||
|
||||
return featuredModels
|
||||
}
|
||||
+11
-42
@@ -8,12 +8,11 @@ import { Command } from "commander"
|
||||
import { render } from "ink"
|
||||
import React from "react"
|
||||
import { ClineEndpoint } from "@/config"
|
||||
import { Controller } from "@/core/controller"
|
||||
import type { Controller } from "@/core/controller"
|
||||
import { StateManager } from "@/core/storage/StateManager"
|
||||
import { AuthHandler } from "@/hosts/external/AuthHandler"
|
||||
import { HostProvider } from "@/hosts/host-provider"
|
||||
import { FileEditProvider } from "@/integrations/editor/FileEditProvider"
|
||||
import { openAiCodexOAuthManager } from "@/integrations/openai-codex/oauth"
|
||||
import { StandaloneTerminalManager } from "@/integrations/terminal/standalone/StandaloneTerminalManager"
|
||||
import { ErrorService } from "@/services/error/ErrorService"
|
||||
import { telemetryService } from "@/services/telemetry"
|
||||
@@ -74,24 +73,7 @@ async function disposeTelemetryServices(): Promise<void> {
|
||||
await Promise.allSettled([telemetryService.dispose(), PostHogClientProvider.getInstance().dispose()])
|
||||
}
|
||||
|
||||
/**
|
||||
* Restore yoloModeToggled to its original value from before this CLI session.
|
||||
* This ensures the --yolo flag is session-only and doesn't leak into future runs.
|
||||
* Must be called before flushPendingState so the restored value gets persisted.
|
||||
*/
|
||||
function restoreYoloState(): void {
|
||||
if (savedYoloModeToggled !== null) {
|
||||
try {
|
||||
StateManager.get().setGlobalState("yoloModeToggled", savedYoloModeToggled)
|
||||
savedYoloModeToggled = null
|
||||
} catch {
|
||||
// StateManager may not be initialized (e.g., early exit before init)
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
async function disposeCliContext(ctx: CliContext): Promise<void> {
|
||||
restoreYoloState()
|
||||
await ctx.controller.stateManager.flushPendingState()
|
||||
await ctx.controller.dispose()
|
||||
await ErrorService.get().dispose()
|
||||
@@ -204,12 +186,10 @@ function applyTaskOptions(options: TaskOptions): void {
|
||||
telemetryService.captureHostEvent("max_consecutive_mistakes_flag", String(maxConsecutiveMistakes))
|
||||
}
|
||||
|
||||
// Override yolo mode only if --yolo flag is explicitly passed.
|
||||
// The original value is saved in initializeCli and restored on exit.
|
||||
// Set yolo mode as a session-scoped override so AutoApprove picks it up,
|
||||
// but it is never persisted to disk (setSessionOverride never touches pendingGlobalState).
|
||||
if (options.yolo) {
|
||||
const state = StateManager.get()
|
||||
savedYoloModeToggled = state.getGlobalSettingsKey("yoloModeToggled") ?? false
|
||||
state.setGlobalState("yoloModeToggled", true)
|
||||
StateManager.get().setSessionOverride("yoloModeToggled", true)
|
||||
telemetryService.captureHostEvent("yolo_flag", "true")
|
||||
}
|
||||
|
||||
@@ -314,9 +294,6 @@ let activeContext: CliContext | null = null
|
||||
let isShuttingDown = false
|
||||
// Track if we're in plain text mode (no Ink UI) - set by runTask when piped stdin detected
|
||||
let isPlainTextMode = false
|
||||
// Track the original yoloModeToggled value from before this CLI session so we can restore it on exit.
|
||||
// The --yolo flag should only affect the current invocation, not persist across runs.
|
||||
let savedYoloModeToggled: boolean | null = null
|
||||
|
||||
/**
|
||||
* Wait for stdout to fully drain before exiting.
|
||||
@@ -358,10 +335,6 @@ function setupSignalHandlers() {
|
||||
printWarning(`${signal} received, shutting down...`)
|
||||
|
||||
try {
|
||||
// Restore yolo state before any cleanup - this is idempotent and safe
|
||||
// even if disposeCliContext also calls it (restoreYoloState checks savedYoloModeToggled !== null)
|
||||
restoreYoloState()
|
||||
|
||||
if (activeContext) {
|
||||
const task = activeContext.controller.task
|
||||
if (task) {
|
||||
@@ -425,7 +398,7 @@ interface InitOptions {
|
||||
*/
|
||||
async function initializeCli(options: InitOptions): Promise<CliContext> {
|
||||
const workspacePath = options.cwd || process.cwd()
|
||||
const { extensionContext, DATA_DIR, EXTENSION_DIR } = initializeCliContext({
|
||||
const { extensionContext, storageContext, DATA_DIR, EXTENSION_DIR } = initializeCliContext({
|
||||
clineDir: options.config,
|
||||
workspaceDir: workspacePath,
|
||||
})
|
||||
@@ -466,13 +439,9 @@ async function initializeCli(options: InitOptions): Promise<CliContext> {
|
||||
DATA_DIR,
|
||||
)
|
||||
|
||||
await StateManager.initialize(extensionContext as any)
|
||||
|
||||
await StateManager.initialize(storageContext)
|
||||
await ErrorService.initialize()
|
||||
|
||||
// Initialize OpenAI Codex OAuth manager with extension context for secrets storage
|
||||
openAiCodexOAuthManager.initialize(extensionContext)
|
||||
|
||||
const webview = HostProvider.get().createWebviewProvider() as CliWebviewProvider
|
||||
const controller = webview.controller
|
||||
|
||||
@@ -754,7 +723,7 @@ program
|
||||
.option("-a, --act", "Run in act mode")
|
||||
.option("-p, --plan", "Run in plan mode")
|
||||
.option("-y, --yolo", "Enable yes/yolo mode (auto-approve actions)")
|
||||
.option("-t, --timeout <seconds>", "Timeout in seconds for yes/yolo mode (default: 600)")
|
||||
.option("-t, --timeout <seconds>", "Optional timeout in seconds (applies only when provided)")
|
||||
.option("-m, --model <model>", "Model to use for the task")
|
||||
.option("-v, --verbose", "Show verbose output")
|
||||
.option("-c, --cwd <path>", "Working directory for the task")
|
||||
@@ -790,9 +759,9 @@ program
|
||||
program
|
||||
.command("auth")
|
||||
.description("Authenticate a provider and configure what model is used")
|
||||
.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic)")
|
||||
.option("-p, --provider <id>", "Provider ID for quick setup (e.g., openai-native, anthropic, moonshot)")
|
||||
.option("-k, --apikey <key>", "API key for the provider")
|
||||
.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-5-20250929)")
|
||||
.option("-m, --modelid <id>", "Model ID to configure (e.g., gpt-4o, claude-sonnet-4-6, kimi-k2.5)")
|
||||
.option("-b, --baseurl <url>", "Base URL (optional, only for openai provider)")
|
||||
.option("-v, --verbose", "Show verbose output")
|
||||
.option("-c, --cwd <path>", "Working directory for the task")
|
||||
@@ -828,7 +797,7 @@ devCommand
|
||||
* If `welcomeViewCompleted` is undefined (first run), checks if ANY provider has credentials
|
||||
* and sets the flag accordingly.
|
||||
*/
|
||||
async function isAuthConfigured(): Promise<boolean> {
|
||||
export async function isAuthConfigured(): Promise<boolean> {
|
||||
const stateManager = StateManager.get()
|
||||
|
||||
// Check welcomeViewCompleted first - this is the single source of truth
|
||||
@@ -983,7 +952,7 @@ program
|
||||
.option("-a, --act", "Run in act mode")
|
||||
.option("-p, --plan", "Run in plan mode")
|
||||
.option("-y, --yolo", "Enable yolo mode (auto-approve actions)")
|
||||
.option("-t, --timeout <seconds>", "Timeout in seconds for yolo mode (default: 600)")
|
||||
.option("-t, --timeout <seconds>", "Optional timeout in seconds (applies only when provided)")
|
||||
.option("-m, --model <model>", "Model to use for the task")
|
||||
.option("-v, --verbose", "Show verbose output")
|
||||
.option("-c, --cwd <path>", "Working directory")
|
||||
|
||||
@@ -26,7 +26,7 @@ export interface PlainTextTaskOptions {
|
||||
imageDataUrls?: string[]
|
||||
verbose?: boolean
|
||||
jsonOutput?: boolean
|
||||
/** Timeout in seconds (default: 600 = 10 minutes) */
|
||||
/** Timeout in seconds (only applied when explicitly provided) */
|
||||
timeoutSeconds?: number
|
||||
/** Task ID to resume an existing task */
|
||||
taskId?: string
|
||||
@@ -153,10 +153,14 @@ export async function runPlainTextTask(options: PlainTextTaskOptions): Promise<b
|
||||
throw new Error("Either taskId or prompt must be provided")
|
||||
}
|
||||
|
||||
// Normal mode: wait for task completion
|
||||
const timeoutMs = (options.timeoutSeconds ?? 600) * 1000 // default 10 minutes
|
||||
const timeoutPromise = new Promise((_, reject) => setTimeout(() => reject(new Error("Timeout")), timeoutMs))
|
||||
await Promise.race([completionPromise, timeoutPromise])
|
||||
// Wait for task completion, with optional timeout only when explicitly configured
|
||||
if (options.timeoutSeconds) {
|
||||
const timeoutMs = options.timeoutSeconds * 1000
|
||||
const timeoutPromise = new Promise((_, reject) => setTimeout(() => reject(new Error("Timeout")), timeoutMs))
|
||||
await Promise.race([completionPromise, timeoutPromise])
|
||||
} else {
|
||||
await completionPromise
|
||||
}
|
||||
} catch (error) {
|
||||
const errMsg = error instanceof Error ? error.message : String(error)
|
||||
if (jsonOutput) {
|
||||
|
||||
@@ -80,15 +80,18 @@ export async function applyProviderConfig(options: ApplyProviderConfigOptions):
|
||||
export interface ApplyBedrockConfigOptions {
|
||||
bedrockConfig: BedrockConfig
|
||||
modelId?: string
|
||||
customModelBaseId?: string // Base model ID for custom ARN/Inference Profile (for capability detection)
|
||||
controller?: Controller
|
||||
}
|
||||
|
||||
/**
|
||||
* Apply Bedrock provider configuration to state
|
||||
* Handles AWS-specific fields (authentication, region, credentials)
|
||||
* When customModelBaseId is provided, sets the custom model flags so the system
|
||||
* knows to use the ARN as the model ID and the base model for capability detection.
|
||||
*/
|
||||
export async function applyBedrockConfig(options: ApplyBedrockConfigOptions): Promise<void> {
|
||||
const { bedrockConfig, modelId, controller } = options
|
||||
const { bedrockConfig, modelId, customModelBaseId, controller } = options
|
||||
const stateManager = StateManager.get()
|
||||
|
||||
const config: Record<string, unknown> = {
|
||||
@@ -108,6 +111,18 @@ export async function applyBedrockConfig(options: ApplyBedrockConfigOptions): Pr
|
||||
if (planModelKey) config[planModelKey] = finalModelId
|
||||
}
|
||||
|
||||
// Handle custom model (Application Inference Profile ARN)
|
||||
if (customModelBaseId) {
|
||||
config.actModeAwsBedrockCustomSelected = true
|
||||
config.planModeAwsBedrockCustomSelected = true
|
||||
config.actModeAwsBedrockCustomModelBaseId = customModelBaseId
|
||||
config.planModeAwsBedrockCustomModelBaseId = customModelBaseId
|
||||
} else {
|
||||
// Ensure custom flags are cleared when using a standard model
|
||||
config.actModeAwsBedrockCustomSelected = false
|
||||
config.planModeAwsBedrockCustomSelected = false
|
||||
}
|
||||
|
||||
// Add optional AWS credentials
|
||||
if (bedrockConfig.awsProfile !== undefined) config.awsProfile = bedrockConfig.awsProfile
|
||||
if (bedrockConfig.awsAccessKey) config.awsAccessKey = bedrockConfig.awsAccessKey
|
||||
|
||||
+56
-92
@@ -1,23 +1,21 @@
|
||||
/**
|
||||
* VSCode context stub for CLI mode
|
||||
* Provides mock implementations of VSCode extension context
|
||||
* Provides mock implementations of VSCode extension context.
|
||||
*/
|
||||
|
||||
import { mkdirSync } from "node:fs"
|
||||
import { fileURLToPath } from "node:url"
|
||||
import os from "os"
|
||||
import path from "path"
|
||||
import { ExtensionRegistryInfo } from "@/registry"
|
||||
import { ClineExtensionContext } from "@/shared/cline"
|
||||
import { ClineFileStorage } from "@/shared/storage"
|
||||
import type { ClineMemento } from "@/shared/storage/ClineStorage"
|
||||
import { createStorageContext, type StorageContext } from "@/shared/storage/storage-context"
|
||||
import { EnvironmentVariableCollection, ExtensionKind, ExtensionMode, readJson, URI } from "./vscode-shim"
|
||||
|
||||
// ES module equivalent of __dirname
|
||||
const __filename = fileURLToPath(import.meta.url)
|
||||
const __dirname = path.dirname(__filename)
|
||||
|
||||
const SETTINGS_SUBFOLDER = "data"
|
||||
|
||||
/**
|
||||
* CLI-specific state overrides.
|
||||
* These values are always returned regardless of what's stored,
|
||||
@@ -35,33 +33,43 @@ const CLI_STATE_OVERRIDES: Record<string, any> = {
|
||||
}
|
||||
|
||||
/**
|
||||
* File-based Memento store with optional key overrides.
|
||||
* Implements VSCode's Memento interface using SyncJsonFileStorage.
|
||||
* Memento adapter that wraps a ClineFileStorage with optional key overrides.
|
||||
* Used for globalState where CLI needs to inject hardcoded overrides.
|
||||
*/
|
||||
class MementoStore extends ClineFileStorage {
|
||||
private overrides: Record<string, any>
|
||||
class MementoAdapter implements ClineMemento {
|
||||
constructor(
|
||||
private readonly store: ClineMemento,
|
||||
private readonly overrides: Record<string, any> = {},
|
||||
) {}
|
||||
|
||||
constructor(filePath: string, overrides: Record<string, any> = {}) {
|
||||
super(filePath, "MementoStore")
|
||||
this.overrides = overrides
|
||||
}
|
||||
|
||||
// VSCode Memento interface - override base class get() with overload support
|
||||
override get<T>(key: string): T | undefined
|
||||
override get<T>(key: string, defaultValue: T): T
|
||||
override get<T>(key: string, defaultValue?: T): T | undefined {
|
||||
get<T>(key: string): T | undefined
|
||||
get<T>(key: string, defaultValue: T): T
|
||||
get<T>(key: string, defaultValue?: T): T | undefined {
|
||||
if (key in this.overrides) {
|
||||
return this.overrides[key] as T
|
||||
}
|
||||
const value = super.get<T>(key)
|
||||
const value = this.store.get<T>(key)
|
||||
return value !== undefined ? value : defaultValue
|
||||
}
|
||||
|
||||
override async update(key: string, value: any): Promise<void> {
|
||||
if (key in this.overrides) {
|
||||
return
|
||||
update(key: string, value: any): Thenable<void> {
|
||||
return this.setBatch({ [key]: value })
|
||||
}
|
||||
|
||||
keys(): readonly string[] {
|
||||
return this.store.keys()
|
||||
}
|
||||
|
||||
setBatch(entries: Record<string, any>): Thenable<void> {
|
||||
// Filter out overridden keys and delegate to underlying store
|
||||
const filteredEntries: Record<string, any> = {}
|
||||
for (const [key, value] of Object.entries(entries)) {
|
||||
if (!(key in this.overrides)) {
|
||||
filteredEntries[key] = value
|
||||
}
|
||||
}
|
||||
this.set(key, value)
|
||||
this.store.setBatch(filteredEntries)
|
||||
return Promise.resolve()
|
||||
}
|
||||
|
||||
setKeysForSync(_keys: readonly string[]): void {
|
||||
@@ -69,81 +77,45 @@ class MementoStore extends ClineFileStorage {
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* File-based secret storage implementing VSCode's SecretStorage interface.
|
||||
* Uses sync storage internally but exposes async API for VSCode compatibility.
|
||||
*/
|
||||
class SecretStore {
|
||||
private storage: ClineFileStorage<string>
|
||||
private onDidChangeEmitter = {
|
||||
event: () => ({ dispose: () => {} }),
|
||||
fire: (_e: any) => {},
|
||||
dispose: () => {},
|
||||
}
|
||||
|
||||
onDidChange = this.onDidChangeEmitter.event
|
||||
|
||||
constructor(filePath: string) {
|
||||
this.storage = new ClineFileStorage<string>(filePath, "SecretStore")
|
||||
}
|
||||
|
||||
get(key: string): Promise<string | undefined> {
|
||||
return Promise.resolve(this.storage.get(key))
|
||||
}
|
||||
|
||||
store(key: string, value: string): Promise<void> {
|
||||
this.storage.set(key, value)
|
||||
return Promise.resolve()
|
||||
}
|
||||
|
||||
delete(key: string): Promise<void> {
|
||||
this.storage.delete(key)
|
||||
return Promise.resolve()
|
||||
}
|
||||
}
|
||||
|
||||
export interface CliContextConfig {
|
||||
clineDir?: string
|
||||
/** The workspace directory being worked in (for hashing into storage path) */
|
||||
/** The workspace directory being worked in (used to compute workspace storage hash) */
|
||||
workspaceDir?: string
|
||||
}
|
||||
|
||||
/**
|
||||
* Create a short hash of a string for use in directory names
|
||||
*/
|
||||
function hashString(str: string): string {
|
||||
let hash = 0
|
||||
for (let i = 0; i < str.length; i++) {
|
||||
const char = str.charCodeAt(i)
|
||||
hash = (hash << 5) - hash + char
|
||||
hash = hash & hash // Convert to 32bit integer
|
||||
}
|
||||
return Math.abs(hash).toString(16).substring(0, 8)
|
||||
}
|
||||
|
||||
export interface CliContextResult {
|
||||
extensionContext: ClineExtensionContext
|
||||
storageContext: StorageContext
|
||||
DATA_DIR: string
|
||||
EXTENSION_DIR: string
|
||||
WORKSPACE_STORAGE_DIR: string
|
||||
}
|
||||
|
||||
/**
|
||||
* Initialize the VSCode-like context for CLI mode
|
||||
* Initialize the VSCode-like context for CLI mode.
|
||||
*
|
||||
* Creates a shared StorageContext (the single source of truth for all storage)
|
||||
* and wraps it in a ClineExtensionContext shell for legacy APIs that still
|
||||
* expect the VSCode ExtensionContext shape.
|
||||
*/
|
||||
export function initializeCliContext(config: CliContextConfig = {}): CliContextResult {
|
||||
const CLINE_DIR = config.clineDir || process.env.CLINE_DIR || path.join(os.homedir(), ".cline")
|
||||
const DATA_DIR = path.join(CLINE_DIR, SETTINGS_SUBFOLDER)
|
||||
|
||||
// Workspace storage should always be under ~/.cline/data/workspaces/<hash>/
|
||||
// where hash is derived from the workspace path to keep workspaces isolated
|
||||
const workspacePath = config.workspaceDir || process.cwd()
|
||||
const workspaceHash = hashString(workspacePath)
|
||||
const WORKSPACE_STORAGE_DIR = process.env.WORKSPACE_STORAGE_DIR || path.join(DATA_DIR, "workspaces", workspaceHash)
|
||||
// Create the shared StorageContext — this owns all ClineFileStorage instances.
|
||||
// CLI, JetBrains, and VSCode all share this same file-backed implementation.
|
||||
let storageContext = createStorageContext({
|
||||
clineDir: CLINE_DIR,
|
||||
workspacePath: config.workspaceDir || process.cwd(),
|
||||
workspaceStorageDir: process.env.WORKSPACE_STORAGE_DIR || undefined,
|
||||
})
|
||||
storageContext = {
|
||||
...storageContext,
|
||||
// Storage — delegates to storageContext stores (with CLI overrides for globalState)
|
||||
globalState: new MementoAdapter(storageContext.globalState, CLI_STATE_OVERRIDES),
|
||||
}
|
||||
|
||||
// Ensure directories exist
|
||||
mkdirSync(DATA_DIR, { recursive: true })
|
||||
mkdirSync(WORKSPACE_STORAGE_DIR, { recursive: true })
|
||||
const DATA_DIR = storageContext.dataDir
|
||||
const WORKSPACE_STORAGE_DIR = storageContext.workspaceStoragePath
|
||||
|
||||
// For CLI, extension dir is the package root (one level up from dist/)
|
||||
const EXTENSION_DIR = path.resolve(__dirname, "..")
|
||||
@@ -160,38 +132,30 @@ export function initializeCliContext(config: CliContextConfig = {}): CliContextR
|
||||
extensionKind: ExtensionKind.UI,
|
||||
}
|
||||
|
||||
// Build the ClineExtensionContext shell. All storage delegates to storageContext —
|
||||
// there are NO separate ClineFileStorage instances here.
|
||||
const extensionContext: ClineExtensionContext = {
|
||||
extension: extension,
|
||||
extensionMode: EXTENSION_MODE,
|
||||
|
||||
// Set up KV stores (globalState has CLI-specific overrides)
|
||||
globalState: new MementoStore(path.join(DATA_DIR, "globalState.json"), CLI_STATE_OVERRIDES),
|
||||
secrets: new SecretStore(path.join(DATA_DIR, "secrets.json")),
|
||||
|
||||
// Set up URIs
|
||||
// URIs / paths
|
||||
storageUri: URI.file(WORKSPACE_STORAGE_DIR),
|
||||
storagePath: WORKSPACE_STORAGE_DIR,
|
||||
globalStorageUri: URI.file(DATA_DIR),
|
||||
globalStoragePath: DATA_DIR,
|
||||
|
||||
// Logs
|
||||
logUri: URI.file(DATA_DIR),
|
||||
logPath: DATA_DIR,
|
||||
|
||||
extensionUri: URI.file(EXTENSION_DIR),
|
||||
extensionPath: EXTENSION_DIR,
|
||||
asAbsolutePath: (relPath: string) => path.join(EXTENSION_DIR, relPath),
|
||||
|
||||
subscriptions: [],
|
||||
|
||||
environmentVariableCollection: new EnvironmentVariableCollection() as any,
|
||||
|
||||
// Workspace state
|
||||
workspaceState: new MementoStore(path.join(WORKSPACE_STORAGE_DIR, "workspaceState.json")),
|
||||
}
|
||||
|
||||
return {
|
||||
extensionContext,
|
||||
storageContext,
|
||||
DATA_DIR,
|
||||
EXTENSION_DIR,
|
||||
WORKSPACE_STORAGE_DIR,
|
||||
|
||||
@@ -202,15 +202,15 @@ If Cline can't access files or run commands:
|
||||
Learn about Cline CLI's core capabilities and use cases.
|
||||
</Card>
|
||||
|
||||
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Master interactive mode, headless automation, and multi-instance workflows.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Skills" icon="graduation-cap" href="/features/skills">
|
||||
<Card title="Skills" icon="graduation-cap" href="/customization/skills">
|
||||
Understand how Cline's Skills work across all editors via ACP.
|
||||
</Card>
|
||||
|
||||
<Card title="Hooks" icon="link" href="/features/hooks/index">
|
||||
<Card title="Hooks" icon="link" href="/customization/hooks">
|
||||
Learn how to enforce policies with Hooks in any editor.
|
||||
</Card>
|
||||
</Columns>
|
||||
|
||||
@@ -1,482 +0,0 @@
|
||||
---
|
||||
title: "CLI Reference (Deprecated)"
|
||||
description: "Command reference for Cline CLI versions earlier than 2.0.0 (deprecated). For the latest commands and options, see the current Cline CLI reference."
|
||||
---
|
||||
|
||||
Complete command reference for Cline CLI. Use this for detailed documentation on all commands, options, and configuration.
|
||||
|
||||
For quick help in your terminal:
|
||||
|
||||
```bash
|
||||
cline --help # Show all commands
|
||||
cline task --help # Show task-specific commands
|
||||
man cline # View the full manual page
|
||||
```
|
||||
|
||||
## Manual Page
|
||||
|
||||
The complete manual page for the Cline CLI:
|
||||
|
||||
```
|
||||
CLINE(1) User Commands CLINE(1)
|
||||
|
||||
NAME
|
||||
cline - orchestrate and interact with Cline AI coding agents
|
||||
|
||||
SYNOPSIS
|
||||
cline [prompt] [options]
|
||||
|
||||
cline command [subcommand] [options] [arguments]
|
||||
|
||||
DESCRIPTION
|
||||
Try: cat README.md | cline "Summarize this for me:"
|
||||
|
||||
cline is a command-line interface for orchestrating multiple Cline AI
|
||||
coding agents. Cline is an autonomous AI agent who can read, write,
|
||||
and execute code across your projects. He operates through a
|
||||
client-server architecture where Cline Core runs as a standalone
|
||||
service, and the CLI acts as a scriptable interface for managing tasks,
|
||||
instances, and agent interactions.
|
||||
|
||||
The CLI is designed for both interactive use and automation, making it
|
||||
ideal for CI/CD pipelines, parallel task execution, and terminal-based
|
||||
workflows. Multiple frontends (CLI, VSCode, JetBrains) can attach to
|
||||
the same Cline Core instance, enabling seamless task handoff between
|
||||
environments.
|
||||
|
||||
MODES OF OPERATION
|
||||
Instant Task Mode
|
||||
The simplest invocation: cline "prompt here" immediately spawns
|
||||
an instance, creates a task, and enters chat mode. This is
|
||||
equivalent to running cline instance new && cline task new &&
|
||||
cline task chat in sequence.
|
||||
|
||||
Subcommand Mode
|
||||
Advanced usage with explicit control: cline <command>
|
||||
[subcommand] [options] provides fine-grained control over
|
||||
instances, tasks, authentication, and configuration.
|
||||
|
||||
AGENT BEHAVIOR
|
||||
Cline operates in two primary modes:
|
||||
|
||||
ACT MODE
|
||||
Cline actively uses tools to accomplish tasks. He can read
|
||||
files, write code, execute commands, use a headless browser, and
|
||||
more. This is the default mode for task execution.
|
||||
|
||||
PLAN MODE
|
||||
Cline gathers information and creates a detailed plan before
|
||||
implementation. He explores the codebase, asks clarifying
|
||||
questions, and presents a strategy for user approval before
|
||||
switching to ACT MODE.
|
||||
|
||||
INSTANT TASK OPTIONS
|
||||
When using the instant task syntax cline "prompt" the following options
|
||||
are available:
|
||||
|
||||
-o, --oneshot
|
||||
Full autonomous mode. Cline completes the task and stops
|
||||
following after completion. Example: cline -o "what's 6 + 8?"
|
||||
|
||||
-s, --setting setting value
|
||||
Override a setting for this task
|
||||
|
||||
-y, --no-interactive, --yolo
|
||||
Enable fully autonomous mode. Disables all interactivity:
|
||||
|
||||
• ask_followup_question tool is disabled
|
||||
|
||||
• attempt_completion happens automatically
|
||||
|
||||
• execute_command runs in non-blocking mode with timeout
|
||||
|
||||
• PLAN MODE automatically switches to ACT MODE
|
||||
|
||||
-m, --mode mode
|
||||
Starting mode. Options: act (default), plan
|
||||
|
||||
-w, --workspace path
|
||||
Additional workspace paths. Can be specified multiple times to
|
||||
include multiple directories. The current working directory is
|
||||
always included as the first workspace. Example: cline -w
|
||||
/path/to/other/project "refactor shared code"
|
||||
|
||||
GLOBAL OPTIONS
|
||||
These options apply to all subcommands:
|
||||
|
||||
-F, --output-format format
|
||||
Output format. Options: rich (default), json, plain
|
||||
|
||||
-h, --help
|
||||
Display help information for the command.
|
||||
|
||||
-v, --verbose
|
||||
Enable verbose output for debugging.
|
||||
|
||||
COMMANDS
|
||||
Authentication
|
||||
cline auth [provider] [key]
|
||||
|
||||
cline a [provider] [key]
|
||||
Configure authentication for AI model providers. Launches an
|
||||
interactive wizard if no arguments provided. If provider is
|
||||
specified without a key, prompts for the key or launches the
|
||||
appropriate OAuth flow.
|
||||
|
||||
Instance Management
|
||||
Cline Core instances are independent agent processes that can run in
|
||||
the background. Multiple instances can run simultaneously, enabling
|
||||
parallel task execution.
|
||||
|
||||
cline instance
|
||||
|
||||
cline i
|
||||
Display instance management help.
|
||||
|
||||
cline instance new [-d|--default]
|
||||
|
||||
cline i n [-d|--default]
|
||||
Spawn a new Cline Core instance. Use --default to set it as
|
||||
the default instance for subsequent commands.
|
||||
|
||||
cline instance list
|
||||
|
||||
cline i l
|
||||
List all running Cline Core instances with their addresses and
|
||||
status.
|
||||
|
||||
cline instance default address
|
||||
|
||||
cline i d address
|
||||
Set the default instance to avoid specifying --address in task
|
||||
commands.
|
||||
|
||||
cline instance kill address [-a|--all]
|
||||
|
||||
cline i k address [-a|--all]
|
||||
Terminate a Cline Core instance. Use --all to kill all running
|
||||
instances.
|
||||
|
||||
Task Management
|
||||
Tasks represent individual work items that Cline executes. Tasks
|
||||
maintain conversation history, checkpoints, and settings.
|
||||
|
||||
cline task [-a|--address ADDR]
|
||||
|
||||
cline t [-a|--address ADDR]
|
||||
Display task management help. The --address flag specifies
|
||||
which Cline Core instance to use (e.g., localhost:50052).
|
||||
|
||||
cline task new prompt [options]
|
||||
|
||||
cline t n prompt [options]
|
||||
Create a new task in the default or specified instance.
|
||||
Options:
|
||||
|
||||
-s, --setting setting value
|
||||
Set task-specific settings
|
||||
|
||||
-y, --no-interactive, --yolo
|
||||
Enable autonomous mode
|
||||
|
||||
-m, --mode mode
|
||||
Starting mode (act or plan)
|
||||
|
||||
cline task open task-id [options]
|
||||
|
||||
cline t o task-id [options]
|
||||
Resume a previous task from history. Accepts the same options
|
||||
as task new.
|
||||
|
||||
cline task list
|
||||
|
||||
cline t l
|
||||
List all tasks in history with their id and snippet
|
||||
|
||||
cline task chat
|
||||
|
||||
cline t c
|
||||
Enter interactive chat mode for the current task. Allows
|
||||
back-and-forth conversation with Cline.
|
||||
|
||||
cline task send [message] [options]
|
||||
|
||||
cline t s [message] [options]
|
||||
Send a message to Cline. If no message is provided, reads from
|
||||
stdin. Options:
|
||||
|
||||
-a, --approve
|
||||
Approve Cline's proposed action
|
||||
|
||||
-d, --deny
|
||||
Deny Cline's proposed action
|
||||
|
||||
-f, --file FILE
|
||||
Attach a file to the message
|
||||
|
||||
-y, --no-interactive, --yolo
|
||||
Enable autonomous mode
|
||||
|
||||
-m, --mode mode
|
||||
Switch mode (act or plan)
|
||||
|
||||
cline task view [-f|--follow] [-c|--follow-complete]
|
||||
|
||||
cline t v [-f|--follow] [-c|--follow-complete]
|
||||
Display the current conversation. Use --follow to stream
|
||||
updates in real-time, or --follow-complete to follow until task
|
||||
completion.
|
||||
|
||||
cline task restore checkpoint
|
||||
|
||||
cline t r checkpoint
|
||||
Restore the task to a previous checkpoint state.
|
||||
|
||||
cline task pause
|
||||
|
||||
cline t p
|
||||
Pause task execution.
|
||||
|
||||
Configuration
|
||||
Configuration can be set globally. Override these global settings for
|
||||
a task using the --setting flag
|
||||
|
||||
cline config
|
||||
|
||||
cline c
|
||||
|
||||
cline config set key value
|
||||
|
||||
cline c s key value
|
||||
Set a configuration variable.
|
||||
|
||||
cline config get key
|
||||
|
||||
cline c g key
|
||||
Read a configuration variable.
|
||||
|
||||
cline config list
|
||||
|
||||
cline c l
|
||||
List all configuration variables and their values.
|
||||
|
||||
Context Window Configuration
|
||||
For local model providers, you can configure the context window size:
|
||||
|
||||
Ollama
|
||||
cline config s ollama-api-options-ctx-num=32768
|
||||
|
||||
LM Studio
|
||||
cline config s lm-studio-max-tokens=32768
|
||||
|
||||
For other providers (Anthropic, OpenRouter, etc.), the context window
|
||||
is defined per model in the model metadata and is not user-settable.
|
||||
Cline uses each model's built-in context limits automatically.
|
||||
|
||||
TASK SETTINGS
|
||||
Task settings are persisted in the ~/.cline/x/tasks directory. When
|
||||
resuming a task with cline task open, task settings are automatically
|
||||
restored.
|
||||
|
||||
Common settings include:
|
||||
|
||||
yolo Enable autonomous mode (true/false)
|
||||
|
||||
mode Starting mode (act/plan)
|
||||
|
||||
hooks_enabled
|
||||
Enable or disable hooks for the task (true/false)
|
||||
|
||||
HOOKS INTEGRATION
|
||||
Hooks let you inject custom logic into Cline's workflow at key moments.
|
||||
They can validate operations before they execute, monitor tool usage,
|
||||
and shape AI decisions. This allows you to integrate hooks into
|
||||
automated workflows, CI/CD pipelines, and headless task execution.
|
||||
|
||||
Enable hooks for a task:
|
||||
|
||||
cline "prompt" -s hooks_enabled=true
|
||||
|
||||
Configure hooks globally:
|
||||
|
||||
cline config set hooks-enabled=true
|
||||
cline config get hooks-enabled
|
||||
|
||||
Note: Hooks in the CLI are only supported on macOS and Linux.
|
||||
|
||||
For complete hooks documentation, see:
|
||||
<https://docs.cline.bot/features/hooks/index>
|
||||
|
||||
NOTES & EXAMPLES
|
||||
The cline task send and cline task new commands support reading from
|
||||
stdin, enabling powerful pipeline compositions:
|
||||
|
||||
cat requirements.txt | cline task send
|
||||
echo "Refactor this code" | cline -y
|
||||
|
||||
Instance Management
|
||||
Manage multiple Cline instances:
|
||||
|
||||
# Start a new instance and make it default
|
||||
cline instance new --default
|
||||
|
||||
# List all running instances
|
||||
cline instance list
|
||||
|
||||
# Kill a specific instance
|
||||
cline instance kill localhost:50052
|
||||
|
||||
# Kill all CLI instances
|
||||
cline instance kill --all-cli
|
||||
|
||||
Task History
|
||||
Work with task history:
|
||||
|
||||
# List previous tasks
|
||||
cline task list
|
||||
|
||||
# Resume a previous task
|
||||
cline task open 1760501486669
|
||||
|
||||
# View conversation history
|
||||
cline task view
|
||||
|
||||
# Start interactive chat with this task
|
||||
cline task chat
|
||||
|
||||
ARCHITECTURE
|
||||
Cline operates on a three-layer architecture:
|
||||
|
||||
Presentation Layer
|
||||
User interfaces (CLI, VSCode, JetBrains) that connect to Cline
|
||||
Core via gRPC
|
||||
|
||||
Cline Core
|
||||
The autonomous agent service handling task management, AI model
|
||||
integration, state management, tool orchestration, and real-time
|
||||
streaming updates
|
||||
|
||||
Host Provider Layer
|
||||
Environment-specific integrations (VSCode APIs, JetBrains APIs,
|
||||
shell APIs) that Cline Core uses to interact with the host
|
||||
system
|
||||
|
||||
BUGS
|
||||
Report bugs at: <https://github.com/cline/cline/issues>
|
||||
|
||||
For real-time help, join the Discord community at:
|
||||
<https://discord.gg/cline>
|
||||
|
||||
SEE ALSO
|
||||
Full documentation: <https://docs.cline.bot>
|
||||
|
||||
AUTHORS
|
||||
Cline is developed by the Cline Bot Inc. and the open source community.
|
||||
|
||||
COPYRIGHT
|
||||
Copyright © 2025 Cline Bot Inc. Licensed under the Apache License 2.0.
|
||||
```
|
||||
|
||||
## JSON output (-F json)
|
||||
|
||||
When you run a command with `-F json` (or `--output-format json`), Cline prints each client message as JSON.
|
||||
|
||||
### ClineMessage schema
|
||||
|
||||
| Field | Type | Required | Notes |
|
||||
|-------|------|----------|-------|
|
||||
| `type` | `"ask" or "say"` | Yes | Top-level message category. |
|
||||
| `text` | `string` | Yes | Human-readable message content. |
|
||||
| `ts` | `number` | Yes | Unix epoch timestamp in milliseconds. |
|
||||
| `reasoning` | `string` | No | Omitted when empty. |
|
||||
| `say` | `string` | No | Omitted when empty. Present when `type` is `"say"`. |
|
||||
| `ask` | `string` | No | Omitted when empty. Present when `type` is `"ask"`. |
|
||||
| `partial` | `boolean` | No | Omitted when false. `true` for streaming updates. |
|
||||
| `images` | `string[]` | No | Omitted when empty. Image URIs when included with a message. |
|
||||
| `files` | `string[]` | No | Omitted when empty. File paths when attached to a message. |
|
||||
| `lastCheckpointHash` | `string` | No | Omitted when empty. Git checkpoint hash when available. |
|
||||
| `isCheckpointCheckedOut` | `boolean` | No | Omitted when false. `true` if Cline checked out a checkpoint. |
|
||||
| `isOperationOutsideWorkspace` | `boolean` | No | Omitted when false. `true` if an operation happened outside the workspace. |
|
||||
|
||||
<Note>
|
||||
Most fields are optional and omitted when empty. If you parse this output, treat missing fields as “not present”, not as empty strings.
|
||||
</Note>
|
||||
|
||||
### Example
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "say",
|
||||
"text": "Cline is about to run a command.",
|
||||
"ts": 1760501486669,
|
||||
"say": "command",
|
||||
"partial": false
|
||||
}
|
||||
```
|
||||
|
||||
### Shell Completion
|
||||
|
||||
Generate autocompletion scripts for various shells:
|
||||
|
||||
#### Bash
|
||||
|
||||
```bash
|
||||
# Generate bash completion
|
||||
cline completion bash > /etc/bash_completion.d/cline
|
||||
|
||||
# Or for user-level installation
|
||||
cline completion bash > ~/.local/share/bash-completion/completions/cline
|
||||
```
|
||||
|
||||
#### Zsh
|
||||
|
||||
```bash
|
||||
# Generate zsh completion
|
||||
cline completion zsh > "${fpath[1]}/_cline"
|
||||
|
||||
# Or add to your .zshrc
|
||||
echo 'source <(cline completion zsh)' >> ~/.zshrc
|
||||
```
|
||||
|
||||
#### Fish
|
||||
|
||||
```bash
|
||||
# Generate fish completion
|
||||
cline completion fish > ~/.config/fish/completions/cline.fish
|
||||
```
|
||||
|
||||
#### PowerShell
|
||||
|
||||
```powershell
|
||||
# Generate PowerShell completion
|
||||
cline completion powershell > cline.ps1
|
||||
|
||||
# Add to your PowerShell profile
|
||||
Add-Content $PROFILE "cline completion powershell | Out-String | Invoke-Expression"
|
||||
```
|
||||
|
||||
### Version Command
|
||||
|
||||
```bash
|
||||
# Show version information
|
||||
cline version
|
||||
```
|
||||
|
||||
### Environment Variables
|
||||
|
||||
#### CLINE_DIR
|
||||
|
||||
Override the default Cline directory location:
|
||||
|
||||
```bash
|
||||
# Override default Cline directory
|
||||
export CLINE_DIR=/custom/path
|
||||
|
||||
# Default: ~/.cline
|
||||
```
|
||||
|
||||
This directory is used for:
|
||||
- Instance registry database
|
||||
- Configuration files
|
||||
- Task history
|
||||
- Checkpoints
|
||||
@@ -3,8 +3,6 @@ title: "CLI Reference"
|
||||
description: "Complete command reference for Cline CLI including all commands, flags, and configuration options"
|
||||
---
|
||||
|
||||
# CLI Reference
|
||||
|
||||
This page documents all available commands, flags, and configuration options for Cline CLI. For quick help in your terminal, use:
|
||||
|
||||
```bash
|
||||
@@ -316,7 +314,7 @@ When using `--json`, each message is output as a JSON object (one per line):
|
||||
|
||||
Cline stores all data in `~/.cline/` by default:
|
||||
|
||||
```
|
||||
```text
|
||||
~/.cline/
|
||||
├── data/ # Configuration directory
|
||||
│ ├── globalState.json # Global settings
|
||||
@@ -416,8 +414,8 @@ cline auth -p openai -k your-key -b https://api.example.com/v1
|
||||
Keyboard shortcuts, slash commands, and file mentions.
|
||||
</Card>
|
||||
|
||||
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Interactive mode, direct execution, and automation patterns.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
|
||||
|
||||
@@ -38,7 +38,7 @@ Rules help Cline understand your project's conventions, coding standards, and pr
|
||||
|
||||
### Workflows Tab
|
||||
|
||||
View and manage [workflows](/features/slash-commands/workflows/index):
|
||||
View and manage [workflows](/customization/workflows):
|
||||
|
||||
- List available workflows
|
||||
- View workflow definitions
|
||||
@@ -46,7 +46,7 @@ View and manage [workflows](/features/slash-commands/workflows/index):
|
||||
|
||||
### Hooks Tab
|
||||
|
||||
Configure [hooks](/features/hooks/index) for custom logic integration:
|
||||
Configure [hooks](/customization/hooks) for custom logic integration:
|
||||
|
||||
- Enable/disable hooks globally
|
||||
- View configured hook scripts
|
||||
@@ -58,7 +58,7 @@ Hooks must be enabled via settings. Use `cline config` to toggle `hooks-enabled`
|
||||
|
||||
### Skills Tab
|
||||
|
||||
Manage [skills](/features/skills) that extend Cline's capabilities:
|
||||
Manage [skills](/customization/skills) that extend Cline's capabilities:
|
||||
|
||||
- View available skills
|
||||
- Enable/disable specific skills
|
||||
@@ -68,11 +68,13 @@ Manage [skills](/features/skills) that extend Cline's capabilities:
|
||||
|
||||
Cline stores configuration in `~/.cline/data/`:
|
||||
|
||||
```
|
||||
```text
|
||||
~/.cline/
|
||||
├── data/ # Configuration directory
|
||||
│ ├── globalState.json # Global settings
|
||||
│ ├── secrets.json # API keys (encrypted)
|
||||
│ ├── settings/ # Settings files
|
||||
│ │ └── cline_mcp_settings.json # MCP server configuration
|
||||
│ ├── workspace/ # Workspace-specific state
|
||||
│ └── tasks/ # Task history and data
|
||||
└── log/ # Log files
|
||||
@@ -172,6 +174,46 @@ cline --config ~/.cline-work "review this PR"
|
||||
cline --config ~/.cline-personal "help me with this side project"
|
||||
```
|
||||
|
||||
## MCP Server Configuration
|
||||
|
||||
Cline CLI supports [MCP (Model Context Protocol)](/mcp/mcp-overview) servers, giving you access to external tools and data sources directly from the terminal. The CLI uses the same MCP configuration format as the VS Code extension.
|
||||
|
||||
### Setting Up MCP Servers
|
||||
|
||||
To configure MCP servers for the CLI, create or edit the settings file at:
|
||||
|
||||
```
|
||||
~/.cline/data/settings/cline_mcp_settings.json
|
||||
```
|
||||
|
||||
The file uses the same JSON format as the VS Code extension:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"my-server": {
|
||||
"command": "node",
|
||||
"args": ["/path/to/server.js"],
|
||||
"env": {
|
||||
"API_KEY": "your_api_key"
|
||||
},
|
||||
"alwaysAllow": ["tool1", "tool2"],
|
||||
"disabled": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For the full configuration reference including STDIO and SSE transport types, see [Adding and Configuring MCP Servers](/mcp/adding-and-configuring-servers).
|
||||
|
||||
<Note>
|
||||
The CLI does not yet have a `/mcp` slash command for managing MCP servers interactively. For now, you'll need to edit the `cline_mcp_settings.json` file directly.
|
||||
</Note>
|
||||
|
||||
### Custom Config Directory
|
||||
|
||||
If you use the `CLINE_DIR` environment variable or `--config` flag, the MCP settings file will be located at `<your-config-dir>/data/settings/cline_mcp_settings.json` instead.
|
||||
|
||||
## Configuration for Local Providers
|
||||
|
||||
### Ollama
|
||||
@@ -268,8 +310,8 @@ cline auth # Re-authenticate
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn about interactive mode, direct execution, and automation patterns.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="CLI Reference" icon="terminal" href="/cline-cli/cli-reference">
|
||||
|
||||
@@ -0,0 +1,457 @@
|
||||
---
|
||||
title: "Getting Started"
|
||||
description: "Run Cline AI coding agents directly in your terminal with an interactive CLI or automated workflows"
|
||||
---
|
||||
|
||||
## What is Cline CLI?
|
||||
|
||||
Cline CLI brings the full power of Cline to your terminal. Whether you prefer an interactive experience or automated workflows for CI/CD pipelines, the CLI adapts to your needs.
|
||||
|
||||
The CLI supports macOS, Linux, and Windows, and works with all the same AI providers as the VS Code extension.
|
||||
|
||||
## Two Ways to Use Cline CLI
|
||||
|
||||
The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:
|
||||
|
||||
### Interactive Mode
|
||||
|
||||
Interactive mode is designed for **hands-on development sessions** where you want to collaborate with Cline in real-time. It provides a rich terminal interface that feels like chatting with an AI assistant.
|
||||
|
||||
**When it activates:** Running `cline` without arguments, or when stdin is a TTY (terminal).
|
||||
|
||||
```bash
|
||||
cline
|
||||
```
|
||||
|
||||
Key features:
|
||||
|
||||
- **Real-time conversation** - Type messages, see Cline's responses, and iterate on tasks
|
||||
- **Visual feedback** - Animated welcome screen, syntax-highlighted code, and progress indicators
|
||||
- **File mentions** with `@` - Reference workspace files with fuzzy search autocomplete
|
||||
- **Slash commands** with `/` - Quick access to `/settings`, `/history`, `/models`, and workflows
|
||||
- **Keyboard shortcuts** - `Tab` to toggle Plan/Act, `Shift+Tab` for auto-approve all
|
||||
- **Session summaries** - See tasks completed, files modified, and token usage on exit
|
||||
- **Settings panel** - Configure providers, models, and features without leaving the CLI
|
||||
|
||||
Interactive mode keeps you in control. You review Cline's plan, approve or modify actions, and guide the conversation.
|
||||
|
||||
[Learn more about interactive mode →](/cline-cli/interactive-mode)
|
||||
|
||||
### Headless Mode (Non-Interactive)
|
||||
|
||||
Headless mode is designed for **automation, scripting, and CI/CD pipelines** where human interaction isn't possible or desired.
|
||||
|
||||
**When it activates:** Using the `-y`/`--yolo` flag, `--json` flag, piping input/output, or when stdin is not a TTY.
|
||||
|
||||
```bash
|
||||
# Headless with auto-approval (YOLO mode)
|
||||
cline -y "Run tests and fix any failures"
|
||||
|
||||
# Headless with JSON output for parsing
|
||||
cline --json "List all TODO comments" | jq '.text'
|
||||
|
||||
# Headless via piped input
|
||||
cat README.md | cline "Summarize this document"
|
||||
|
||||
# Chain multiple headless commands
|
||||
git diff | cline -y "explain these changes" | cline -y "write a commit message"
|
||||
```
|
||||
|
||||
Key features:
|
||||
|
||||
- **No visual interface** - Clean text or JSON output suitable for scripting
|
||||
- **Automatic execution** - With `-y`, Cline approves all actions and runs autonomously
|
||||
- **Process control** - Exits automatically when the task completes
|
||||
- **Piped workflows** - Read from stdin, write to stdout, chain with other commands
|
||||
- **Machine-readable output** - Use `--json` to get structured output for parsing
|
||||
|
||||
<Warning>
|
||||
Headless mode with `-y` gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
|
||||
</Warning>
|
||||
|
||||
### Mode Detection Summary
|
||||
|
||||
Cline automatically detects which mode to use based on your invocation. This table shows how different command patterns trigger each mode, helping you predict behavior in scripts and interactive sessions.
|
||||
|
||||
| Invocation | Mode | Reason |
|
||||
|------------|------|--------|
|
||||
| `cline` | Interactive | No arguments, TTY connected |
|
||||
| `cline "task"` | Interactive | TTY connected |
|
||||
| `cline -y "task"` | Headless | YOLO flag forces headless |
|
||||
| `cline --json "task"` | Headless | JSON flag forces headless |
|
||||
| `cat file \| cline "task"` | Headless | stdin is piped |
|
||||
| `cline "task" > output.txt` | Headless | stdout is redirected |
|
||||
|
||||
[Learn more about headless mode →](/cline-cli/three-core-flows)
|
||||
|
||||
## Supported Model Providers
|
||||
|
||||
Cline CLI supports all providers available in the VS Code extension:
|
||||
|
||||
- **Anthropic** (Claude)
|
||||
- **OpenAI** (GPT-4o, GPT-4)
|
||||
- **OpenAI Codex** (ChatGPT subscription)
|
||||
- **OpenRouter**
|
||||
- **AWS Bedrock**
|
||||
- **Google Gemini**
|
||||
- **X AI (Grok)**
|
||||
- **Cerebras**
|
||||
- **DeepSeek**
|
||||
- **Ollama** (local models)
|
||||
- **LM Studio** (local models)
|
||||
- **OpenAI Compatible** (any compatible API)
|
||||
|
||||
During setup, authenticate with `cline auth` to configure your preferred provider. [See authentication →](#authenticate)
|
||||
|
||||
## What You Can Build
|
||||
|
||||
### Automated Code Maintenance
|
||||
|
||||
Keep your codebase healthy with automated fixes. Cline scans for issues and applies corrections across multiple files.
|
||||
|
||||
```bash
|
||||
cline -y "Fix all ESLint errors in src/"
|
||||
```
|
||||
Finds and fixes linting violations throughout your source directory.
|
||||
|
||||
```bash
|
||||
cline -y "Update all deprecated React lifecycle methods"
|
||||
```
|
||||
Migrates legacy code patterns to modern equivalents (e.g., `componentWillMount` → `useEffect`).
|
||||
|
||||
```bash
|
||||
cline -y "Update dependencies with known vulnerabilities"
|
||||
```
|
||||
Identifies outdated packages with security issues and updates them to safe versions.
|
||||
|
||||
### CI/CD Integration
|
||||
|
||||
Integrate Cline into your continuous integration pipelines for automated code review and documentation.
|
||||
|
||||
```bash
|
||||
git diff origin/main | cline -y "Review these changes for issues"
|
||||
```
|
||||
Pipes your PR diff to Cline for automated code review, catching bugs and style issues before merge.
|
||||
|
||||
```bash
|
||||
git log --oneline v1.0..v1.1 | cline -y "Write release notes"
|
||||
```
|
||||
Generates human-readable release notes from your commit history between two tags.
|
||||
|
||||
```bash
|
||||
cline -y "Run tests and fix failures" --timeout 600
|
||||
```
|
||||
Executes your test suite, analyzes failures, and attempts fixes with a 10-minute timeout.
|
||||
|
||||
### Development Workflows
|
||||
|
||||
From quick edits to complex refactors, Cline adapts to your workflow.
|
||||
|
||||
```bash
|
||||
cline
|
||||
```
|
||||
Launches interactive mode for exploratory development and back-and-forth collaboration.
|
||||
|
||||
```bash
|
||||
cline "Refactor this function to use async/await"
|
||||
```
|
||||
Executes a focused task directly from the command line with approval prompts at key steps.
|
||||
|
||||
```bash
|
||||
cline "Based on @src/api.ts, add error handling to all endpoints"
|
||||
```
|
||||
Uses file mentions (`@`) to give Cline context about specific files in your workspace.
|
||||
|
||||
### Custom Shell Pipelines
|
||||
|
||||
Chain Cline with other CLI tools to build powerful automation workflows.
|
||||
|
||||
```bash
|
||||
gh pr diff 123 | cline -y "Review this PR"
|
||||
```
|
||||
Fetches a GitHub PR diff and pipes it directly to Cline for review.
|
||||
|
||||
```bash
|
||||
cline --json "List all TODO comments" | jq '.text'
|
||||
```
|
||||
Outputs structured JSON that you can process with tools like `jq` for scripting.
|
||||
|
||||
```bash
|
||||
git diff | cline -y "explain" | cline -y "write a haiku about these changes"
|
||||
```
|
||||
Chains multiple Cline invocations together for creative multi-step workflows.
|
||||
|
||||
## Features at a Glance
|
||||
|
||||
| Feature | Interactive Mode | Non-Interactive Mode |
|
||||
|---------|------------------|----------------------|
|
||||
| Interactive chat | ✓ | - |
|
||||
| File mentions (@) | ✓ | ✓ (inline) |
|
||||
| Slash commands (/) | ✓ | - |
|
||||
| Settings panel | ✓ | `cline config` |
|
||||
| Plan/Act toggle | ✓ (Tab) | `-p` / `-a` flags |
|
||||
| Auto-approve | ✓ (Shift+Tab) | `-y` flag |
|
||||
| Session summary | ✓ | - |
|
||||
| JSON output | - | `--json` |
|
||||
| Piped input | - | ✓ |
|
||||
|
||||
---
|
||||
|
||||
## Installation & Setup
|
||||
|
||||
In just a few minutes, you can install the CLI, authenticate with your preferred AI provider, and start running tasks from any directory on your machine.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Cline CLI requires **Node.js version 20 or higher**. We recommend Node.js 22 for the best experience.
|
||||
|
||||
Check your Node.js version:
|
||||
|
||||
```bash
|
||||
node --version
|
||||
```
|
||||
|
||||
If you need to install or update Node.js, visit [nodejs.org](https://nodejs.org) or use a version manager like [nvm](https://github.com/nvm-sh/nvm).
|
||||
|
||||
### Install Cline CLI
|
||||
|
||||
Install globally via npm:
|
||||
|
||||
```bash
|
||||
npm install -g cline
|
||||
```
|
||||
|
||||
Verify the installation:
|
||||
|
||||
```bash
|
||||
cline version
|
||||
```
|
||||
|
||||
<Tip>
|
||||
To install a specific version, use `npm install -g cline@2.0.0`. Check [npm](https://www.npmjs.com/package/cline) for available versions.
|
||||
</Tip>
|
||||
|
||||
### Authenticate
|
||||
|
||||
After installation, run the authentication wizard:
|
||||
|
||||
```bash
|
||||
cline auth
|
||||
```
|
||||
|
||||
This launches an interactive wizard with multiple options. Choose the method that works best for your workflow.
|
||||
|
||||
#### Option 1: Sign in with Cline (Recommended)
|
||||
|
||||
Select **"Sign in with Cline"** to authenticate with your Cline account via OAuth. Your browser opens automatically to complete sign-in.
|
||||
|
||||
#### Option 2: Sign in with ChatGPT Subscription
|
||||
|
||||
If you have a ChatGPT Plus or Pro subscription, select **"Sign in with ChatGPT Subscription"**. This uses OpenAI's Codex OAuth to authenticate with your existing subscription.
|
||||
|
||||
#### Option 3: Import from Existing Tools
|
||||
|
||||
Already using another AI coding CLI? Cline can import your existing configuration:
|
||||
|
||||
- **Import from Codex CLI** - Imports credentials from `~/.codex/auth.json`
|
||||
- **Import from OpenCode** - Imports configuration from `~/.local/share/opencode/auth.json`
|
||||
|
||||
#### Option 4: Bring Your Own API Key
|
||||
|
||||
Select **"Bring your own API key"** to manually configure any supported provider. Or skip the wizard entirely with flags:
|
||||
|
||||
```bash
|
||||
# Anthropic (Claude)
|
||||
cline auth -p anthropic -k sk-ant-api-xxxxx -m claude-sonnet-4-5-20250929
|
||||
|
||||
# OpenAI
|
||||
cline auth -p openai-native -k sk-xxxxx -m gpt-4o
|
||||
|
||||
# OpenRouter
|
||||
cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929
|
||||
|
||||
# OpenAI-compatible provider with custom base URL
|
||||
cline auth -p openai -k your-api-key -b https://api.example.com/v1
|
||||
```
|
||||
|
||||
**Quick Setup Flags:**
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
|
||||
| `-k, --apikey <key>` | Your API key |
|
||||
| `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
|
||||
| `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
|
||||
|
||||
<Tip>
|
||||
Flags are especially useful for scripting, CI/CD environments, or setting up multiple machines.
|
||||
</Tip>
|
||||
|
||||
#### Supported Providers
|
||||
|
||||
| Provider | Provider ID | Notes |
|
||||
|----------|-------------|-------|
|
||||
| Anthropic | `anthropic` | Direct Claude API access |
|
||||
| OpenAI | `openai-native` | GPT-4o, GPT-4, etc. |
|
||||
| OpenAI Codex | `openai-codex` | ChatGPT subscription OAuth |
|
||||
| OpenRouter | `openrouter` | Access multiple providers |
|
||||
| AWS Bedrock | `bedrock` | Claude via AWS |
|
||||
| Google Gemini | `gemini` | Gemini Pro, etc. |
|
||||
| X AI (Grok) | `xai` | Grok models |
|
||||
| Cerebras | `cerebras` | Fast inference |
|
||||
| DeepSeek | `deepseek` | DeepSeek models |
|
||||
| Ollama | `ollama` | Local models |
|
||||
| LM Studio | `lmstudio` | Local models |
|
||||
| OpenAI Compatible | `openai` | Any OpenAI-compatible API |
|
||||
|
||||
### Verify Your Setup
|
||||
|
||||
Confirm everything is working with a simple test:
|
||||
|
||||
```bash
|
||||
cline "What is 2 + 2?"
|
||||
```
|
||||
|
||||
If Cline responds with an answer, your installation and authentication are complete.
|
||||
|
||||
Check your current configuration:
|
||||
|
||||
```bash
|
||||
cline config
|
||||
```
|
||||
|
||||
### Quick Start
|
||||
|
||||
Now you're ready to use Cline. Choose how you want to work:
|
||||
|
||||
#### Interactive Mode
|
||||
|
||||
Launch the interactive CLI for development:
|
||||
|
||||
```bash
|
||||
cline
|
||||
```
|
||||
|
||||
You'll see the Cline welcome screen. Type your task and press Enter. Use:
|
||||
- `Tab` to toggle between Plan and Act modes
|
||||
- `Shift+Tab` to enable auto-approve
|
||||
- `/help` for available commands
|
||||
|
||||
[Learn more about interactive mode →](/cline-cli/interactive-mode)
|
||||
|
||||
#### Direct Task Execution
|
||||
|
||||
Run a task directly from your shell:
|
||||
|
||||
```bash
|
||||
cline "Add error handling to utils.js"
|
||||
```
|
||||
|
||||
For non-interactive execution (perfect for scripts and CI/CD):
|
||||
|
||||
```bash
|
||||
cline -y "Run tests and fix any failures"
|
||||
```
|
||||
|
||||
[Learn more about headless mode →](/cline-cli/three-core-flows)
|
||||
|
||||
### Switching Providers
|
||||
|
||||
To change your configured provider at any time:
|
||||
|
||||
```bash
|
||||
cline auth
|
||||
```
|
||||
|
||||
You can also use the settings panel in interactive mode:
|
||||
|
||||
```bash
|
||||
cline
|
||||
# Then type: /settings
|
||||
# Navigate to the API tab
|
||||
```
|
||||
|
||||
### Updating
|
||||
|
||||
Check for updates and install the latest version:
|
||||
|
||||
```bash
|
||||
cline update
|
||||
```
|
||||
|
||||
Or update manually via npm:
|
||||
|
||||
```bash
|
||||
npm update -g cline
|
||||
```
|
||||
|
||||
### Troubleshooting
|
||||
|
||||
#### Command Not Found
|
||||
|
||||
If `cline` is not found after installation:
|
||||
|
||||
1. Ensure npm global bin is in your PATH:
|
||||
```bash
|
||||
npm bin -g
|
||||
```
|
||||
|
||||
2. Add the path to your shell configuration (`.bashrc`, `.zshrc`, etc.):
|
||||
```bash
|
||||
export PATH="$PATH:$(npm bin -g)"
|
||||
```
|
||||
|
||||
3. Restart your terminal or source your shell config.
|
||||
|
||||
#### Permission Errors
|
||||
|
||||
If you get permission errors during installation:
|
||||
|
||||
```bash
|
||||
# Option 1: Use a Node version manager (recommended)
|
||||
# nvm, fnm, or volta handle permissions automatically
|
||||
|
||||
# Option 2: Fix npm permissions
|
||||
# See: https://docs.npmjs.com/resolving-eacces-permissions-errors-when-installing-packages-globally
|
||||
```
|
||||
|
||||
#### OAuth Flow Issues
|
||||
|
||||
If the browser doesn't open automatically during OAuth:
|
||||
1. Copy the URL from the terminal
|
||||
2. Paste it in your browser manually
|
||||
3. Complete the sign-in flow
|
||||
4. Return to the terminal
|
||||
|
||||
#### API Key Validation
|
||||
|
||||
If your API key is rejected:
|
||||
1. Verify the key is correct and hasn't expired
|
||||
2. Check that you've selected the correct provider
|
||||
3. Ensure your API account has the necessary permissions
|
||||
|
||||
**Provider-specific tips:**
|
||||
- **Anthropic**: Keys start with `sk-ant-`
|
||||
- **OpenAI**: Keys start with `sk-`
|
||||
- **AWS Bedrock**: Requires AWS credentials configured separately. See [AWS Bedrock documentation](/provider-config/aws-bedrock/api-key).
|
||||
|
||||
### Uninstallation
|
||||
|
||||
To remove Cline CLI:
|
||||
|
||||
```bash
|
||||
npm uninstall -g cline
|
||||
```
|
||||
|
||||
To also remove configuration data:
|
||||
|
||||
```bash
|
||||
rm -rf ~/.cline
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
- **[Interactive Mode](/cline-cli/interactive-mode)** - Master the interactive CLI with shortcuts and slash commands
|
||||
- **[Headless Mode](/cline-cli/three-core-flows)** - Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows
|
||||
- **[Configuration](/cline-cli/configuration)** - Configure settings, rules, workflows, and environment variables
|
||||
- **[CLI Reference](/cline-cli/cli-reference)** - Complete command documentation with all flags and options
|
||||
@@ -74,6 +74,9 @@ cline auth -p openai-native -k sk-xxxxx -m gpt-4o
|
||||
# OpenRouter
|
||||
cline auth -p openrouter -k sk-or-xxxxx -m anthropic/claude-sonnet-4-5-20250929
|
||||
|
||||
# Moonshot
|
||||
cline auth -p moonshot -k sk-xxxxx -m kimi-k2.5
|
||||
|
||||
# OpenAI-compatible provider with custom base URL
|
||||
cline auth -p openai -k your-api-key -b https://api.example.com/v1
|
||||
```
|
||||
@@ -82,7 +85,7 @@ cline auth -p openai -k your-api-key -b https://api.example.com/v1
|
||||
|
||||
| Flag | Description |
|
||||
|------|-------------|
|
||||
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`) |
|
||||
| `-p, --provider <id>` | Provider ID (e.g., `anthropic`, `openai-native`, `openrouter`, `moonshot`) |
|
||||
| `-k, --apikey <key>` | Your API key |
|
||||
| `-m, --modelid <id>` | Model ID (e.g., `claude-sonnet-4-5-20250929`, `gpt-4o`) |
|
||||
| `-b, --baseurl <url>` | Base URL for OpenAI-compatible providers |
|
||||
@@ -104,6 +107,7 @@ Flags are especially useful for scripting, CI/CD environments, or setting up mul
|
||||
| X AI (Grok) | `xai` | Grok models |
|
||||
| Cerebras | `cerebras` | Fast inference |
|
||||
| DeepSeek | `deepseek` | DeepSeek models |
|
||||
| Moonshot | `moonshot` | Kimi models via Moonshot AI |
|
||||
| Ollama | `ollama` | Local models |
|
||||
| LM Studio | `lmstudio` | Local models |
|
||||
| OpenAI Compatible | `openai` | Any OpenAI-compatible API |
|
||||
@@ -157,7 +161,7 @@ For non-interactive execution (perfect for scripts and CI/CD):
|
||||
cline -y "Run tests and fix any failures"
|
||||
```
|
||||
|
||||
[Learn more about CLI workflows →](/cline-cli/three-core-flows)
|
||||
[Learn more about headless mode →](/cline-cli/three-core-flows)
|
||||
|
||||
## Switching Providers
|
||||
|
||||
@@ -260,8 +264,8 @@ rm -rf ~/.cline
|
||||
Master the interactive CLI with shortcuts and slash commands.
|
||||
</Card>
|
||||
|
||||
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn interactive mode, direct execution, and automation patterns.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
|
||||
|
||||
@@ -65,7 +65,7 @@ Keyboard shortcuts are the primary way to navigate and control the interactive C
|
||||
|
||||
Reference files from your workspace by typing `@` followed by the filename:
|
||||
|
||||
```
|
||||
```text
|
||||
@src/utils.ts can you add error handling to this file?
|
||||
```
|
||||
|
||||
@@ -79,7 +79,7 @@ File search uses ripgrep for fast, fuzzy matching. You can type partial paths li
|
||||
|
||||
Include multiple files in a single message:
|
||||
|
||||
```
|
||||
```text
|
||||
Compare @src/old-api.ts with @src/new-api.ts and list the breaking changes
|
||||
```
|
||||
|
||||
@@ -100,9 +100,9 @@ Type `/` to see available commands. Slash commands provide quick access to setti
|
||||
|
||||
### Workflow Commands
|
||||
|
||||
If you have [workflows](/features/slash-commands/workflows/index) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:
|
||||
If you have [workflows](/customization/workflows) configured, they appear as additional slash commands. For example, if you have a workflow named `code-review`, you can invoke it with:
|
||||
|
||||
```
|
||||
```text
|
||||
/code-review
|
||||
```
|
||||
|
||||
@@ -120,7 +120,7 @@ Access the settings panel with `/settings`. Navigate between tabs using arrow ke
|
||||
|
||||
## Plan and Act Modes
|
||||
|
||||
Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/features/plan-and-act).
|
||||
Cline operates in two modes, toggled with `Tab`. These modes work the same way in the CLI as they do in the VS Code extension. For a deeper explanation of how Plan and Act modes work, see the [Plan and Act documentation](/core-workflows/plan-and-act).
|
||||
|
||||
### Plan Mode
|
||||
|
||||
@@ -211,7 +211,7 @@ Use terminal multiplexers like tmux or split terminals to run multiple Cline ins
|
||||
|
||||
Give Cline context about what you're working on:
|
||||
|
||||
```
|
||||
```text
|
||||
I'm building a REST API with Express. The routes are in @src/routes/ and models in @src/models/. Help me add user authentication.
|
||||
```
|
||||
|
||||
@@ -219,7 +219,7 @@ I'm building a REST API with Express. The routes are in @src/routes/ and models
|
||||
|
||||
When you're unsure about the best approach:
|
||||
|
||||
```
|
||||
```text
|
||||
[Tab to Plan mode]
|
||||
How should I structure the database schema for a multi-tenant SaaS app?
|
||||
```
|
||||
@@ -228,7 +228,7 @@ How should I structure the database schema for a multi-tenant SaaS app?
|
||||
|
||||
The interactive CLI maintains conversation context. Build on previous messages:
|
||||
|
||||
```
|
||||
```text
|
||||
> Add a login endpoint
|
||||
[Cline creates the endpoint]
|
||||
|
||||
@@ -242,8 +242,8 @@ The interactive CLI maintains conversation context. Build on previous messages:
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn about interactive mode, direct execution, and automation patterns.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
|
||||
|
||||
@@ -15,6 +15,15 @@ Ready to get started? Check out the [installation guide](/cline-cli/installation
|
||||
|
||||
## Two Ways to Use Cline CLI
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
|
||||
**For hands-on development.** Launch `cline` in your terminal and collaborate with Cline in real-time — chat, review plans, approve actions, and iterate on tasks with a rich visual interface.
|
||||
</Card>
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
**For automation & CI/CD.** Run `cline -y "task"` to let Cline work autonomously — no interaction needed. Pipe input/output, get JSON results, and chain commands in scripts and pipelines.
|
||||
</Card>
|
||||
</Columns>
|
||||
|
||||
The CLI operates in two distinct modes, automatically selecting the appropriate one based on how you invoke it:
|
||||
|
||||
### Interactive Mode
|
||||
@@ -86,7 +95,7 @@ Cline automatically detects which mode to use based on your invocation. This tab
|
||||
| `cat file \| cline "task"` | Headless | stdin is piped |
|
||||
| `cline "task" > output.txt` | Headless | stdout is redirected |
|
||||
|
||||
[Learn more about CLI workflows →](/cline-cli/three-core-flows)
|
||||
[Learn more about headless mode →](/cline-cli/three-core-flows)
|
||||
|
||||
## Supported Model Providers
|
||||
|
||||
@@ -198,6 +207,15 @@ Chains multiple Cline invocations together for creative multi-step workflows.
|
||||
| Session summary | ✓ | - |
|
||||
| JSON output | - | `--json` |
|
||||
| Piped input | - | ✓ |
|
||||
| [MCP servers](/cline-cli/configuration#mcp-server-configuration) | ✓ | ✓ |
|
||||
|
||||
## MCP Server Support
|
||||
|
||||
Cline CLI supports [MCP (Model Context Protocol)](/mcp/mcp-overview) servers, the same extensibility system available in the VS Code extension. MCP servers give Cline access to external tools and data sources, from databases and APIs to browser automation and project management.
|
||||
|
||||
To use MCP servers with the CLI, add your server configuration to `~/.cline/data/settings/cline_mcp_settings.json`. The format is identical to the VS Code extension.
|
||||
|
||||
[Configure MCP servers for the CLI →](/cline-cli/configuration#mcp-server-configuration)
|
||||
|
||||
## Learn More
|
||||
|
||||
@@ -210,8 +228,8 @@ Chains multiple Cline invocations together for creative multi-step workflows.
|
||||
Master the interactive CLI with keyboard shortcuts and slash commands.
|
||||
</Card>
|
||||
|
||||
<Card title="CLI Workflows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn interactive mode, direct execution, and automation patterns.
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Configuration" icon="gear" href="/cline-cli/configuration">
|
||||
@@ -222,7 +240,7 @@ Chains multiple Cline invocations together for creative multi-step workflows.
|
||||
Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
|
||||
</Card>
|
||||
|
||||
<Card title="Use in Other Editors" icon="code" href="/cline-cli/acp-editor-integrations">
|
||||
Run Cline as an ACP agent in JetBrains, Neovim, Zed, and more.
|
||||
<Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
|
||||
Real-world examples of headless workflows and automation patterns.
|
||||
</Card>
|
||||
</Columns>
|
||||
|
||||
@@ -3,8 +3,6 @@ title: "GitHub Actions Integration"
|
||||
description: "Automatically respond to GitHub issues by mentioning @cline in comments using Cline CLI in GitHub Actions."
|
||||
---
|
||||
|
||||
# GitHub Integration Sample
|
||||
|
||||
Automate GitHub issue analysis with AI. Mention `@cline` in any issue comment to trigger an autonomous investigation that reads files, analyzes code, and provides actionable insights - all running automatically in GitHub Actions.
|
||||
|
||||
|
||||
@@ -273,7 +271,7 @@ git push
|
||||
|
||||
Once set up, simply mention `@cline` in any issue comment:
|
||||
|
||||
```
|
||||
```text
|
||||
@cline what's causing this error?
|
||||
|
||||
@cline analyze the root cause
|
||||
|
||||
@@ -3,8 +3,6 @@ title: "GitHub Issue RCA Sample"
|
||||
description: "Automated GitHub issue analysis using Cline CLI to identify root causes."
|
||||
---
|
||||
|
||||
# GitHub Root Cause Analysis
|
||||
|
||||
Automated GitHub issue analysis using Cline CLI. This script uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues, outputting clean, parseable results that can be easily integrated into your development workflows.
|
||||
|
||||
<Note>
|
||||
@@ -203,7 +201,7 @@ fi
|
||||
This is where the magic happens:
|
||||
|
||||
```bash
|
||||
# Ask Cline for his analysis, showing only the summary
|
||||
# Ask Cline for its analysis, showing only the summary
|
||||
cline -y "$PROMPT: $ISSUE_URL" --mode act $ADDRESS -F json | \
|
||||
sed -n '/^{/,$p' | \
|
||||
jq -r 'select(.say == "completion_result") | .text' | \
|
||||
@@ -380,4 +378,4 @@ This pattern can be adapted for many other automation scenarios, from pull reque
|
||||
|
||||
- [CLI Installation Guide](https://docs.cline.bot/cline-cli/installation)
|
||||
- [CLI Reference Documentation](https://docs.cline.bot/cline-cli/cli-reference)
|
||||
- [Three Core Flows](https://docs.cline.bot/cline-cli/three-core-flows)
|
||||
- [Headless Mode](https://docs.cline.bot/cline-cli/three-core-flows)
|
||||
|
||||
@@ -3,14 +3,8 @@ title: "GitHub PR Review"
|
||||
description: "Automatically review Pull Requests with AI using Cline CLI in GitHub Actions."
|
||||
---
|
||||
|
||||
# GitHub PR Review Sample
|
||||
|
||||
Automate code review for every Pull Request. Detailed analysis, security checks, and code suggestions provided by Cline running autonomously in GitHub Actions.
|
||||
|
||||
<Frame>
|
||||
<img src="https://storage.googleapis.com/cline_public_images/cli-pr-review.png" alt="Cline PR Review Comment" width="600" />
|
||||
</Frame>
|
||||
|
||||
## The Workflow
|
||||
|
||||
When a PR is opened or marked ready for review, this workflow:
|
||||
|
||||
@@ -3,26 +3,21 @@ title: "Model Orchestration"
|
||||
description: "Use multiple AI models strategically: optimize costs, reduce bias, and leverage model-specific strengths in your workflows"
|
||||
---
|
||||
|
||||
# Model Orchestration
|
||||
|
||||
Cline CLI's `--config` and `--thinking` flags enable sophisticated multi-model workflows. Instead of using a single model for all tasks, you can route different work to different models based on cost, capability, and specialization.
|
||||
|
||||
## Why Orchestrate Multiple Models?
|
||||
|
||||
**Cost Optimization**
|
||||
- Use fast, cheap models (Haiku, Gemini Flash) for simple tasks like summarization
|
||||
- Reserve expensive models (Opus, O1) for complex reasoning and planning
|
||||
- Reduce API costs by 10-100x on routine operations
|
||||
|
||||
By routing work to the right model for the job, you can dramatically reduce API costs. Fast, inexpensive models like Haiku and Gemini Flash handle simple tasks such as summarization, while expensive models like Opus and O1 are reserved for complex reasoning and planning. This approach can reduce costs by 10-100x on routine operations.
|
||||
|
||||
**Bias Reduction**
|
||||
- Different models catch different issues in code reviews
|
||||
- Cross-validate solutions with multiple AI perspectives
|
||||
- Reduce blind spots from single-model thinking
|
||||
|
||||
Different models catch different issues, so cross-validating solutions with multiple AI perspectives helps reduce blind spots that come from relying on a single model. In code reviews especially, combining viewpoints surfaces problems that any one model might miss.
|
||||
|
||||
**Specialization**
|
||||
- Some models excel at code (Codex, DeepSeek)
|
||||
- Others are better at documentation (GPT-4, Claude)
|
||||
- Security analysis benefits from multiple viewpoints
|
||||
|
||||
Certain models excel in specific domains: Codex and DeepSeek are strong at code generation, while GPT-4 and Claude shine at documentation and prose. Security analysis in particular benefits from combining multiple model viewpoints, since each brings different training data and heuristics to the table.
|
||||
|
||||
## Pattern 1: CI/CD Code Review
|
||||
|
||||
@@ -213,8 +208,8 @@ cat *-sec.md | cline -y "find security issues all 3 reviews mentioned"
|
||||
Complete documentation for --config and --thinking flags
|
||||
</Card>
|
||||
|
||||
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn about interactive mode, headless automation, and multi-instance workflows
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
|
||||
<Card title="Model Selection Guide" icon="brain" href="/core-features/model-selection-guide">
|
||||
|
||||
@@ -53,4 +53,4 @@ This section provides sample implementations that demonstrate various Cline CLI
|
||||
|
||||
- [CLI Installation Guide](/cline-cli/installation)
|
||||
- [CLI Reference Documentation](/cline-cli/cli-reference)
|
||||
- [Three Core Flows](/cline-cli/three-core-flows)
|
||||
- [Headless Mode](/cline-cli/three-core-flows)
|
||||
|
||||
@@ -3,8 +3,6 @@ title: "Worktree Workflows"
|
||||
description: "Use Git worktrees with Cline CLI to run parallel tasks, test different approaches, and pipe context between isolated environments"
|
||||
---
|
||||
|
||||
# Worktree Workflows
|
||||
|
||||
Git worktrees let you have multiple branches checked out simultaneously in different folders. Combined with Cline CLI's `--cwd` flag, this enables powerful parallel development workflows and isolated experimentation.
|
||||
|
||||
<Tip>
|
||||
@@ -269,7 +267,7 @@ git worktree remove ~/cline-worktrees/feature-auth
|
||||
Complete documentation for --cwd and all other CLI flags
|
||||
</Card>
|
||||
|
||||
<Card title="Three Core Flows" icon="route" href="/cline-cli/three-core-flows">
|
||||
Learn about interactive mode, task mode, and plain text workflows
|
||||
<Card title="Headless Mode" icon="robot" href="/cline-cli/three-core-flows">
|
||||
Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows.
|
||||
</Card>
|
||||
</Columns>
|
||||
|
||||
+101
-149
@@ -1,134 +1,32 @@
|
||||
---
|
||||
title: "CLI Workflows"
|
||||
description: "Learn the three ways to use Cline CLI: interactive mode, direct task execution, and automation"
|
||||
title: "Headless Mode"
|
||||
description: "Run Cline autonomously in scripts, CI/CD pipelines, and automated workflows"
|
||||
---
|
||||
|
||||
Cline CLI supports three primary workflows, each optimized for different use cases. Choose the approach that best fits your needs.
|
||||
Headless mode runs Cline without an interactive interface — perfect for automation, scripting, and CI/CD pipelines where human interaction isn't possible or desired. Cline executes tasks, produces clean text or JSON output, and exits when complete.
|
||||
|
||||
For collaborative, conversational development, see [Interactive Mode](/cline-cli/interactive-mode) instead.
|
||||
|
||||
<Note>
|
||||
**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler. Just run `cline` for interactive mode or `cline "task"` for direct execution.
|
||||
**Migrating from an older CLI version?** Instance commands (`cline instance new/list/kill`) have been removed in Cline CLI 2.0. The new architecture is simpler — just use `cline -y "task"` for headless execution.
|
||||
</Note>
|
||||
|
||||
## 1. Interactive Mode
|
||||
## When Headless Mode Activates
|
||||
|
||||
The interactive CLI provides the richest experience for interactive development.
|
||||
Cline automatically enters headless mode when any of these conditions are met:
|
||||
|
||||
### Getting Started
|
||||
| Invocation | Reason |
|
||||
|------------|--------|
|
||||
| `cline -y "task"` | `-y`/`--yolo` flag forces headless |
|
||||
| `cline --json "task"` | `--json` flag forces headless |
|
||||
| `cat file \| cline "task"` | stdin is piped |
|
||||
| `cline "task" > output.txt` | stdout is redirected |
|
||||
|
||||
```bash
|
||||
cline
|
||||
```
|
||||
If none of these apply (e.g., running `cline` or `cline "task"` in a terminal), Cline launches in [interactive mode](/cline-cli/interactive-mode).
|
||||
|
||||
This launches an interactive session in your current directory. Type your task, and Cline will analyze and execute it.
|
||||
## YOLO Mode (Fully Autonomous)
|
||||
|
||||
### Key Features
|
||||
|
||||
**Plan/Act Mode Toggle** - Press `Tab` to switch between modes:
|
||||
- **Plan Mode**: Cline analyzes your request and presents a strategy
|
||||
- **Act Mode**: Cline executes actions directly
|
||||
|
||||
**Auto-approve Toggle** - Press `Shift+Tab` to enable automatic approval for all actions.
|
||||
|
||||
**Slash Commands** - Type `/` for quick access to:
|
||||
- `/settings` - Configure providers, models, and features
|
||||
- `/models` - Quick model switching
|
||||
- `/history` - Browse and resume previous tasks
|
||||
- `/clear` - Start a fresh task
|
||||
- `/help` - Show available commands
|
||||
|
||||
**File Mentions** - Type `@` to reference workspace files:
|
||||
```
|
||||
@src/utils.ts add error handling to this file
|
||||
```
|
||||
|
||||
**Session Summary** - When you exit with `Ctrl+C`, Cline displays a summary of your session including tasks completed, files modified, and token usage.
|
||||
|
||||
### When to Use Interactive Mode
|
||||
|
||||
- Exploring a new codebase
|
||||
- Complex refactoring that requires back-and-forth
|
||||
- Learning how Cline approaches problems
|
||||
- Tasks where you want to review before executing
|
||||
|
||||
[Full Interactive Mode Guide →](/cline-cli/interactive-mode)
|
||||
|
||||
## 2. Direct Task Execution
|
||||
|
||||
Execute tasks directly from the command line without entering interactive mode.
|
||||
|
||||
### Basic Usage
|
||||
|
||||
```bash
|
||||
cline "Add unit tests to utils.js"
|
||||
```
|
||||
|
||||
Cline analyzes your task, creates a plan, and executes it. You'll be prompted for approval at key decision points.
|
||||
|
||||
### Piping Context
|
||||
|
||||
Pipe file contents or command output into Cline:
|
||||
|
||||
```bash
|
||||
# Explain a file
|
||||
cat README.md | cline "Summarize this document"
|
||||
|
||||
# Review git changes
|
||||
git diff | cline "Review these changes and suggest improvements"
|
||||
|
||||
# Analyze command output
|
||||
npm test 2>&1 | cline "Analyze these test failures and fix them"
|
||||
```
|
||||
|
||||
### Chaining Cline Commands
|
||||
|
||||
Pipe Cline's output into another Cline instance for creative workflows:
|
||||
|
||||
```bash
|
||||
# Explain changes, then write a commit message
|
||||
git diff | cline -y "explain these changes" | cline -y "write a commit message for this"
|
||||
|
||||
# Generate code, then write tests
|
||||
cline -y "create a fibonacci function" | cline -y "write unit tests for this code"
|
||||
|
||||
# Fun: Generate a poem about your code
|
||||
git diff | cline -y "explain" | cline -y "write a haiku about this"
|
||||
```
|
||||
|
||||
### Including Images
|
||||
|
||||
Attach images to your task:
|
||||
|
||||
```bash
|
||||
cline task -i screenshot.png "Fix the layout issue shown in this screenshot"
|
||||
|
||||
# Or reference inline
|
||||
cline "Fix the UI shown in @./design-mockup.png"
|
||||
```
|
||||
|
||||
### Mode Selection
|
||||
|
||||
```bash
|
||||
# Start in Plan mode (analyze before acting)
|
||||
cline -p "Design a REST API for user management"
|
||||
|
||||
# Start in Act mode (default)
|
||||
cline -a "Fix the typo in README.md"
|
||||
```
|
||||
|
||||
### When to Use Direct Execution
|
||||
|
||||
- Quick, well-defined tasks
|
||||
- Tasks with sufficient context in the prompt
|
||||
- Scripting and shell workflows
|
||||
- When you don't need interactive conversation
|
||||
|
||||
## 3. Automation & CI/CD
|
||||
|
||||
For fully autonomous operation in scripts, CI/CD pipelines, and automated workflows.
|
||||
|
||||
### YOLO Mode (Yes Mode)
|
||||
|
||||
The `-y` or `--yolo` flag enables fully autonomous operation:
|
||||
The `-y` or `--yolo` flag enables fully autonomous operation — Cline approves all actions and runs without prompts:
|
||||
|
||||
```bash
|
||||
cline -y "Run the test suite and fix any failures"
|
||||
@@ -141,12 +39,59 @@ In YOLO mode:
|
||||
- Perfect for CI/CD and scripts
|
||||
|
||||
<Warning>
|
||||
Run YOLO mode on a clean git branch or directory. You get speed in exchange for oversight, so be ready to revert if needed.
|
||||
YOLO mode gives Cline full autonomy. Run on a clean git branch so you can easily revert changes if needed.
|
||||
</Warning>
|
||||
|
||||
### JSON Output
|
||||
### Mode Selection
|
||||
|
||||
Use `--json` for machine-readable output:
|
||||
Control whether Cline plans first or acts immediately:
|
||||
|
||||
```bash
|
||||
# Start in Plan mode (analyze before acting)
|
||||
cline -y -p "Design a REST API for user management"
|
||||
|
||||
# Start in Act mode (default)
|
||||
cline -y -a "Fix the typo in README.md"
|
||||
```
|
||||
|
||||
## Piping Context
|
||||
|
||||
Pipe file contents or command output into Cline to provide context:
|
||||
|
||||
```bash
|
||||
# Explain a file
|
||||
cat README.md | cline "Summarize this document"
|
||||
|
||||
# Review git changes
|
||||
git diff | cline "Review these changes and suggest improvements"
|
||||
|
||||
# Analyze command output
|
||||
npm test 2>&1 | cline "Analyze these test failures and fix them"
|
||||
|
||||
# Pipe a GitHub PR diff
|
||||
gh pr diff 123 | cline -y "Review this PR"
|
||||
```
|
||||
|
||||
When stdin is piped, Cline automatically enters headless mode — the piped content becomes part of the task context.
|
||||
|
||||
## Chaining Commands
|
||||
|
||||
Pipe Cline's output into another Cline instance for multi-step workflows:
|
||||
|
||||
```bash
|
||||
# Explain changes, then write a commit message
|
||||
git diff | cline -y "explain these changes" | cline -y "write a commit message for this"
|
||||
|
||||
# Generate code, then write tests
|
||||
cline -y "create a fibonacci function" | cline -y "write unit tests for this code"
|
||||
|
||||
# Fun: Generate a poem about your code
|
||||
git diff | cline -y "explain" | cline -y "write a haiku about this"
|
||||
```
|
||||
|
||||
## JSON Output
|
||||
|
||||
Use `--json` for machine-readable output that's easy to parse in scripts:
|
||||
|
||||
```bash
|
||||
cline --json "List all TODO comments in the codebase" | jq '.text'
|
||||
@@ -164,25 +109,36 @@ JSON output follows the same format as task files in `~/.cline/data/tasks/<id>/u
|
||||
| `reasoning` | `string` | (Optional) Model reasoning |
|
||||
| `partial` | `boolean` | (Optional) Streaming flag |
|
||||
|
||||
### Timeout Control
|
||||
## Including Images
|
||||
|
||||
Set a maximum execution time:
|
||||
Attach images to your headless task:
|
||||
|
||||
```bash
|
||||
cline -y -i screenshot.png "Fix the layout issue shown in this screenshot"
|
||||
|
||||
# Or reference inline
|
||||
cline -y "Fix the UI shown in @./design-mockup.png"
|
||||
```
|
||||
|
||||
## Timeout Control
|
||||
|
||||
Set a maximum execution time to prevent runaway tasks:
|
||||
|
||||
```bash
|
||||
cline -y --timeout 600 "Run full test suite"
|
||||
```
|
||||
|
||||
### Environment Variables
|
||||
## Environment Variables
|
||||
|
||||
Control Cline behavior via environment variables:
|
||||
Control Cline behavior via environment variables — useful for CI/CD where you can't use interactive configuration.
|
||||
|
||||
**CLINE_DIR** - Custom configuration directory:
|
||||
**CLINE_DIR** — Custom configuration directory:
|
||||
```bash
|
||||
export CLINE_DIR=/path/to/config
|
||||
cline -y "your task"
|
||||
```
|
||||
|
||||
**CLINE_COMMAND_PERMISSIONS** - Restrict allowed commands:
|
||||
**CLINE_COMMAND_PERMISSIONS** — Restrict allowed commands:
|
||||
```bash
|
||||
export CLINE_COMMAND_PERMISSIONS='{"allow": ["npm *", "git *"], "deny": ["rm -rf *"]}'
|
||||
cline -y "your task"
|
||||
@@ -190,6 +146,8 @@ cline -y "your task"
|
||||
|
||||
See [Configuration](/cline-cli/configuration#environment-variables) for full documentation.
|
||||
|
||||
## CI/CD Integration
|
||||
|
||||
### GitHub Actions Example
|
||||
|
||||
Automate PR reviews with Cline:
|
||||
@@ -232,7 +190,7 @@ jobs:
|
||||
|
||||
### Shell Script Example
|
||||
|
||||
Create a code review script:
|
||||
Create a reusable code review script:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
@@ -252,30 +210,24 @@ fi
|
||||
echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text'
|
||||
```
|
||||
|
||||
### When to Use Automation Mode
|
||||
## Common Use Cases
|
||||
|
||||
- CI/CD pipelines
|
||||
- Scheduled maintenance tasks
|
||||
- Batch processing
|
||||
- Any workflow requiring non-interactive execution
|
||||
|
||||
## Choosing the Right Flow
|
||||
|
||||
| Use Case | Recommended Flow |
|
||||
|----------|------------------|
|
||||
| Exploring a new codebase | Interactive Mode |
|
||||
| Complex refactoring | Interactive Mode (Plan first) |
|
||||
| Quick file edits | Direct Execution |
|
||||
| Code review | Direct Execution with pipe |
|
||||
| CI/CD integration | Automation (`-y` flag) |
|
||||
| Scheduled tasks | Automation (`-y` flag) |
|
||||
| Learning Cline | Interactive Mode |
|
||||
| Use Case | Example |
|
||||
|----------|---------|
|
||||
| Code review | `git diff \| cline -y "Review these changes"` |
|
||||
| Fix test failures | `cline -y "Run tests and fix any failures"` |
|
||||
| Generate release notes | `git log --oneline v1.0..v1.1 \| cline -y "Write release notes"` |
|
||||
| Fix lint errors | `cline -y "Fix all ESLint errors in src/"` |
|
||||
| Update dependencies | `cline -y "Update dependencies with known vulnerabilities"` |
|
||||
| Migrate code patterns | `cline -y "Update all deprecated React lifecycle methods"` |
|
||||
| PR automation | `gh pr diff 123 \| cline -y "Review this PR"` |
|
||||
| Batch processing | `cline -y --json "List all TODO comments" \| jq '.text'` |
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Columns cols={2}>
|
||||
<Card title="Interactive Mode" icon="terminal" href="/cline-cli/interactive-mode">
|
||||
Master keyboard shortcuts, slash commands, and file mentions.
|
||||
For hands-on development with keyboard shortcuts, slash commands, and file mentions.
|
||||
</Card>
|
||||
|
||||
<Card title="CLI Reference" icon="book" href="/cline-cli/cli-reference">
|
||||
@@ -286,7 +238,7 @@ echo "$DIFF" | cline -y --json "Review this code diff for issues" | jq -r '.text
|
||||
Environment variables, rules, and advanced settings.
|
||||
</Card>
|
||||
|
||||
<Card title="YOLO Mode" icon="zap" href="/features/yolo-mode">
|
||||
Deep dive into autonomous execution and safety considerations.
|
||||
<Card title="CLI Samples" icon="flask" href="/cline-cli/samples/overview">
|
||||
Real-world examples of headless workflows and automation patterns.
|
||||
</Card>
|
||||
</Columns>
|
||||
|
||||
@@ -0,0 +1,316 @@
|
||||
---
|
||||
title: "Documentation Templates"
|
||||
sidebarTitle: "Templates"
|
||||
description: "Templates for different types of Cline documentation"
|
||||
---
|
||||
|
||||
Use these templates as starting points for new documentation. Each template is designed for a specific purpose. Choose the one that best fits what you're documenting.
|
||||
|
||||
## Choosing a Template
|
||||
|
||||
| If you're documenting... | Use this template |
|
||||
|--------------------------|-------------------|
|
||||
| What a feature does and how to use it | Feature Doc |
|
||||
| How to accomplish a specific task | How-To Guide |
|
||||
| Technical specifications or API details | Reference Doc |
|
||||
| A complete project walkthrough | Tutorial |
|
||||
|
||||
## Feature Doc
|
||||
|
||||
Use this template when explaining a Cline feature. Focus on what it does, how to use it, and real examples.
|
||||
|
||||
````text
|
||||
---
|
||||
title: "Feature Name"
|
||||
sidebarTitle: "Feature Name"
|
||||
---
|
||||
|
||||
[One sentence explaining what this feature does.]
|
||||
|
||||
<Frame>
|
||||
<img src="..." alt="Feature in action" />
|
||||
</Frame>
|
||||
|
||||
[1-2 paragraphs explaining the feature in plain terms. What problem does it
|
||||
solve? Why would someone use it?]
|
||||
|
||||
## How It Works
|
||||
|
||||
[Explain the mechanics without jargon. What happens when you use this feature?]
|
||||
|
||||
## Using [Feature Name]
|
||||
|
||||
[Show how to access and use it. Include the exact UI path.]
|
||||
|
||||
### [Option or Variation 1]
|
||||
|
||||
[Details with examples]
|
||||
|
||||
### [Option or Variation 2]
|
||||
|
||||
[Details with examples]
|
||||
|
||||
## Inspiration
|
||||
|
||||
[Share how you personally use this feature. Use "I" voice. Give 2-3 real
|
||||
examples that spark imagination about what's possible.]
|
||||
|
||||
<Note>
|
||||
[Important caveat, limitation, or requirement]
|
||||
</Note>
|
||||
````
|
||||
|
||||
### Example: Checkpoints Feature
|
||||
|
||||
Here's how the [Checkpoints](/core-workflows/checkpoints) doc follows this pattern:
|
||||
|
||||
- Opens with one clear sentence about what checkpoints do
|
||||
- Shows a screenshot of the feature in action
|
||||
- Explains how checkpoints work under the hood
|
||||
- Shows exact steps to create and restore checkpoints
|
||||
- Includes real examples of when checkpoints save the day
|
||||
|
||||
## How-To Guide
|
||||
|
||||
Use this template when showing how to accomplish a specific task. Focus on clear steps and troubleshooting.
|
||||
|
||||
````text
|
||||
---
|
||||
title: "How to [Accomplish Task]"
|
||||
sidebarTitle: "[Short Title]"
|
||||
description: "[One sentence describing what the reader will learn]"
|
||||
---
|
||||
|
||||
[Brief intro explaining what problem this guide solves and what you'll end up
|
||||
with after following it.]
|
||||
|
||||
## Prerequisites
|
||||
|
||||
[What the reader needs before starting. Keep it short. Link to other docs
|
||||
rather than explaining setup here.]
|
||||
|
||||
- Cline installed and configured
|
||||
- [Other requirement]
|
||||
|
||||
## Steps
|
||||
|
||||
<Steps>
|
||||
<Step title="[First Action]">
|
||||
[Clear instructions. Show exactly what to click or type.]
|
||||
|
||||
```bash
|
||||
example command if needed
|
||||
```
|
||||
</Step>
|
||||
<Step title="[Second Action]">
|
||||
[Next step. Include screenshots for complex UI interactions.]
|
||||
|
||||
<Frame>
|
||||
<img src="..." alt="What you should see" />
|
||||
</Frame>
|
||||
</Step>
|
||||
<Step title="[Final Action]">
|
||||
[Complete the task. Show the expected result.]
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Common issues and how to fix them:
|
||||
|
||||
- **Problem description**: Solution in one or two sentences.
|
||||
- **Another problem**: Another solution.
|
||||
|
||||
## Next Steps
|
||||
|
||||
<Card title="Related Feature" icon="arrow-right" href="/path/to/related">
|
||||
Continue learning with this related guide.
|
||||
</Card>
|
||||
````
|
||||
|
||||
### Example: Your First Project
|
||||
|
||||
The [Your First Project](/getting-started/your-first-project) guide follows this pattern:
|
||||
|
||||
- Clear goal stated upfront
|
||||
- Prerequisites listed briefly
|
||||
- Step-by-step instructions with the Steps component
|
||||
- Troubleshooting section for common issues
|
||||
|
||||
## Reference Doc
|
||||
|
||||
Use this template for technical specifications, API documentation, or detailed configuration options.
|
||||
|
||||
````text
|
||||
---
|
||||
title: "[Component/API] Reference"
|
||||
sidebarTitle: "[Short Title]"
|
||||
description: "[What this reference covers]"
|
||||
---
|
||||
|
||||
[Brief description of what this reference documents and when you'd need it.]
|
||||
|
||||
## Overview
|
||||
|
||||
[High-level explanation. What is this component? What role does it play?]
|
||||
|
||||
## [Category 1]
|
||||
|
||||
### [Item Name]
|
||||
|
||||
[What it does in one sentence.]
|
||||
|
||||
| Property | Type | Default | Description |
|
||||
|----------|------|---------|-------------|
|
||||
| `propertyName` | `string` | `"default"` | What this property controls |
|
||||
| `anotherProp` | `boolean` | `false` | What this does |
|
||||
|
||||
**Example:**
|
||||
|
||||
```typescript
|
||||
// Show practical usage
|
||||
const example = {
|
||||
propertyName: "custom value",
|
||||
anotherProp: true
|
||||
}
|
||||
```
|
||||
|
||||
### [Another Item]
|
||||
|
||||
[Continue for each item in this category.]
|
||||
|
||||
## [Category 2]
|
||||
|
||||
[Continue with other categories as needed.]
|
||||
|
||||
## Examples
|
||||
|
||||
[Show 2-3 complete, practical examples that combine multiple concepts.]
|
||||
|
||||
### [Example 1 Title]
|
||||
|
||||
```typescript
|
||||
// Complete working example
|
||||
```
|
||||
|
||||
### [Example 2 Title]
|
||||
|
||||
```typescript
|
||||
// Another complete example
|
||||
```
|
||||
|
||||
## Related
|
||||
|
||||
- [Related Doc 1](/path/to/doc) - Brief description
|
||||
- [Related Doc 2](/path/to/doc) - Brief description
|
||||
````
|
||||
|
||||
### Example: Cline Tools Guide
|
||||
|
||||
The [Cline Tools Guide](/tools-reference/all-cline-tools) follows this pattern:
|
||||
|
||||
- Overview of the tool system
|
||||
- Each tool documented with parameters and examples
|
||||
- Practical examples showing tools in context
|
||||
|
||||
## Tutorial
|
||||
|
||||
Use this template for comprehensive project walkthroughs where users build something from start to finish.
|
||||
|
||||
````text
|
||||
---
|
||||
title: "[Build/Create X] Tutorial"
|
||||
sidebarTitle: "[Short Title]"
|
||||
description: "[What the reader will build]"
|
||||
---
|
||||
|
||||
In this tutorial, you'll build [specific outcome]. By the end, you'll have
|
||||
[tangible result you can see/use].
|
||||
|
||||
<Frame>
|
||||
<img src="..." alt="Preview of what you'll build" />
|
||||
</Frame>
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- [Skill or concept 1]
|
||||
- [Skill or concept 2]
|
||||
- [Skill or concept 3]
|
||||
|
||||
## Prerequisites
|
||||
|
||||
[Required setup. Link to installation guides rather than repeating them.]
|
||||
|
||||
- [Prerequisite 1]
|
||||
- [Prerequisite 2]
|
||||
|
||||
## Part 1: [First Major Section]
|
||||
|
||||
[Introduction to this section. What are we doing and why?]
|
||||
|
||||
### [Subsection]
|
||||
|
||||
[Detailed walkthrough with code blocks and explanations.]
|
||||
|
||||
```typescript
|
||||
// Code that the reader should write or understand
|
||||
```
|
||||
|
||||
[Explain what the code does and why.]
|
||||
|
||||
## Part 2: [Second Major Section]
|
||||
|
||||
[Continue building on Part 1.]
|
||||
|
||||
### [Subsection]
|
||||
|
||||
[More detailed walkthrough.]
|
||||
|
||||
## Part 3: [Final Section]
|
||||
|
||||
[Complete the project.]
|
||||
|
||||
## Summary
|
||||
|
||||
You built [what they built]. Along the way, you learned:
|
||||
|
||||
- [Key takeaway 1]
|
||||
- [Key takeaway 2]
|
||||
- [Key takeaway 3]
|
||||
|
||||
## Next Steps
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Go Deeper" icon="book" href="/path/to/advanced">
|
||||
Learn more advanced techniques.
|
||||
</Card>
|
||||
<Card title="Related Tutorial" icon="code" href="/path/to/related">
|
||||
Build something else with similar concepts.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
````
|
||||
|
||||
### Example Structure
|
||||
|
||||
A good tutorial:
|
||||
- Shows the end result upfront so readers know what they're building
|
||||
- Breaks the work into logical parts
|
||||
- Explains the "why" alongside the "how"
|
||||
- Ends with clear next steps
|
||||
|
||||
## Quick Tips
|
||||
|
||||
When using these templates:
|
||||
|
||||
1. **Delete sections you don't need.** Templates are starting points, not rigid structures.
|
||||
|
||||
2. **Add sections that make sense.** If your doc needs something not in the template, add it.
|
||||
|
||||
3. **Keep the reader moving forward.** Every section should lead naturally to the next.
|
||||
|
||||
4. **Test your own instructions.** Follow your guide from scratch to catch missing steps.
|
||||
|
||||
<Tip>
|
||||
Use the `/write-docs` workflow to generate documentation from these templates automatically.
|
||||
Cline helps you fill in each section based on your project.
|
||||
</Tip>
|
||||
@@ -0,0 +1,200 @@
|
||||
---
|
||||
title: "Documentation Guide"
|
||||
sidebarTitle: "Documentation Guide"
|
||||
description: "How to write and contribute to Cline documentation"
|
||||
---
|
||||
|
||||
Cline's documentation lives in the `docs/` directory and uses [Mintlify](https://mintlify.com) for rendering. This guide covers how to write docs that match Cline's established style.
|
||||
|
||||
## Using the Documentation Workflow
|
||||
|
||||
The fastest way to create documentation is using the `/write-docs` workflow. Type `/write-docs` in Cline and describe what you want to document. Cline guides you through a 4-step process:
|
||||
|
||||
1. **Research**: Examine existing docs structure and patterns
|
||||
2. **Scope**: Clarify audience, doc type, and key use cases
|
||||
3. **Outline**: Select a template and create structure
|
||||
4. **Write**: Generate documentation following style guidelines
|
||||
|
||||
The workflow file lives at `.clinerules/workflows/write-docs.md` and contains templates, style rules, and examples.
|
||||
|
||||
## Documentation Principles
|
||||
|
||||
### Write for Developers
|
||||
|
||||
Your audience is developers who value their time. Get to the point. Every sentence should either help them understand something or help them do something.
|
||||
|
||||
```markdown
|
||||
# Good
|
||||
Switch to bash in Cline Settings → Terminal → Default Terminal Profile.
|
||||
|
||||
# Bad
|
||||
Users who are experiencing issues may find it helpful to navigate to the
|
||||
Cline settings menu where they can locate the terminal configuration
|
||||
options and subsequently modify the default terminal profile setting.
|
||||
```
|
||||
|
||||
### Show Real Examples
|
||||
|
||||
Abstract descriptions don't help anyone. Show actual code, real file paths, and concrete implementations.
|
||||
|
||||
```markdown
|
||||
# Good
|
||||
I use `/deep-planning` whenever I'm building features that touch multiple
|
||||
parts of the codebase. For example, when adding authentication, Cline
|
||||
mapped every endpoint and created a migration plan that avoided breaking changes.
|
||||
|
||||
# Bad
|
||||
The deep planning feature can be utilized for various complex tasks
|
||||
that may require careful consideration and planning.
|
||||
```
|
||||
|
||||
### Use Active Voice
|
||||
|
||||
Cline does things. Files don't get created by Cline, Cline creates files.
|
||||
|
||||
```markdown
|
||||
# Good
|
||||
Cline reads your project files and builds context automatically.
|
||||
|
||||
# Bad
|
||||
Project files are read and context is built automatically.
|
||||
```
|
||||
|
||||
### Use Neutral Pronouns for Cline
|
||||
|
||||
Refer to Cline as "it" not "he". Cline is software, not a person.
|
||||
|
||||
```markdown
|
||||
# Good
|
||||
When Cline encounters an error, it suggests fixes.
|
||||
|
||||
# Bad
|
||||
When Cline encounters an error, he suggests fixes.
|
||||
```
|
||||
|
||||
## File Format
|
||||
|
||||
All documentation uses MDX format with YAML frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
title: "Full Page Title"
|
||||
sidebarTitle: "Shorter Nav Title" # optional
|
||||
description: "One sentence for SEO" # optional but recommended
|
||||
---
|
||||
```
|
||||
|
||||
### Adding New Pages
|
||||
|
||||
After creating a new `.mdx` file, add it to `docs/docs.json` in the appropriate navigation group:
|
||||
|
||||
```json
|
||||
{
|
||||
"group": "Features",
|
||||
"pages": [
|
||||
"features/existing-page",
|
||||
"features/your-new-page"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Mintlify Components
|
||||
|
||||
Use these components appropriately throughout your docs.
|
||||
|
||||
### Frame
|
||||
|
||||
Wrap all images and videos:
|
||||
|
||||
```jsx
|
||||
<Frame>
|
||||
<img
|
||||
src="https://storage.googleapis.com/cline_public_images/docs/assets/filename.png"
|
||||
alt="Descriptive alt text"
|
||||
/>
|
||||
</Frame>
|
||||
```
|
||||
|
||||
### Callouts
|
||||
|
||||
Use sparingly and purposefully:
|
||||
|
||||
```jsx
|
||||
<Tip>Helpful suggestions that improve the experience.</Tip>
|
||||
<Note>Important information the reader needs to know.</Note>
|
||||
<Warning>Something that could cause problems if ignored.</Warning>
|
||||
```
|
||||
|
||||
### Steps
|
||||
|
||||
For sequential procedures:
|
||||
|
||||
```jsx
|
||||
<Steps>
|
||||
<Step title="Install the Extension">
|
||||
Search for "Cline" in the VS Code marketplace.
|
||||
</Step>
|
||||
<Step title="Configure Your Model">
|
||||
Open settings and add your API key.
|
||||
</Step>
|
||||
</Steps>
|
||||
```
|
||||
|
||||
### Cards
|
||||
|
||||
For navigation and feature overviews:
|
||||
|
||||
```jsx
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Getting Started" icon="rocket" href="/getting-started/installing-cline">
|
||||
Install Cline and set up your first project.
|
||||
</Card>
|
||||
<Card title="Features" icon="wand-magic-sparkles" href="/core-workflows/plan-and-act">
|
||||
Explore what Cline can do.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
```
|
||||
|
||||
## Style Rules
|
||||
|
||||
Quick reference for consistent documentation:
|
||||
|
||||
| Do | Don't |
|
||||
|---|---|
|
||||
| Use "use" | Use "utilize" |
|
||||
| Keep sentences under 25 words | Write run-on sentences |
|
||||
| Use bullet points for lists | Write walls of text |
|
||||
| Show where things are in the UI | Assume users can find features |
|
||||
| Cross-link related docs | Leave readers stranded |
|
||||
| Use code blocks with language tags | Use inline code for long snippets |
|
||||
|
||||
### Avoid These Patterns
|
||||
|
||||
- Em dashes and emojis
|
||||
- Starting with "This document explains..."
|
||||
- The **Bold Text**: description pattern
|
||||
- Explaining obvious things
|
||||
- Passive voice
|
||||
|
||||
## Previewing Changes
|
||||
|
||||
Run the docs locally to preview your changes:
|
||||
|
||||
```bash
|
||||
cd docs
|
||||
npm install # first time only
|
||||
npm run dev
|
||||
```
|
||||
|
||||
Open `http://localhost:3000` to see your changes in real time.
|
||||
|
||||
## Related Resources
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Documentation Templates" icon="file-lines" href="/contributing/doc-templates">
|
||||
Templates for different documentation types.
|
||||
</Card>
|
||||
<Card title="Workflows" icon="diagram-project" href="/customization/workflows">
|
||||
Learn about Cline's workflow system.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: "Model Selection Guide"
|
||||
description: "Last updated: August 20, 2025."
|
||||
description: "Choose the right AI model for your workflow based on reliability, speed, cost, and context window size."
|
||||
---
|
||||
|
||||
New models drop constantly, so this guide focuses on what's working well with Cline right now. We'll keep it updated as the landscape shifts.
|
||||
@@ -59,12 +59,17 @@ Choose your preferred AI provider from the dropdown menu.
|
||||
| **Cline** | Easiest setup | No API keys needed, access to multiple models including stealth models |
|
||||
| **OpenRouter** | Value seekers | Multiple models, competitive pricing |
|
||||
| **Anthropic** | Reliability | Claude models, most dependable tool usage |
|
||||
| **OpenAI** | Latest tech | GPT models |
|
||||
| **Google Gemini** | Large context | Google's AI models |
|
||||
| **OpenAI** | Latest tech | GPT-5, o3, o4-mini models |
|
||||
| **OpenAI Codex** | ChatGPT subscribers | Use your ChatGPT subscription — no API key needed |
|
||||
| **Google Gemini** | Large context | Gemini 3/2.5 with up to 2M context |
|
||||
| **DeepSeek** | Budget reasoning | V3.2, R1 models at low cost |
|
||||
| **Alibaba Qwen** | Open source coding | Qwen3 Coder with 1M context |
|
||||
| **Moonshot** | Agentic coding | Kimi K2.5 with 262K context |
|
||||
| **Cerebras** | Speed | Up to 2,600 tokens/sec |
|
||||
| **AWS Bedrock** | Enterprise | Advanced features |
|
||||
| **Ollama** | Privacy | Run models locally |
|
||||
|
||||
See the [full provider list](/provider-config) for more options including Cerebras, Vertex AI, Azure, and more.
|
||||
See the [full provider list](/getting-started/authorizing-with-cline) for all 30+ supported providers including xAI Grok, Mistral, Groq, Fireworks, Together, Baseten, SambaNova, Nebius, Hugging Face, and more.
|
||||
|
||||
<Info>
|
||||
**Recommended for beginners:** Start with **Cline** as your provider - no API key management needed, instant access to multiple models, and occasional free inferencing through partner providers.
|
||||
@@ -81,6 +86,19 @@ The next step depends on which provider you selected.
|
||||
- You'll be redirected to [app.cline.bot](https://app.cline.bot) to authenticate
|
||||
- After signing in, return to your IDE
|
||||
|
||||
<Note>
|
||||
For detailed information about the Cline authentication flow, OAuth tokens, and troubleshooting, see [Authorizing with Cline](/getting-started/authorizing-with-cline).
|
||||
</Note>
|
||||
|
||||
#### If you selected **OpenAI Codex** as your provider:
|
||||
|
||||
- **No API key needed!** If you have a ChatGPT subscription (Plus, Pro, or Team), you can use it directly in Cline
|
||||
- Click **"Sign in with OpenAI"** to authenticate via your browser
|
||||
- Once authorized, all models available on your OpenAI plan will appear automatically
|
||||
- Usage is governed by your ChatGPT subscription — no separate API billing
|
||||
|
||||
See the full [OpenAI Codex setup guide](/provider-config/openai-codex) for details.
|
||||
|
||||
#### If you selected any other provider:
|
||||
|
||||
You'll need to get an API key from your chosen provider:
|
||||
@@ -90,7 +108,7 @@ You'll need to get an API key from your chosen provider:
|
||||
- **OpenRouter**: [openrouter.ai/keys](https://openrouter.ai/keys)
|
||||
- **OpenAI**: [platform.openai.com/api-keys](https://platform.openai.com/api-keys)
|
||||
- **Google**: [aistudio.google.com/apikey](https://aistudio.google.com/apikey)
|
||||
- **Others**: See [Provider Setup Guide](/provider-config)
|
||||
- **Others**: See [Provider Setup Guide](/getting-started/authorizing-with-cline)
|
||||
|
||||
2. **Generate a new API key** on the provider's website
|
||||
|
||||
@@ -168,8 +186,7 @@ Selecting the right model involves balancing several factors. Use this framework
|
||||
|
||||
## Model Comparison Resources
|
||||
|
||||
For detailed model comparisons, pricing, and performance metrics, see:
|
||||
- [**Model Comparison & Pricing**](/model-config/model-comparison) - Complete pricing tables and performance benchmarks
|
||||
For detailed model comparisons and performance metrics, see:
|
||||
- [**Context Window Guide**](/model-config/context-windows) - Understanding and optimizing context usage
|
||||
|
||||
## Open Source vs Closed Source
|
||||
@@ -195,8 +212,9 @@ For detailed model comparisons, pricing, and performance metrics, see:
|
||||
| Huge context windows | Gemini 2.5 Pro or Claude Sonnet 4.5 |
|
||||
| Open source | Qwen3 Coder, Z AI GLM 4.5, or Kimi K2 |
|
||||
| Latest tech | GPT-5 |
|
||||
| To use your ChatGPT subscription | [OpenAI Codex](/provider-config/openai-codex) — sign in with your OpenAI account, no API key needed |
|
||||
| Speed | Qwen3 Coder on Cerebras (fastest available) |
|
||||
|
||||
## What Others Are Using
|
||||
|
||||
Check [OpenRouter's Cline usage stats](https://openrouter.ai/apps?url=https%3A%2F%2Fcline.bot%2F) to see real usage patterns from the community.
|
||||
Check [Vercel's leaderboard](https://vercel.com/ai-gateway/leaderboards) to see real usage patterns from the community.
|
||||
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: "Checkpoints"
|
||||
sidebarTitle: "Checkpoints"
|
||||
description: "Roll back code changes while keeping your conversation. Experiment freely."
|
||||
---
|
||||
|
||||
Checkpoints let you undo code changes without losing your conversation. Every time Cline modifies a file or runs a command, it saves a snapshot of your project files. You can restore to any checkpoint, keeping the context you've built while reverting the code.
|
||||
|
||||
This changes how you work with Cline. Instead of carefully reviewing every change before approving, you can let Cline move fast and roll back if something goes wrong. The cost of a mistake drops to nearly zero.
|
||||
|
||||
<Tip>
|
||||
Checkpoints are enabled by default. See [Enable or Disable Checkpoints](#enable-or-disable-checkpoints) if you need to turn them off.
|
||||
</Tip>
|
||||
|
||||
## How It Works
|
||||
|
||||
Cline maintains a shadow Git repository separate from your project's actual Git history. After each tool use (file edits, commands, etc.), Cline commits the current state of your files to this shadow repo. Your main Git repository stays untouched.
|
||||
|
||||
This means:
|
||||
|
||||
- Your Git history remains clean and under your control
|
||||
- Checkpoints capture everything, including files not tracked by Git
|
||||
- You can restore to any point in a task without affecting commits you've made
|
||||
- Checkpoints persist across editor sessions
|
||||
|
||||
Each checkpoint captures the complete file state at that moment. If Cline edits three files in sequence, you get three checkpoints and can restore to any of them independently.
|
||||
|
||||
## Enable or Disable Checkpoints
|
||||
|
||||
Checkpoints are enabled by default. To toggle them:
|
||||
|
||||
1. Open Cline settings (gear icon in the Cline sidebar)
|
||||
2. Scroll to the "Feature Settings" section
|
||||
3. Toggle "Enable Checkpoints"
|
||||
|
||||
<Note>
|
||||
For very large repositories, checkpoints may use significant storage and slow down Cline as it commits file snapshots after each tool use. Consider disabling them if you notice performance issues.
|
||||
</Note>
|
||||
|
||||
## Viewing and Comparing Changes
|
||||
|
||||
After each tool use, a checkpoint indicator appears in your conversation. Look for a bookmark icon labeled "Checkpoint" with a dotted line connecting to **Compare** and **Restore** buttons.
|
||||
|
||||
Click **Compare** to open a diff view showing exactly what changed at that checkpoint. This opens in your editor's diff viewer, letting you see additions, deletions, and modifications across all affected files.
|
||||
|
||||
This is useful when Cline makes changes you want to understand before deciding whether to keep them. You can review the diff, then either continue or restore to undo.
|
||||
|
||||
## Restoring Checkpoints
|
||||
|
||||
Click **Restore** next to any step to open the restore menu. You have three options:
|
||||
|
||||
| Option | What It Does | When to Use It |
|
||||
|--------|--------------|----------------|
|
||||
| **Restore Files** | Reverts your project's files to the snapshot at this checkpoint | Undoing code changes while keeping the conversation |
|
||||
| **Restore Task Only** | Deletes messages after this point, does not affect files | Trying a different prompt while keeping current code |
|
||||
| **Restore Files & Task** | Reverts files and deletes messages after this point | Starting over completely from a known good state |
|
||||
|
||||
The right choice depends on what went wrong:
|
||||
|
||||
- If the conversation is productive but the code changes broke something, use **Restore Files**. Cline keeps all the context you've discussed and can try a different implementation.
|
||||
|
||||
- If Cline's code changes are good but the conversation went off track, use **Restore Task Only**. You keep the files and can guide the conversation differently.
|
||||
|
||||
- If you want to start over from a clean slate, use **Restore Files & Task**. This resets both your files and the conversation to that checkpoint.
|
||||
|
||||
## When to Use Checkpoints
|
||||
|
||||
| Scenario | Recommended Action |
|
||||
|----------|-------------------|
|
||||
| Cline refactored code and broke something | Restore Files, ask for a different approach |
|
||||
| Experimenting with multiple solutions | Compare each checkpoint, restore to the best one |
|
||||
| Cline misunderstood your intent | Restore Files & Task, rephrase your request |
|
||||
| Want to try a different prompt | Restore Task Only, keep the files, resubmit |
|
||||
| Reviewing changes before committing to Git | Use Compare to inspect, then commit manually |
|
||||
| Testing risky changes | Let Cline proceed, restore if it fails |
|
||||
|
||||
## Working with Auto-Approve
|
||||
|
||||
Checkpoints make [auto-approve](/features/auto-approve) practical. Without checkpoints, auto-approve feels risky because Cline can make many changes before you notice a problem. With checkpoints, you can let Cline work autonomously and roll back if needed.
|
||||
|
||||
A typical workflow:
|
||||
|
||||
1. Enable auto-approve for file edits and commands
|
||||
2. Let Cline work through your task quickly
|
||||
3. Review the final result
|
||||
4. If something is wrong, restore to the last good checkpoint
|
||||
5. Give Cline more specific guidance
|
||||
|
||||
This approach is faster than reviewing every change individually, and checkpoints provide the safety net.
|
||||
|
||||
## Checkpoints and Message Editing
|
||||
|
||||
The message editing feature integrates with checkpoints. When you edit a previous message and select "Restore All," Cline restores your files to the checkpoint at that point before resubmitting your edited message.
|
||||
|
||||
This lets you fix a poorly worded prompt and undo all the changes that resulted from it in one action.
|
||||
@@ -0,0 +1,120 @@
|
||||
---
|
||||
title: "Plan & Act Mode"
|
||||
sidebarTitle: "Plan & Act Mode"
|
||||
description: "Think first, then build. Cline's dual-mode system for structured development."
|
||||
---
|
||||
|
||||
Plan & Act modes separate thinking from doing. Plan mode lets you explore and strategize without changing files. Act mode executes against your plan.
|
||||
|
||||
<Tip>
|
||||
**New to Plan & Act?** Watch [Plan & Act Deep Dive](https://youtu.be/b7o6URFPp64) to see it in action.
|
||||
</Tip>
|
||||
|
||||
## Plan Mode
|
||||
|
||||
Plan mode is where you and Cline figure out what you're building and how. In this mode, Cline can read your codebase, run searches, and discuss strategy, but cannot modify any files or execute commands.
|
||||
|
||||
This constraint is intentional. It keeps the conversation focused on understanding and planning, without the distraction of implementation details. You can explore freely, ask questions, and iterate on the approach before committing to changes.
|
||||
|
||||
Use Plan mode to:
|
||||
|
||||
- Explore unfamiliar codebases before making changes
|
||||
- Discuss architecture decisions and tradeoffs
|
||||
- Identify edge cases and potential issues upfront
|
||||
- Create a clear implementation strategy
|
||||
- Review code and understand complex workflows
|
||||
|
||||
## Act Mode
|
||||
|
||||
Once you have a plan, switch to Act mode. Cline retains the full context from your planning session and can now modify files, run commands, and execute your strategy.
|
||||
|
||||
The conversation history carries over when you switch modes. Cline remembers everything you discussed in Plan mode, so you don't need to repeat yourself. This makes the transition seamless.
|
||||
|
||||
<Note>
|
||||
While you can start directly in Act mode, planning first is highly recommended. The planning phase intentionally builds context that Cline needs to implement changes effectively. Without it, Cline may lack the understanding required to make the right decisions.
|
||||
</Note>
|
||||
|
||||
## Typical Workflow
|
||||
|
||||
1. Start in Plan mode and describe what you want to build
|
||||
2. Let Cline explore relevant files and understand the codebase
|
||||
3. Discuss the approach, considering edge cases and potential issues
|
||||
4. When confident in the plan, switch to Act mode
|
||||
5. Cline implements the solution based on your planning session
|
||||
|
||||
For complex projects, you may cycle between modes multiple times. Return to Plan mode when you hit unexpected complexity or need to rethink the approach, then switch back to Act mode to continue implementation.
|
||||
|
||||
## When to Use Each Mode
|
||||
|
||||
| Scenario | Recommended Mode |
|
||||
|----------|-----------------|
|
||||
| Starting new features where the approach isn't obvious | Plan |
|
||||
| Debugging tricky issues where you're unsure what's wrong | Plan |
|
||||
| Making architectural decisions affecting multiple files | Plan |
|
||||
| Understanding complex workflows before modifying them | Plan |
|
||||
| Code review and security analysis | Plan |
|
||||
| Learning a new codebase | Plan |
|
||||
| Implementing a solution you've already planned | Act |
|
||||
| Making routine changes with a clear approach | Act |
|
||||
| Following established patterns in the codebase | Act |
|
||||
| Running tests and making adjustments | Act |
|
||||
| Quick fixes where the solution is obvious | Act |
|
||||
|
||||
## Using Different Models for Each Mode
|
||||
|
||||
You can configure separate models for Plan and Act modes. This is useful when you want to use a stronger reasoning model for planning and a faster model for implementation.
|
||||
|
||||
To enable this:
|
||||
|
||||
1. Open Cline Settings
|
||||
2. Enable "Use different models for Plan and Act"
|
||||
3. Select your preferred model for each mode
|
||||
|
||||
When enabled, switching between Plan and Act mode automatically switches to the configured model for that mode. Your model selection is preserved when you switch back.
|
||||
|
||||
**Example configurations:**
|
||||
|
||||
| Use Case | Plan Mode | Act Mode |
|
||||
|----------|-----------|----------|
|
||||
| Cost optimization | GLM 4.6 | Grok Code Fast |
|
||||
| Maximum quality | Claude Opus | Claude Sonnet |
|
||||
| Speed-focused | Gemini 3 Flash | Cerebras |
|
||||
|
||||
## Using `/deep-planning`
|
||||
|
||||
For complex tasks that need thorough analysis, use the `/deep-planning` slash command. This triggers an extended planning session where Cline:
|
||||
|
||||
1. Explores the codebase systematically
|
||||
2. Identifies all affected files and dependencies
|
||||
3. Creates a detailed implementation plan
|
||||
4. Asks clarifying questions before proceeding
|
||||
|
||||
The deep planning prompt is optimized for each model family, so it adapts to the strengths of whatever model you're using. See the [Deep Planning docs](/features/deep-planning) for more details.
|
||||
|
||||
## Choosing the Right Approach by Task Size
|
||||
|
||||
### Small tasks: Act mode only
|
||||
|
||||
For quick fixes like typos, simple bug fixes, or following established patterns, start directly in Act mode. Planning adds overhead when the solution is obvious.
|
||||
|
||||
**Examples:** Fix a typo, add a missing import, update a config value, rename a variable.
|
||||
|
||||
### Medium tasks: Plan → Act
|
||||
|
||||
For most development work, start in Plan mode to understand the scope and approach, then switch to Act mode to implement. This is the sweet spot for features that touch a few files and have some complexity.
|
||||
|
||||
**Examples:** Add a new API endpoint, implement a UI component, fix a bug that requires investigation, refactor a single module.
|
||||
|
||||
### Large tasks: Use `/deep-planning`
|
||||
|
||||
For complex features that span multiple files, require architectural decisions, or will take multiple sessions to complete, use the `/deep-planning` slash command. This creates a detailed implementation plan that Cline can reference throughout the work.
|
||||
|
||||
**Examples:** Add a new feature across frontend and backend, major refactoring across the codebase, implementing a new system or integration, multi-step migrations.
|
||||
|
||||
## Tips
|
||||
|
||||
- Have Cline write a markdown file summarizing the plan for future reference
|
||||
- Use [file mentions](/core-workflows/working-with-files) to point Cline at relevant files during planning
|
||||
- Switch back to Plan mode when encountering unexpected complexity rather than pushing through
|
||||
- Enable [Checkpoints](/core-workflows/checkpoints) before Act mode so you can roll back if needed
|
||||
- For large tasks, ask Cline to create a todo list during planning that you can track in Act mode
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
title: "Tasks"
|
||||
sidebarTitle: "Tasks"
|
||||
description: "Organize your work with tasks - self-contained sessions that capture your conversations, code changes, and decisions."
|
||||
---
|
||||
|
||||
Every interaction with Cline happens within a task. Tasks are self-contained work sessions that capture your entire conversation, code changes, command executions, and decisions.
|
||||
|
||||
## What are Tasks?
|
||||
|
||||
A task begins when you submit a prompt to Cline. Your prompt defines the goal, and Cline works toward it through conversation, code changes, and tool use. The quality of your initial prompt directly affects how well Cline performs - clear, specific prompts lead to better results.
|
||||
|
||||
Each task:
|
||||
|
||||
- Starts with your prompt and builds context through the conversation
|
||||
- Has a unique identifier and dedicated storage directory
|
||||
- Contains the full conversation history
|
||||
- Tracks token usage, API costs, and execution time
|
||||
- Can be interrupted and resumed across sessions
|
||||
- Creates [checkpoints](/core-workflows/checkpoints) for file changes through Git-based snapshots
|
||||
|
||||
<Tip>
|
||||
Want to get better results from Cline? Learn how to write effective prompts in our [Prompt Module](https://cline.bot/learn).
|
||||
</Tip>
|
||||
|
||||
## Scoping Your Tasks
|
||||
|
||||
Each task carries its own context: the conversation history, decisions made, and understanding built up over the session. How you scope your tasks directly affects how well Cline can help you.
|
||||
|
||||
Think of it this way: **one task = one goal**. "Implement user authentication" is one task. "Fix an unrelated CSS bug" is a separate task, even if you notice it while working on auth.
|
||||
|
||||
A focused task produces better results. When a task tries to cover too many unrelated goals, the context becomes cluttered and responses become less relevant.
|
||||
|
||||
<Note>
|
||||
If you're unsure, err on the side of starting fresh. You can always find previous sessions in your task history.
|
||||
</Note>
|
||||
|
||||
### Context Window
|
||||
|
||||
Every AI model has a context window - a limit on how much information it can process at once. Think of it as Cline's working memory for the current task.
|
||||
|
||||
As you work, the context window fills up with:
|
||||
- Your prompts and Cline's responses
|
||||
- File contents Cline reads or edits
|
||||
- Command outputs and tool results
|
||||
- System instructions that guide Cline's behavior (including [Cline Rules](/customization/cline-rules))
|
||||
|
||||
When the context window approaches its limit, Cline automatically compresses older parts of the conversation to make room. This means very long tasks may lose some earlier details, though Cline preserves the most important context.
|
||||
|
||||
This is why task scoping matters: a focused task keeps relevant information in the context window. A sprawling task fills the window with noise, pushing out useful context.
|
||||
|
||||
If your starting context seems high even for simple prompts, add a [`.clineignore`](/customization/clineignore) file to exclude dependencies, build artifacts, and other files Cline doesn't need. This can dramatically reduce your baseline token usage.
|
||||
|
||||
<Tip>
|
||||
For long-running tasks, enable [Auto-Compact](/features/auto-compact) to intelligently manage context as you work.
|
||||
</Tip>
|
||||
|
||||
### New Task vs. Continue
|
||||
|
||||
Knowing when to start fresh versus continue can feel unclear at first. As you work with Cline more, you'll develop an intuition for it. Use this table as a starting point:
|
||||
|
||||
| Scenario | Action | Why |
|
||||
|----------|--------|-----|
|
||||
| Switching to a different feature | **New task** | Clean context, focused responses |
|
||||
| Building on work Cline just completed | **Continue** | Shared understanding preserved |
|
||||
| Cline keeps going off-track | **New task** | Fighting context wastes time |
|
||||
| Iterating on the same files | **Continue** | Conversation history helps |
|
||||
| Explaining what to ignore | **New task** | Cluttered context hurts quality |
|
||||
| Refining Cline's last output | **Continue** | Momentum and decisions preserved |
|
||||
|
||||
To start a new task, click the **+** button in the Cline sidebar or use the `/newtask` command. Your file changes are preserved through [checkpoints](/core-workflows/checkpoints), and you can reference previous tasks from history anytime.
|
||||
|
||||
## Understanding Task Costs
|
||||
|
||||
Every cloud-based AI model charges for usage based on tokens, the units of text the model processes. Cline tracks these costs automatically and displays them in the task header so you can monitor spending as you work.
|
||||
|
||||
### How Costs Are Calculated
|
||||
|
||||
When you interact with Cline, the model processes:
|
||||
|
||||
- **Input tokens**: Your prompts, file contents, conversation history, and system instructions
|
||||
- **Output tokens**: The model's responses, code suggestions, and tool calls
|
||||
|
||||
Cloud providers charge per million tokens, with output tokens typically costing more than input. Some providers also support **prompt caching**, which reduces costs when the same context (like your cline rules or large files) appears in multiple requests. Cline automatically tracks cache savings when available.
|
||||
|
||||
The estimated cost shown in the task header updates after each API request. This estimate uses the pricing information from your selected provider and may vary slightly from your final bill depending on how your provider rounds or bills usage.
|
||||
|
||||
### When You Pay
|
||||
|
||||
You pay for AI usage when using cloud providers like Anthropic, OpenAI, OpenRouter, or Google. Costs vary significantly:
|
||||
|
||||
| Provider Type | Billing Model |
|
||||
|--------------|---------------|
|
||||
| **Cline Provider** | Pay-per-use with credits you purchase |
|
||||
| **Direct API keys** | Billed by your provider (Anthropic, OpenAI, etc.) |
|
||||
| **OpenRouter/Requesty** | Aggregated billing across multiple models |
|
||||
| **Local models** | Free (you provide the hardware) |
|
||||
|
||||
If you're using your own API keys, check your provider's pricing page for current rates. Prices change frequently and vary by model.
|
||||
|
||||
### Free Options
|
||||
|
||||
Not ready to pay? Cline offers several free paths:
|
||||
|
||||
- **Free models**: Search "free" in the model selector when using the Cline provider. These models display a **FREE** tag and work well for learning and experimentation.
|
||||
- **Free tiers**: Some providers offer limited free usage when you use your own API key.
|
||||
- **Local models**: Run models on your own hardware with zero per-request costs.
|
||||
|
||||
### Self-Hosted Models
|
||||
|
||||
Running models locally means no API costs, ever. Your only expense is the hardware to run them.
|
||||
|
||||
To run local models effectively, you need:
|
||||
|
||||
- **32GB RAM minimum** for entry-level models (4-bit quantization)
|
||||
- **64GB RAM** for better quality (8-bit quantization)
|
||||
- **128GB+ RAM** for cloud-competitive performance
|
||||
|
||||
The trade-off is speed. Local models run at 5-20 tokens per second on typical hardware, compared to hundreds of tokens per second from cloud APIs. They also require more setup and configuration.
|
||||
|
||||
<Tip>
|
||||
If you have the hardware, local models offer unlimited experimentation with complete privacy. See [Running Models Locally](/running-models-locally/overview) to get started.
|
||||
</Tip>
|
||||
|
||||
For most users, starting with free cloud models and moving to paid options as needed provides the best balance of cost, speed, and capability. Check [Selecting Your Model](/getting-started/authorizing-with-cline) for guidance on choosing the right option for your workflow.
|
||||
|
||||
|
||||
## Task History
|
||||
|
||||
Every task you work on is saved automatically to your local machine. You can revisit past conversations, resume interrupted work, or reference successful approaches from earlier sessions.
|
||||
|
||||
### Finding Your History
|
||||
|
||||
Click the **History** button in the Cline sidebar (clock icon at the top-right) to open the history view. You'll see all your past tasks with their initial prompt, timestamp, and token usage. Each task card expands to show a preview of the conversation.
|
||||
|
||||
### Searching Tasks
|
||||
|
||||
Use the search bar at the top of the history view to find specific tasks. The fuzzy search looks across everything: your prompts, Cline's responses, code snippets, and file names.
|
||||
|
||||
Sort results by:
|
||||
- **Newest/Oldest** for chronological browsing
|
||||
- **Most Expensive/Most Tokens** to find resource-heavy tasks
|
||||
- **Most Relevant** when searching for specific content
|
||||
- **Favorites** to show only starred tasks
|
||||
|
||||
<Tip>
|
||||
Use favorites strategically. Star tasks that represent successful patterns, good prompts, or complex work you might want to reference later. Favorited tasks are protected from deletion.
|
||||
</Tip>
|
||||
|
||||
## Resuming Tasks
|
||||
|
||||
Cline can resume interrupted tasks with full context:
|
||||
|
||||
1. Open the task from history
|
||||
2. Cline loads the complete conversation
|
||||
3. File states are checked against [checkpoints](/core-workflows/checkpoints)
|
||||
4. The task continues with awareness of the interruption
|
||||
5. Provide additional context if needed
|
||||
|
||||
This works across sessions. Even if you close the editor and return days later, Cline can pick up where you left off.
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
title: "Using Commands"
|
||||
sidebarTitle: "Using Commands"
|
||||
description: "Built-in slash commands to manage context, plan implementations, and create reusable workflows."
|
||||
---
|
||||
|
||||
Cline provides slash commands in chat that help you manage your conversation and plan complex implementations.
|
||||
|
||||
<Tip>
|
||||
**New to slash commands?** Watch our [quick video walkthrough](https://youtu.be/MxS5Jerpf-o) to see these commands in action.
|
||||
</Tip>
|
||||
|
||||
## Slash Commands
|
||||
|
||||
Type `/` in the chat input to see available slash commands:
|
||||
|
||||
| Command | What It Does |
|
||||
|---------|--------------|
|
||||
| `/newtask` | Start fresh task with distilled context from current conversation |
|
||||
| `/smol` | Compress conversation history while preserving essential context |
|
||||
| `/newrule` | Create a rule file to teach Cline your preferences |
|
||||
| `/deep-planning` | Investigate codebase, plan thoroughly, then create implementation task |
|
||||
| `/explain-changes` | Generate AI explanations for any git diff (VS Code only) |
|
||||
| `/reportbug` | Report a bug with diagnostic info |
|
||||
|
||||
### /newtask
|
||||
|
||||
`/newtask` works like a developer handoff. It packages what matters (overall plan, work accomplished, relevant files, next steps) into a fresh task with a clean context window, leaving behind the noise of tool calls and implementation details.
|
||||
|
||||
I use `/newtask` when working through complex implementations. If I've completed 3 steps of a 10-step process and my context is already 75% full, I use `/newtask` to extract key decisions, file changes, and progress without all the noise.
|
||||
|
||||
### /smol
|
||||
|
||||
`/smol` (or its alias `/compact`) compresses your conversation history while preserving essential context. Unlike `/newtask` which creates a new task, `/smol` condenses your current conversation into a comprehensive summary, freeing up context window space while allowing you to continue working in the same task.
|
||||
|
||||
Use `/smol` when you're deep into a debugging session or brainstorming and need to continue in the same task without losing the insights you've gained. For more details, see [Smol Command](#smol).
|
||||
|
||||
### /newrule
|
||||
|
||||
`/newrule` creates a rule file that teaches Cline your preferences. Cline will guide you through setting up guidelines for communication style, coding standards, project context, and workflows. The rule is saved to your `.clinerules` directory and automatically loaded for future conversations.
|
||||
|
||||
Use `/newrule` when you find yourself repeating the same instructions across tasks. For more about rules, see [Cline Rules](/customization/cline-rules).
|
||||
|
||||
### /deep-planning
|
||||
|
||||
Transform Cline into a meticulous architect who investigates your codebase, asks clarifying questions, and creates a comprehensive implementation plan before writing any code. Deep planning follows a four-step process:
|
||||
|
||||
1. **Silent Investigation** - Cline explores your codebase structure and patterns
|
||||
2. **Discussion** - Targeted questions about requirements and approach
|
||||
3. **Plan Creation** - Generates `implementation_plan.md` with detailed specifications
|
||||
4. **Task Creation** - Creates a new task with trackable implementation steps
|
||||
|
||||
Use `/deep-planning` for features touching multiple parts of your codebase, architectural changes, or complex integrations. For detailed documentation, see [Deep Planning](/features/deep-planning).
|
||||
|
||||
### /explain-changes
|
||||
|
||||
<Note>
|
||||
This command is only available in VS Code.
|
||||
</Note>
|
||||
|
||||
`/explain-changes` generates AI-powered explanations for any git diff. You can explain the last commit, uncommitted work, staged changes, specific commits, branches, PRs, or any range of changes.
|
||||
|
||||
Use `/explain-changes` when reviewing code, onboarding to a new codebase, or understanding what changed. For the full list of use cases and examples, see [Explain Changes Command](#explain-changes).
|
||||
|
||||
### /reportbug
|
||||
|
||||
`/reportbug` collects diagnostic information and helps you report issues with Cline. It gathers relevant context like your configuration, recent errors, and system details to make bug reports more useful for the development team.
|
||||
|
||||
Use `/reportbug` when you encounter unexpected behavior, crashes, or bugs you want to report.
|
||||
|
||||
## Custom Workflows
|
||||
|
||||
Beyond the built-in slash commands, you can create your own workflow files that work the same way. Store Markdown files in `.clinerules/workflows/` and invoke them with `/your-workflow.md`.
|
||||
|
||||
For a complete guide on creating and managing custom workflows, see [Workflows](/customization/workflows).
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
title: "Adding Context"
|
||||
sidebarTitle: "Adding Context"
|
||||
description: "Use @ mentions and drag & drop to bring files, terminal output, errors, git changes, and web content into your conversations."
|
||||
---
|
||||
|
||||
Cline works best when it has the right context, not just more context. @ mentions let you pull in exactly the files, errors, terminal output, or documentation that matter for your task. No copying, no pasting, no context switching.
|
||||
|
||||
You can add context two ways:
|
||||
- Type `@` in the chat input and select what you want
|
||||
- Click the **+** button in the bottom left to browse files, images, or mentions
|
||||
|
||||
<Tip>
|
||||
**Want to learn more about managing context?** Watch [Adding Context with @ Mentions](https://youtu.be/7j6R75Dvj1Y) to see it in action.
|
||||
</Tip>
|
||||
|
||||
## Quick Reference
|
||||
|
||||
| What you want | Syntax | Example |
|
||||
|---------------|--------|---------|
|
||||
| File content | `@/path/to/file` | `@/src/index.ts` |
|
||||
| Folder contents | `@/path/to/folder/` | `@/src/components/` |
|
||||
| Workspace errors | `@problems` | `@problems` |
|
||||
| Terminal output | `@terminal` | `@terminal` |
|
||||
| Uncommitted changes | `@git-changes` | `@git-changes` |
|
||||
| Specific commit | `@<commit-hash>` | `@a1b2c3d` |
|
||||
| Web page | `@<url>` | `@https://react.dev/learn` |
|
||||
|
||||
## File Mentions
|
||||
|
||||
Reference any file with `@/path/to/file`. Cline sees the complete file content, including imports, related functions, and surrounding context.
|
||||
|
||||
```text
|
||||
Can you refactor the error handling in @/src/api/users.ts?
|
||||
```
|
||||
|
||||
## Folder Mentions
|
||||
|
||||
Reference entire directories with `@/path/to/folder/` (note the trailing slash). Cline sees the folder structure and all file contents.
|
||||
|
||||
```text
|
||||
Explain how the components in @/src/components/auth/ work together.
|
||||
```
|
||||
|
||||
<Note>
|
||||
In multi-root workspaces, prefix paths with the workspace name: `@workspace-name:/path/to/file`
|
||||
</Note>
|
||||
|
||||
## Problem Mentions
|
||||
|
||||
Use `@problems` to share all errors and warnings from your workspace's Problems panel.
|
||||
|
||||
```text
|
||||
@problems Can you fix these TypeScript errors?
|
||||
```
|
||||
|
||||
## Terminal Mentions
|
||||
|
||||
Use `@terminal` to share recent terminal output. Perfect for debugging build errors or test failures.
|
||||
|
||||
```text
|
||||
@terminal The build is failing. What's wrong?
|
||||
```
|
||||
|
||||
## Git Mentions
|
||||
|
||||
Reference uncommitted changes with `@git-changes`:
|
||||
|
||||
```text
|
||||
@git-changes Review my changes before I commit.
|
||||
```
|
||||
|
||||
Reference specific commits with `@<commit-hash>` (7-40 character hex):
|
||||
|
||||
```text
|
||||
What did @a1b2c3d change?
|
||||
```
|
||||
|
||||
## URL Mentions
|
||||
|
||||
Reference web content with `@https://example.com`. Cline fetches the page content.
|
||||
|
||||
```text
|
||||
Implement the pattern described in @https://react.dev/learn/scaling-up-with-reducer-and-context
|
||||
```
|
||||
|
||||
## Combining Mentions
|
||||
|
||||
Combine multiple @ mentions for comprehensive context:
|
||||
|
||||
```text
|
||||
I'm getting these errors: @problems
|
||||
|
||||
Here's my component: @/src/components/Form.jsx
|
||||
And the API endpoint: @/src/api/users.js
|
||||
|
||||
The error happens when I submit: @terminal
|
||||
|
||||
I think this commit might have caused it: @a1b2c3d
|
||||
```
|
||||
|
||||
## Drag & Drop
|
||||
|
||||
Drag files directly into the chat input to add them to your conversation.
|
||||
|
||||
<Note>
|
||||
In VS Code, hold **Shift** while dragging files into the chat input.
|
||||
</Note>
|
||||
|
||||
Dragging workspace files automatically creates file mentions. You can also drag files from Finder or File Explorer directly into Cline.
|
||||
|
||||
### Supported File Types
|
||||
|
||||
Cline supports text files from your workspace, plus images, PDFs, CSVs, and Excel files from your file system.
|
||||
|
||||
<Note>
|
||||
Images require a multimodal model. Check the model selector to see which models support image inputs.
|
||||
</Note>
|
||||
|
||||
## Context Menu Commands
|
||||
|
||||
Right-click on selected code to access Cline without typing. This is the fastest way to get help with specific code since it automatically includes the selected text and its file location as context.
|
||||
|
||||
### Code Editor Commands
|
||||
|
||||
| Command | When to Use |
|
||||
|---------|-------------|
|
||||
| **Add to Cline** | Ask questions about code, get suggestions, or start a conversation with specific code as context |
|
||||
| **Fix with Cline** | Quick fixes for errors, bugs, or issues in the selected code |
|
||||
| **Explain with Cline** | Understand unfamiliar code, complex logic, or code you're reviewing |
|
||||
| **Improve with Cline** | Get refactoring suggestions, performance improvements, or cleaner implementations |
|
||||
|
||||
**Fix with Cline** also appears in the lightbulb menu (Quick Fix) when your cursor is on an error or warning, making it easy to fix issues inline.
|
||||
|
||||
### Terminal Commands
|
||||
|
||||
Right-click in the terminal to "Add to Cline" and get help with:
|
||||
- Build errors and failed commands
|
||||
- Test failures and stack traces
|
||||
- Configuration issues
|
||||
- Any terminal output you need help interpreting
|
||||
|
||||
### Source Control Commands
|
||||
|
||||
In the Source Control panel, use "Generate Commit Message" to create AI-powered commit messages from your staged changes. Cline analyzes the diff and writes a descriptive commit message following conventional commit patterns.
|
||||
@@ -0,0 +1,396 @@
|
||||
---
|
||||
title: "Rules"
|
||||
sidebarTitle: "Rules"
|
||||
description: "Define specific instructions and coding standards for Cline."
|
||||
---
|
||||
|
||||
Rules are markdown files that provide persistent instructions across all conversations. Instead of repeating the same preferences every time you start a new task, rules let you define them once and have Cline follow them automatically.
|
||||
|
||||
Use rules when you want Cline to:
|
||||
- Follow your team's coding standards (naming conventions, file organization, error handling patterns)
|
||||
- Understand project-specific context (tech stack, architecture decisions, dependencies)
|
||||
- Apply consistent documentation or testing requirements
|
||||
- Remember constraints like "don't modify files in /legacy" or "always use TypeScript"
|
||||
|
||||
<Tip>
|
||||
**New to Rules?** Watch [Cline Rules Explained](https://youtu.be/xQwsy2vkK5M) to see them in action.
|
||||
</Tip>
|
||||
|
||||
|
||||
## Supported Rule Types
|
||||
|
||||
Cline recognizes rules from multiple sources, so you can use existing rule files from other tools:
|
||||
|
||||
| Rule Type | Location | Description |
|
||||
|-----------|----------|-------------|
|
||||
| Cline Rules | `.clinerules/` | Primary rule format |
|
||||
| Cursor Rules | `.cursorrules` | Automatically detected |
|
||||
| Windsurf Rules | `.windsurfrules` | Automatically detected |
|
||||
| AGENTS.md | `AGENTS.md` | [Standard format](https://agents.md/) for cross-tool compatibility |
|
||||
|
||||
All detected rule types appear in the Rules panel, where you can toggle them individually.
|
||||
|
||||
|
||||
## Where Rules Live
|
||||
|
||||
Rules can be stored in two locations: your project workspace or globally on your system.
|
||||
|
||||
**Workspace rules** go in `.clinerules/` at your project root. Use these for team standards, project-specific constraints, and anything you want to share with collaborators via version control.
|
||||
|
||||
**Global rules** go in your system's Cline Rules directory. Use these for personal preferences that apply across all projects.
|
||||
|
||||
```text
|
||||
your-project/
|
||||
├── .clinerules/ # Workspace rules
|
||||
│ ├── coding.md # Coding standards
|
||||
│ ├── testing.md # Test requirements
|
||||
│ └── architecture.md # Structural decisions
|
||||
├── src/
|
||||
└── ...
|
||||
```
|
||||
|
||||
Cline processes all `.md` and `.txt` files inside `.clinerules/`, combining them into a unified set of rules. Numeric prefixes (like `01-coding.md`) help organize files but are optional.
|
||||
|
||||
When both workspace and global rules exist, Cline combines them. Workspace rules take precedence when they conflict with global rules. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
|
||||
|
||||
### Global Rules Directory
|
||||
|
||||
| Operating System | Default Location |
|
||||
|------------------|------------------|
|
||||
| Windows | `Documents\Cline\Rules` |
|
||||
| macOS | `~/Documents/Cline/Rules` |
|
||||
| Linux/WSL | `~/Documents/Cline/Rules` |
|
||||
|
||||
<Note>
|
||||
Linux/WSL users: If you don't find global rules in `~/Documents/Cline/Rules`, check `~/Cline/Rules`.
|
||||
</Note>
|
||||
|
||||
|
||||
## Creating Rules
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the Rules menu">
|
||||
Click the scale icon at the bottom of the Cline panel, to the left of the model selector.
|
||||
</Step>
|
||||
<Step title="Create a new rule file">
|
||||
Click "New rule file..." and enter a filename (e.g., `coding-standards`). The file will be created with a `.md` extension.
|
||||
</Step>
|
||||
<Step title="Write your rule">
|
||||
Add your instructions in markdown format. Keep each rule file focused on a single concern.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
You can also use the [`/newrule` slash command](/core-workflows/using-commands#newrule) to have Cline create a rule interactively.
|
||||
|
||||
### Toggling Rules
|
||||
|
||||
Every rule has a toggle to enable or disable it. This gives you fine-grained control over which rules apply to your current task without deleting the rule file.
|
||||
|
||||
For example, you might have a strict testing rule that you want to disable when prototyping, or a client-specific rule you only need when working on that client's features.
|
||||
|
||||
## Writing Effective Rules
|
||||
|
||||
### Structure
|
||||
|
||||
Rules work best when they're scannable and specific. Use markdown structure to organize instructions:
|
||||
|
||||
```markdown
|
||||
# Rule Title
|
||||
|
||||
Brief context about why this rule exists (optional but helpful).
|
||||
|
||||
## Category 1
|
||||
- Specific instruction
|
||||
- Another instruction with example: `like this`
|
||||
- Reference to file: see /src/utils/example.ts
|
||||
|
||||
## Category 2
|
||||
- More instructions
|
||||
- Include the "why" when it's not obvious
|
||||
```
|
||||
|
||||
Cline reads rules as context, so formatting matters. Headers help Cline understand the scope of each instruction. Bullet points make individual requirements clear. Code examples show exactly what you want.
|
||||
|
||||
### Best Practices
|
||||
|
||||
**Be specific, not vague.** "Use descriptive variable names" is too broad. "Use camelCase for variables, PascalCase for classes, UPPER_SNAKE for constants" gives Cline something concrete to follow.
|
||||
|
||||
**Include the why.** When a rule might seem arbitrary, explain the reason. "Don't modify files in /legacy (this code is scheduled for removal in Q2)" helps Cline make better decisions in edge cases.
|
||||
|
||||
**Point to examples.** If your codebase already demonstrates the pattern you want, reference it. "Follow the error handling pattern in /src/utils/errors.ts" is more effective than describing the pattern from scratch.
|
||||
|
||||
**Keep rules current.** Outdated rules confuse Cline and waste context. If a constraint no longer applies, remove it. If your tech stack changes, update the rules.
|
||||
|
||||
**One concern per file.** Split rules by topic: `coding.md` for style, `testing.md` for test requirements, `architecture.md` for structural decisions. This makes it easy to toggle specific rules on or off.
|
||||
|
||||
<Warning>
|
||||
Rules consume context tokens. Avoid lengthy explanations or pasting entire style guides. Keep rules concise and link to external documentation when detailed reference is needed.
|
||||
</Warning>
|
||||
|
||||
## Example
|
||||
|
||||
```markdown
|
||||
# Project Guidelines
|
||||
|
||||
## Code Style
|
||||
- Use TypeScript for all new files
|
||||
- Prefer composition over inheritance
|
||||
- Use repository pattern for data access
|
||||
- Follow error handling pattern in /src/utils/errors.ts
|
||||
|
||||
## Documentation
|
||||
- Update relevant docs when modifying features
|
||||
- Keep README.md in sync with new capabilities
|
||||
|
||||
## Testing
|
||||
- Unit tests required for business logic
|
||||
- Integration tests for API endpoints
|
||||
- E2E tests for critical user flows
|
||||
```
|
||||
|
||||
|
||||
## Conditional Rules
|
||||
|
||||
Conditional rules let you scope rules to specific parts of your codebase. Rules activate only when you're working with matching files, keeping your context focused and relevant.
|
||||
|
||||
- **Without conditionals**: every rule loads for every request.
|
||||
- **With conditionals**, rules activate only when your current files match their defined scope.
|
||||
|
||||
For example, documentation style rules should only appear when you're editing docs, not when you're writing application code or tests.
|
||||
|
||||
As your rule library grows, loading every rule for every request wastes context tokens and can dilute Cline's focus. Conditional rules solve this by giving Cline only the instructions that matter for the files you're actually touching. This means faster, more accurate responses. Your frontend rules won't compete for attention when you're deep in backend code, and your testing standards appear exactly when you're writing tests. It's the difference between handing someone an entire policy manual versus the one page they need right now.
|
||||
|
||||
### How It Works
|
||||
|
||||
Conditional rules use YAML frontmatter at the top of your rule files. When Cline processes a request, it gathers context from your current work (open files, visible tabs, mentioned paths, edited files), evaluates each rule's conditions, and activates matching rules.
|
||||
|
||||
<Note>
|
||||
When a conditional rule activates, you'll see a notification: **"Conditional rules applied: workspace:frontend-rules.md"**
|
||||
</Note>
|
||||
|
||||
### Writing Conditional Rules
|
||||
|
||||
Add YAML frontmatter to the top of any rule file in your `.clinerules/` directory:
|
||||
|
||||
```yaml
|
||||
---
|
||||
paths:
|
||||
- "src/components/**"
|
||||
- "src/hooks/**"
|
||||
---
|
||||
|
||||
# React Component Guidelines
|
||||
|
||||
When creating or modifying React components:
|
||||
- Use functional components with React hooks
|
||||
- Extract reusable logic into custom React hooks
|
||||
- Keep components focused on a single responsibility
|
||||
```
|
||||
|
||||
The `---` markers delimit the frontmatter. Everything after the closing `---` is your rule content.
|
||||
|
||||
#### The `paths` Conditional
|
||||
|
||||
Currently, `paths` is the supported conditional. It takes an array of glob patterns:
|
||||
|
||||
```yaml
|
||||
---
|
||||
paths:
|
||||
- "src/**" # All files under src/
|
||||
- "*.config.js" # Config files in root
|
||||
- "packages/*/src/" # Monorepo package sources
|
||||
---
|
||||
```
|
||||
|
||||
**Glob pattern syntax:**
|
||||
|
||||
- `*` matches any characters except `/`
|
||||
- `**` matches any characters including `/` (recursive)
|
||||
- `?` matches a single character
|
||||
- `[abc]` matches any character in the brackets
|
||||
- `{a,b}` matches either pattern
|
||||
|
||||
| Pattern | Matches |
|
||||
|---------|---------|
|
||||
| `src/**/*.ts` | All TypeScript files under `src/` |
|
||||
| `*.md` | Markdown files in root only |
|
||||
| `**/*.test.ts` | Test files anywhere in the project |
|
||||
| `packages/{web,api}/**` | Files in web or api packages |
|
||||
| `src/components/*.tsx` | TSX files directly in components (not nested) |
|
||||
|
||||
#### Behavior Details
|
||||
|
||||
**Multiple patterns**: A rule activates if any pattern matches any file in your context.
|
||||
|
||||
```yaml
|
||||
---
|
||||
paths:
|
||||
- "frontend/**"
|
||||
- "mobile/**"
|
||||
---
|
||||
# Activates when working in frontend OR mobile
|
||||
```
|
||||
|
||||
**No frontmatter**: Rules without frontmatter are always active.
|
||||
|
||||
**Empty paths array**: `paths: []` means the rule never activates. Use this to temporarily disable a rule.
|
||||
|
||||
**Invalid YAML**: If frontmatter can't be parsed, Cline fails open. The rule activates with raw content visible to help debugging.
|
||||
|
||||
### What Counts as "Current Context"
|
||||
|
||||
Cline evaluates rules based on:
|
||||
|
||||
1. **Your message**: File paths mentioned in your prompt (e.g., "update `src/App.tsx`")
|
||||
2. **Open tabs**: Files currently open in your editor
|
||||
3. **Visible files**: Files visible in your active editor panes
|
||||
4. **Edited files**: Files Cline has created, modified, or deleted during the task
|
||||
5. **Pending operations**: Files Cline is about to edit
|
||||
|
||||
Conditional rules can activate on your first message, when relevant files are open, or mid-task when Cline starts working with matching files.
|
||||
|
||||
<Tip>
|
||||
Be explicit about file paths in your prompts. "Update `src/services/user.ts`" reliably triggers path-based rules; "update the user service" may not.
|
||||
</Tip>
|
||||
|
||||
### Practical Examples
|
||||
|
||||
Copy these patterns and adapt them to your project structure.
|
||||
|
||||
#### Frontend vs Backend Rules
|
||||
|
||||
Keep frontend and backend rules separate to avoid noise. Frontend rules only load when working with UI code, backend rules only load when working with API or service code.
|
||||
|
||||
```yaml
|
||||
# .clinerules/frontend.md
|
||||
---
|
||||
paths:
|
||||
- "src/components/**"
|
||||
- "src/pages/**"
|
||||
- "src/hooks/**"
|
||||
---
|
||||
|
||||
# Frontend Guidelines
|
||||
|
||||
- Use Tailwind CSS for styling
|
||||
- Prefer server components where possible
|
||||
- Keep client components small and focused
|
||||
```
|
||||
|
||||
```yaml
|
||||
# .clinerules/backend.md
|
||||
---
|
||||
paths:
|
||||
- "src/api/**"
|
||||
- "src/services/**"
|
||||
- "src/db/**"
|
||||
---
|
||||
|
||||
# Backend Guidelines
|
||||
|
||||
- Use dependency injection for services
|
||||
- All database queries go through repositories
|
||||
- Return typed errors, not thrown exceptions
|
||||
```
|
||||
|
||||
#### Test File Rules
|
||||
|
||||
Enforce testing standards automatically. This rule activates only when you're writing or modifying tests, so testing guidance appears exactly when you need it.
|
||||
|
||||
```yaml
|
||||
# .clinerules/testing.md
|
||||
---
|
||||
paths:
|
||||
- "**/*.test.ts"
|
||||
- "**/*.spec.ts"
|
||||
- "**/__tests__/**"
|
||||
---
|
||||
|
||||
# Testing Standards
|
||||
|
||||
- Use descriptive test names: "should [expected behavior] when [condition]"
|
||||
- One assertion per test when possible
|
||||
- Mock external dependencies, not internal modules
|
||||
- Use factories for test data, not fixtures
|
||||
```
|
||||
|
||||
#### Documentation Rules
|
||||
|
||||
Apply documentation standards only when editing docs. Prevents style rules from cluttering your context when you're writing code.
|
||||
|
||||
```yaml
|
||||
# .clinerules/docs.md
|
||||
---
|
||||
paths:
|
||||
- "docs/**"
|
||||
- "**/*.md"
|
||||
- "**/*.mdx"
|
||||
---
|
||||
|
||||
# Documentation Guidelines
|
||||
|
||||
- Use sentence case for headings
|
||||
- Include code examples for all features
|
||||
- Keep paragraphs short (3-4 sentences max)
|
||||
- Link to related documentation
|
||||
```
|
||||
|
||||
### Combining with Rule Toggles
|
||||
|
||||
Conditional rules work alongside the rule toggle UI. Toggle off a conditional rule to disable it entirely (it won't activate even if paths match). Toggle on to let it activate when conditions are met.
|
||||
|
||||
This provides two levels of control: manual toggles and automatic condition-based activation.
|
||||
|
||||
### Tips for Effective Conditional Rules
|
||||
|
||||
**Start Broad, Then Narrow.** Begin with broader patterns and refine as you learn what works:
|
||||
|
||||
```yaml
|
||||
# Start here
|
||||
paths:
|
||||
- "src/**"
|
||||
|
||||
# Then narrow down
|
||||
paths:
|
||||
- "src/features/auth/**"
|
||||
```
|
||||
|
||||
**Use Descriptive Filenames.** Name your rule files to indicate their scope:
|
||||
|
||||
```text
|
||||
.clinerules/
|
||||
├── api-endpoints.md # Rules for API code
|
||||
├── database-models.md # Rules for DB layer
|
||||
├── react-components.md # Rules for React
|
||||
└── universal.md # No frontmatter = always active
|
||||
```
|
||||
|
||||
**Keep Universal Rules Separate.** Put always-on rules (coding standards, project conventions) in files without frontmatter. Reserve conditional rules for context-specific guidance.
|
||||
|
||||
**Test Your Patterns.** Not sure if a pattern matches? Create a simple test rule:
|
||||
|
||||
```yaml
|
||||
---
|
||||
paths:
|
||||
- "your/pattern/here/**"
|
||||
---
|
||||
TEST: This rule should activate for your/pattern/here files.
|
||||
```
|
||||
|
||||
Then work with a file in that path and check if you see the activation notification.
|
||||
|
||||
### Troubleshooting Conditional Rules
|
||||
|
||||
**Rule not activating:**
|
||||
- Check that file paths in your context match the glob pattern
|
||||
- Verify the rule is toggled on in the rules panel
|
||||
- Ensure YAML frontmatter has proper `---` delimiters
|
||||
|
||||
**Rule activating unexpectedly:**
|
||||
- Review glob patterns. `**` is recursive and may match more than intended
|
||||
- Check for open files that match the pattern
|
||||
- File paths mentioned in your message also count as context
|
||||
|
||||
**Frontmatter showing in output:**
|
||||
- YAML couldn't be parsed
|
||||
- Check for syntax errors (unquoted special characters, improper indentation)
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
title: ".clineignore"
|
||||
sidebarTitle: ".clineignore"
|
||||
description: "Control which files and directories Cline can access in your project."
|
||||
---
|
||||
|
||||
The `.clineignore` file tells Cline which files and directories to skip when analyzing your codebase. It works like `.gitignore`: create a file named `.clineignore` in your project root, add patterns for files you want excluded, and Cline will ignore them.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
Without a `.clineignore`, Cline may load your entire project into context, including dependencies, build artifacts, and generated files. This wastes tokens, increases costs, and can push useful context out of the window.
|
||||
|
||||
Adding a `.clineignore` can cut your starting context from 200k+ tokens to under 50k. That means faster responses, lower costs, and the ability to use smaller, cheaper models effectively.
|
||||
|
||||
## Creating a .clineignore
|
||||
|
||||
Create a file named `.clineignore` in your project root:
|
||||
|
||||
```text
|
||||
# Dependencies
|
||||
node_modules/
|
||||
**/node_modules/
|
||||
|
||||
# Build outputs
|
||||
/build/
|
||||
/dist/
|
||||
/.next/
|
||||
/out/
|
||||
|
||||
# Testing artifacts
|
||||
/coverage/
|
||||
|
||||
# Environment variables
|
||||
.env
|
||||
.env.*
|
||||
|
||||
# Large data files
|
||||
*.csv
|
||||
*.xlsx
|
||||
*.sqlite
|
||||
|
||||
# Generated/minified code
|
||||
*.min.js
|
||||
*.map
|
||||
```
|
||||
|
||||
## Pattern Syntax
|
||||
|
||||
`.clineignore` uses the same pattern syntax as `.gitignore`:
|
||||
|
||||
| Pattern | Matches |
|
||||
|---------|---------|
|
||||
| `node_modules/` | The `node_modules` directory |
|
||||
| `**/node_modules/` | `node_modules` at any depth |
|
||||
| `*.csv` | All CSV files |
|
||||
| `/build/` | The `build` directory at the project root only |
|
||||
| `*.env.*` | Files like `.env.local`, `.env.production` |
|
||||
| `!important.csv` | Exception: do not ignore this file |
|
||||
|
||||
Lines starting with `#` are comments. Blank lines are ignored.
|
||||
|
||||
## What to Exclude
|
||||
|
||||
Start with these categories and adjust for your project:
|
||||
|
||||
**Almost always exclude:**
|
||||
- Package manager directories (`node_modules/`, `vendor/`, `.venv/`)
|
||||
- Build outputs (`dist/`, `build/`, `.next/`, `out/`)
|
||||
- Coverage reports (`coverage/`)
|
||||
- Lock files if large (`package-lock.json`, `yarn.lock`)
|
||||
|
||||
**Exclude if present:**
|
||||
- Large data files (`.csv`, `.xlsx`, `.sqlite`, `.parquet`)
|
||||
- Binary assets (images, fonts, videos)
|
||||
- Generated code (API clients, protobuf outputs, minified bundles)
|
||||
- Environment files with secrets (`.env`, `.env.local`)
|
||||
|
||||
**Keep accessible:**
|
||||
- Source code you actively work on
|
||||
- Configuration files Cline needs to understand (`tsconfig.json`, `package.json`)
|
||||
- Documentation and READMEs
|
||||
- Test files (Cline often needs these for context)
|
||||
|
||||
## How It Works
|
||||
|
||||
When Cline scans your project to build context, it checks each file path against your `.clineignore` patterns. Matching files are excluded from:
|
||||
|
||||
- The file listing Cline sees when starting a task
|
||||
- Automatic context gathering during conversations
|
||||
- Search results when Cline looks for relevant code
|
||||
|
||||
You can still reference ignored files explicitly using [@ mentions](/core-workflows/working-with-files). If you type `@/node_modules/some-package/index.js`, Cline will read that specific file even though `node_modules/` is in your `.clineignore`. The ignore rules control automatic loading, not explicit access.
|
||||
|
||||
<Note>
|
||||
`.clineignore` is separate from `.gitignore`. Files tracked by Git but irrelevant to Cline (like large test fixtures or data files) should go in `.clineignore` even if they're not in `.gitignore`.
|
||||
</Note>
|
||||
|
||||
## Tips
|
||||
|
||||
- Add `.clineignore` early in your project. It's easier to start with broad exclusions and narrow them than to debug why context is bloated later.
|
||||
- Check your token usage in the task header after adding a `.clineignore`. The difference is often dramatic.
|
||||
- If Cline seems to be missing context about a file, check whether it's being excluded by your ignore patterns.
|
||||
- For monorepos or multi-root workspaces, each workspace root can have its own `.clineignore`. See [Multi-Root Workspaces](/features/multiroot-workspace) for details.
|
||||
|
||||
## Related
|
||||
|
||||
- [Cline Rules](/customization/cline-rules) - Define persistent instructions for Cline
|
||||
- [Task Management](/core-workflows/task-management#context-window) - Understand how context windows work
|
||||
- [Auto-Compact](/features/auto-compact) - Automatic context compression during long tasks
|
||||
- [Memory Bank](/features/memory-bank) - Structured documentation for cross-session context
|
||||
@@ -0,0 +1,470 @@
|
||||
---
|
||||
title: "Hooks"
|
||||
sidebarTitle: "Hooks"
|
||||
description: "Inject custom logic into Cline's workflow to validate operations and shape Cline's decisions."
|
||||
---
|
||||
|
||||
Hooks are scripts that run at key moments in Cline's workflow. Because they execute at known points with consistent inputs and outputs, hooks bring determinism to the non-deterministic nature of AI models by enforcing guardrails, validations, and context injection. You can validate operations before they execute, monitor tool usage, and shape how Cline makes decisions.
|
||||
|
||||
## What You Can Build
|
||||
|
||||
- Stop operations before they cause problems (like creating `.js` files in a TypeScript project)
|
||||
- Run linters or custom validators before files get saved
|
||||
- Prevent operations that violate security policies
|
||||
- Track everything for analytics or compliance
|
||||
- Trigger external tools or services at the right moments
|
||||
- Add context to the conversation based on what Cline is doing
|
||||
|
||||
## Hook Types
|
||||
|
||||
Cline supports 8 hook types that run at different points in the task lifecycle:
|
||||
|
||||
| Hook Type | When It Runs |
|
||||
|-----------|--------------|
|
||||
| TaskStart | When you start a new task |
|
||||
| TaskResume | When you resume an interrupted task |
|
||||
| TaskCancel | When you cancel a running task |
|
||||
| TaskComplete | When a task finishes successfully |
|
||||
| PreToolUse | Before Cline executes a tool (read_file, write_to_file, etc.) |
|
||||
| PostToolUse | After a tool execution completes |
|
||||
| UserPromptSubmit | When you submit a message to Cline |
|
||||
| PreCompact | Before Cline truncates conversation history to free up context |
|
||||
|
||||
## Hook Lifecycle
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
%% Styling
|
||||
classDef hook fill:#FFB74D,stroke:#E65100,stroke-width:2px,color:black,rx:5,ry:5;
|
||||
classDef state fill:#E1F5FE,stroke:#0277BD,stroke-width:2px,color:black;
|
||||
classDef action fill:#FFFFFF,stroke:#333,stroke-width:1px,color:black,stroke-dasharray: 5 5;
|
||||
|
||||
%% Entry Points
|
||||
Start((Start)) --> CheckType{New or<br/>Resume?}
|
||||
|
||||
%% Initialization Hooks
|
||||
CheckType -- New Task --> H_Start[TaskStart]:::hook
|
||||
CheckType -- Resume --> H_Resume[TaskResume]:::hook
|
||||
|
||||
%% Main Loop
|
||||
H_Start --> Loop(Task Active Loop):::state
|
||||
H_Resume --> Loop
|
||||
|
||||
subgraph Conversation Cycle
|
||||
direction TB
|
||||
Loop -- User sends message --> H_Submit[UserPromptSubmit]:::hook
|
||||
H_Submit --> Thinking[Cline Processes Context]:::state
|
||||
|
||||
%% Context Compaction Path
|
||||
Thinking -. Context Limit Reached .-> H_Compact[PreCompact]:::hook
|
||||
H_Compact -.-> Thinking
|
||||
|
||||
%% Tool Execution Path
|
||||
Thinking -- Decides to use tool --> H_PreTool[PreToolUse]:::hook
|
||||
H_PreTool -- Allowed --> ToolExec[Tool Executes]:::action
|
||||
H_PreTool -- Cancelled --> Thinking
|
||||
ToolExec --> H_PostTool[PostToolUse]:::hook
|
||||
H_PostTool --> Thinking
|
||||
end
|
||||
|
||||
%% Termination Paths
|
||||
Thinking -- Task Successfully Finished --> H_Complete[TaskComplete]:::hook
|
||||
Loop -- User Cancels Task --> H_Cancel[TaskCancel]:::hook
|
||||
|
||||
%% End
|
||||
H_Complete --> End((End))
|
||||
H_Cancel --> End
|
||||
```
|
||||
|
||||
The diagram shows the complete hook lifecycle:
|
||||
|
||||
1. **Entry**: When you start a task, either **TaskStart** (new task) or **TaskResume** (interrupted task) runs first
|
||||
2. **Conversation Cycle**: Each time you send a message, **UserPromptSubmit** runs, then Cline processes your request
|
||||
3. **Tool Execution**: When Cline decides to use a tool, **PreToolUse** runs first-if allowed, the tool executes, then **PostToolUse** runs
|
||||
4. **Context Management**: If the conversation approaches context limits, **PreCompact** runs before truncation
|
||||
5. **Exit**: The task ends with either **TaskComplete** (success) or **TaskCancel** (user cancellation)
|
||||
|
||||
Orange nodes represent hooks where you can inject custom logic. The cycle repeats as you continue the conversation.
|
||||
|
||||
## Hook Locations
|
||||
|
||||
Hooks can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
|
||||
|
||||
- **Global hooks**: `~/Documents/Cline/Hooks/`
|
||||
- **Project hooks**: `.clinerules/hooks/` in your repo (can be committed to version control)
|
||||
|
||||
When both global and workspace hooks exist for the same hook type, both run. Global hooks execute first, then workspace hooks. If either returns `cancel: true`, the operation stops.
|
||||
|
||||
## Creating a Hook
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the Hooks tab">
|
||||
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Hooks tab.
|
||||
</Step>
|
||||
<Step title="Create a new hook">
|
||||
Click **"New hook..."** dropdown and select a hook type (e.g., PreToolUse, TaskStart).
|
||||
</Step>
|
||||
<Step title="Review the hook's code">
|
||||
Click the pencil icon to open and edit the hook script. Cline generates a template with examples.
|
||||
</Step>
|
||||
<Step title="Enable the hook">
|
||||
Toggle the switch to activate the hook once you understand what it does.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Warning>
|
||||
Always review a hook's code before enabling it. Hooks execute automatically during your workflow and can block operations or run shell commands.
|
||||
</Warning>
|
||||
|
||||
## Quick Start: Your First Hook
|
||||
|
||||
Let's create a simple hook that logs every file Cline reads or writes. You'll see results in seconds.
|
||||
|
||||
### The Hook
|
||||
|
||||
Create a file called `file-logger` in your hooks directory with this content:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# Logs all file operations to ~/cline-activity.log
|
||||
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
|
||||
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // "N/A"')
|
||||
|
||||
# Log to file
|
||||
echo "$(date '+%H:%M:%S') - $TOOL: $FILE_PATH" >> ~/cline-activity.log
|
||||
|
||||
# Always allow the operation
|
||||
echo '{"cancel":false}'
|
||||
```
|
||||
|
||||
### Setup
|
||||
|
||||
<Steps>
|
||||
<Step title="Create the hook file">
|
||||
Save the script above as `~/Documents/Cline/Hooks/file-logger` (macOS/Linux) or create it through the Hooks UI.
|
||||
</Step>
|
||||
<Step title="Make it executable">
|
||||
Run `chmod +x ~/Documents/Cline/Hooks/file-logger` in your terminal.
|
||||
</Step>
|
||||
<Step title="Enable it">
|
||||
In Cline's Hooks tab, find "file-logger" under PreToolUse hooks and toggle it on.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
### Test It
|
||||
|
||||
Ask Cline to read any file in your project: "What's in package.json?"
|
||||
|
||||
Then check the log:
|
||||
|
||||
```bash
|
||||
cat ~/cline-activity.log
|
||||
```
|
||||
|
||||
You'll see entries like:
|
||||
```text
|
||||
14:23:45 - read_file: /path/to/package.json
|
||||
14:23:47 - search_files: /path/to/src
|
||||
```
|
||||
|
||||
### Customize It
|
||||
|
||||
Try modifying the hook to:
|
||||
- Filter specific file types (only log `.ts` files)
|
||||
- Add the task ID to each log entry
|
||||
- Send notifications for write operations
|
||||
- Block operations on certain paths
|
||||
|
||||
The sections below explain how hooks receive input and return output, plus more examples.
|
||||
|
||||
## How Hooks Work
|
||||
|
||||
Hooks are executable scripts that receive JSON input via stdin and return JSON output via stdout.
|
||||
|
||||
### Input Structure
|
||||
|
||||
Every hook receives a JSON object with common fields plus hook-specific data:
|
||||
|
||||
```json
|
||||
{
|
||||
"taskId": "abc123",
|
||||
"clineVersion": "3.17.0",
|
||||
"timestamp": 1736654400000,
|
||||
"workspacePath": "/path/to/project",
|
||||
|
||||
// Hook-specific field (name matches hook type in camelCase)
|
||||
"taskStart": {
|
||||
"task": "Add authentication to the API"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The hook-specific field name matches the hook type:
|
||||
- `taskStart`, `taskResume`, `taskCancel`, `taskComplete` contain `{ task: string }`
|
||||
- `preToolUse` contains `{ tool: string, parameters: object }`
|
||||
- `postToolUse` contains `{ tool: string, parameters: object, result: string, success: boolean, durationMs: number }`
|
||||
- `userPromptSubmit` contains `{ prompt: string }`
|
||||
- `preCompact` contains `{ conversationLength: number, estimatedTokens: number }`
|
||||
|
||||
### Output Structure
|
||||
|
||||
Hooks return a JSON object to stdout:
|
||||
|
||||
```json
|
||||
{
|
||||
"cancel": false,
|
||||
"contextModification": "Optional text to add to the conversation",
|
||||
"errorMessage": ""
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `cancel` | boolean | If `true`, stops the operation (blocks the tool, cancels the task start, etc.) |
|
||||
| `contextModification` | string | Optional text that gets injected into the conversation as context for Cline |
|
||||
| `errorMessage` | string | Shown to the user if `cancel` is `true` |
|
||||
|
||||
### Context Modification
|
||||
|
||||
The `contextModification` field lets hooks inject information into the conversation. This is useful for:
|
||||
|
||||
- Adding project-specific context when a task starts
|
||||
- Providing validation results that Cline should consider
|
||||
- Injecting environment information before tool execution
|
||||
|
||||
For example, a PreToolUse hook could add: `"Note: This file is auto-generated. Edits may be overwritten."`
|
||||
|
||||
## Hook Reference
|
||||
|
||||
### Task Lifecycle Hooks
|
||||
|
||||
#### TaskStart
|
||||
|
||||
Runs when you start a new task. Use it to:
|
||||
- Log task start time for analytics
|
||||
- Add project context to the conversation
|
||||
- Check prerequisites before work begins
|
||||
- Notify external systems (Slack, issue trackers)
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
INPUT=$(cat)
|
||||
TASK=$(echo "$INPUT" | jq -r '.taskStart.task')
|
||||
echo "[TaskStart] Starting: $TASK" >&2
|
||||
echo '{"cancel":false,"contextModification":"","errorMessage":""}'
|
||||
```
|
||||
|
||||
#### TaskResume
|
||||
|
||||
Runs when you resume an interrupted task (instead of TaskStart). Use it to:
|
||||
- Check for changes since the task was paused
|
||||
- Refresh context with latest project state
|
||||
- Notify that work is resuming
|
||||
|
||||
#### TaskCancel
|
||||
|
||||
Runs when you cancel a running task. Use it to:
|
||||
- Clean up temporary files or resources
|
||||
- Notify external systems about cancellation
|
||||
- Log cancellation for analytics
|
||||
|
||||
#### TaskComplete
|
||||
|
||||
Runs when a task completes successfully. Use it to:
|
||||
- Run tests or validation after changes
|
||||
- Generate reports or summaries
|
||||
- Notify stakeholders
|
||||
- Trigger CI/CD pipelines
|
||||
|
||||
### Tool Hooks
|
||||
|
||||
#### PreToolUse
|
||||
|
||||
Runs before any tool executes. This is the most powerful hook for validation and safety. Use it to:
|
||||
- Block dangerous operations
|
||||
- Validate parameters before execution
|
||||
- Add context about the file or resource being accessed
|
||||
- Log tool usage
|
||||
|
||||
The input includes the tool name and its parameters:
|
||||
|
||||
```json
|
||||
{
|
||||
"preToolUse": {
|
||||
"tool": "write_to_file",
|
||||
"parameters": {
|
||||
"path": "src/config.ts",
|
||||
"content": "..."
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Example that blocks `.js` files in a TypeScript project:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
|
||||
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
|
||||
|
||||
if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
|
||||
echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo '{"cancel":false}'
|
||||
```
|
||||
|
||||
#### PostToolUse
|
||||
|
||||
Runs after a tool completes (success or failure). Use it to:
|
||||
- Audit tool usage
|
||||
- Validate results
|
||||
- Trigger follow-up actions
|
||||
- Monitor performance
|
||||
|
||||
The input includes execution results:
|
||||
|
||||
```json
|
||||
{
|
||||
"postToolUse": {
|
||||
"tool": "execute_command",
|
||||
"parameters": { "command": "npm test" },
|
||||
"result": "All tests passed",
|
||||
"success": true,
|
||||
"durationMs": 3450
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
PostToolUse hooks can return `cancel: true` to stop the task, but they cannot undo the tool execution that already happened.
|
||||
</Note>
|
||||
|
||||
### Other Hooks
|
||||
|
||||
#### UserPromptSubmit
|
||||
|
||||
Runs when you send a message to Cline. Use it to:
|
||||
- Log prompts for analytics
|
||||
- Add context based on prompt content
|
||||
- Validate or sanitize prompts
|
||||
|
||||
#### PreCompact
|
||||
|
||||
Runs before Cline truncates conversation history to stay within context limits. Use it to:
|
||||
- Archive important conversation parts before they're removed
|
||||
- Log compaction events
|
||||
- Add a summary of what's being removed
|
||||
|
||||
The input includes context metrics:
|
||||
|
||||
```json
|
||||
{
|
||||
"preCompact": {
|
||||
"conversationLength": 45,
|
||||
"estimatedTokens": 125000
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### TypeScript Enforcement
|
||||
|
||||
Block creation of `.js` files in a TypeScript project:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# PreToolUse hook
|
||||
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.preToolUse.tool')
|
||||
FILE_PATH=$(echo "$INPUT" | jq -r '.preToolUse.parameters.path // empty')
|
||||
|
||||
if [[ "$TOOL" == "write_to_file" && "$FILE_PATH" == *.js ]]; then
|
||||
echo '{"cancel":true,"errorMessage":"Use .ts files instead of .js in this TypeScript project"}'
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo '{"cancel":false}'
|
||||
```
|
||||
|
||||
### Tool Usage Logging
|
||||
|
||||
Log all tool executions to a file:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# PostToolUse hook
|
||||
|
||||
INPUT=$(cat)
|
||||
TOOL=$(echo "$INPUT" | jq -r '.postToolUse.tool')
|
||||
SUCCESS=$(echo "$INPUT" | jq -r '.postToolUse.success')
|
||||
DURATION=$(echo "$INPUT" | jq -r '.postToolUse.durationMs')
|
||||
|
||||
echo "$(date -Iseconds) | $TOOL | success=$SUCCESS | ${DURATION}ms" >> ~/.cline-tool-log.txt
|
||||
|
||||
echo '{"cancel":false}'
|
||||
```
|
||||
|
||||
### Add Project Context on Task Start
|
||||
|
||||
Inject project-specific information when a task begins:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
# TaskStart hook
|
||||
|
||||
INPUT=$(cat)
|
||||
WORKSPACE=$(echo "$INPUT" | jq -r '.workspacePath')
|
||||
|
||||
# Read project info if available
|
||||
if [[ -f "$WORKSPACE/.project-context" ]]; then
|
||||
CONTEXT=$(cat "$WORKSPACE/.project-context")
|
||||
echo "{\"cancel\":false,\"contextModification\":\"Project context: $CONTEXT\"}"
|
||||
else
|
||||
echo '{"cancel":false}'
|
||||
fi
|
||||
```
|
||||
|
||||
## CLI Support
|
||||
|
||||
Hooks are available in the [Cline CLI](/cline-cli/getting-started):
|
||||
|
||||
```bash
|
||||
# Enable hooks for a task
|
||||
cline "What does this repo do?" -s hooks_enabled=true
|
||||
|
||||
# Configure hooks globally
|
||||
cline config set hooks-enabled=true
|
||||
```
|
||||
|
||||
<Note>
|
||||
CLI hooks are only supported on macOS and Linux.
|
||||
</Note>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Hook not running?**
|
||||
- Check that the file is executable (`chmod +x hookname`)
|
||||
- Verify the hook is enabled (toggle is on in the Hooks tab)
|
||||
- Check that Hooks are enabled globally in Settings
|
||||
|
||||
**Hook output not parsed?**
|
||||
- Ensure output is valid JSON on a single line to stdout
|
||||
- Use stderr (`>&2`) for debug logging, not stdout
|
||||
- Check for trailing characters or newlines before the JSON
|
||||
|
||||
**Hook blocking unexpectedly?**
|
||||
- Review the hook's logic and test with sample input
|
||||
- Check both global and workspace hooks (both run if they exist)
|
||||
|
||||
## Related Features
|
||||
|
||||
- [Rules](/customization/cline-rules) define high-level guidance that hooks can enforce programmatically
|
||||
- [Checkpoints](/core-workflows/checkpoints) let you roll back if a hook didn't catch an issue
|
||||
- [Auto-Approve](/features/auto-approve) works well with hooks as safety nets
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Understand how Rules, Skills, Workflows, Hooks, and .clineignore work together to customize Cline."
|
||||
---
|
||||
|
||||
Out of the box, Cline is a general-purpose AI assistant. Customizations transform it into an expert on your codebase, your team's conventions, and your workflows. Instead of repeating the same instructions every task, you define them once and Cline follows them automatically.
|
||||
|
||||
Cline offers five systems for this: Rules, Skills, Workflows, Hooks, and .clineignore. Each serves a different purpose and activates at different times.
|
||||
|
||||
## Quick Comparison
|
||||
|
||||
| Feature | Purpose | When Active | Best For |
|
||||
|---------|---------|-------------|----------|
|
||||
| **[Rules](/customization/cline-rules)** | Define how Cline behaves | Always (or contextually) | Coding standards, project constraints, team conventions |
|
||||
| **[Skills](/customization/skills)** | Domain expertise loaded on-demand | Triggered by matching requests | Specialized knowledge, complex procedures, institutional expertise |
|
||||
| **[Workflows](/customization/workflows)** | Step-by-step task automation | Invoked with `/workflow.md` | Repetitive processes, release procedures, setup scripts |
|
||||
| **[Hooks](/customization/hooks)** | Inject custom logic at key moments | Automatically on specific events | Validation, enforcement, monitoring, automation triggers |
|
||||
| **[.clineignore](/customization/clineignore)** | Control file access | Always | Excluding dependencies, build artifacts, large data files |
|
||||
|
||||
## Understanding Each Tool
|
||||
|
||||
**[Rules](/customization/cline-rules)** are always-on guidance. Use them when you want Cline to consistently follow certain patterns: coding standards, naming conventions, architectural constraints, or project-specific context. Rules shape *how* Cline works across all tasks. For example, a rule might say "always use TypeScript" or "follow the repository pattern for data access."
|
||||
|
||||
**[Skills](/customization/skills)** are domain expertise that loads only when relevant. Use them when you have extensive knowledge that would waste context if always active. Cline sees skill descriptions at startup and activates the full instructions only when your request matches. A data analysis skill might include pandas patterns, visualization preferences, and output formats that Cline only loads when you're working with data files.
|
||||
|
||||
**[Workflows](/customization/workflows)** are explicit task scripts you invoke on demand. Use them when you have a repeatable multi-step process that should run the same way every time. Type `/release.md` and Cline executes your release sequence: bump version, run tests, update changelog, commit, tag, push. Workflows define *what* to do, step by step.
|
||||
|
||||
**[Hooks](/customization/hooks)** are programmatic guardrails that run automatically at key moments. Use them when you need to validate, enforce, or extend Cline's behavior with custom code. A hook might block `.js` file creation in a TypeScript project, run linters before saves, or notify external services after deployments.
|
||||
|
||||
**[.clineignore](/customization/clineignore)** controls which files and directories Cline can access. Use it to exclude dependencies, build artifacts, generated files, and large data files from Cline's context. This reduces token usage, lowers costs, and keeps Cline focused on the code that matters. It works like `.gitignore`: add patterns to a `.clineignore` file in your project root and matching files are automatically excluded.
|
||||
|
||||
### Example: A Release Process
|
||||
|
||||
Consider how all five work together for releasing a new version:
|
||||
|
||||
1. **Rules** ensure Cline follows your team's commit message format and versioning policy
|
||||
2. **Skills** offer deep knowledge about your CI/CD system that Cline loads when deployment questions arise
|
||||
3. **Workflows** provide the explicit `/release.md` sequence: bump version, update changelog, tag, push
|
||||
4. **Hooks** validate that tests pass before allowing any commit or that the changelog was actually updated
|
||||
5. **.clineignore** keeps build artifacts, `node_modules/`, and generated files out of Cline's context so it stays focused
|
||||
|
||||
## Storage Locations
|
||||
|
||||
All five systems support both global and project-specific configurations:
|
||||
|
||||
| System | Global Location | Project Location |
|
||||
|--------|-----------------|------------------|
|
||||
| Rules | `~/Documents/Cline/Rules/` | `.clinerules/` |
|
||||
| Skills | `~/.cline/skills/` | `.cline/skills/` |
|
||||
| Workflows | `~/Documents/Cline/Workflows/` | `.clinerules/workflows/` |
|
||||
| Hooks | `~/Documents/Cline/Hooks/` | `.clinerules/hooks/` |
|
||||
| .clineignore | N/A | `.clineignore` |
|
||||
|
||||
### When to Use Each
|
||||
|
||||
**Start with project storage.** Most customizations belong in your project's directory because they're tied to that specific codebase. Team coding standards, deployment workflows, and architectural constraints all live with the code they describe. This also means your customizations travel with the repository, so collaborators get them automatically and changes can be reviewed in pull requests.
|
||||
|
||||
**Use global storage for personal preferences.** If you find yourself adding the same customization to every project, move it to global storage. Your preferred communication style, personal productivity workflows, and tools you use everywhere belong here. Global customizations apply to all projects but stay out of version control, so they won't affect your teammates.
|
||||
|
||||
When names conflict, project-specific configurations take precedence (except for Skills, where global takes precedence). This lets you override global defaults for specific projects when needed.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
<Warning>
|
||||
Always review customizations before adding them to your projects. Only use customizations from sources you trust.
|
||||
</Warning>
|
||||
|
||||
Customizations are powerful. They shape how Cline writes code, execute commands automatically, and influence every interaction. Treat customization files with the same scrutiny you'd give any code running in your environment.
|
||||
|
||||
### Best Practices
|
||||
|
||||
Review any customization file before adding it to your project or global configuration. Understand what it does and why.
|
||||
|
||||
When downloading customizations from GitHub repositories, community shares, or other external sources, verify the source:
|
||||
- Is the author reputable?
|
||||
- Has the community reviewed it?
|
||||
- Does the code do what it claims?
|
||||
|
||||
Look for dangerous commands:
|
||||
- Shell commands that delete files (`rm`, `del`)
|
||||
- Commands that transmit data (`curl`, `wget` with POST)
|
||||
- File operations outside your project directory
|
||||
- Commands that modify system configuration
|
||||
|
||||
Keep your customizations in version control so you can track changes, review diffs, and roll back if something goes wrong. When creating hooks, use the most restrictive event triggers necessary. Don't run hooks on every file save if you only need them before commits.
|
||||
@@ -0,0 +1,261 @@
|
||||
---
|
||||
title: "Skills"
|
||||
sidebarTitle: "Skills"
|
||||
description: "Modular instruction sets that extend Cline's capabilities for specific tasks."
|
||||
---
|
||||
|
||||
Skills are modular instruction sets that extend Cline's capabilities for specific tasks. Each skill packages detailed guidance, workflows, and optional resources that Cline loads only when relevant to your request.
|
||||
|
||||
Install multiple skills and Cline only loads what it needs. A deployment skill stays dormant until you ask about deploying. Unlike [rules](/customization/cline-rules) (which are always active), skills load on-demand so they don't consume context when you're working on something unrelated.
|
||||
|
||||
<Note>
|
||||
Skills is an experimental feature. Enable it in **Settings → Features → Enable Skills**.
|
||||
</Note>
|
||||
|
||||
## How Skills Work
|
||||
|
||||
Skills use progressive loading to maximize efficiency:
|
||||
|
||||
| Level | When Loaded | Token Cost | Content |
|
||||
|-------|-------------|------------|---------|
|
||||
| Metadata | Always (at startup) | ~100 tokens per skill | `name` and `description` from YAML frontmatter |
|
||||
| Instructions | When skill is triggered | Under 5k tokens | SKILL.md body with instructions and guidance |
|
||||
| Resources | As needed | Effectively unlimited | Bundled files accessed via `read_file` or executed scripts |
|
||||
|
||||
When you send a message, Cline sees a list of available skills with their descriptions. If your request matches a skill's description, Cline activates it using the `use_skill` tool, which loads the full instructions from SKILL.md.
|
||||
|
||||
## Skill Structure
|
||||
|
||||
Every skill is a directory containing a `SKILL.md` file with YAML frontmatter.
|
||||
|
||||
```text title="Skill directory structure"
|
||||
my-skill/
|
||||
├── SKILL.md # Required: main instructions
|
||||
├── docs/ # Optional: additional documentation
|
||||
│ └── advanced.md
|
||||
└── scripts/ # Optional: utility scripts
|
||||
└── helper.sh
|
||||
```
|
||||
|
||||
The `SKILL.md` file has two parts: metadata and instructions.
|
||||
|
||||
```markdown title="SKILL.md"
|
||||
---
|
||||
name: my-skill
|
||||
description: Brief description of what this skill does and when to use it.
|
||||
---
|
||||
|
||||
# My Skill
|
||||
|
||||
Detailed instructions for Cline to follow when this skill is activated.
|
||||
|
||||
## Steps
|
||||
1. First, do this
|
||||
2. Then do that
|
||||
3. For advanced usage, see [advanced.md](docs/advanced.md)
|
||||
```
|
||||
|
||||
Required fields:
|
||||
- `name` must exactly match the directory name
|
||||
- `description` tells Cline when to use this skill (max 1024 characters)
|
||||
|
||||
## Creating a Skill
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the Skills menu">
|
||||
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Skills tab.
|
||||
</Step>
|
||||
<Step title="Create a new skill">
|
||||
Click "New skill..." and enter a name for your skill (e.g., `aws-deploy`). Cline creates a skill directory with a template `SKILL.md` file.
|
||||
</Step>
|
||||
<Step title="Write your skill instructions">
|
||||
Edit the `SKILL.md` file:
|
||||
- Update the `description` field to specify when this skill should trigger
|
||||
- Add detailed instructions in the body
|
||||
- Optionally add supporting files in `docs/`, `templates/`, or `scripts/` subdirectories
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
You can also create skills manually by creating the directory structure in your file system. Place skill directories in `.cline/skills/` (workspace) or `~/.cline/skills/` (global) and Cline will detect them automatically.
|
||||
|
||||
Put the important information first in your SKILL.md. Cline reads the file sequentially, so front-load the common cases. Use clear section headers like "## Error Handling" or "## Configuration" so Cline can scan for relevant sections.
|
||||
|
||||
### Toggling Skills
|
||||
|
||||
Every skill has a toggle to enable or disable it. This lets you control which skills are active without deleting the skill directory. Skills are enabled by default when discovered.
|
||||
|
||||
For example, you might disable a CI/CD skill when working on local development, or enable a client-specific skill only when working on that client's project.
|
||||
|
||||
## Writing Your SKILL.md
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
The skill name appears in the `name` field and must match the directory name exactly. Use lowercase with hyphens (kebab-case) and be descriptive about what the skill does.
|
||||
|
||||
Good names:
|
||||
- `aws-cdk-deploy`
|
||||
- `pr-review-checklist`
|
||||
- `database-migration`
|
||||
- `api-client-generator`
|
||||
|
||||
Avoid:
|
||||
- `aws` (too vague)
|
||||
- `my_skill` (underscores, not descriptive)
|
||||
- `DeployToAWS` (use kebab-case, not PascalCase)
|
||||
- `misc-helpers` (too generic)
|
||||
|
||||
### Writing Effective Descriptions
|
||||
|
||||
The description determines when Cline activates the skill. A vague description means the skill won't trigger when you expect it to.
|
||||
|
||||
Good descriptions are specific and actionable:
|
||||
|
||||
```yaml
|
||||
description: Deploy applications to AWS using CDK. Use when deploying, updating infrastructure, or managing AWS resources.
|
||||
|
||||
description: Generate release notes from git commits. Use when preparing releases, writing changelogs, or summarizing recent changes.
|
||||
|
||||
description: Analyze CSV and Excel data files. Use when exploring datasets, generating statistics, or creating visualizations from tabular data.
|
||||
```
|
||||
|
||||
Weak descriptions leave too much ambiguity:
|
||||
|
||||
```yaml
|
||||
description: Helps with AWS stuff.
|
||||
|
||||
description: Data analysis helper.
|
||||
|
||||
description: Useful for releases.
|
||||
```
|
||||
|
||||
Start with what the skill does (action verbs), include trigger phrases users might say, and mention specific file types, tools, or domains. Test your descriptions by trying different phrasings of requests to see if the skill triggers.
|
||||
|
||||
### Keeping Skills Focused
|
||||
|
||||
Keep SKILL.md under 5k tokens. If your skill needs more content, split it into separate files in a `docs/` directory and reference them from the main instructions. Cline loads referenced files only when needed.
|
||||
|
||||
Include real examples. Show what commands to run, what output to expect, and what the result should look like. Abstract instructions are harder to follow than concrete examples.
|
||||
|
||||
## Where Skills Live
|
||||
|
||||
Skills can be stored globally or in a project workspace. See [Storage Locations](/customization/overview#storage-locations) for guidance on when to use each.
|
||||
|
||||
Project skills:
|
||||
- `.cline/skills/` (recommended)
|
||||
- `.clinerules/skills/`
|
||||
- `.claude/skills/`
|
||||
|
||||
Global skills:
|
||||
- `~/.cline/skills/` (macOS/Linux)
|
||||
- `C:\Users\USERNAME\.cline\skills\` (Windows)
|
||||
|
||||
When a global skill and project skill have the same name, the global skill takes precedence. This lets you keep general-purpose skills globally while using project-specific skills in `.cline/skills/` so the whole team can use them.
|
||||
|
||||
Version control your project skills by committing `.cline/skills/`. Your team can share, review, and improve them together.
|
||||
|
||||
## Bundling Supporting Files
|
||||
|
||||
Skills can include additional files that Cline accesses only when needed.
|
||||
|
||||
```text title="Directory structure"
|
||||
complex-skill/
|
||||
├── SKILL.md
|
||||
├── docs/
|
||||
│ ├── setup.md
|
||||
│ └── troubleshooting.md
|
||||
├── templates/
|
||||
│ └── config.yaml
|
||||
└── scripts/
|
||||
└── validate.py
|
||||
```
|
||||
|
||||
### docs/
|
||||
|
||||
Use docs for information that's too detailed for SKILL.md or only relevant in specific situations:
|
||||
- Advanced configuration options
|
||||
- Troubleshooting guides for edge cases
|
||||
- Reference material (API schemas, database schemas)
|
||||
- Platform-specific instructions
|
||||
|
||||
A deployment skill might have `docs/aws.md`, `docs/gcp.md`, and `docs/azure.md`. Cline loads only the relevant platform guide based on your request.
|
||||
|
||||
### templates/
|
||||
|
||||
Use templates when your skill creates configuration files, boilerplate code, or structured documents:
|
||||
- Config files (Terraform, Docker Compose, CI/CD pipelines)
|
||||
- Code scaffolding (component templates, test fixtures)
|
||||
- Documentation templates (README, API docs)
|
||||
|
||||
A project setup skill could include `templates/dockerfile`, `templates/docker-compose.yml`, and `templates/.env.example` that Cline customizes for each new project.
|
||||
|
||||
### scripts/
|
||||
|
||||
Use scripts for deterministic operations where you want consistent behavior:
|
||||
- Validation (linting configs, checking prerequisites)
|
||||
- Data processing (parsing, formatting, transforming)
|
||||
- Complex calculations (cost estimation, resource sizing)
|
||||
- API interactions (fetching data, running health checks)
|
||||
|
||||
Scripts are token-efficient because only their output enters context, not the code itself. A 500-line validation script produces a simple "Passed" or detailed error messages without consuming any context for the script logic.
|
||||
|
||||
### Referencing Bundled Files
|
||||
|
||||
Reference these files in your SKILL.md instructions:
|
||||
|
||||
```markdown title="SKILL.md (referencing bundled files)"
|
||||
For initial setup, follow [setup.md](docs/setup.md).
|
||||
Use the config template at `templates/config.yaml` as a starting point.
|
||||
Run the validation script to check your configuration:
|
||||
|
||||
python scripts/validate.py
|
||||
```
|
||||
|
||||
Cline reads documentation files using `read_file` when the instructions reference them. Scripts can be executed directly, and only the script's output enters the context window.
|
||||
|
||||
| Use Scripts For | Use Instructions For |
|
||||
|-----------------|---------------------|
|
||||
| Deterministic operations (validation, formatting) | Flexible guidance that adapts to context |
|
||||
| Complex computations | Decision-making workflows |
|
||||
| Operations that need reliability | Steps that might vary by situation |
|
||||
| Anything you'd rather not consume tokens explaining | Best practices and patterns |
|
||||
|
||||
## Example: Data Analysis Skill
|
||||
|
||||
Here's a practical skill for data analysis tasks. Create a directory called `data-analysis/` with this `SKILL.md`:
|
||||
|
||||
```markdown title="data-analysis/SKILL.md"
|
||||
---
|
||||
name: data-analysis
|
||||
description: Analyze data files and generate insights. Use when working with CSV, Excel, or JSON data files that need exploration, cleaning, or visualization.
|
||||
---
|
||||
|
||||
# Data Analysis
|
||||
|
||||
When analyzing data files, follow this workflow:
|
||||
|
||||
## 1. Understand the Data
|
||||
- Read a sample of the file to understand its structure
|
||||
- Identify column types and data quality issues
|
||||
- Note any missing values or anomalies
|
||||
|
||||
## 2. Ask Clarifying Questions
|
||||
Before diving in, ask the user:
|
||||
- What specific insights are they looking for?
|
||||
- Are there any known data quality issues?
|
||||
- What format do they want for the output?
|
||||
|
||||
## 3. Perform Analysis
|
||||
Use pandas for data manipulation:
|
||||
|
||||
import pandas as pd
|
||||
|
||||
# Load and explore
|
||||
df = pd.read_csv("data.csv")
|
||||
print(df.head())
|
||||
print(df.describe())
|
||||
print(df.info())
|
||||
|
||||
For visualization, prefer matplotlib or seaborn depending on complexity.
|
||||
```
|
||||
|
||||
Skills transform Cline from a general-purpose assistant into a specialist that knows your domain. Start with one skill for a task you repeat often, test it, and iterate on the description until it triggers reliably.
|
||||
@@ -0,0 +1,221 @@
|
||||
---
|
||||
title: "Workflows"
|
||||
sidebarTitle: "Workflows"
|
||||
description: "Automate repetitive tasks with Markdown-based workflow files."
|
||||
---
|
||||
|
||||
Workflows are Markdown files that define a series of steps to guide Cline through repetitive or complex tasks. Type `/` followed by the workflow's filename to invoke it (e.g., `/deploy.md`).
|
||||
|
||||
Deploying, setting up a new project, running through a release checklist: these tasks often require remembering a dozen steps, running commands in the right order, and updating files manually. Mess up one step and you're debugging for an hour. Workflows turn those multi-step processes into one command. Type `/release.md` and Cline handles the version bump, runs tests, updates the changelog, commits, tags, and pushes. You just review and approve.
|
||||
|
||||
## Workflow Structure
|
||||
|
||||
A workflow is a markdown file with a title and steps. The filename becomes the command: `demo-workflow.md` is invoked with `/demo-workflow.md`.
|
||||
|
||||
````markdown title="demo-workflow.md"
|
||||
# Demo Workflow
|
||||
|
||||
Brief description of what this workflow accomplishes.
|
||||
|
||||
## Step 1: Check prerequisites
|
||||
Verify the environment is ready. Look for required tools and dependencies.
|
||||
|
||||
## Step 2: Run the build
|
||||
Execute the build command:
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
## Step 3: Verify results
|
||||
Check that the build completed successfully and report any issues.
|
||||
````
|
||||
|
||||
Steps can be written at different levels of detail:
|
||||
|
||||
- **High-level**: "Run the test suite and fix any failures" lets Cline decide how to accomplish the goal
|
||||
- **Specific**: Use XML tool syntax or exact commands when you need precise control
|
||||
|
||||
## Creating Workflows
|
||||
|
||||
<Steps>
|
||||
<Step title="Open the Workflows menu">
|
||||
Click the scale icon at the bottom of the Cline panel, to the left of the model selector. Switch to the Workflows tab.
|
||||
</Step>
|
||||
<Step title="Create a new workflow file">
|
||||
Click "New workflow file..." and enter a filename (e.g., `deploy`). The file will be created with a `.md` extension.
|
||||
</Step>
|
||||
<Step title="Write your workflow">
|
||||
Add a title and numbered steps in markdown format. Describe what each step should accomplish.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
<Tip>
|
||||
**Create workflows from completed tasks.** After finishing something you'll need to repeat, tell Cline: "Create a workflow for the process I just completed." Cline analyzes the conversation, identifies the steps, and generates the workflow file. Your accumulated context becomes reusable automation.
|
||||
</Tip>
|
||||
|
||||
### Invoking Workflows
|
||||
|
||||
Type `/` in the chat input to see available workflows. Cline shows autocomplete suggestions as you type, so `/rel` would match `release-prep.md`. Select a workflow and press Enter to start it.
|
||||
|
||||
Cline executes each step in sequence, pausing for your approval when needed. You can stop a workflow at any point by rejecting a step.
|
||||
|
||||
### Toggling Workflows
|
||||
|
||||
Every workflow has a toggle to enable or disable it. This lets you control which workflows appear in the `/` menu without deleting the file.
|
||||
|
||||
## Where Workflows Live
|
||||
|
||||
Workflows can be stored in two locations: your project workspace or globally on your system.
|
||||
|
||||
**Workspace workflows** go in `.clinerules/workflows/` at your project root. Use these for project-specific automation like deployment scripts, release processes, or setup procedures that your team shares.
|
||||
|
||||
**Global workflows** go in your system's Cline Workflows directory. Use these for personal productivity workflows you use across all projects.
|
||||
|
||||
### Global Workflows Directory
|
||||
|
||||
| Operating System | Default Location |
|
||||
|------------------|------------------|
|
||||
| Windows | `Documents\Cline\Workflows` |
|
||||
| macOS | `~/Documents/Cline/Workflows` |
|
||||
| Linux/WSL | `~/Documents/Cline/Workflows` |
|
||||
|
||||
Workspace workflows take precedence when names match global workflows. See [Storage Locations](/customization/overview#storage-locations) for more guidance.
|
||||
|
||||
## What Workflows Can Use
|
||||
|
||||
Workflows can combine natural language instructions with specific tool calls. This flexibility lets you write workflows that are as simple or as precise as your task requires.
|
||||
|
||||
### Natural Language
|
||||
|
||||
Write steps as plain instructions. Cline interprets them and figures out which tools to use:
|
||||
|
||||
```markdown
|
||||
## Step 1: Check for uncommitted changes
|
||||
Look at the git status. If there are uncommitted changes, ask whether to continue or abort.
|
||||
|
||||
## Step 2: Run the test suite
|
||||
Execute all tests. If any fail, show the failures and stop.
|
||||
```
|
||||
|
||||
This approach works well when you want Cline to adapt to the situation rather than follow rigid steps.
|
||||
|
||||
### Cline Tools
|
||||
|
||||
For precise control, use Cline's built-in tools with XML syntax. This guarantees specific actions:
|
||||
|
||||
```xml
|
||||
<execute_command>
|
||||
<command>npm run test</command>
|
||||
<requires_approval>false</requires_approval>
|
||||
</execute_command>
|
||||
```
|
||||
|
||||
```xml
|
||||
<read_file>
|
||||
<path>src/config.json</path>
|
||||
</read_file>
|
||||
```
|
||||
|
||||
```xml
|
||||
<ask_followup_question>
|
||||
<question>Deploy to production or staging?</question>
|
||||
<options>["Production", "Staging", "Cancel"]</options>
|
||||
</ask_followup_question>
|
||||
```
|
||||
|
||||
See the full list in the [Cline Tools Reference](/tools-reference/all-cline-tools).
|
||||
|
||||
### CLI Tools
|
||||
|
||||
Reference any command-line tool installed on your machine. Git, npm, docker, gh, make, curl: whatever you have available.
|
||||
|
||||
```bash
|
||||
git log --author="$(git config user.name)" --since="yesterday" --oneline
|
||||
```
|
||||
|
||||
### MCP Tools
|
||||
|
||||
If you have [MCP servers](/mcp/mcp-overview) connected, use them in your workflows with the `use_mcp_tool` syntax. This lets you integrate with external services like GitHub, Slack, databases, or custom internal tools.
|
||||
|
||||
```xml
|
||||
<use_mcp_tool>
|
||||
<server_name>github-server</server_name>
|
||||
<tool_name>create_release</tool_name>
|
||||
<arguments>{"tag": "v1.2.0", "name": "Release v1.2.0", "body": "Changelog content here"}</arguments>
|
||||
</use_mcp_tool>
|
||||
```
|
||||
|
||||
Or describe the intent in natural language and let Cline figure out the tool call:
|
||||
|
||||
```markdown
|
||||
## Step 3: Create GitHub release
|
||||
Use the GitHub MCP server to create a release tagged with the version from package.json.
|
||||
Include the changelog as the release body.
|
||||
```
|
||||
|
||||
## Writing Effective Workflows
|
||||
|
||||
**Start simple.** Write natural language steps first. Only add XML tool calls when you need guaranteed behavior.
|
||||
|
||||
**Be specific about decisions.** If a step requires user input, make that explicit: "Ask whether to deploy to production or staging."
|
||||
|
||||
**Include failure handling.** Tell Cline what to do when something goes wrong: "If tests fail, show the failures and stop the workflow."
|
||||
|
||||
**Keep workflows focused.** A `deploy.md` should deploy. A `setup-db.md` should set up the database. Split complex processes into multiple workflows that can be run independently.
|
||||
|
||||
**Version control your workflows.** Store workflows in `.clinerules/workflows/` and commit them. Your team can share, review, and improve them together.
|
||||
|
||||
<Warning>
|
||||
Workflows execute with your permissions. Review workflows before running them, especially those from external sources.
|
||||
</Warning>
|
||||
|
||||
## Example: Release Preparation
|
||||
|
||||
This workflow automates the tedious pre-release checklist. It verifies your working directory is clean, runs tests and builds, prompts you for the version bump, and generates a changelog from recent commits.
|
||||
|
||||
The workflow demonstrates both approaches: XML tool syntax (`<execute_command>`, `<ask_followup_question>`) for steps that need precise control, and natural language for steps where Cline should adapt to the situation.
|
||||
|
||||
````markdown title="release-prep.md"
|
||||
# Release Preparation
|
||||
|
||||
Prepare a new release by running tests, building, and updating version info.
|
||||
|
||||
## Step 1: Check for clean working directory
|
||||
<execute_command>
|
||||
<command>git status --porcelain</command>
|
||||
</execute_command>
|
||||
|
||||
If there are uncommitted changes, ask whether to continue or stash them first.
|
||||
|
||||
## Step 2: Run the test suite
|
||||
<execute_command>
|
||||
<command>npm run test</command>
|
||||
</execute_command>
|
||||
|
||||
If any tests fail, stop the workflow and report the failures.
|
||||
|
||||
## Step 3: Build the project
|
||||
<execute_command>
|
||||
<command>npm run build</command>
|
||||
</execute_command>
|
||||
|
||||
Verify the build completes without errors.
|
||||
|
||||
## Step 4: Ask for new version
|
||||
<ask_followup_question>
|
||||
<question>What should the new version be?</question>
|
||||
<options>["Patch (x.x.X)", "Minor (x.X.0)", "Major (X.0.0)", "Custom"]</options>
|
||||
</ask_followup_question>
|
||||
|
||||
## Step 5: Update version
|
||||
Update the version in `package.json` to the new version specified by the user.
|
||||
|
||||
## Step 6: Generate changelog entry
|
||||
<execute_command>
|
||||
<command>git log --oneline $(git describe --tags --abbrev=0)..HEAD</command>
|
||||
</execute_command>
|
||||
|
||||
Use these commits to write a changelog entry for the new version.
|
||||
````
|
||||
|
||||
Invoke it with `/release-prep.md` and Cline walks through each step.
|
||||
+322
-164
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"$schema": "https://mintlify.com/docs.json",
|
||||
"theme": "linden",
|
||||
"theme": "mint",
|
||||
"name": "Cline",
|
||||
"description": "AI-powered coding agent for complex work",
|
||||
"colors": {
|
||||
@@ -60,180 +60,91 @@
|
||||
"icon": "square-terminal",
|
||||
"groups": [
|
||||
{
|
||||
"group": "Introduction",
|
||||
"group": "Home",
|
||||
"pages": [
|
||||
"introduction/welcome",
|
||||
"introduction/overview"
|
||||
"home",
|
||||
"getting-started/quick-start"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Getting Started",
|
||||
"pages": [
|
||||
"getting-started/what-is-cline",
|
||||
"getting-started/installing-cline",
|
||||
"getting-started/selecting-your-model",
|
||||
"getting-started/authorizing-with-cline",
|
||||
"getting-started/your-first-project"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Best Practices",
|
||||
"group": "Core Workflows",
|
||||
"pages": [
|
||||
"prompting/understanding-context-management",
|
||||
"prompting/prompt-engineering-guide",
|
||||
"prompting/cline-memory-bank"
|
||||
"core-workflows/task-management",
|
||||
"core-workflows/plan-and-act",
|
||||
"core-workflows/working-with-files",
|
||||
"core-workflows/using-commands",
|
||||
"core-workflows/checkpoints"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "CLI",
|
||||
"group": "Customization",
|
||||
"pages": [
|
||||
"customization/overview",
|
||||
"customization/cline-rules",
|
||||
"customization/skills",
|
||||
"customization/workflows",
|
||||
"customization/hooks",
|
||||
"customization/clineignore"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cline CLI",
|
||||
"pages": [
|
||||
"cline-cli/overview",
|
||||
"cline-cli/installation",
|
||||
"cline-cli/interactive-mode",
|
||||
"cline-cli/configuration",
|
||||
"cline-cli/three-core-flows",
|
||||
"cline-cli/acp-editor-integrations",
|
||||
{
|
||||
"group": "CLI Samples",
|
||||
"group": "Headless Mode",
|
||||
"pages": [
|
||||
"cline-cli/three-core-flows",
|
||||
"cline-cli/samples/overview",
|
||||
"cline-cli/samples/model-orchestration",
|
||||
"cline-cli/samples/worktree-workflows",
|
||||
"cline-cli/samples/github-issue-rca",
|
||||
"cline-cli/samples/github-integration",
|
||||
"cline-cli/samples/github-pr-review"
|
||||
"cline-cli/samples/github-pr-review",
|
||||
"cline-cli/samples/model-orchestration",
|
||||
"cline-cli/samples/worktree-workflows"
|
||||
]
|
||||
},
|
||||
"cline-cli/configuration",
|
||||
"cline-cli/acp-editor-integrations",
|
||||
"cline-cli/cli-reference"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Features",
|
||||
"pages": [
|
||||
{
|
||||
"group": "@ Mentions",
|
||||
"pages": [
|
||||
"features/at-mentions/overview",
|
||||
"features/at-mentions/file-mentions",
|
||||
"features/at-mentions/terminal-mentions",
|
||||
"features/at-mentions/problem-mentions",
|
||||
"features/at-mentions/git-mentions",
|
||||
"features/at-mentions/url-mentions"
|
||||
]
|
||||
},
|
||||
"features/memory-bank",
|
||||
"features/focus-chain",
|
||||
"features/auto-approve",
|
||||
"features/auto-compact",
|
||||
"features/background-edit",
|
||||
"features/checkpoints",
|
||||
{
|
||||
"group": "Cline Rules",
|
||||
"pages": [
|
||||
"features/cline-rules/overview",
|
||||
"features/cline-rules/conditional-rules"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Commands & Shortcuts",
|
||||
"pages": [
|
||||
"features/commands-and-shortcuts/overview",
|
||||
"features/commands-and-shortcuts/code-commands",
|
||||
"features/commands-and-shortcuts/terminal-integration",
|
||||
"features/commands-and-shortcuts/git-integration",
|
||||
"features/commands-and-shortcuts/keyboard-shortcuts"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Customization",
|
||||
"pages": [
|
||||
"features/customization/opening-cline-in-sidebar",
|
||||
"features/customization/disable-terminal-pagers"
|
||||
]
|
||||
},
|
||||
"features/dictation",
|
||||
"features/drag-and-drop",
|
||||
"features/editing-messages",
|
||||
"features/explain-changes",
|
||||
"features/focus-chain",
|
||||
{
|
||||
"group": "Hooks",
|
||||
"pages": [
|
||||
"features/hooks/index",
|
||||
"features/hooks/hook-reference",
|
||||
"features/hooks/samples"
|
||||
]
|
||||
},
|
||||
"features/jupyter-notebooks",
|
||||
"features/multiroot-workspace",
|
||||
"features/plan-and-act",
|
||||
"features/skills",
|
||||
"features/subagents",
|
||||
{
|
||||
"group": "Slash Commands",
|
||||
"pages": [
|
||||
"features/slash-commands/new-task",
|
||||
"features/slash-commands/new-rule",
|
||||
"features/slash-commands/explain-changes",
|
||||
"features/slash-commands/smol",
|
||||
"features/slash-commands/report-bug",
|
||||
"features/slash-commands/deep-planning"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Workflows",
|
||||
"pages": [
|
||||
"features/slash-commands/workflows/index",
|
||||
"features/slash-commands/workflows/quickstart",
|
||||
"features/slash-commands/workflows/best-practices"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Task Management",
|
||||
"pages": [
|
||||
"features/tasks/understanding-tasks",
|
||||
"features/tasks/task-management"
|
||||
]
|
||||
},
|
||||
"features/worktrees",
|
||||
"features/yolo-mode"
|
||||
"features/background-edit",
|
||||
"features/jupyter-notebooks",
|
||||
"features/deep-planning",
|
||||
"features/web-tools",
|
||||
"features/worktrees"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Model & Provider Configuration",
|
||||
"group": "Models & Providers",
|
||||
"pages": [
|
||||
{
|
||||
"group": "Model Selection",
|
||||
"group": "Choosing & Configuring Models",
|
||||
"pages": [
|
||||
"core-features/model-selection-guide",
|
||||
"model-config/model-comparison",
|
||||
"model-config/context-windows"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cloud Providers",
|
||||
"pages": [
|
||||
"provider-config/anthropic",
|
||||
"provider-config/claude-code",
|
||||
"provider-config/openai",
|
||||
"provider-config/openai-codex",
|
||||
"provider-config/openrouter",
|
||||
"provider-config/cerebras",
|
||||
"provider-config/deepseek",
|
||||
"provider-config/groq",
|
||||
"provider-config/xai-grok",
|
||||
"provider-config/mistral-ai",
|
||||
"provider-config/doubao",
|
||||
"provider-config/fireworks",
|
||||
"provider-config/zai",
|
||||
"provider-config/gcp-vertex-ai",
|
||||
"provider-config/baseten",
|
||||
{
|
||||
"group": "AWS Bedrock",
|
||||
"pages": [
|
||||
"provider-config/aws-bedrock/api-key",
|
||||
"provider-config/aws-bedrock/iam-credentials",
|
||||
"provider-config/aws-bedrock/cli-profile"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Running Models Locally",
|
||||
"pages": [
|
||||
@@ -242,47 +153,94 @@
|
||||
"running-models-locally/lm-studio"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cloud Providers",
|
||||
"pages": [
|
||||
"provider-config/qwen",
|
||||
"provider-config/anthropic",
|
||||
"provider-config/asksage",
|
||||
"provider-config/baseten",
|
||||
"provider-config/cerebras",
|
||||
"provider-config/claude-code",
|
||||
"provider-config/deepseek",
|
||||
"provider-config/doubao",
|
||||
"provider-config/fireworks",
|
||||
"provider-config/gcp-vertex-ai",
|
||||
"provider-config/google-gemini",
|
||||
"provider-config/groq",
|
||||
"provider-config/huawei-cloud-maas",
|
||||
"provider-config/huggingface",
|
||||
"provider-config/minimax",
|
||||
"provider-config/mistral-ai",
|
||||
"provider-config/moonshot",
|
||||
"provider-config/nebius",
|
||||
"provider-config/nousresearch",
|
||||
"provider-config/openai",
|
||||
"provider-config/openai-codex",
|
||||
"provider-config/openrouter",
|
||||
"provider-config/oracle-code-assist",
|
||||
"provider-config/qwen-code",
|
||||
"provider-config/sambanova",
|
||||
"provider-config/together",
|
||||
"provider-config/xai-grok",
|
||||
"provider-config/zai",
|
||||
{
|
||||
"group": "AWS Bedrock",
|
||||
"pages": [
|
||||
"provider-config/aws-bedrock/api-key",
|
||||
"provider-config/aws-bedrock/iam-credentials",
|
||||
"provider-config/aws-bedrock/cli-profile"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Advanced Configuration",
|
||||
"pages": [
|
||||
"provider-config/openai-compatible",
|
||||
"provider-config/aihubmix",
|
||||
"provider-config/dify",
|
||||
"provider-config/hicap",
|
||||
"provider-config/litellm-and-cline-using-codestral",
|
||||
"provider-config/vscode-language-model-api",
|
||||
"provider-config/openai-compatible",
|
||||
"provider-config/requesty",
|
||||
"provider-config/sap-aicore",
|
||||
"provider-config/vercel-ai-gateway",
|
||||
"provider-config/requesty"
|
||||
"provider-config/vscode-language-model-api"
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "MCP Integration",
|
||||
"group": "MCP (Extending Cline)",
|
||||
"pages": [
|
||||
"mcp/mcp-overview",
|
||||
"mcp/adding-mcp-servers-from-github",
|
||||
"mcp/configuring-mcp-servers",
|
||||
"mcp/connecting-to-a-remote-server",
|
||||
"mcp/mcp-marketplace",
|
||||
"mcp/adding-and-configuring-servers",
|
||||
"mcp/mcp-server-development-protocol",
|
||||
"mcp/connecting-to-a-remote-server",
|
||||
"mcp/mcp-transport-mechanisms"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Cline Tools Reference",
|
||||
"group": "Tools Reference",
|
||||
"pages": [
|
||||
"exploring-clines-tools/cline-tools-guide",
|
||||
"exploring-clines-tools/new-task-tool",
|
||||
"exploring-clines-tools/remote-browser-support"
|
||||
"tools-reference/all-cline-tools",
|
||||
"tools-reference/browser-automation"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Reference",
|
||||
"group": "Troubleshooting",
|
||||
"pages": [
|
||||
"troubleshooting/networking-and-proxies",
|
||||
"troubleshooting/terminal-quick-fixes",
|
||||
"troubleshooting/terminal-integration-guide",
|
||||
"troubleshooting/task-history-recovery",
|
||||
"more-info/telemetry"
|
||||
"troubleshooting/networking-and-proxies",
|
||||
"troubleshooting/task-history-recovery"
|
||||
]
|
||||
},
|
||||
{
|
||||
"group": "Contributing",
|
||||
"pages": [
|
||||
"contributing/documentation-guide",
|
||||
"contributing/doc-templates"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -328,7 +286,8 @@
|
||||
{
|
||||
"group": "Control Other Cline Features",
|
||||
"pages": [
|
||||
"enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode"
|
||||
"enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode",
|
||||
"enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/mcp-marketplace"
|
||||
]
|
||||
},
|
||||
{
|
||||
@@ -336,8 +295,7 @@
|
||||
"pages": [
|
||||
"enterprise-solutions/monitoring/overview",
|
||||
"enterprise-solutions/monitoring/telemetry",
|
||||
"enterprise-solutions/monitoring/opentelemetry",
|
||||
"enterprise-solutions/monitoring/opentelemetry_override"
|
||||
"enterprise-solutions/monitoring/opentelemetry"
|
||||
]
|
||||
}
|
||||
]
|
||||
@@ -362,7 +320,7 @@
|
||||
{
|
||||
"name": "Overview",
|
||||
"icon": "house",
|
||||
"url": "introduction/overview"
|
||||
"url": "getting-started/what-is-cline"
|
||||
}
|
||||
],
|
||||
"redirects": [
|
||||
@@ -370,17 +328,21 @@
|
||||
"source": "/getting-started/installing-cline-jetbrains",
|
||||
"destination": "/getting-started/installing-cline"
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/what-is-cline",
|
||||
"destination": "/introduction/overview"
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/overview",
|
||||
"destination": "/introduction/overview"
|
||||
"destination": "/getting-started/what-is-cline"
|
||||
},
|
||||
{
|
||||
"source": "/introduction",
|
||||
"destination": "/introduction/welcome"
|
||||
"destination": "/getting-started/what-is-cline"
|
||||
},
|
||||
{
|
||||
"source": "/introduction/welcome",
|
||||
"destination": "/getting-started/what-is-cline"
|
||||
},
|
||||
{
|
||||
"source": "/introduction/overview",
|
||||
"destination": "/getting-started/what-is-cline"
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/model-selection-guide",
|
||||
@@ -396,11 +358,39 @@
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/understanding-context-management",
|
||||
"destination": "/prompting/understanding-context-management"
|
||||
"destination": "/model-config/context-windows"
|
||||
},
|
||||
{
|
||||
"source": "/best-practices/understanding-context-management",
|
||||
"destination": "/prompting/understanding-context-management"
|
||||
"destination": "/model-config/context-windows"
|
||||
},
|
||||
{
|
||||
"source": "/prompting/understanding-context-management",
|
||||
"destination": "/model-config/context-windows"
|
||||
},
|
||||
{
|
||||
"source": "/prompting/prompt-engineering-guide",
|
||||
"destination": "/customization/cline-rules"
|
||||
},
|
||||
{
|
||||
"source": "/prompting/cline-memory-bank",
|
||||
"destination": "/features/memory-bank"
|
||||
},
|
||||
{
|
||||
"source": "/customization/memory-bank",
|
||||
"destination": "/features/memory-bank"
|
||||
},
|
||||
{
|
||||
"source": "/customization/focus-chain",
|
||||
"destination": "/features/focus-chain"
|
||||
},
|
||||
{
|
||||
"source": "/customization/auto-approve",
|
||||
"destination": "/features/auto-approve"
|
||||
},
|
||||
{
|
||||
"source": "/customization/auto-compact",
|
||||
"destination": "/features/auto-compact"
|
||||
},
|
||||
{
|
||||
"source": "/getting-started/your-first-task",
|
||||
@@ -410,9 +400,149 @@
|
||||
"source": "/cline-cli/samples",
|
||||
"destination": "/cline-cli/samples/overview"
|
||||
},
|
||||
{
|
||||
"source": "/cline-cli/overview",
|
||||
"destination": "/cline-cli/getting-started"
|
||||
},
|
||||
{
|
||||
"source": "/features/hooks/real-world-examples",
|
||||
"destination": "/features/hooks/samples"
|
||||
"destination": "/customization/hooks"
|
||||
},
|
||||
{
|
||||
"source": "/features/hooks/index",
|
||||
"destination": "/customization/hooks"
|
||||
},
|
||||
{
|
||||
"source": "/features/hooks/hook-reference",
|
||||
"destination": "/customization/hooks"
|
||||
},
|
||||
{
|
||||
"source": "/features/hooks/samples",
|
||||
"destination": "/customization/hooks"
|
||||
},
|
||||
{
|
||||
"source": "/features/plan-and-act",
|
||||
"destination": "/core-workflows/plan-and-act"
|
||||
},
|
||||
{
|
||||
"source": "/features/checkpoints",
|
||||
"destination": "/core-workflows/checkpoints"
|
||||
},
|
||||
{
|
||||
"source": "/features/tasks/understanding-tasks",
|
||||
"destination": "/core-workflows/task-management"
|
||||
},
|
||||
{
|
||||
"source": "/features/tasks/task-management",
|
||||
"destination": "/core-workflows/task-management"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/overview",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/file-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/folder-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/terminal-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/problem-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/git-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/at-mentions/url-mentions",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/drag-and-drop",
|
||||
"destination": "/core-workflows/working-with-files"
|
||||
},
|
||||
{
|
||||
"source": "/features/yolo-mode",
|
||||
"destination": "/features/auto-approve"
|
||||
},
|
||||
{
|
||||
"source": "/features/cline-rules",
|
||||
"destination": "/customization/cline-rules"
|
||||
},
|
||||
{
|
||||
"source": "/features/cline-rules/overview",
|
||||
"destination": "/customization/cline-rules"
|
||||
},
|
||||
{
|
||||
"source": "/features/cline-rules/conditional-rules",
|
||||
"destination": "/customization/cline-rules"
|
||||
},
|
||||
{
|
||||
"source": "/features/commands-and-shortcuts/overview",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/commands-and-shortcuts/code-commands",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/commands-and-shortcuts/terminal-integration",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/commands-and-shortcuts/git-integration",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/commands-and-shortcuts/keyboard-shortcuts",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/new-task",
|
||||
"destination": "/core-workflows/using-commands"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/workflows/index",
|
||||
"destination": "/customization/workflows"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/workflows/quickstart",
|
||||
"destination": "/customization/workflows"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/workflows/best-practices",
|
||||
"destination": "/customization/workflows"
|
||||
},
|
||||
{
|
||||
"source": "/exploring-clines-tools/cline-tools-guide",
|
||||
"destination": "/tools-reference/all-cline-tools"
|
||||
},
|
||||
{
|
||||
"source": "/exploring-clines-tools/new-task-tool",
|
||||
"destination": "/tools-reference/all-cline-tools"
|
||||
},
|
||||
{
|
||||
"source": "/exploring-clines-tools/remote-browser-support",
|
||||
"destination": "/tools-reference/browser-automation"
|
||||
},
|
||||
{
|
||||
"source": "/mcp/adding-mcp-servers-from-github",
|
||||
"destination": "/mcp/adding-and-configuring-servers"
|
||||
},
|
||||
{
|
||||
"source": "/mcp/configuring-mcp-servers",
|
||||
"destination": "/mcp/adding-and-configuring-servers"
|
||||
},
|
||||
{
|
||||
"source": "/more-info/telemetry",
|
||||
"destination": "/enterprise-solutions/monitoring/telemetry"
|
||||
},
|
||||
{
|
||||
"source": "/enterprise-solutions/configure-AWS-Bedrock-Admin",
|
||||
@@ -439,16 +569,44 @@
|
||||
"destination": "/enterprise-solutions/team-management/managing-members"
|
||||
},
|
||||
{
|
||||
"source": "/features/cline-rules",
|
||||
"destination": "/features/cline-rules/overview"
|
||||
"source": "/features/customization/opening-cline-in-sidebar",
|
||||
"destination": "/getting-started/installing-cline"
|
||||
},
|
||||
{
|
||||
"source": "/features/conditional-rules",
|
||||
"destination": "/features/cline-rules/conditional-rules"
|
||||
"source": "/prompting/prompt-engineering-guide/clineignore-file-guide",
|
||||
"destination": "/customization/clineignore"
|
||||
},
|
||||
{
|
||||
"source": "/cline-cli/authentication",
|
||||
"destination": "/cline-cli/installation"
|
||||
"source": "/getting-started/selecting-your-model",
|
||||
"destination": "/getting-started/authorizing-with-cline"
|
||||
},
|
||||
{
|
||||
"source": "/model-config/model-comparison",
|
||||
"destination": "/core-features/model-selection-guide"
|
||||
},
|
||||
{
|
||||
"source": "/troubleshooting/terminal-integration-guide",
|
||||
"destination": "/troubleshooting/terminal-quick-fixes"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/deep-planning",
|
||||
"destination": "/features/deep-planning"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/smol",
|
||||
"destination": "/core-workflows/using-commands#smol"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/explain-changes",
|
||||
"destination": "/core-workflows/using-commands#explain-changes"
|
||||
},
|
||||
{
|
||||
"source": "/features/slash-commands/new-rule",
|
||||
"destination": "/core-workflows/using-commands#newrule"
|
||||
},
|
||||
{
|
||||
"source": "/features/skills",
|
||||
"destination": "/customization/skills"
|
||||
}
|
||||
],
|
||||
"search": {
|
||||
|
||||
@@ -1,287 +0,0 @@
|
||||
---
|
||||
title: "Bundled Endpoints Configuration"
|
||||
description: "Enterprise guide for distributing Cline with pre-configured endpoints"
|
||||
---
|
||||
|
||||
# Bundled Endpoints Configuration
|
||||
|
||||
This guide explains how enterprise customers can distribute Cline with pre-configured endpoints bundled directly into the installation packages.
|
||||
|
||||
## Overview
|
||||
|
||||
Cline supports bundling custom endpoint configurations directly into distribution packages (VSIX, NPM, or JetBrains). This eliminates the need for end users to manually configure endpoints, ensuring consistent configuration across your organization.
|
||||
|
||||
### Configuration Priority
|
||||
|
||||
When Cline starts, it checks for endpoints configuration in this order:
|
||||
|
||||
1. **Bundled endpoints.json** (in extension installation directory) - Highest priority
|
||||
2. **User endpoints.json** (`~/.cline/endpoints.json`) - Fallback
|
||||
3. **Built-in endpoints** (standard Cline URLs) - Default
|
||||
|
||||
When a bundled `endpoints.json` is found, Cline automatically switches to self-hosted mode and uses those endpoints exclusively.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Official Cline release package (VSIX, TGZ, or ZIP)
|
||||
- Your `endpoints.json` configuration file
|
||||
- `jq` command-line tool (for JSON validation)
|
||||
- `unzip`, `zip`, `tar` utilities
|
||||
|
||||
## Creating endpoints.json
|
||||
|
||||
Create a JSON file with your organization's endpoints:
|
||||
|
||||
```json
|
||||
{
|
||||
"appBaseUrl": "https://cline.yourcompany.com",
|
||||
"apiBaseUrl": "https://api-cline.yourcompany.com",
|
||||
"mcpBaseUrl": "https://api-cline.yourcompany.com/v1/mcp"
|
||||
}
|
||||
```
|
||||
|
||||
### Required Fields
|
||||
|
||||
All three fields are required and must be valid URLs:
|
||||
|
||||
- **appBaseUrl**: Web application base URL
|
||||
- **apiBaseUrl**: API server base URL
|
||||
- **mcpBaseUrl**: MCP (Model Context Protocol) server URL
|
||||
|
||||
### Validation
|
||||
|
||||
The packaging scripts automatically validate:
|
||||
- Valid JSON syntax
|
||||
- All required fields present
|
||||
- Non-empty string values
|
||||
- Valid URL format (must start with `http://` or `https://`)
|
||||
|
||||
## Packaging Scripts
|
||||
|
||||
Cline provides three scripts for adding bundled endpoints to packages:
|
||||
|
||||
### VSCode Extension (VSIX)
|
||||
|
||||
```bash
|
||||
./scripts/add-endpoints-to-vsix.sh \
|
||||
cline-3.55.0.vsix \
|
||||
cline-3.55.0-enterprise.vsix \
|
||||
endpoints.json
|
||||
```
|
||||
|
||||
This script:
|
||||
1. Extracts the VSIX package
|
||||
2. Adds `endpoints.json` to the `extension/` directory
|
||||
3. Repackages as a new VSIX file
|
||||
|
||||
### NPM Package (CLI)
|
||||
|
||||
```bash
|
||||
./scripts/add-endpoints-to-npm.sh \
|
||||
cline-3.55.0.tgz \
|
||||
cline-3.55.0-enterprise.tgz \
|
||||
endpoints.json
|
||||
```
|
||||
|
||||
This script:
|
||||
1. Extracts the NPM tarball
|
||||
2. Adds `endpoints.json` to the package root
|
||||
3. Repackages as a new tarball
|
||||
|
||||
### JetBrains Plugin (ZIP)
|
||||
|
||||
```bash
|
||||
./scripts/add-endpoints-to-jetbrains.sh \
|
||||
cline-jetbrains-3.55.0.zip \
|
||||
cline-jetbrains-3.55.0-enterprise.zip \
|
||||
endpoints.json
|
||||
```
|
||||
|
||||
This script:
|
||||
1. Extracts the ZIP package
|
||||
2. Adds `endpoints.json` to the plugin directory
|
||||
3. Repackages as a new ZIP file
|
||||
|
||||
## Distribution Workflow
|
||||
|
||||
### 1. Download Official Release
|
||||
|
||||
Download the official Cline package for your platform:
|
||||
|
||||
```bash
|
||||
# VSCode - from marketplace or GitHub releases
|
||||
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
|
||||
|
||||
# NPM - from npm registry
|
||||
npm pack @cline/cline@3.55.0
|
||||
|
||||
# JetBrains - from marketplace or GitHub releases
|
||||
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-jetbrains-3.55.0.zip
|
||||
```
|
||||
|
||||
### 2. Create Endpoints Configuration
|
||||
|
||||
Create your `endpoints.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"appBaseUrl": "https://cline.internal.company.com",
|
||||
"apiBaseUrl": "https://cline-api.internal.company.com",
|
||||
"mcpBaseUrl": "https://cline-api.internal.company.com/v1/mcp"
|
||||
}
|
||||
```
|
||||
|
||||
### 3. Run Packaging Script
|
||||
|
||||
Choose the appropriate script for your platform:
|
||||
|
||||
```bash
|
||||
# VSCode
|
||||
./scripts/add-endpoints-to-vsix.sh \
|
||||
cline-3.55.0.vsix \
|
||||
cline-3.55.0-yourcompany.vsix \
|
||||
endpoints.json
|
||||
|
||||
# CLI
|
||||
./scripts/add-endpoints-to-npm.sh \
|
||||
cline-3.55.0.tgz \
|
||||
cline-3.55.0-yourcompany.tgz \
|
||||
endpoints.json
|
||||
|
||||
# JetBrains
|
||||
./scripts/add-endpoints-to-jetbrains.sh \
|
||||
cline-jetbrains-3.55.0.zip \
|
||||
cline-jetbrains-3.55.0-yourcompany.zip \
|
||||
endpoints.json
|
||||
```
|
||||
|
||||
### 4. Distribute to Users
|
||||
|
||||
Distribute the enterprise package to your users through your internal channels:
|
||||
|
||||
- **VSCode**: Install via `code --install-extension cline-3.55.0-yourcompany.vsix`
|
||||
- **CLI**: Install via `npm install -g cline-3.55.0-yourcompany.tgz`
|
||||
- **JetBrains**: Install through IDE plugin manager from disk
|
||||
|
||||
## Verification
|
||||
|
||||
After installation, verify the configuration is active:
|
||||
|
||||
1. Launch Cline
|
||||
2. Check the logs for: `"Cline running in self-hosted mode with custom endpoints"`
|
||||
3. Confirm that environment switching is disabled (as expected in self-hosted mode)
|
||||
|
||||
## User Experience
|
||||
|
||||
### What Users See
|
||||
|
||||
- Cline automatically uses the bundled endpoints
|
||||
- No manual configuration required
|
||||
- Environment switching is disabled (prevents accidental misconfiguration)
|
||||
- All API calls route to your organization's infrastructure
|
||||
|
||||
### User Override
|
||||
|
||||
Users **cannot** override bundled endpoints through the UI. The bundled configuration takes absolute precedence. This ensures:
|
||||
- Consistent configuration across the organization
|
||||
- No accidental connections to external services
|
||||
- Simplified deployment and support
|
||||
|
||||
If users have a `~/.cline/endpoints.json` file, it will be ignored when bundled configuration is present.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Invalid Configuration Error
|
||||
|
||||
If users see an error about invalid configuration on startup:
|
||||
|
||||
```
|
||||
ClineConfigurationError: Invalid JSON in bundled endpoints configuration file
|
||||
```
|
||||
|
||||
**Solution**: The bundled `endpoints.json` is malformed. Repackage with a valid JSON file.
|
||||
|
||||
### Missing Required Field Error
|
||||
|
||||
```
|
||||
ClineConfigurationError: Missing required field "apiBaseUrl" in endpoints configuration file
|
||||
```
|
||||
|
||||
**Solution**: Ensure all three required fields are present in `endpoints.json`.
|
||||
|
||||
### Invalid URL Error
|
||||
|
||||
```
|
||||
ClineConfigurationError: Field "appBaseUrl" must be a valid URL. Got: "not-a-url"
|
||||
```
|
||||
|
||||
**Solution**: All URLs must start with `http://` or `https://`.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
1. **Bundle Validation**: The packaging scripts validate JSON structure and required fields
|
||||
2. **Read-Only Configuration**: Users cannot modify bundled endpoints through the UI
|
||||
3. **Self-Hosted Mode**: Automatic switch to self-hosted mode prevents external connections
|
||||
4. **Audit Trail**: All endpoint access is logged with configuration source
|
||||
|
||||
## Updating Endpoints
|
||||
|
||||
To update endpoints for existing installations:
|
||||
|
||||
1. Create updated `endpoints.json`
|
||||
2. Repackage the same Cline version with new endpoints
|
||||
3. Distribute updated package
|
||||
4. Users reinstall/update the package
|
||||
|
||||
The version number remains the same since only configuration changed, not the Cline code.
|
||||
|
||||
## Support
|
||||
|
||||
For questions or issues with bundled endpoints:
|
||||
|
||||
1. Verify your `endpoints.json` is valid JSON with all required fields
|
||||
2. Check that URLs are accessible from user networks
|
||||
3. Review Cline logs for configuration loading messages
|
||||
4. Contact your Cline support representative for assistance
|
||||
|
||||
## Example: Complete Workflow
|
||||
|
||||
Here's a complete example for VSCode deployment:
|
||||
|
||||
```bash
|
||||
# 1. Download official release
|
||||
curl -LO https://github.com/cline/cline/releases/download/v3.55.0/cline-3.55.0.vsix
|
||||
|
||||
# 2. Create endpoints configuration
|
||||
cat > endpoints.json << 'EOF'
|
||||
{
|
||||
"appBaseUrl": "https://cline.acme.internal",
|
||||
"apiBaseUrl": "https://cline-api.acme.internal",
|
||||
"mcpBaseUrl": "https://cline-api.acme.internal/v1/mcp"
|
||||
}
|
||||
EOF
|
||||
|
||||
# 3. Validate JSON
|
||||
jq empty endpoints.json # Should succeed silently
|
||||
|
||||
# 4. Run packaging script
|
||||
./scripts/add-endpoints-to-vsix.sh \
|
||||
cline-3.55.0.vsix \
|
||||
cline-3.55.0-acme.vsix \
|
||||
endpoints.json
|
||||
|
||||
# 5. Verify output
|
||||
unzip -l cline-3.55.0-acme.vsix | grep endpoints.json
|
||||
# Should show: extension/endpoints.json
|
||||
|
||||
# 6. Test installation (on test machine)
|
||||
code --install-extension cline-3.55.0-acme.vsix
|
||||
|
||||
# 7. Distribute to organization
|
||||
# Upload to internal package repository
|
||||
# or distribute via configuration management system
|
||||
```
|
||||
|
||||
## Changelog
|
||||
|
||||
- **v3.55.0**: Initial release of bundled endpoints support
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
title: "Choosing Your Configuration Path"
|
||||
sidebarTitle: "Deployment Guide"
|
||||
description: "Decide between SaaS and Self-Hosted configuration for your Cline Enterprise deployment"
|
||||
---
|
||||
|
||||
Choose the right configuration approach for your organization. Most teams start with SaaS for quick deployment, while enterprises with complex requirements opt for self-hosted infrastructure.
|
||||
|
||||
## Configuration Paths
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="SaaS Provider Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
|
||||
### Quick Setup via Web Console
|
||||
|
||||
✅ No infrastructure required
|
||||
✅ 5-10 minute configuration
|
||||
✅ Web-based admin console
|
||||
✅ Automatic updates
|
||||
✅ Simplified credential management
|
||||
|
||||
**Best for:**
|
||||
- Small to medium teams (5-50 developers)
|
||||
- Quick deployment needs
|
||||
- Limited DevOps resources
|
||||
- Standard security requirements
|
||||
- Single region deployments
|
||||
</Card>
|
||||
|
||||
<Card title="Self-Hosted Configuration" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
|
||||
### Full Infrastructure Control
|
||||
|
||||
✅ Your own AWS/GCP/K8s
|
||||
✅ VPC endpoints & private connectivity
|
||||
✅ Multi-account setups
|
||||
✅ Advanced compliance & audit
|
||||
✅ GitOps workflows
|
||||
|
||||
**Best for:**
|
||||
- Large enterprises (50+ developers)
|
||||
- Complex security requirements
|
||||
- Existing cloud infrastructure
|
||||
- Multi-region deployments
|
||||
- Custom compliance needs
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Detailed Comparison
|
||||
|
||||
### Feature Comparison
|
||||
|
||||
| Feature | SaaS | Self-Hosted |
|
||||
|---------|------|-------------|
|
||||
| **Configuration** | Web UI | YAML + Helm/Kubernetes |
|
||||
| **Infrastructure** | None required | Full AWS/GCP/K8s |
|
||||
| **VPC Endpoints** | Basic | Full private connectivity |
|
||||
| **Multi-Account** | ❌ | ✅ |
|
||||
| **IAM** | Standard RBAC roles | Standard RBAC roles |
|
||||
| **Compliance** | Standard | Custom frameworks |
|
||||
| **GitOps** | ❌ | ✅ |
|
||||
| **Maintenance** | Managed by Cline | Self-managed |
|
||||
| **Updates** | Automatic (extension) | Automatic (extension) + Infrastructure control |
|
||||
|
||||
### Security & Compliance
|
||||
|
||||
| Capability | SaaS | Self-Hosted |
|
||||
|------------|------|-------------|
|
||||
| **Network Encryption** | HTTPS/TLS | HTTPS/TLS |
|
||||
| **Network** | Public internet | Private VPC endpoints |
|
||||
| **Access Control** | Standard RBAC | Standard RBAC |
|
||||
| **Audit Logs** | OpenTelemetry traces | OpenTelemetry traces + Infrastructure logs |
|
||||
| **Data Residency** | Cline-managed deployment | Customer-controlled deployment |
|
||||
|
||||
### Cost Structure
|
||||
|
||||
| Cost Category | SaaS | Self-Hosted |
|
||||
|---------------|------|-------------|
|
||||
| **Cline Subscription** | Fixed enterprise fee | Fixed enterprise fee |
|
||||
| **Inference Provider Costs** | Usage-based | Usage-based |
|
||||
| **Infrastructure** | ✅ None required | Kubernetes, networking, storage |
|
||||
| **Personnel** | ✅ None required | DevOps team needed |
|
||||
| **Total Cost Profile** | Predictable and simple | Variable based on scale |
|
||||
|
||||
## Migration Path
|
||||
|
||||
<Note>
|
||||
Most organizations start with SaaS configuration for quick deployment, then migrate to self-hosted later as requirements grow. This minimizes risk and ensures your infrastructure meets actual usage patterns.
|
||||
</Note>
|
||||
|
||||
## Getting Started
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Start with SaaS" icon="rocket" href="/enterprise-solutions/configuration/remote-configuration/overview">
|
||||
Begin with quick SaaS setup
|
||||
</Card>
|
||||
|
||||
<Card title="Deploy Self-Hosted" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/overview">
|
||||
Plan your infrastructure deployment
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Need Help Deciding?
|
||||
|
||||
- [**Contact Cline Enterprise Sales**](https://cline.bot/contact-sales) for a consultation on your specific requirements
|
||||
- [**Start with SaaS**](/enterprise-solutions/configuration/remote-configuration/overview) if unsure - it's lower risk and you can always migrate later
|
||||
- [**Review Self-Hosted Requirements**](/enterprise-solutions/configuration/infrastructure-configuration/overview) if you have existing infrastructure that could benefit from self-hosted deployment
|
||||
+298
@@ -0,0 +1,298 @@
|
||||
---
|
||||
title: "MCP Marketplace"
|
||||
sidebarTitle: "MCP Marketplace"
|
||||
description: "Enterprise controls for MCP Marketplace access, server allowlisting, and remote MCP server management"
|
||||
---
|
||||
|
||||
The MCP Marketplace lets developers discover and install MCP servers that extend Cline's capabilities. For Enterprise administrators, this page covers how to control marketplace access, restrict which servers are available, and push pre-configured MCP servers to your organization.
|
||||
|
||||
<Note>
|
||||
For complete details about the MCP Marketplace and how developers use it, see [MCP Made Easy](/mcp/mcp-marketplace).
|
||||
</Note>
|
||||
|
||||
## Overview
|
||||
|
||||
Enterprise administrators have four configuration options to govern MCP server usage across their organization:
|
||||
|
||||
| Setting | Purpose |
|
||||
|---------|---------|
|
||||
| `mcpMarketplaceEnabled` | Enable or disable the MCP Marketplace entirely |
|
||||
| `allowedMCPServers` | Restrict the marketplace to only approved MCP servers |
|
||||
| `remoteMCPServers` | Push pre-configured remote MCP servers to all users |
|
||||
| `blockPersonalRemoteMCPServers` | Prevent users from adding their own remote MCP servers |
|
||||
|
||||
These settings are applied through your organization's [remote configuration](/enterprise-solutions/configuration/remote-configuration/overview) and take effect immediately for all team members.
|
||||
|
||||
## Disabling the MCP Marketplace
|
||||
|
||||
To completely disable the MCP Marketplace for your organization, set `mcpMarketplaceEnabled` to `false`:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpMarketplaceEnabled": false
|
||||
}
|
||||
```
|
||||
|
||||
When `mcpMarketplaceEnabled` is set to `false`:
|
||||
- The MCP Marketplace tab is hidden from all users
|
||||
- Users cannot browse or install MCP servers from the marketplace
|
||||
- Locally configured MCP servers are blocked
|
||||
- Enterprise policy takes precedence over individual preferences
|
||||
|
||||
When `mcpMarketplaceEnabled` is set to `true` or omitted:
|
||||
- Users can freely browse and install MCP servers from the marketplace
|
||||
- No organizational restrictions apply to marketplace access
|
||||
|
||||
<Warning>
|
||||
Disabling the marketplace entirely also blocks locally configured MCP servers. If you want to allow specific servers while restricting others, use the allowlist approach described below instead.
|
||||
</Warning>
|
||||
|
||||
## Restricting the Marketplace to Approved Servers
|
||||
|
||||
Rather than disabling the marketplace entirely, you can restrict it to a curated list of approved MCP servers using the `allowedMCPServers` setting. This is the recommended approach for most enterprises — it lets developers benefit from MCP while ensuring only vetted servers are available.
|
||||
|
||||
### Configuration
|
||||
|
||||
Add an `allowedMCPServers` array to your remote configuration. Each entry requires an `id` field set to the server's GitHub repository path:
|
||||
|
||||
```json
|
||||
{
|
||||
"allowedMCPServers": [
|
||||
{ "id": "github.com/modelcontextprotocol/server-filesystem" },
|
||||
{ "id": "github.com/modelcontextprotocol/server-github" },
|
||||
{ "id": "github.com/your-org/internal-mcp-server" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### How It Works
|
||||
|
||||
When `allowedMCPServers` is configured:
|
||||
- The marketplace catalog is filtered to show **only** the servers in your allowlist
|
||||
- Users can browse, view details, and install any server on the list
|
||||
- Servers not on the list are completely hidden from the marketplace
|
||||
- The allowlist applies to all team members in the organization
|
||||
|
||||
When `allowedMCPServers` is omitted or `undefined`:
|
||||
- The full marketplace catalog is available with no restrictions
|
||||
|
||||
When `allowedMCPServers` is set to an empty array (`[]`):
|
||||
- The marketplace shows no servers — effectively disabling installation while keeping the UI visible
|
||||
|
||||
### Finding Server IDs
|
||||
|
||||
The `id` for each allowed server is its GitHub repository path (without the `https://` prefix). For example:
|
||||
|
||||
| Server | ID |
|
||||
|--------|----|
|
||||
| Filesystem | `github.com/modelcontextprotocol/server-filesystem` |
|
||||
| GitHub | `github.com/modelcontextprotocol/server-github` |
|
||||
| Custom internal server | `github.com/your-org/your-mcp-server` |
|
||||
|
||||
You can find the correct ID by checking the `githubUrl` field of any server in the [MCP Marketplace](/mcp/mcp-marketplace) and removing the `https://` prefix.
|
||||
|
||||
## Pushing Pre-Configured Remote MCP Servers
|
||||
|
||||
Use `remoteMCPServers` to push MCP servers directly to all users without requiring them to install anything from the marketplace. This is ideal for internal MCP servers or third-party servers that need specific configuration.
|
||||
|
||||
### Configuration
|
||||
|
||||
```json
|
||||
{
|
||||
"remoteMCPServers": [
|
||||
{
|
||||
"name": "Internal Code Search",
|
||||
"url": "https://mcp.internal.yourcompany.com/code-search",
|
||||
"alwaysEnabled": true,
|
||||
"headers": {
|
||||
"Authorization": "Bearer ${AUTH_TOKEN}"
|
||||
}
|
||||
},
|
||||
{
|
||||
"name": "Documentation Server",
|
||||
"url": "https://mcp.internal.yourcompany.com/docs",
|
||||
"alwaysEnabled": false
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Remote Server Options
|
||||
|
||||
Each remote MCP server entry supports the following fields:
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|-------|------|----------|-------------|
|
||||
| `name` | string | Yes | Display name for the server |
|
||||
| `url` | string | Yes | The URL endpoint of the MCP server |
|
||||
| `alwaysEnabled` | boolean | No | When `true`, users cannot disable this server |
|
||||
| `headers` | object | No | Custom HTTP headers for authentication |
|
||||
|
||||
### Always-Enabled Servers
|
||||
|
||||
When `alwaysEnabled` is set to `true`:
|
||||
- The server is automatically active for all users
|
||||
- Users cannot toggle the server off
|
||||
- The server appears in the user's MCP configuration but the disable control is locked
|
||||
- This is useful for compliance, security, or internal tooling servers that must always be available
|
||||
|
||||
## Blocking Personal Remote MCP Servers
|
||||
|
||||
To prevent users from adding their own remote MCP servers, set `blockPersonalRemoteMCPServers` to `true`:
|
||||
|
||||
```json
|
||||
{
|
||||
"blockPersonalRemoteMCPServers": true
|
||||
}
|
||||
```
|
||||
|
||||
When `blockPersonalRemoteMCPServers` is `true`:
|
||||
- Users cannot add or configure remote MCP servers on their own
|
||||
- Only servers defined in the organization's `remoteMCPServers` configuration are available
|
||||
- This ensures all remote MCP connections go through approved, organization-managed endpoints
|
||||
|
||||
When `blockPersonalRemoteMCPServers` is `false` or omitted:
|
||||
- Users can freely add their own remote MCP server connections
|
||||
|
||||
## Combined Configuration Examples
|
||||
|
||||
### Locked-Down Environment
|
||||
|
||||
For organizations that need strict control over all MCP server access:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpMarketplaceEnabled": true,
|
||||
"allowedMCPServers": [
|
||||
{ "id": "github.com/modelcontextprotocol/server-filesystem" },
|
||||
{ "id": "github.com/modelcontextprotocol/server-github" }
|
||||
],
|
||||
"remoteMCPServers": [
|
||||
{
|
||||
"name": "Internal API Gateway",
|
||||
"url": "https://mcp.internal.yourcompany.com/gateway",
|
||||
"alwaysEnabled": true,
|
||||
"headers": {
|
||||
"X-Api-Key": "org-managed-key"
|
||||
}
|
||||
}
|
||||
],
|
||||
"blockPersonalRemoteMCPServers": true
|
||||
}
|
||||
```
|
||||
|
||||
This configuration:
|
||||
- Allows the marketplace but limits it to two approved servers
|
||||
- Pushes an always-enabled internal MCP server to all users
|
||||
- Blocks users from adding their own remote MCP servers
|
||||
|
||||
### Open Environment with Internal Servers
|
||||
|
||||
For organizations that want flexibility with internal server access:
|
||||
|
||||
```json
|
||||
{
|
||||
"remoteMCPServers": [
|
||||
{
|
||||
"name": "Company Knowledge Base",
|
||||
"url": "https://mcp.yourcompany.com/kb",
|
||||
"alwaysEnabled": true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
This configuration:
|
||||
- Leaves the full marketplace open (no `allowedMCPServers` restriction)
|
||||
- Ensures all developers have access to the company knowledge base
|
||||
- Allows users to add their own remote MCP servers
|
||||
|
||||
### Marketplace Disabled with Internal Servers Only
|
||||
|
||||
For organizations that want to fully manage the MCP experience:
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpMarketplaceEnabled": false,
|
||||
"remoteMCPServers": [
|
||||
{
|
||||
"name": "Approved Code Assistant",
|
||||
"url": "https://mcp.internal.yourcompany.com/code-assist",
|
||||
"alwaysEnabled": true
|
||||
},
|
||||
{
|
||||
"name": "Internal Docs Search",
|
||||
"url": "https://mcp.internal.yourcompany.com/docs",
|
||||
"alwaysEnabled": true
|
||||
}
|
||||
],
|
||||
"blockPersonalRemoteMCPServers": true
|
||||
}
|
||||
```
|
||||
|
||||
This configuration:
|
||||
- Disables the marketplace completely
|
||||
- Provides only organization-managed MCP servers
|
||||
- Prevents users from adding any additional remote servers
|
||||
|
||||
## Enterprise Policy Recommendations
|
||||
|
||||
### Recommended Approach
|
||||
|
||||
Most organizations should **use the allowlist** (`allowedMCPServers`) rather than disabling the marketplace entirely. This gives developers access to useful tools while ensuring security review of each server.
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Security Review Process" icon="shield">
|
||||
Before adding an MCP server to your allowlist:
|
||||
- Review the server's source code on GitHub
|
||||
- Evaluate the server's permissions and data access patterns
|
||||
- Check for active maintenance and security practices
|
||||
- Assess whether the server's data handling meets your compliance requirements
|
||||
- Test the server in a sandbox environment before approving
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Internal MCP Servers" icon="building">
|
||||
For internal tooling, use `remoteMCPServers` with `alwaysEnabled: true`:
|
||||
- Connect Cline to internal APIs, databases, and knowledge bases
|
||||
- Ensure consistent access across all developers
|
||||
- Manage authentication centrally through custom headers
|
||||
- Use `blockPersonalRemoteMCPServers` to prevent shadow IT
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Compliance Considerations" icon="clipboard-check">
|
||||
MCP servers can access external APIs and process data:
|
||||
- Audit which servers handle sensitive data
|
||||
- Ensure servers comply with your data residency requirements
|
||||
- Document approved servers in your security policies
|
||||
- Regularly review and update your allowlist
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
### Recommendations by Organization Size
|
||||
|
||||
#### Small Teams (5–20 developers)
|
||||
- **Marketplace:** Open or lightly restricted with an allowlist
|
||||
- **Remote Servers:** Push internal servers as needed
|
||||
- **Personal Servers:** Allow with guidance
|
||||
- **Review Cadence:** Quarterly allowlist review
|
||||
|
||||
#### Medium Organizations (20–100 developers)
|
||||
- **Marketplace:** Restricted to an approved allowlist
|
||||
- **Remote Servers:** Push internal servers with `alwaysEnabled`
|
||||
- **Personal Servers:** Consider blocking (`blockPersonalRemoteMCPServers: true`)
|
||||
- **Review Cadence:** Monthly allowlist review
|
||||
|
||||
#### Large Enterprises (100+ developers)
|
||||
- **Marketplace:** Strictly restricted to a vetted allowlist
|
||||
- **Remote Servers:** All MCP access through organization-managed servers
|
||||
- **Personal Servers:** Blocked (`blockPersonalRemoteMCPServers: true`)
|
||||
- **Review Cadence:** Formal approval process for new servers with security review
|
||||
|
||||
## Support & Questions
|
||||
|
||||
For help configuring MCP Marketplace policies:
|
||||
- Review [Remote Configuration Overview](/enterprise-solutions/configuration/remote-configuration/overview)
|
||||
- See [MCP Made Easy](/mcp/mcp-marketplace) for marketplace functionality details
|
||||
- See [MCP Overview](/mcp/mcp-overview) for general MCP concepts
|
||||
- Contact your Enterprise support representative
|
||||
- Join our [Discord](https://discord.gg/cline) for community discussion
|
||||
-35
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "Overview"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Configure Cline settings for your enterprise deployment"
|
||||
---
|
||||
|
||||
This section covers configuration options for controlling Cline's behavior in enterprise deployments.
|
||||
|
||||
## Available Settings
|
||||
|
||||
<Card title="YOLO Mode" icon="rocket" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/yolo-mode">
|
||||
Control enterprise access to autonomous operation mode with complete auto-approval
|
||||
</Card>
|
||||
|
||||
## Configuration Methods
|
||||
|
||||
These settings can be configured through:
|
||||
|
||||
|
||||
### Individual Users
|
||||
- Users can toggle settings in their local Cline interface
|
||||
- Enterprise policies can restrict certain settings
|
||||
- Changes apply immediately to new tasks
|
||||
|
||||
## Enterprise Controls
|
||||
|
||||
Administrators can enforce policies through remote configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"yoloModeAllowed": false
|
||||
}
|
||||
```
|
||||
|
||||
When `yoloModeAllowed` is set to `false`, users cannot enable YOLO Mode in their local Cline interface.
|
||||
-565
@@ -1,565 +0,0 @@
|
||||
---
|
||||
title: "MCP Marketplace"
|
||||
sidebarTitle: "MCP Marketplace"
|
||||
description: "Deploy pre-built enterprise MCP servers from the Cline marketplace with one-click configuration"
|
||||
---
|
||||
|
||||
The MCP Marketplace provides curated, enterprise-ready integrations with popular development tools and services. All marketplace servers are built with enterprise security, compliance, and scalability in mind.
|
||||
|
||||
## Enterprise Marketplace Benefits
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="One-Click Deployment" icon="rocket">
|
||||
Deploy complex integrations instantly with pre-configured enterprise settings.
|
||||
</Card>
|
||||
|
||||
<Card title="Security Hardened" icon="shield-check">
|
||||
All servers include enterprise security features, audit logging, and compliance controls.
|
||||
</Card>
|
||||
|
||||
<Card title="Maintained & Updated" icon="sync">
|
||||
Regular security updates and feature enhancements managed by Cline Enterprise team.
|
||||
</Card>
|
||||
|
||||
<Card title="Enterprise Support" icon="headset">
|
||||
Dedicated support channels for marketplace integration issues and customization.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Available Integrations
|
||||
|
||||
### Development Tools
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="GitHub Enterprise" icon="github">
|
||||
Repository management, issue tracking, PR workflows, and code analysis
|
||||
</Card>
|
||||
|
||||
<Card title="GitLab Enterprise" icon="gitlab">
|
||||
Project management, CI/CD pipelines, merge requests, and security scanning
|
||||
</Card>
|
||||
|
||||
<Card title="Bitbucket Enterprise" icon="bitbucket">
|
||||
Source code management, build pipelines, and deployment automation
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Project Management
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Jira Enterprise" icon="jira">
|
||||
Issue tracking, sprint management, custom fields, and workflow automation
|
||||
</Card>
|
||||
|
||||
<Card title="Azure DevOps" icon="microsoft">
|
||||
Work items, boards, repos, pipelines, and test management
|
||||
</Card>
|
||||
|
||||
<Card title="Linear" icon="linear">
|
||||
Issue tracking, project planning, and development workflow integration
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Communication & Collaboration
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Slack Enterprise Grid" icon="slack">
|
||||
Notifications, bot interactions, file sharing, and workflow automation
|
||||
</Card>
|
||||
|
||||
<Card title="Microsoft Teams" icon="microsoft-teams">
|
||||
Chat notifications, meeting integration, and collaborative workflows
|
||||
</Card>
|
||||
|
||||
<Card title="Discord" icon="discord">
|
||||
Community management, bot interactions, and developer notifications
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
### Cloud Services
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="AWS Services" icon="aws">
|
||||
EC2, S3, Lambda, RDS, CloudWatch, and other AWS service integrations
|
||||
</Card>
|
||||
|
||||
<Card title="Google Cloud" icon="google-cloud">
|
||||
Compute Engine, Cloud Storage, BigQuery, and GCP service management
|
||||
</Card>
|
||||
|
||||
<Card title="Azure Services" icon="azure">
|
||||
Virtual Machines, Storage Accounts, Functions, and Azure resource management
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Installing Marketplace Servers
|
||||
|
||||
### Via Cline Enterprise Dashboard
|
||||
|
||||
1. **Access Marketplace**: Navigate to `Settings > Enterprise > MCP Marketplace`
|
||||
2. **Browse Integrations**: Filter by category, popularity, or search by name
|
||||
3. **Review Details**: Check compatibility, permissions, and configuration requirements
|
||||
4. **Install**: Click "Install" and configure required settings
|
||||
5. **Deploy**: Approve deployment to your selected environment
|
||||
|
||||
### Via Configuration File
|
||||
|
||||
Install marketplace servers through enterprise configuration:
|
||||
|
||||
```yaml
|
||||
# enterprise-mcp-config.yaml
|
||||
mcp:
|
||||
marketplace_servers:
|
||||
- name: "github-enterprise"
|
||||
package: "@cline/mcp-github-enterprise"
|
||||
version: "2.1.0"
|
||||
environment: "production"
|
||||
|
||||
config:
|
||||
github:
|
||||
base_url: "https://github.company.com/api/v3"
|
||||
token: "${GITHUB_ENTERPRISE_TOKEN}"
|
||||
organization: "company"
|
||||
|
||||
features:
|
||||
issue_management: true
|
||||
pull_request_automation: true
|
||||
code_analysis: true
|
||||
security_scanning: true
|
||||
|
||||
permissions:
|
||||
repositories: "read-write"
|
||||
issues: "write"
|
||||
pull_requests: "write"
|
||||
|
||||
compliance:
|
||||
audit_logging: true
|
||||
data_retention_days: 365
|
||||
encryption_at_rest: true
|
||||
|
||||
- name: "jira-enterprise"
|
||||
package: "@cline/mcp-jira-enterprise"
|
||||
version: "1.8.3"
|
||||
environment: "production"
|
||||
|
||||
config:
|
||||
jira:
|
||||
base_url: "https://company.atlassian.net"
|
||||
username: "${JIRA_USERNAME}"
|
||||
api_token: "${JIRA_API_TOKEN}"
|
||||
|
||||
projects:
|
||||
- key: "DEV"
|
||||
permissions: ["read", "write", "transition"]
|
||||
- key: "OPS"
|
||||
permissions: ["read", "comment"]
|
||||
|
||||
compliance:
|
||||
field_encryption: ["description", "comments"]
|
||||
audit_trail: true
|
||||
```
|
||||
|
||||
### Via CLI
|
||||
|
||||
Deploy using the Cline Enterprise CLI:
|
||||
|
||||
```bash
|
||||
# Install GitHub Enterprise integration
|
||||
cline-enterprise mcp install github-enterprise \
|
||||
--version 2.1.0 \
|
||||
--config-file github-config.yaml \
|
||||
--environment production
|
||||
|
||||
# Install Slack Enterprise Grid integration
|
||||
cline-enterprise mcp install slack-enterprise-grid \
|
||||
--version 1.5.2 \
|
||||
--config workspace_id=T1234567890 \
|
||||
--config bot_token=${SLACK_BOT_TOKEN} \
|
||||
--environment production
|
||||
|
||||
# List installed marketplace servers
|
||||
cline-enterprise mcp list --environment production
|
||||
|
||||
# Check server status
|
||||
cline-enterprise mcp status github-enterprise --environment production
|
||||
```
|
||||
|
||||
## Configuration Examples
|
||||
|
||||
### GitHub Enterprise Integration
|
||||
|
||||
```yaml
|
||||
# github-enterprise-config.yaml
|
||||
github:
|
||||
base_url: "https://github.company.com/api/v3"
|
||||
token: "${GITHUB_ENTERPRISE_TOKEN}"
|
||||
organization: "company"
|
||||
|
||||
# Repository access controls
|
||||
repositories:
|
||||
allowed_patterns:
|
||||
- "company/*"
|
||||
- "internal/*"
|
||||
blocked_patterns:
|
||||
- "*/secrets"
|
||||
- "*/private-keys"
|
||||
|
||||
# Feature configuration
|
||||
features:
|
||||
issue_management:
|
||||
enabled: true
|
||||
auto_assign: true
|
||||
labels:
|
||||
- "ai-generated"
|
||||
- "cline-task"
|
||||
|
||||
pull_requests:
|
||||
enabled: true
|
||||
auto_review_request: true
|
||||
required_approvals: 2
|
||||
enforce_branch_protection: true
|
||||
|
||||
code_analysis:
|
||||
enabled: true
|
||||
languages: ["typescript", "python", "go", "rust"]
|
||||
security_scan: true
|
||||
|
||||
# Security and compliance
|
||||
security:
|
||||
webhook_secret: "${GITHUB_WEBHOOK_SECRET}"
|
||||
rate_limiting:
|
||||
requests_per_hour: 5000
|
||||
burst_limit: 100
|
||||
ip_whitelist:
|
||||
- "10.0.0.0/8"
|
||||
- "192.168.0.0/16"
|
||||
|
||||
audit:
|
||||
log_level: "INFO"
|
||||
include_payloads: false
|
||||
retention_days: 365
|
||||
destinations: ["datadog", "splunk"]
|
||||
```
|
||||
|
||||
### Jira Enterprise Integration
|
||||
|
||||
```yaml
|
||||
# jira-enterprise-config.yaml
|
||||
jira:
|
||||
base_url: "https://company.atlassian.net"
|
||||
username: "${JIRA_USERNAME}"
|
||||
api_token: "${JIRA_API_TOKEN}"
|
||||
|
||||
# Project access configuration
|
||||
projects:
|
||||
- key: "DEV"
|
||||
name: "Development"
|
||||
permissions: ["read", "write", "transition", "assign"]
|
||||
issue_types: ["Story", "Bug", "Task", "Subtask"]
|
||||
|
||||
- key: "OPS"
|
||||
name: "Operations"
|
||||
permissions: ["read", "comment", "watch"]
|
||||
|
||||
# Custom field mappings
|
||||
custom_fields:
|
||||
story_points: "customfield_10002"
|
||||
epic_link: "customfield_10014"
|
||||
sprint: "customfield_10020"
|
||||
|
||||
# Workflow automation
|
||||
automation:
|
||||
auto_transition:
|
||||
enabled: true
|
||||
rules:
|
||||
- from_status: "To Do"
|
||||
to_status: "In Progress"
|
||||
condition: "assignee_changed"
|
||||
|
||||
auto_assign:
|
||||
enabled: true
|
||||
rules:
|
||||
- issue_type: "Bug"
|
||||
component: "Frontend"
|
||||
assignee: "frontend-team-lead"
|
||||
|
||||
# Security and compliance
|
||||
security:
|
||||
encrypt_fields: ["description", "comment"]
|
||||
mask_sensitive_data: true
|
||||
audit_changes: true
|
||||
|
||||
compliance:
|
||||
gdpr_compliant: true
|
||||
data_retention_policy: "365_days"
|
||||
audit_log_retention: "7_years"
|
||||
```
|
||||
|
||||
### Slack Enterprise Grid Integration
|
||||
|
||||
```yaml
|
||||
# slack-enterprise-config.yaml
|
||||
slack:
|
||||
workspace_id: "T1234567890"
|
||||
bot_token: "${SLACK_BOT_TOKEN}"
|
||||
signing_secret: "${SLACK_SIGNING_SECRET}"
|
||||
|
||||
# Channel management
|
||||
channels:
|
||||
notifications:
|
||||
- name: "#dev-alerts"
|
||||
types: ["deployments", "errors", "security"]
|
||||
- name: "#ai-activity"
|
||||
types: ["cline-tasks", "completions"]
|
||||
|
||||
private_channels:
|
||||
- name: "#security-incidents"
|
||||
members: ["security-team"]
|
||||
types: ["security-alerts", "compliance-issues"]
|
||||
|
||||
# Bot behavior
|
||||
bot:
|
||||
display_name: "Cline Enterprise"
|
||||
default_channel: "#general"
|
||||
response_delay_ms: 1000
|
||||
|
||||
commands:
|
||||
- command: "/cline-status"
|
||||
description: "Check Cline Enterprise status"
|
||||
permission: "all"
|
||||
|
||||
- command: "/cline-deploy"
|
||||
description: "Trigger deployment"
|
||||
permission: "admin"
|
||||
|
||||
# Enterprise features
|
||||
enterprise:
|
||||
app_approval_required: true
|
||||
data_residency: "US"
|
||||
compliance_export: true
|
||||
|
||||
dlp:
|
||||
enabled: true
|
||||
scan_messages: true
|
||||
block_sensitive_data: true
|
||||
|
||||
# Security settings
|
||||
security:
|
||||
require_app_approval: true
|
||||
audit_api_calls: true
|
||||
encrypt_messages: true
|
||||
retain_audit_logs_days: 2555 # 7 years
|
||||
```
|
||||
|
||||
## Enterprise Management
|
||||
|
||||
### Multi-Environment Deployment
|
||||
|
||||
Deploy marketplace servers across environments:
|
||||
|
||||
```yaml
|
||||
# environments-config.yaml
|
||||
environments:
|
||||
development:
|
||||
marketplace_servers:
|
||||
- github-enterprise:
|
||||
version: "2.1.0-beta"
|
||||
config_override:
|
||||
github:
|
||||
base_url: "https://github-dev.company.com/api/v3"
|
||||
organization: "company-dev"
|
||||
|
||||
staging:
|
||||
marketplace_servers:
|
||||
- github-enterprise:
|
||||
version: "2.1.0-rc1"
|
||||
config_override:
|
||||
github:
|
||||
base_url: "https://github-staging.company.com/api/v3"
|
||||
organization: "company-staging"
|
||||
|
||||
production:
|
||||
marketplace_servers:
|
||||
- github-enterprise:
|
||||
version: "2.1.0"
|
||||
config_override:
|
||||
github:
|
||||
base_url: "https://github.company.com/api/v3"
|
||||
organization: "company"
|
||||
```
|
||||
|
||||
### Version Management
|
||||
|
||||
Control marketplace server versions:
|
||||
|
||||
```bash
|
||||
# List available versions
|
||||
cline-enterprise mcp versions github-enterprise
|
||||
|
||||
# Upgrade to latest version
|
||||
cline-enterprise mcp upgrade github-enterprise --version 2.2.0 --environment staging
|
||||
|
||||
# Rollback to previous version
|
||||
cline-enterprise mcp rollback github-enterprise --version 2.1.0 --environment staging
|
||||
|
||||
# Pin to specific version (disable auto-updates)
|
||||
cline-enterprise mcp pin github-enterprise --version 2.1.0
|
||||
```
|
||||
|
||||
### Health Monitoring
|
||||
|
||||
Monitor marketplace server health:
|
||||
|
||||
```yaml
|
||||
# monitoring-config.yaml
|
||||
monitoring:
|
||||
marketplace_servers:
|
||||
health_checks:
|
||||
interval_seconds: 30
|
||||
timeout_seconds: 10
|
||||
|
||||
metrics:
|
||||
- server_status
|
||||
- request_latency
|
||||
- error_rate
|
||||
- resource_usage
|
||||
|
||||
alerts:
|
||||
- name: "marketplace-server-down"
|
||||
condition: "server_status != 1"
|
||||
severity: "critical"
|
||||
|
||||
- name: "high-error-rate"
|
||||
condition: "error_rate > 0.05"
|
||||
severity: "warning"
|
||||
|
||||
- name: "performance-degradation"
|
||||
condition: "request_latency > 5s"
|
||||
severity: "warning"
|
||||
```
|
||||
|
||||
## Security & Compliance
|
||||
|
||||
### Enterprise Security Features
|
||||
|
||||
All marketplace servers include:
|
||||
|
||||
- **Authentication Integration**: SSO, SAML, OAuth2 support
|
||||
- **Authorization Controls**: RBAC and fine-grained permissions
|
||||
- **Audit Logging**: Comprehensive activity tracking
|
||||
- **Data Encryption**: At-rest and in-transit encryption
|
||||
- **Network Security**: VPN, IP whitelisting, private endpoints
|
||||
- **Compliance**: SOC2, GDPR, HIPAA compliance frameworks
|
||||
|
||||
### Data Governance
|
||||
|
||||
Configure data handling policies:
|
||||
|
||||
```yaml
|
||||
# data-governance-config.yaml
|
||||
data_governance:
|
||||
classification:
|
||||
public:
|
||||
retention_days: 90
|
||||
backup_required: false
|
||||
|
||||
internal:
|
||||
retention_days: 365
|
||||
backup_required: true
|
||||
encryption_required: false
|
||||
|
||||
confidential:
|
||||
retention_days: 2555 # 7 years
|
||||
backup_required: true
|
||||
encryption_required: true
|
||||
audit_access: true
|
||||
|
||||
restricted:
|
||||
retention_days: 2555
|
||||
backup_required: true
|
||||
encryption_required: true
|
||||
audit_access: true
|
||||
approval_required: true
|
||||
|
||||
privacy:
|
||||
pii_detection: true
|
||||
pii_masking: true
|
||||
gdpr_compliance: true
|
||||
data_subject_requests: true
|
||||
|
||||
compliance:
|
||||
frameworks: ["SOC2", "GDPR", "CCPA", "HIPAA"]
|
||||
audit_frequency: "quarterly"
|
||||
certification_renewal: "annual"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Installation
|
||||
1. **Review Permissions**: Always review required permissions before installation
|
||||
2. **Test in Staging**: Deploy to staging environment first
|
||||
3. **Configuration Validation**: Validate configuration files before deployment
|
||||
4. **Backup Current State**: Create configuration backups before changes
|
||||
5. **Monitor Deployment**: Watch health metrics during rollout
|
||||
|
||||
### Configuration
|
||||
1. **Environment Separation**: Use different configurations per environment
|
||||
2. **Secret Management**: Store sensitive data in secure secret stores
|
||||
3. **Version Pinning**: Pin versions for production deployments
|
||||
4. **Access Controls**: Implement least-privilege access policies
|
||||
5. **Regular Updates**: Schedule regular security and feature updates
|
||||
|
||||
### Monitoring
|
||||
1. **Health Checks**: Monitor server health continuously
|
||||
2. **Performance Metrics**: Track latency and throughput
|
||||
3. **Error Tracking**: Alert on error rates and failure patterns
|
||||
4. **Resource Usage**: Monitor CPU, memory, and network usage
|
||||
5. **Audit Reviews**: Regular review of audit logs and access patterns
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
**Installation Failures**:
|
||||
```bash
|
||||
# Check marketplace connectivity
|
||||
cline-enterprise mcp marketplace-status
|
||||
|
||||
# Verify authentication
|
||||
cline-enterprise auth verify --service marketplace
|
||||
|
||||
# Check installation logs
|
||||
cline-enterprise logs mcp-installer --lines 100
|
||||
```
|
||||
|
||||
**Configuration Errors**:
|
||||
```bash
|
||||
# Validate configuration
|
||||
cline-enterprise mcp validate-config --file config.yaml
|
||||
|
||||
# Test connectivity
|
||||
cline-enterprise mcp test-connection github-enterprise --environment staging
|
||||
|
||||
# Check server status
|
||||
cline-enterprise mcp status --all
|
||||
```
|
||||
|
||||
**Performance Issues**:
|
||||
```bash
|
||||
# Check server metrics
|
||||
cline-enterprise mcp metrics github-enterprise --duration 1h
|
||||
|
||||
# View recent error logs
|
||||
cline-enterprise logs github-enterprise --level error --lines 50
|
||||
```
|
||||
|
||||
## Support
|
||||
|
||||
For marketplace server issues:
|
||||
|
||||
- **Documentation**: Check server-specific documentation in the dashboard
|
||||
- **Community**: Join the Cline Enterprise community forum
|
||||
- **Support Tickets**: Create support tickets for critical issues
|
||||
- **Professional Services**: Engage professional services for custom configurations
|
||||
|
||||
Enterprise customers have access to dedicated support channels with SLA guarantees.
|
||||
-571
@@ -1,571 +0,0 @@
|
||||
---
|
||||
title: "MCP Integration"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Configure Model Context Protocol (MCP) servers and marketplace integrations for enterprise Cline deployments"
|
||||
---
|
||||
|
||||
Model Context Protocol (MCP) provides standardized communication between AI models and external data sources, tools, and services. Enterprise MCP integration allows you to securely connect Cline to your organization's systems while maintaining governance and compliance.
|
||||
|
||||
## Enterprise MCP Benefits
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Extensible Architecture" icon="puzzle-piece">
|
||||
Connect to unlimited external tools, databases, APIs, and services through standardized MCP servers.
|
||||
</Card>
|
||||
|
||||
<Card title="Enterprise Security" icon="shield-alt">
|
||||
Secure authentication, authorization, and audit trails for all MCP server communications.
|
||||
</Card>
|
||||
|
||||
<Card title="Centralized Management" icon="network-wired">
|
||||
Manage and deploy MCP servers enterprise-wide with version control and configuration management.
|
||||
</Card>
|
||||
|
||||
<Card title="Compliance Ready" icon="clipboard-check">
|
||||
Built-in logging, monitoring, and data governance for regulatory compliance requirements.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## MCP Architecture Overview
|
||||
|
||||
```mermaid
|
||||
graph TB
|
||||
A[Cline Enterprise] --> B[MCP Hub]
|
||||
B --> C[MCP Marketplace]
|
||||
B --> D[Remote MCP Servers]
|
||||
B --> E[Internal MCP Servers]
|
||||
|
||||
C --> F[GitHub Integration]
|
||||
C --> G[Slack Integration]
|
||||
C --> H[Jira Integration]
|
||||
|
||||
D --> I[Custom APIs]
|
||||
D --> J[Databases]
|
||||
D --> K[Cloud Services]
|
||||
|
||||
E --> L[Internal Tools]
|
||||
E --> M[Legacy Systems]
|
||||
E --> N[Security Systems]
|
||||
|
||||
O[Enterprise Admin] --> B
|
||||
P[Audit Logging] --> B
|
||||
Q[Authentication] --> B
|
||||
```
|
||||
|
||||
## Core Components
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="MCP Marketplace" icon="store" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace">
|
||||
Pre-built, enterprise-ready MCP servers for popular tools and services with one-click deployment.
|
||||
</Card>
|
||||
|
||||
<Card title="Remote MCP Servers" icon="server" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers">
|
||||
Deploy and manage custom MCP servers across your infrastructure with centralized configuration.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Enterprise Configuration
|
||||
|
||||
### Basic MCP Hub Setup
|
||||
|
||||
Configure the central MCP hub for your enterprise deployment:
|
||||
|
||||
```yaml
|
||||
# mcp-hub-config.yaml
|
||||
mcp:
|
||||
hub:
|
||||
enabled: true
|
||||
port: 8080
|
||||
authentication:
|
||||
method: "enterprise-sso"
|
||||
jwt_secret: "${MCP_JWT_SECRET}"
|
||||
|
||||
# Server discovery
|
||||
discovery:
|
||||
methods: ["marketplace", "remote", "local"]
|
||||
marketplace_url: "https://mcp.cline.bot/marketplace"
|
||||
|
||||
# Security settings
|
||||
security:
|
||||
enforce_tls: true
|
||||
allowed_origins: ["https://*.company.com"]
|
||||
rate_limiting:
|
||||
requests_per_minute: 1000
|
||||
burst_size: 100
|
||||
|
||||
# Audit and compliance
|
||||
audit:
|
||||
enabled: true
|
||||
log_level: "INFO"
|
||||
destinations: ["file", "syslog", "datadog"]
|
||||
retention_days: 90
|
||||
```
|
||||
|
||||
### Multi-Environment Configuration
|
||||
|
||||
Deploy MCP configurations across environments:
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Development">
|
||||
```yaml
|
||||
# mcp-dev-config.yaml
|
||||
mcp:
|
||||
environment: "development"
|
||||
|
||||
servers:
|
||||
- name: "github-dev"
|
||||
type: "marketplace"
|
||||
package: "@cline/mcp-github"
|
||||
version: "latest"
|
||||
config:
|
||||
github_token: "${GITHUB_DEV_TOKEN}"
|
||||
org: "company-dev"
|
||||
|
||||
- name: "local-db"
|
||||
type: "remote"
|
||||
url: "http://localhost:3001"
|
||||
auth:
|
||||
type: "api-key"
|
||||
key: "${DEV_DB_API_KEY}"
|
||||
|
||||
policies:
|
||||
allow_experimental: true
|
||||
auto_update: true
|
||||
rate_limits:
|
||||
relaxed: true
|
||||
```
|
||||
</Tab>
|
||||
|
||||
<Tab title="Production">
|
||||
```yaml
|
||||
# mcp-prod-config.yaml
|
||||
mcp:
|
||||
environment: "production"
|
||||
|
||||
servers:
|
||||
- name: "github-prod"
|
||||
type: "marketplace"
|
||||
package: "@cline/mcp-github"
|
||||
version: "1.2.3" # Pinned version
|
||||
config:
|
||||
github_token: "${GITHUB_PROD_TOKEN}"
|
||||
org: "company"
|
||||
|
||||
- name: "crm-integration"
|
||||
type: "remote"
|
||||
url: "https://mcp-crm.internal.company.com"
|
||||
auth:
|
||||
type: "mtls"
|
||||
cert_path: "/certs/mcp-client.pem"
|
||||
key_path: "/certs/mcp-client-key.pem"
|
||||
|
||||
- name: "security-scanner"
|
||||
type: "remote"
|
||||
url: "https://security-mcp.company.com"
|
||||
auth:
|
||||
type: "oauth2"
|
||||
client_id: "${SECURITY_CLIENT_ID}"
|
||||
client_secret: "${SECURITY_CLIENT_SECRET}"
|
||||
|
||||
policies:
|
||||
allow_experimental: false
|
||||
auto_update: false
|
||||
strict_versioning: true
|
||||
|
||||
monitoring:
|
||||
metrics: true
|
||||
health_checks: true
|
||||
alert_on_failure: true
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Server Management
|
||||
|
||||
### Lifecycle Management
|
||||
|
||||
Manage MCP server deployments with GitOps:
|
||||
|
||||
```yaml
|
||||
# mcp-server-manifest.yaml
|
||||
apiVersion: mcp.cline.bot/v1
|
||||
kind: MCPServer
|
||||
metadata:
|
||||
name: custom-api-server
|
||||
namespace: cline-enterprise
|
||||
spec:
|
||||
image: company/custom-mcp-server:v1.0.0
|
||||
replicas: 3
|
||||
|
||||
config:
|
||||
api_endpoint: "https://api.internal.company.com"
|
||||
timeout: 30s
|
||||
retry_attempts: 3
|
||||
|
||||
auth:
|
||||
type: service-account
|
||||
service_account: mcp-custom-api
|
||||
|
||||
resources:
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "100m"
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
|
||||
monitoring:
|
||||
enabled: true
|
||||
metrics_port: 9090
|
||||
health_endpoint: "/health"
|
||||
|
||||
security:
|
||||
network_policy: strict
|
||||
pod_security_standard: restricted
|
||||
```
|
||||
|
||||
### Configuration Management
|
||||
|
||||
Use Helm charts for enterprise MCP deployments:
|
||||
|
||||
```yaml
|
||||
# values-prod.yaml
|
||||
mcp:
|
||||
hub:
|
||||
replicaCount: 3
|
||||
image:
|
||||
repository: cline/mcp-hub-enterprise
|
||||
tag: "1.5.2"
|
||||
|
||||
servers:
|
||||
marketplace:
|
||||
enabled: true
|
||||
catalog_url: "https://enterprise-catalog.company.com"
|
||||
|
||||
custom:
|
||||
- name: "salesforce"
|
||||
enabled: true
|
||||
image: "company/mcp-salesforce:1.0.0"
|
||||
config:
|
||||
instance_url: "https://company.my.salesforce.com"
|
||||
|
||||
- name: "jira"
|
||||
enabled: true
|
||||
image: "company/mcp-jira:2.1.0"
|
||||
config:
|
||||
base_url: "https://company.atlassian.net"
|
||||
|
||||
ingress:
|
||||
enabled: true
|
||||
className: nginx
|
||||
annotations:
|
||||
cert-manager.io/cluster-issuer: "letsencrypt-prod"
|
||||
hosts:
|
||||
- host: mcp.company.com
|
||||
paths:
|
||||
- path: /
|
||||
pathType: Prefix
|
||||
tls:
|
||||
- secretName: mcp-tls
|
||||
hosts:
|
||||
- mcp.company.com
|
||||
```
|
||||
|
||||
## Security & Governance
|
||||
|
||||
### Authentication & Authorization
|
||||
|
||||
Configure enterprise authentication for MCP servers:
|
||||
|
||||
```yaml
|
||||
# mcp-auth-config.yaml
|
||||
authentication:
|
||||
providers:
|
||||
- name: "enterprise-sso"
|
||||
type: "oidc"
|
||||
issuer: "https://sso.company.com"
|
||||
client_id: "${SSO_CLIENT_ID}"
|
||||
client_secret: "${SSO_CLIENT_SECRET}"
|
||||
|
||||
- name: "service-accounts"
|
||||
type: "jwt"
|
||||
signing_key: "${SERVICE_ACCOUNT_KEY}"
|
||||
|
||||
authorization:
|
||||
policies:
|
||||
- name: "developers"
|
||||
subjects: ["group:developers"]
|
||||
resources: ["mcp:servers:read", "mcp:servers:execute"]
|
||||
|
||||
- name: "admins"
|
||||
subjects: ["group:mcp-admins"]
|
||||
resources: ["mcp:*"]
|
||||
|
||||
- name: "security-team"
|
||||
subjects: ["group:security"]
|
||||
resources: ["mcp:audit:*", "mcp:servers:security-*"]
|
||||
|
||||
rbac:
|
||||
enabled: true
|
||||
default_role: "viewer"
|
||||
```
|
||||
|
||||
### Network Security
|
||||
|
||||
Implement network policies for MCP communications:
|
||||
|
||||
```yaml
|
||||
# mcp-network-policy.yaml
|
||||
apiVersion: networking.k8s.io/v1
|
||||
kind: NetworkPolicy
|
||||
metadata:
|
||||
name: mcp-server-policy
|
||||
namespace: cline-enterprise
|
||||
spec:
|
||||
podSelector:
|
||||
matchLabels:
|
||||
app: mcp-server
|
||||
policyTypes:
|
||||
- Ingress
|
||||
- Egress
|
||||
|
||||
ingress:
|
||||
- from:
|
||||
- namespaceSelector:
|
||||
matchLabels:
|
||||
name: cline-enterprise
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: cline-core
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 8080
|
||||
|
||||
egress:
|
||||
# Allow DNS
|
||||
- to: []
|
||||
ports:
|
||||
- protocol: UDP
|
||||
port: 53
|
||||
# Allow HTTPS to external APIs
|
||||
- to: []
|
||||
ports:
|
||||
- protocol: TCP
|
||||
port: 443
|
||||
```
|
||||
|
||||
## Monitoring & Observability
|
||||
|
||||
### Metrics Collection
|
||||
|
||||
Configure comprehensive MCP monitoring:
|
||||
|
||||
```yaml
|
||||
# mcp-monitoring.yaml
|
||||
monitoring:
|
||||
metrics:
|
||||
enabled: true
|
||||
interval: 30s
|
||||
|
||||
collectors:
|
||||
- name: "server-health"
|
||||
metrics:
|
||||
- mcp_server_status
|
||||
- mcp_server_response_time
|
||||
- mcp_server_error_rate
|
||||
|
||||
- name: "hub-performance"
|
||||
metrics:
|
||||
- mcp_hub_requests_total
|
||||
- mcp_hub_request_duration
|
||||
- mcp_hub_active_connections
|
||||
|
||||
- name: "resource-usage"
|
||||
metrics:
|
||||
- mcp_memory_usage
|
||||
- mcp_cpu_usage
|
||||
- mcp_network_io
|
||||
|
||||
alerts:
|
||||
- name: "server-down"
|
||||
condition: "mcp_server_status == 0"
|
||||
severity: "critical"
|
||||
notification_channels: ["pagerduty", "slack"]
|
||||
|
||||
- name: "high-error-rate"
|
||||
condition: "mcp_server_error_rate > 0.05"
|
||||
severity: "warning"
|
||||
notification_channels: ["slack"]
|
||||
|
||||
- name: "performance-degradation"
|
||||
condition: "mcp_server_response_time > 5s"
|
||||
severity: "warning"
|
||||
notification_channels: ["email"]
|
||||
```
|
||||
|
||||
### Audit Logging
|
||||
|
||||
Implement comprehensive audit trails:
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp": "2024-01-15T10:30:00Z",
|
||||
"event_type": "mcp_server_call",
|
||||
"user_id": "john.doe@company.com",
|
||||
"session_id": "sess_abc123",
|
||||
"server_name": "github-prod",
|
||||
"method": "github.create_issue",
|
||||
"request": {
|
||||
"repository": "company/project",
|
||||
"title": "Bug fix required",
|
||||
"sensitive_data_detected": false
|
||||
},
|
||||
"response": {
|
||||
"status": "success",
|
||||
"issue_id": "12345",
|
||||
"duration_ms": 234
|
||||
},
|
||||
"compliance": {
|
||||
"data_classification": "internal",
|
||||
"retention_required": true,
|
||||
"pii_detected": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Custom MCP Server Development
|
||||
|
||||
### Development Framework
|
||||
|
||||
Create custom MCP servers using the enterprise SDK:
|
||||
|
||||
```typescript
|
||||
// custom-mcp-server.ts
|
||||
import { MCPServer, Tool, Resource } from '@cline/mcp-enterprise-sdk';
|
||||
|
||||
class CustomAPIServer extends MCPServer {
|
||||
constructor() {
|
||||
super({
|
||||
name: 'custom-api-server',
|
||||
version: '1.0.0',
|
||||
description: 'Custom API integration server'
|
||||
});
|
||||
|
||||
this.addTool(new DatabaseQueryTool());
|
||||
this.addResource(new UserDataResource());
|
||||
}
|
||||
}
|
||||
|
||||
class DatabaseQueryTool implements Tool {
|
||||
name = 'query_database';
|
||||
description = 'Query the company database';
|
||||
|
||||
async execute(params: any) {
|
||||
// Implement database query logic
|
||||
const result = await this.database.query(params.sql);
|
||||
|
||||
// Audit log the query
|
||||
await this.auditLog({
|
||||
action: 'database_query',
|
||||
query: params.sql,
|
||||
user: params.user_id,
|
||||
results_count: result.length
|
||||
});
|
||||
|
||||
return result;
|
||||
}
|
||||
|
||||
async validate(params: any): Promise<boolean> {
|
||||
// Implement query validation
|
||||
return params.sql && !this.containsMaliciousSQL(params.sql);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Deployment Pipeline
|
||||
|
||||
Automate MCP server deployments:
|
||||
|
||||
```yaml
|
||||
# .github/workflows/deploy-mcp-server.yml
|
||||
name: Deploy MCP Server
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths: ['mcp-servers/**']
|
||||
|
||||
jobs:
|
||||
deploy:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: Build MCP Server
|
||||
run: |
|
||||
docker build -t company/mcp-server:${{ github.sha }} .
|
||||
docker push company/mcp-server:${{ github.sha }}
|
||||
|
||||
- name: Deploy to Staging
|
||||
run: |
|
||||
helm upgrade mcp-server-staging ./helm-chart \
|
||||
--set image.tag=${{ github.sha }} \
|
||||
--namespace mcp-staging
|
||||
|
||||
- name: Run Integration Tests
|
||||
run: |
|
||||
kubectl wait --for=condition=ready pod -l app=mcp-server -n mcp-staging
|
||||
npm run test:integration
|
||||
|
||||
- name: Deploy to Production
|
||||
if: success()
|
||||
run: |
|
||||
helm upgrade mcp-server-prod ./helm-chart \
|
||||
--set image.tag=${{ github.sha }} \
|
||||
--namespace mcp-prod
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Security
|
||||
1. **Authentication**: Always require authentication for MCP servers
|
||||
2. **Encryption**: Use TLS for all MCP communications
|
||||
3. **Validation**: Validate all inputs and sanitize outputs
|
||||
4. **Least Privilege**: Grant minimal required permissions
|
||||
5. **Audit**: Log all MCP server interactions
|
||||
|
||||
### Performance
|
||||
1. **Caching**: Implement response caching where appropriate
|
||||
2. **Connection Pooling**: Reuse connections to external services
|
||||
3. **Async Operations**: Use non-blocking operations for I/O
|
||||
4. **Resource Limits**: Set appropriate CPU and memory limits
|
||||
5. **Load Balancing**: Scale MCP servers based on demand
|
||||
|
||||
### Reliability
|
||||
1. **Health Checks**: Implement comprehensive health endpoints
|
||||
2. **Circuit Breakers**: Fail fast when external services are down
|
||||
3. **Retry Logic**: Implement exponential backoff for failures
|
||||
4. **Graceful Degradation**: Provide fallback behavior
|
||||
5. **Monitoring**: Set up proactive alerting and monitoring
|
||||
|
||||
## Production Checklist
|
||||
|
||||
Before deploying MCP servers to production:
|
||||
|
||||
- [ ] Security review completed
|
||||
- [ ] Authentication and authorization configured
|
||||
- [ ] Network policies implemented
|
||||
- [ ] Monitoring and alerting set up
|
||||
- [ ] Audit logging enabled
|
||||
- [ ] Resource limits configured
|
||||
- [ ] Health checks implemented
|
||||
- [ ] Integration tests passing
|
||||
- [ ] Disaster recovery plan documented
|
||||
- [ ] Compliance requirements validated
|
||||
|
||||
## Getting Started
|
||||
|
||||
Ready to implement enterprise MCP integration? Start with:
|
||||
|
||||
1. [MCP Marketplace](/enterprise-solutions/configuration/infrastructure-configuration/mcp/mcp-marketplace) - Deploy pre-built integrations
|
||||
2. [Remote MCP Servers](/enterprise-solutions/configuration/infrastructure-configuration/mcp/remote-mcp-servers) - Configure custom servers
|
||||
3. Review our [MCP Development Guide](/mcp/mcp-overview) for building custom integrations
|
||||
-1025
File diff suppressed because it is too large
Load Diff
@@ -1,95 +0,0 @@
|
||||
---
|
||||
title: "Self-Hosted Configuration"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Deploy and configure Cline on your own infrastructure with enterprise-grade security and compliance"
|
||||
---
|
||||
|
||||
<Warning>
|
||||
**Self-Hosted Configuration Path**
|
||||
|
||||
This section is for enterprises deploying **self-hosted Cline infrastructure** with complex security, compliance, and multi-environment requirements. Configuration is done through YAML files, Kubernetes/Helm deployments, and infrastructure-as-code.
|
||||
|
||||
**Looking for simple setup?** See [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview) for quick configuration through the app.cline.bot admin console - no infrastructure deployment required, just web-based settings.
|
||||
</Warning>
|
||||
|
||||
Self-Hosted Configuration provides centralized control over all aspects of your Cline deployment on your own infrastructure, from AI providers to custom workflows. This section covers how to configure, manage, and optimize your enterprise Cline installation with advanced security, compliance, and operational features.
|
||||
|
||||
## Configuration Categories
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Providers" icon="cloud" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/overview">
|
||||
Configure AI providers including AWS Bedrock, LiteLLM, and Google Vertex AI with enterprise-grade security and governance.
|
||||
</Card>
|
||||
|
||||
<Card title="MCP Integration" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/mcp/overview">
|
||||
Manage Model Context Protocol servers, marketplace integrations, and remote MCP server configurations.
|
||||
</Card>
|
||||
|
||||
<Card title="Rules Engine" icon="shield-check" href="/enterprise-solutions/configuration/infrastructure-configuration/rules">
|
||||
Define and enforce enterprise governance rules, security policies, and compliance requirements.
|
||||
</Card>
|
||||
|
||||
<Card title="Workflows" icon="workflow" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
|
||||
Create automated workflows for development processes, approval chains, and integration pipelines.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Advanced Controls
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Control Other Cline Features" icon="toggles" href="/enterprise-solutions/configuration/infrastructure-configuration/control-other-cline-features/overview">
|
||||
Enable or disable specific Cline features across your organization with granular permission controls.
|
||||
</Card>
|
||||
|
||||
<Card title="Monitoring" icon="chart-line" href="/enterprise-solutions/monitoring/overview">
|
||||
Configure OpenTelemetry integration for comprehensive monitoring, logging, and analytics.
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. **Assessment**: Review your current infrastructure and integration requirements
|
||||
2. **Provider Setup**: Configure your preferred AI providers with enterprise credentials
|
||||
3. **Security Configuration**: Implement rules and access controls
|
||||
4. **Monitoring Setup**: Enable telemetry and monitoring for operational visibility
|
||||
5. **User Onboarding**: Deploy configurations to your development teams
|
||||
|
||||
## Enterprise Architecture Considerations
|
||||
|
||||
### Security & Compliance
|
||||
- **Zero Trust Architecture**: All configurations support zero-trust security models
|
||||
- **Audit Logging**: Complete audit trails for all configuration changes
|
||||
- **Role-Based Access**: Granular permissions for different administrative roles
|
||||
- **Data Sovereignty**: Keep sensitive data within your infrastructure boundaries
|
||||
|
||||
### Scalability & Performance
|
||||
- **Multi-Region Support**: Deploy configurations across multiple geographic regions
|
||||
- **Load Balancing**: Distribute AI provider requests across multiple endpoints
|
||||
- **Caching Strategies**: Optimize performance with intelligent caching
|
||||
- **Rate Limiting**: Prevent abuse with configurable rate limits
|
||||
|
||||
### Integration & Automation
|
||||
- **GitOps Integration**: Version control your configurations alongside code
|
||||
- **CI/CD Pipeline Integration**: Automate configuration deployment
|
||||
- **Webhook Support**: React to configuration changes with custom automation
|
||||
- **API-First Design**: Programmatically manage all configurations
|
||||
|
||||
## Configuration Management
|
||||
|
||||
All enterprise configurations support:
|
||||
|
||||
- **Version Control**: Track changes with full revision history
|
||||
- **Environment Promotion**: Deploy configurations from dev → staging → production
|
||||
- **Rollback Capabilities**: Quickly revert problematic configurations
|
||||
- **Configuration Validation**: Automated testing of configuration changes
|
||||
- **Drift Detection**: Monitor and alert on configuration drift
|
||||
|
||||
## Next Steps
|
||||
|
||||
Ready to configure your enterprise deployment? Start with:
|
||||
|
||||
1. [Provider Configuration](/enterprise-solutions/configuration/infrastructure-configuration/providers/overview) - Set up your AI providers
|
||||
2. [Security Rules](/enterprise-solutions/configuration/infrastructure-configuration/rules) - Implement governance policies
|
||||
3. [Monitoring Setup](/enterprise-solutions/monitoring/overview) - Enable operational visibility
|
||||
|
||||
For hands-on configuration assistance, contact your Cline Enterprise support team or refer to our implementation guides.
|
||||
-182
@@ -1,182 +0,0 @@
|
||||
---
|
||||
title: "AWS Bedrock Configuration"
|
||||
sidebarTitle: "AWS Bedrock"
|
||||
description: "Configure AWS Bedrock for your Cline deployment"
|
||||
---
|
||||
|
||||
<Info>
|
||||
**Configuration Path: Self-Hosted**
|
||||
|
||||
This guide covers Bedrock configuration for self-hosted deployments. For simple web-based setup, see [AWS Bedrock SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/aws-bedrock/admin-configuration).
|
||||
</Info>
|
||||
|
||||
Configure Cline to use AWS Bedrock for enterprise access to Claude and other foundation models through Amazon's managed service.
|
||||
|
||||
## Configuration Format
|
||||
|
||||
Configure Bedrock through your remote configuration JSON using the `providerSettings.AwsBedrock` section:
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"AwsBedrock": {
|
||||
"models": [
|
||||
{
|
||||
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
}
|
||||
],
|
||||
"awsRegion": "us-east-1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration Fields
|
||||
|
||||
| Field | Type | Description | Required |
|
||||
|-------|------|-------------|----------|
|
||||
| `models` | Array | List of model configurations | Yes |
|
||||
| `awsRegion` | String | AWS region (e.g., `us-east-1`) | Yes |
|
||||
| `awsUseCrossRegionInference` | Boolean | Enable cross-region inference | No |
|
||||
| `awsUseGlobalInference` | Boolean | Enable global inference routing | No |
|
||||
| `awsBedrockUsePromptCache` | Boolean | Enable prompt caching | No |
|
||||
| `awsBedrockEndpoint` | String | Custom Bedrock endpoint URL | No |
|
||||
| `customModels` | Array | Custom model configurations | No |
|
||||
|
||||
### Model Configuration
|
||||
|
||||
Each model in the `models` array requires:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
|
||||
"name": "Claude 3.5 Sonnet",
|
||||
"info": {
|
||||
"maxTokens": 8192,
|
||||
"contextWindow": 200000,
|
||||
"supportsImages": true,
|
||||
"supportsPromptCache": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Common Model IDs
|
||||
|
||||
| Model ID | Description | Context Window |
|
||||
|----------|-------------|----------------|
|
||||
| `anthropic.claude-3-5-sonnet-20241022-v2:0` | Latest Claude Sonnet | 200K tokens |
|
||||
| `anthropic.claude-3-5-haiku-20241022-v1:0` | Latest Claude Haiku | 200K tokens |
|
||||
| `anthropic.claude-3-opus-20240229-v1:0` | Claude Opus | 200K tokens |
|
||||
|
||||
<Note>
|
||||
Model availability varies by region. See [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html) for region-specific model availability.
|
||||
</Note>
|
||||
|
||||
## Example Configurations
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"AwsBedrock": {
|
||||
"models": [
|
||||
{
|
||||
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
}
|
||||
],
|
||||
"awsRegion": "us-east-1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### With Prompt Caching
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"AwsBedrock": {
|
||||
"models": [
|
||||
{
|
||||
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
}
|
||||
],
|
||||
"awsRegion": "us-east-1",
|
||||
"awsBedrockUsePromptCache": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Multiple Models
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"AwsBedrock": {
|
||||
"models": [
|
||||
{
|
||||
"id": "anthropic.claude-3-5-sonnet-20241022-v2:0",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
},
|
||||
{
|
||||
"id": "anthropic.claude-3-5-haiku-20241022-v1:0",
|
||||
"name": "Claude 3.5 Haiku"
|
||||
}
|
||||
],
|
||||
"awsRegion": "us-east-1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring Cline to use Bedrock, you need:
|
||||
|
||||
1. **AWS Account** with Bedrock access enabled
|
||||
2. **IAM Permissions** for Bedrock API calls (`bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream`)
|
||||
3. **Model Access** enabled for desired models in the Bedrock console
|
||||
4. **AWS Credentials** configured (IAM role, access keys, or AWS profile)
|
||||
|
||||
<Tip>
|
||||
For AWS account setup and IAM configuration, see the [AWS Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html).
|
||||
</Tip>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**"Access Denied" Errors**
|
||||
|
||||
Ensure your AWS credentials have the required Bedrock permissions. See [AWS IAM documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html) for permission requirements.
|
||||
|
||||
**"Model Not Found" Errors**
|
||||
|
||||
Verify model access is enabled in the AWS Bedrock console and the model is available in your configured region.
|
||||
|
||||
**High Latency**
|
||||
|
||||
Consider using a region closer to your users or enabling cross-region inference for better performance.
|
||||
|
||||
## Related Resources
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="AWS Bedrock Docs" icon="book" href="https://docs.aws.amazon.com/bedrock/">
|
||||
Complete AWS Bedrock documentation
|
||||
</Card>
|
||||
|
||||
<Card title="Model Access" icon="key" href="https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html">
|
||||
How to enable model access
|
||||
</Card>
|
||||
|
||||
<Card title="IAM Permissions" icon="shield" href="https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html">
|
||||
Required IAM permissions
|
||||
</Card>
|
||||
|
||||
<Card title="Pricing" icon="dollar-sign" href="https://aws.amazon.com/bedrock/pricing/">
|
||||
AWS Bedrock pricing details
|
||||
</Card>
|
||||
</CardGroup>
|
||||
-254
@@ -1,254 +0,0 @@
|
||||
---
|
||||
title: "Custom Provider Configuration"
|
||||
sidebarTitle: "Custom Providers"
|
||||
description: "Configure custom OpenAI-compatible providers for your Cline deployment"
|
||||
---
|
||||
|
||||
<Info>
|
||||
**Configuration Path: Self-Hosted**
|
||||
|
||||
This guide covers custom provider configuration for self-hosted deployments.
|
||||
</Info>
|
||||
|
||||
Configure Cline to use any OpenAI-compatible API provider, including Azure OpenAI, self-hosted inference servers, and other third-party services.
|
||||
|
||||
## What are Custom Providers?
|
||||
|
||||
Custom providers include any API that implements the OpenAI API format:
|
||||
|
||||
- **Azure OpenAI Service**: Microsoft's managed OpenAI models
|
||||
- **vLLM**: Self-hosted inference server
|
||||
- **Ollama**: Local model runner
|
||||
- **Text Generation Inference (TGI)**: Hugging Face's inference server
|
||||
- **LocalAI**: Local OpenAI API replacement
|
||||
- **Other OpenAI-compatible APIs**: Any custom implementation
|
||||
|
||||
## Configuration Format
|
||||
|
||||
Configure custom providers through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://your-api.company.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration Fields
|
||||
|
||||
| Field | Type | Description | Required |
|
||||
|-------|------|-------------|----------|
|
||||
| `models` | Array | List of model configurations | Yes |
|
||||
| `openAiBaseUrl` | String | API endpoint base URL | Yes |
|
||||
| `openAiApiKey` | String | API key for authentication | No |
|
||||
| `openAiModelId` | String | Default model identifier | No |
|
||||
|
||||
### Azure OpenAI Specific Fields
|
||||
|
||||
For Azure OpenAI, additional fields are available:
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `azureApiVersion` | String | Azure API version (e.g., `2024-02-15-preview`) |
|
||||
|
||||
## Example Configurations
|
||||
|
||||
### Azure OpenAI
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://your-resource.openai.azure.com/openai/deployments/gpt-4-turbo",
|
||||
"openAiApiKey": "your-azure-api-key",
|
||||
"azureApiVersion": "2024-02-15-preview"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Self-Hosted vLLM
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "meta-llama/Llama-2-70b-chat-hf",
|
||||
"name": "Llama 2 70B"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://vllm.company.com:8000/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Local Ollama
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "codellama",
|
||||
"name": "Code Llama"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://localhost:11434/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Text Generation Inference (TGI)
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "mistralai/Mistral-7B-Instruct-v0.2",
|
||||
"name": "Mistral 7B Instruct"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://tgi.company.com:8080/v1",
|
||||
"openAiApiKey": "your-tgi-api-key"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### LocalAI
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-3.5-turbo",
|
||||
"name": "Local GPT-3.5"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://localhost:8080/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Internal Network (No Auth)
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "custom-model",
|
||||
"name": "Custom Model"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://internal.api:8000/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Model Configuration
|
||||
|
||||
Each model requires basic information:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "model-identifier",
|
||||
"name": "Display Name",
|
||||
"info": {
|
||||
"maxTokens": 4096,
|
||||
"contextWindow": 128000,
|
||||
"supportsImages": true,
|
||||
"supportsPromptCache": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring a custom provider, you need:
|
||||
|
||||
1. **API Endpoint**: URL of your OpenAI-compatible API
|
||||
2. **API Key** (if required): Authentication credentials
|
||||
3. **Model IDs**: Names of available models
|
||||
4. **Network Access**: Connectivity from where Cline is being used
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Connection Errors**
|
||||
|
||||
Verify the endpoint is accessible:
|
||||
```bash
|
||||
curl https://your-api.company.com/v1/models
|
||||
```
|
||||
|
||||
**Authentication Errors**
|
||||
|
||||
Test authentication with your API key:
|
||||
```bash
|
||||
curl -H "Authorization: Bearer your-api-key" \
|
||||
https://your-api.company.com/v1/models
|
||||
```
|
||||
|
||||
**Model Not Found**
|
||||
|
||||
Ensure the model ID in your configuration matches what the API expects. Check available models:
|
||||
```bash
|
||||
curl -H "Authorization: Bearer your-api-key" \
|
||||
https://your-api.company.com/v1/models
|
||||
```
|
||||
|
||||
**Timeout Issues**
|
||||
|
||||
If responses are slow:
|
||||
- Check network latency
|
||||
- Verify server has adequate resources
|
||||
- Consider using faster models
|
||||
|
||||
## Provider Documentation
|
||||
|
||||
For setup and deployment of these services, see their official documentation:
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Azure OpenAI" icon="microsoft" href="https://learn.microsoft.com/en-us/azure/ai-services/openai/">
|
||||
Microsoft's managed OpenAI service
|
||||
</Card>
|
||||
|
||||
<Card title="vLLM" icon="server" href="https://docs.vllm.ai/">
|
||||
High-performance inference engine
|
||||
</Card>
|
||||
|
||||
<Card title="Ollama" icon="download" href="https://ollama.ai/">
|
||||
Run models locally
|
||||
</Card>
|
||||
|
||||
<Card title="Text Generation Inference" icon="code" href="https://huggingface.co/docs/text-generation-inference/">
|
||||
Hugging Face inference server
|
||||
</Card>
|
||||
</CardGroup>
|
||||
-185
@@ -1,185 +0,0 @@
|
||||
---
|
||||
title: "Google Vertex AI Configuration"
|
||||
sidebarTitle: "Google Vertex"
|
||||
description: "Configure Google Vertex AI for your Cline deployment"
|
||||
---
|
||||
|
||||
<Info>
|
||||
**Configuration Path: Self-Hosted**
|
||||
|
||||
This guide covers Vertex AI configuration for self-hosted deployments. For simple web-based setup, see [Google Vertex SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/google-vertex/admin-configuration).
|
||||
</Info>
|
||||
|
||||
Configure Cline to use Google Vertex AI for enterprise access to Gemini and other Google AI models through Google Cloud Platform.
|
||||
|
||||
## Configuration Format
|
||||
|
||||
Configure Vertex AI through your remote configuration JSON using the `providerSettings.Vertex` section:
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"Vertex": {
|
||||
"models": [
|
||||
{
|
||||
"id": "claude-3-5-sonnet-v2@20241022",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
}
|
||||
],
|
||||
"vertexProjectId": "my-project-id",
|
||||
"vertexRegion": "us-central1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration Fields
|
||||
|
||||
| Field | Type | Description | Required |
|
||||
|-------|------|-------------|----------|
|
||||
| `models` | Array | List of model configurations | Yes |
|
||||
| `vertexProjectId` | String | Google Cloud project ID | Yes |
|
||||
| `vertexRegion` | String | GCP region (e.g., `us-central1`) | Yes |
|
||||
|
||||
### Model Configuration
|
||||
|
||||
Each model in the `models` array requires:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "claude-3-5-sonnet-v2@20241022",
|
||||
"name": "Claude 3.5 Sonnet",
|
||||
"info": {
|
||||
"maxTokens": 8192,
|
||||
"contextWindow": 200000,
|
||||
"supportsImages": true,
|
||||
"supportsPromptCache": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Common Model IDs
|
||||
|
||||
| Model ID | Description | Context Window |
|
||||
|----------|-------------|----------------|
|
||||
| `claude-3-5-sonnet-v2@20241022` | Claude 3.5 Sonnet | 200K tokens |
|
||||
| `claude-3-5-haiku@20241022` | Claude 3.5 Haiku | 200K tokens |
|
||||
| `claude-3-opus@20240229` | Claude 3 Opus | 200K tokens |
|
||||
| `gemini-2.0-flash-exp` | Gemini Flash (experimental) | 1M tokens |
|
||||
| `gemini-1.5-pro-002` | Gemini Pro | 2M tokens |
|
||||
| `gemini-1.5-flash-002` | Gemini Flash | 1M tokens |
|
||||
|
||||
<Note>
|
||||
Model availability varies by region. See [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models) for region-specific model availability.
|
||||
</Note>
|
||||
|
||||
## Example Configurations
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"Vertex": {
|
||||
"models": [
|
||||
{
|
||||
"id": "claude-3-5-sonnet-v2@20241022",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
}
|
||||
],
|
||||
"vertexProjectId": "my-company-prod",
|
||||
"vertexRegion": "us-central1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Multiple Models
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"Vertex": {
|
||||
"models": [
|
||||
{
|
||||
"id": "claude-3-5-sonnet-v2@20241022",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
},
|
||||
{
|
||||
"id": "gemini-1.5-pro-002",
|
||||
"name": "Gemini Pro"
|
||||
}
|
||||
],
|
||||
"vertexProjectId": "my-company-prod",
|
||||
"vertexRegion": "us-central1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### With Extended Thinking
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"Vertex": {
|
||||
"models": [
|
||||
{
|
||||
"id": "claude-3-5-sonnet-v2@20241022",
|
||||
"name": "Claude 3.5 Sonnet",
|
||||
"thinkingBudgetTokens": 1600
|
||||
}
|
||||
],
|
||||
"vertexProjectId": "my-company-prod",
|
||||
"vertexRegion": "us-central1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring Cline to use Vertex AI, you need:
|
||||
|
||||
1. **Google Cloud Project** with Vertex AI API enabled
|
||||
2. **Service Account** with Vertex AI User role (`roles/aiplatform.user`)
|
||||
3. **Service Account Credentials** configured for authentication
|
||||
4. **Model Access** verified in your project and region
|
||||
|
||||
<Tip>
|
||||
For Google Cloud setup and authentication configuration, see the [Vertex AI documentation](https://cloud.google.com/vertex-ai/docs/generative-ai/start/quickstarts/quickstart-multimodal).
|
||||
</Tip>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**"Permission Denied" Errors**
|
||||
|
||||
Ensure your service account has the required Vertex AI permissions. See [Google Cloud IAM documentation](https://cloud.google.com/vertex-ai/docs/general/access-control) for permission requirements.
|
||||
|
||||
**"API Not Enabled" Errors**
|
||||
|
||||
Verify the Vertex AI API is enabled in your Google Cloud project.
|
||||
|
||||
**"Model Not Found" Errors**
|
||||
|
||||
Check that the model is available in your configured region and that your project has access to it.
|
||||
|
||||
## Related Resources
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Vertex AI Docs" icon="book" href="https://cloud.google.com/vertex-ai/docs">
|
||||
Complete Vertex AI documentation
|
||||
</Card>
|
||||
|
||||
<Card title="Service Accounts" icon="key" href="https://cloud.google.com/iam/docs/service-accounts">
|
||||
Service account best practices
|
||||
</Card>
|
||||
|
||||
<Card title="Model Guide" icon="brain" href="https://cloud.google.com/vertex-ai/docs/generative-ai/learn/models">
|
||||
Available models and features
|
||||
</Card>
|
||||
|
||||
<Card title="Pricing" icon="dollar-sign" href="https://cloud.google.com/vertex-ai/pricing">
|
||||
Vertex AI pricing details
|
||||
</Card>
|
||||
</CardGroup>
|
||||
-215
@@ -1,215 +0,0 @@
|
||||
---
|
||||
title: "LiteLLM Configuration"
|
||||
sidebarTitle: "LiteLLM"
|
||||
description: "Configure LiteLLM proxy for your Cline deployment"
|
||||
---
|
||||
|
||||
<Info>
|
||||
**Configuration Path: Self-Hosted**
|
||||
|
||||
This guide covers LiteLLM configuration for self-hosted deployments. For web-based setup, see [LiteLLM SaaS Configuration](/enterprise-solutions/configuration/remote-configuration/litellm/admin-configuration).
|
||||
</Info>
|
||||
|
||||
Configure Cline to use an existing LiteLLM proxy for unified access to multiple AI models through a single API endpoint.
|
||||
|
||||
## What is LiteLLM?
|
||||
|
||||
[LiteLLM](https://github.com/BerriAI/litellm) is an open-source proxy that provides a unified OpenAI-compatible API for accessing 100+ AI models from different providers. Cline connects to your deployed LiteLLM instance.
|
||||
|
||||
<Note>
|
||||
LiteLLM is a separate service you deploy and manage. This guide covers how to configure Cline to connect to an existing LiteLLM deployment.
|
||||
</Note>
|
||||
|
||||
## Configuration Format
|
||||
|
||||
Configure LiteLLM through your remote configuration JSON using the `providerSettings.OpenAiCompatible` section:
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://litellm.yourcompany.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration Fields
|
||||
|
||||
| Field | Type | Description | Required |
|
||||
|-------|------|-------------|----------|
|
||||
| `models` | Array | List of model configurations | Yes |
|
||||
| `openAiBaseUrl` | String | LiteLLM proxy endpoint URL | Yes |
|
||||
| `openAiApiKey` | String | API key for authentication | No |
|
||||
|
||||
### Model Configuration
|
||||
|
||||
Each model in the `models` array requires:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo",
|
||||
"info": {
|
||||
"maxTokens": 4096,
|
||||
"contextWindow": 128000,
|
||||
"supportsImages": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<Note>
|
||||
Model IDs must match the model names configured in your LiteLLM proxy deployment.
|
||||
</Note>
|
||||
|
||||
## Example Configurations
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://litellm.company.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### With Authentication
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://litellm.company.com/v1",
|
||||
"openAiApiKey": "sk-your-litellm-key"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Multiple Models
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
},
|
||||
{
|
||||
"id": "claude-3-5-sonnet",
|
||||
"name": "Claude 3.5 Sonnet"
|
||||
},
|
||||
{
|
||||
"id": "gemini-pro",
|
||||
"name": "Gemini Pro"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "https://litellm.company.com/v1",
|
||||
"openAiApiKey": "sk-your-litellm-key"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Internal Network (No Auth)
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"OpenAiCompatible": {
|
||||
"models": [
|
||||
{
|
||||
"id": "gpt-4-turbo",
|
||||
"name": "GPT-4 Turbo"
|
||||
}
|
||||
],
|
||||
"openAiBaseUrl": "http://litellm.internal:4000/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before configuring Cline to use LiteLLM, you need:
|
||||
|
||||
1. **LiteLLM Proxy** deployed and accessible
|
||||
2. **LiteLLM Configuration** with desired models enabled
|
||||
3. **API Key** (if authentication is enabled)
|
||||
4. **Network Access** from where Cline is being used
|
||||
|
||||
<Tip>
|
||||
For LiteLLM deployment and configuration, see the [LiteLLM documentation](https://docs.litellm.ai/docs/proxy/quick_start).
|
||||
</Tip>
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Connection Errors**
|
||||
|
||||
Verify the LiteLLM proxy is running and accessible:
|
||||
```bash
|
||||
curl https://litellm.yourcompany.com/health
|
||||
```
|
||||
|
||||
**Authentication Errors**
|
||||
|
||||
Check your API key is valid:
|
||||
```bash
|
||||
curl -H "Authorization: Bearer sk-your-key" \
|
||||
https://litellm.yourcompany.com/v1/models
|
||||
```
|
||||
|
||||
**Model Not Found**
|
||||
|
||||
Verify the model is configured in your LiteLLM deployment. Model IDs in Cline's config must match the model names in LiteLLM's configuration.
|
||||
|
||||
## Benefits of Using LiteLLM
|
||||
|
||||
- **Multi-Provider Access**: Connect to multiple AI providers through one endpoint
|
||||
- **Load Balancing**: Distribute requests across providers automatically
|
||||
- **Fallback Support**: Automatic retry with different models on failure
|
||||
- **Cost Tracking**: Monitor usage and costs across all models
|
||||
- **Rate Limiting**: Control usage at the proxy level
|
||||
|
||||
## Related Resources
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="LiteLLM Docs" icon="book" href="https://docs.litellm.ai/">
|
||||
Complete LiteLLM documentation
|
||||
</Card>
|
||||
|
||||
<Card title="LiteLLM GitHub" icon="github" href="https://github.com/BerriAI/litellm">
|
||||
Source code and deployment examples
|
||||
</Card>
|
||||
|
||||
<Card title="Proxy Setup" icon="server" href="https://docs.litellm.ai/docs/proxy/quick_start">
|
||||
LiteLLM proxy deployment guide
|
||||
</Card>
|
||||
|
||||
<Card title="Supported Providers" icon="list" href="https://docs.litellm.ai/docs/providers">
|
||||
List of supported AI providers
|
||||
</Card>
|
||||
</CardGroup>
|
||||
-144
@@ -1,144 +0,0 @@
|
||||
---
|
||||
title: "AI Provider Configuration"
|
||||
sidebarTitle: "Overview"
|
||||
description: "Configure AI provider settings for your Cline deployment"
|
||||
---
|
||||
|
||||
<Info>
|
||||
**Configuration Path: Self-Hosted**
|
||||
|
||||
This section covers provider configuration for self-hosted deployments. For web-based configuration through app.cline.bot, see [SaaS Provider Configuration](/enterprise-solutions/configuration/remote-configuration/overview).
|
||||
</Info>
|
||||
|
||||
Configure which AI providers your team can use and manage provider credentials centrally. Cline supports major AI providers with enterprise-grade authentication options.
|
||||
|
||||
## Supported Providers
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
|
||||
Amazon's managed service for Claude and other foundation models
|
||||
</Card>
|
||||
|
||||
<Card title="Google Vertex AI" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
|
||||
Google Cloud's AI platform with Gemini and PaLM models
|
||||
</Card>
|
||||
|
||||
<Card title="LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
|
||||
Universal proxy for accessing 100+ AI models through a unified API
|
||||
</Card>
|
||||
|
||||
<Card title="Custom Providers" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
|
||||
OpenAI-compatible APIs and self-hosted models
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## What is Provider Configuration?
|
||||
|
||||
Provider configuration in Cline allows administrators to:
|
||||
|
||||
1. **Manage Credentials Centrally**: Store API keys and authentication details in one place
|
||||
2. **Control Model Access**: Specify which models teams can use
|
||||
3. **Enforce Provider Usage**: Direct all team members to approved providers
|
||||
|
||||
## How It Works
|
||||
|
||||
Provider settings are configured through your remote configuration JSON file:
|
||||
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"provider": "bedrock",
|
||||
"bedrockRegion": "us-east-1",
|
||||
"bedrockServiceRole": "arn:aws:iam::..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When configured, these settings:
|
||||
- Apply to all team members automatically
|
||||
- Override individual user settings
|
||||
- Ensure consistent provider usage across the team
|
||||
|
||||
## Configuration Options
|
||||
|
||||
### Provider Selection
|
||||
|
||||
Choose from supported providers:
|
||||
- **bedrock**: Use AWS Bedrock
|
||||
- **vertex**: Use Google Vertex AI
|
||||
- **openai**: Use OpenAI API
|
||||
- **azure**: Use Azure OpenAI
|
||||
- **litellm**: Use a LiteLLM proxy
|
||||
|
||||
### Authentication
|
||||
|
||||
Each provider supports different authentication methods:
|
||||
|
||||
**AWS Bedrock:**
|
||||
- IAM roles with cross-account access
|
||||
- Access keys (not recommended for production)
|
||||
|
||||
**Google Vertex AI:**
|
||||
- Service account JSON keys
|
||||
- Workload Identity (for GKE deployments)
|
||||
|
||||
**OpenAI/Azure:**
|
||||
- API keys
|
||||
|
||||
**LiteLLM:**
|
||||
- Endpoint URL + API key
|
||||
|
||||
## Example Configurations
|
||||
|
||||
### AWS Bedrock with IAM Role
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"provider": "bedrock",
|
||||
"bedrockRegion": "us-east-1",
|
||||
"bedrockServiceRole": "arn:aws:iam::123456789012:role/ClineBedrockRole"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Google Vertex AI
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"provider": "vertex",
|
||||
"vertexProject": "my-project-id",
|
||||
"vertexRegion": "us-central1"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### LiteLLM Proxy
|
||||
```json
|
||||
{
|
||||
"providerSettings": {
|
||||
"provider": "litellm",
|
||||
"litellmBaseUrl": "https://litellm.company.com",
|
||||
"litellmApiKey": "sk-..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Configure AWS Bedrock" icon="aws" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/aws-bedrock">
|
||||
Set up AWS Bedrock integration
|
||||
</Card>
|
||||
|
||||
<Card title="Configure Google Vertex" icon="google" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/google-vertex">
|
||||
Set up Google Vertex AI integration
|
||||
</Card>
|
||||
|
||||
<Card title="Configure LiteLLM" icon="zap" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/litellm">
|
||||
Set up LiteLLM proxy integration
|
||||
</Card>
|
||||
|
||||
<Card title="Configure Custom Provider" icon="plug" href="/enterprise-solutions/configuration/infrastructure-configuration/providers/custom">
|
||||
Set up custom OpenAI-compatible provider
|
||||
</Card>
|
||||
</CardGroup>
|
||||
@@ -1,239 +0,0 @@
|
||||
---
|
||||
title: "Rules"
|
||||
sidebarTitle: "Rules"
|
||||
description: "Custom instruction files that guide Cline's behavior in your enterprise deployment"
|
||||
---
|
||||
|
||||
Rules are custom instruction files that provide Cline with guidelines about your coding preferences, standards, and best practices. These instructions get added to Cline's context when working on tasks.
|
||||
|
||||
## What are Rules?
|
||||
|
||||
Rules are simple markdown files stored in a `.clinerules/` directory that contain your team's conventions, preferences, and guidelines. They help Cline understand your:
|
||||
|
||||
- Coding style and conventions
|
||||
- Preferred libraries and frameworks
|
||||
- Architectural patterns
|
||||
- Testing strategies
|
||||
- Documentation standards
|
||||
- Communication preferences
|
||||
|
||||
<Tip>
|
||||
Rules are just `.md` files - no complex configuration needed!
|
||||
</Tip>
|
||||
|
||||
## Quick Example
|
||||
|
||||
Here's a simple rule file that guides TypeScript development:
|
||||
|
||||
```markdown
|
||||
# TypeScript Conventions
|
||||
|
||||
## Code Style
|
||||
- Use 2-space indentation
|
||||
- Prefer `const` over `let`
|
||||
- Always use explicit return types for functions
|
||||
- Use named exports instead of default exports
|
||||
|
||||
## Testing
|
||||
- Write unit tests for all utility functions
|
||||
- Use Vitest as the testing framework
|
||||
- Aim for 80%+ code coverage
|
||||
|
||||
## Dependencies
|
||||
- Prefer native TypeScript features over external libraries
|
||||
- Use Zod for runtime type validation
|
||||
- Use date-fns for date manipulation
|
||||
```
|
||||
|
||||
## Creating Rules
|
||||
|
||||
<Tabs>
|
||||
<Tab title="Using /newrule Command">
|
||||
The easiest way to create a rule is with the `/newrule` command:
|
||||
|
||||
1. During a conversation with Cline, type `/newrule`
|
||||
2. Cline will analyze your conversation and preferences
|
||||
3. It creates an appropriately named `.md` file in `.clinerules/`
|
||||
|
||||
**Example:**
|
||||
```
|
||||
/newrule
|
||||
|
||||
Based on our conversation, create a rule for React component structure
|
||||
```
|
||||
</Tab>
|
||||
|
||||
<Tab title="Manual Creation">
|
||||
You can also create rule files manually:
|
||||
|
||||
1. Create a `.clinerules/` directory in your repository root
|
||||
2. Add markdown files with your guidelines
|
||||
3. Use descriptive names like `react-patterns.md` or `api-conventions.md`
|
||||
|
||||
**File structure:**
|
||||
```
|
||||
your-repo/
|
||||
├── .clinerules/
|
||||
│ ├── typescript-style.md
|
||||
│ ├── testing-standards.md
|
||||
│ └── code-review-checklist.md
|
||||
└── src/
|
||||
```
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Global vs Workspace Rules
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Workspace Rules" icon="folder">
|
||||
**Location:** `.clinerules/` in your repository
|
||||
|
||||
**Scope:** Specific to that project
|
||||
|
||||
**Use for:** Project-specific conventions and patterns
|
||||
</Card>
|
||||
|
||||
<Card title="Global Rules" icon="globe">
|
||||
**Location:** `Documents/Cline/` directory
|
||||
|
||||
**Scope:** All your projects
|
||||
|
||||
**Use for:** Personal preferences that apply everywhere
|
||||
</Card>
|
||||
</CardGroup>
|
||||
|
||||
## Managing Rules
|
||||
|
||||
### Toggling Rules
|
||||
|
||||
You can enable or disable individual rule files:
|
||||
|
||||
1. Click the rules icon in Cline's interface
|
||||
2. Toggle rules on/off as needed
|
||||
3. Changes apply immediately to new tasks
|
||||
|
||||
<Note>
|
||||
Disabling a rule removes it from Cline's context, but keeps the file intact. You can re-enable it anytime.
|
||||
</Note>
|
||||
|
||||
### Enterprise Remote Rules
|
||||
|
||||
<Info>
|
||||
Enterprise deployments can configure **remote global rules** that apply to all team members. These are managed through your infrastructure configuration and cannot be toggled off by individual developers.
|
||||
|
||||
See [Self-Hosted Configuration](/enterprise-solutions/configuration/infrastructure-configuration/overview) for details on remote rules.
|
||||
</Info>
|
||||
|
||||
## Compatible Formats
|
||||
|
||||
Cline also respects rules from other AI coding tools:
|
||||
|
||||
| File/Directory | Tool | Location |
|
||||
|----------------|------|----------|
|
||||
| `.cursorrules` | Cursor | Workspace root (single file) |
|
||||
| `.cursor/rules/` | Cursor | Workspace directory (`.mdc` files) |
|
||||
| `.windsurfrules` | Windsurf | Workspace root (single file) |
|
||||
| `AGENTS.md` | Various | Workspace root + recursive search |
|
||||
|
||||
<Note>
|
||||
**AGENTS.md behavior:** Cline only searches for nested `AGENTS.md` files recursively if a top-level `AGENTS.md` exists in your workspace root. If found, all `AGENTS.md` files are combined with their relative paths as headers.
|
||||
</Note>
|
||||
|
||||
These files work the same way as `.clinerules/` files and can be toggled on/off independently.
|
||||
|
||||
## Best Practices
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Keep Rules Focused" icon="bullseye">
|
||||
Each rule file should focus on one topic:
|
||||
- ✅ `typescript-conventions.md`
|
||||
- ✅ `react-component-structure.md`
|
||||
- ❌ `everything-about-our-codebase.md`
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Be Specific, Not Generic" icon="crosshairs">
|
||||
Base rules on actual team preferences, not assumptions:
|
||||
- ✅ "We use React Query for server state management"
|
||||
- ❌ "Use best practices for state management"
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Update Rules as Projects Evolve" icon="rotate">
|
||||
Review and update rules periodically:
|
||||
- When adopting new technologies
|
||||
- After major architectural changes
|
||||
- When team conventions evolve
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Don't Overdo It" icon="gauge-simple-high">
|
||||
Too many rules can overwhelm Cline's context:
|
||||
- Start with 3-5 essential rules
|
||||
- Add more only when truly needed
|
||||
- Remove outdated rules promptly
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Example Rule Files
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="API Design Standards" icon="code">
|
||||
```markdown
|
||||
# API Design Standards
|
||||
|
||||
## REST Conventions
|
||||
- Use plural nouns for endpoints (`/users`, not `/user`)
|
||||
- Use HTTP methods semantically (GET, POST, PUT, DELETE)
|
||||
- Return appropriate status codes
|
||||
|
||||
## Response Format
|
||||
\`\`\`typescript
|
||||
{
|
||||
data: T,
|
||||
error?: string,
|
||||
metadata?: {
|
||||
page: number,
|
||||
total: number
|
||||
}
|
||||
}
|
||||
\`\`\`
|
||||
|
||||
## Error Handling
|
||||
- Always return error messages in `error` field
|
||||
- Use 4xx for client errors, 5xx for server errors
|
||||
- Include request ID in error responses
|
||||
```
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Testing Requirements" icon="vial">
|
||||
```markdown
|
||||
# Testing Requirements
|
||||
|
||||
## Test Organization
|
||||
- Place tests next to source files (`Button.test.tsx`)
|
||||
- Use `describe` blocks to group related tests
|
||||
- Write descriptive test names
|
||||
|
||||
## Coverage Requirements
|
||||
- Unit tests for all utility functions
|
||||
- Integration tests for API endpoints
|
||||
- E2E tests for critical user flows
|
||||
- Minimum 80% coverage for new code
|
||||
|
||||
## Mocking Strategy
|
||||
- Mock external API calls
|
||||
- Use test fixtures for complex data
|
||||
- Prefer dependency injection for testability
|
||||
```
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Next Steps
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Workflows" icon="diagram-project" href="/enterprise-solutions/configuration/infrastructure-configuration/workflows">
|
||||
Combine rules with automated workflows
|
||||
</Card>
|
||||
|
||||
<Card title="Remote Configuration" icon="cloud" href="/enterprise-solutions/configuration/remote-configuration/overview">
|
||||
Deploy global rules for your team
|
||||
</Card>
|
||||
</CardGroup>
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user