* fix(cli): reject schedule and history options that do nothing
Several options were accepted and saved, but nothing ever read them, so
scripts that used them succeeded and silently did nothing:
- `cline schedule create|update --autonomous`, `--no-autonomous`,
`--idle-timeout` and `--poll-interval` wrote `metadata.autonomous`.
Its only reader was the scheduler package, removed in 7a042fe25.
- `--delivery-channel` wrote `metadata.delivery.channelId`, which no
connector reads. Chat-created schedules and `/whereami` stop writing
and showing it too.
- `cline history --page` has been hidden and ignored.
These options are removed, so they now fail with "unknown option".
A delivery is also rejected when it can never be delivered. Connectors
post a scheduled result only to a chat they can find from the thread,
so `--delivery-adapter` or `--delivery-bot` without a thread was saved
and then never posted. `create` and `update` now fail unless the
delivery, after merging with the schedule's existing one, has a thread
and an adapter. `create` checks before starting the hub.
`schedule import` no longer passes its file through the delivery flag
merge; it never registered those flags, so the merge only copied the
file's metadata.
Schedules saved with the old keys still load: nothing reads them, and
`update` keeps metadata it doesn't recognise.
* fix(cli): check schedule deliveries set with --metadata-json
mergeScheduleMetadata checked the delivery only when a delivery flag was
set, so create --metadata-json '{"delivery":{"adapter":"telegram"}}'
saved a delivery with no thread, which no connector ever posts. It now
takes the stored metadata, the --metadata-json object and the flags
separately, and checks the delivery whenever the JSON or the flags set
it. An update that changes neither keeps a stored delivery as it is,
so editing other metadata on an old schedule still works, and
"delivery": null removes the delivery.
* refactor(cli): check every schedule delivery input in one place
A schedule's delivery can come from the stored schedule, from
--metadata-json or an import file's metadata, and from the delivery
flags. Each path checked it differently, and import didn't check it.
connectors/schedule-delivery.ts states what the connectors read from
metadata.delivery and checks a delivery once, returning issues that name
an abstract field (adapter, threadId, ...). It also rejects an adapter
that is not a connector in the catalog, which no connector would post.
commands/schedule/delivery-input.ts merges the three inputs in order of
precedence and remembers which input set each key, so every issue is
reported as the flag or JSON path the user would change:
"--metadata-json delivery.threadId", "<file> metadata.delivery.adapter"
or "--delivery-thread <id>". All issues are reported together. One
table defines the delivery flags, their keys and their names in
messages.
A delivery that only the stored schedule sets is still kept unchecked,
and "delivery": null still removes it.
---------
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
Drop the fixed max width on the composer's model picker so long model
names show in full when the settings row has room, truncating only when
it runs out. Keep the settings row on one line instead of wrapping,
reserve room for the model and thinking controls so a long branch name
can't squeeze the model name out, and give the conversation layout a
shrinkable grid column so the composer row truncates instead of being
clipped at narrow widths.
Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>
get_git_branch only needs the current branch, but it ran listGitBranches,
which also executes git for-each-ref. Over an SSH environment each command is
its own ssh login, so the 5s branch label poll opened two fresh SSH sessions
every 5 seconds against the remote host for as long as it was connected.
Run only git branch --show-current for the label, and poll it every 30s for
SSH environments (5s stays for local). Branch switches made through the picker
still refresh immediately, as do focus and visibility changes.
Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>
* fix(desktop): stop UPX-packing the Linux SSH remote helpers
Since the Bun 1.4.2 upgrade (#14631) the compiled helper lazily reads its
embedded module payload back from its own executable at runtime. On a
UPX-packed binary those reads return NUL padding, so the helper starts but
every --remote-hub-ensure fails with "SyntaxError: Invalid character:
'\0'" and SSH remotes cannot start (desktop 0.0.38 through 0.0.44).
Ship the helpers uncompressed again and drop the upx installs from the
publish workflow. Bundles grow by roughly 175 MB until the CLI-managed Hub
replaces the helper binary.
Fixes#14815Fixes#14781
Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>
* ci(desktop): smoke-test the bundled SSH remote helper before publishing
Run each Linux job's native remote helper through --remote-hub-ensure and
--remote-hub-stop against an isolated CLINE_DIR and discovery record. The
UPX regression started the helper fine but failed on exactly this path,
and nothing in the publish workflow exercised it.
Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>
---------
Co-authored-by: Saoud Rizwan <saoudrizwan@users.noreply.github.com>
* fix(vscode): stop labelling every HTTP 401-428 as an auth failure
ClineError.getErrorType treated any status in 401-428 as
ClineErrorType.Auth, so a 404 from an OpenAI-compatible server with a
stale model id, or from Gemini for a retired model, was shown as an
authentication problem: for the cline provider the webview replaced the
real message with the logged-out card or "(Click Retry below)".
Only 401/403/407 are Auth now. 402 maps to Balance, 404/405/410 to a new
NotFound class, and other 4xx fall through to the generic row, which
shows the real status and message. The axios ERR_BAD_REQUEST code (set
on every 4xx) only stands in for an auth failure when no status is
available. ErrorRow adds model-id/base-URL guidance to a status-based
NotFound, and the host's text-matched model-not-found rewrite shares the
same guidance text so a message is never told twice.
* fix(vscode): keep 407 off the auth row and pin message-based detection
A 407 is the proxy rejecting credentials, not the provider, so the
sign-in card would point at the wrong account; it now stays on the
generic row, matching the SDK classifier's 401/403. Also pin that a
status outside the dedicated sets still reaches the wording checks:
Gemini answers an invalid key with a 400 and only the message says so.
* fix: stop child-stdin EPIPE and the SAP SDK's winston handler from killing the host process
Two stacked bugs made cline-core exit with code 1 about 3s after a hook
(or MCP server) exited before draining its stdin:
- HookProcess and the SDK stdio MCP client wrote to a child's stdin with
no "error" listener. When the child dies while part of the write is
still queued (input larger than the pipe buffer), Node fails it
asynchronously with EPIPE and, unhandled, raises it as an uncaught
exception on the host process. Both writers now absorb the error and
let the existing exit handling report how the child ended.
- @sap-cloud-sdk/util (a dependency of the SAP AI Core provider) builds a
winston logger with exceptionHandlers at module load, installing a
process-wide uncaughtException listener that calls process.exit(1)
three seconds later -- overriding cline-core's own "log but survive"
handler. @jerome-benoit/sap-ai-provider bundles a second private copy
of that module, so disableExceptionLogger() cannot reach it; the
community vendor module now strips winston's process catchers by name
after the import and again after building the provider.
Regression tests cover both halves: a hook and an MCP server that exit
mid-write must fail the single operation without an uncaught exception,
and importing the community module must leave no winston catcher on the
process.
* fix(hooks): explain an undelivered input in hook failure messages
Review follow-up: the stdin "error" listener only logged. It still must
not settle the run -- a hook may legitimately ignore its input and exit
0, and the shell wrapper keeps the pipe open while the script lives, so
"close" stays the single source of truth -- but the failure is now
recorded and appended to the timeout / non-zero-exit errors so a hook
that never read its input is diagnosable from the error alone. Adds a
test that a hook ignoring a large input and exiting 0 still succeeds.
* test: type the uncaughtException probes so apps/vscode check-types passes
bun-types merges extra process listener overloads into `process`, which
made `process.off("uncaughtException", ...)` fail overload resolution
under the apps/vscode tsconfig (and with it the e2e package step). Type
the probe listeners and remove them through the plain EventEmitter type.
* fix(mcp): report the server's exit, not the broken pipe, when it dies mid-write
Review follow-up: the stdin "error" listener failed every pending request
with the EPIPE message, and it fires before "exit", so the exit handler
(which carries the exit code and stderr) never got to report. It now only
records the failure; the exit and request-timeout errors append a note
that the server stopped reading its input. The test server crashes with
exit code 3 and the test asserts the exit is what gets reported.
Also drops the changeset: changesets are no longer used in this repo.
* fix(mcp): kill a server whose stdin write failed instead of waiting out the timeout
A stdin write only fails once nothing holds the pipe's read end, so the
connection is dead either way. Killing the child lets the "exit" handler
fail pending requests immediately. A server that already exited keeps
its real exit status (the kill is a no-op); one that closed stdin but
stayed alive no longer stalls the request for the full timeout.
* fix: strip only the SAP SDK's own process catchers; give a dying MCP server its graceful window
Review follow-ups:
- community.ts removed every winston `uncaughtException`/`unhandledRejection`
listener by name, which would also take out an embedding host's own
winston exception handlers. The SAP provider is now imported lazily
(literal specifier, so bundlers still include it) inside the same
snapshot-and-diff wrapper the opencode provider already uses, so only
the listeners that import and construction added are removed. The
hygiene test installs a host listener with winston's name and asserts
it survives.
- The MCP client killed the server as soon as a stdin write failed, so a
server that closed stdin and was about to exit with its own code was
reported as SIGTERM instead. The kill now waits the existing graceful
shutdown window (250ms) and is skipped if the server exits first; a
test covers a server that exits 7 shortly after closing stdin.
* test(mcp): keep the stays-alive fixture alive and assert the client killed it
Number("") is 0, so with FAKE_MCP_EXIT_AFTER_CLOSE_MS unset the fixture
exited with code 7 at once and the stays-alive test passed without
exercising the kill. Use Number(undefined) (NaN) for the unset case and
require signal=SIGTERM so a fixture that exits on its own fails the test.
* fix(mcp): bound request failure and shutdown when a server outlives a failed stdin write
Sending a single SIGTERM and waiting for "exit" left a server that handles
SIGTERM alive, with the pending request stalled until its normal timeout.
If the server is still the current child when the graceful window ends,
the pending requests now fail with the stdin-failure message and the child
goes through disconnect()'s SIGTERM -> SIGKILL escalation. A server that
exits within the window is still reported by its own exit code.
Tests cover a stdin-closing server that honors and one that ignores
SIGTERM: the request fails within seconds and the process is gone.
* fix(llms): remove only the exit handlers the SAP import registers
The previous wrapper diffed process listeners across the async import and
construction, so it also removed host listeners registered in that
window (e.g. the CLI's abort-time unhandledRejection swap), and it had no
finally, so a rejected first construction left winston's handlers armed.
The SAP provider now loads through a small helper that attributes
"uncaughtException" registrations to the import by async context
(AsyncLocalStorage + a temporary "newListener" listener) and removes
exactly those in a finally. Construction runs after cleanup.
unhandledRejection is no longer touched: SAP never registers one.
On Bun, async context does not reach module evaluation, so nothing is
attributed; the Bun-run CLI and hub already treat uncaught exceptions as
fatal. The opencode signal-handler helper is back to exactly main's.
Tests run in fresh processes (one per file) and prove the SAP import
armed a handler: host listeners registered after loading starts survive
and SAP's are removed, on both a successful and a rejected first
construction.
The legacy migration treated a defined sapAiCoreUseOrchestrationMode as
evidence that SAP AI Core was configured. The extension writes that flag
as a default for every user, so every migrated providers.json gained a
phantom "sapaicore" entry with no credentials. Candidate collection now
relies on the SAP-specific fields only.
* docs: match the CLI reference to CLI 3.0.68
The CLI reference and the pages that repeat it had drifted from the CLI.
They named a `dev` command that no longer exists, swapped the --config
and --data-dir defaults, described `connect` as an IDE adapter, said
--thinking defaults to medium, and showed a JSON output shape (say/ask
messages) that the CLI never prints. The documented `jq -r .text`
example prints only nulls.
Replace the pasted help with the 3.0.68 output and document what it
lists: --compaction, --worktree, --update, --kanban, `skill`,
`dashboard`, the `auth` options, `config <target>`, `connect --stop`
and `--restart`, `mcp add`/`remove`, the `history` subcommands and
options, and the `hub` subcommands including `drain` and `upgrade`.
Rewrite the JSON section around the agent_event and run_result lines,
with a jq filter that prints the final answer. Note that -k also saves
the key, drop the `-i` image example (-i opens the TUI), and use the
Cline provider's model id in the API auth example.
Co-authored-by: Harshil Mistry <125483347+harshil-mistry@users.noreply.github.com>
Co-authored-by: MarMar Labs <marmar9615@icloud.com>
* docs: correct CLI defaults and JSON notes from review
--retries defaults to 3, not the 6 that `cline --help` prints; note the
discrepancy under the pasted help. Without --thinking, Cline uses the
reasoning level saved from the TUI before the provider's default. Drop
--page, which the CLI accepts but ignores. Say that a --timeout stops
the run without a run_aborted line, and that scripts should skip line
types they don't use.
Use Claude Sonnet 5.5 in the auth examples, and say "in your terminal"
where the pages described commands that need one.
* fix(cli): make --help match what the CLI does
`cline --help` said --retries defaults to 6, but runs use 3. The help
now reads the same CLI_DEFAULT_MAX_CONSECUTIVE_MISTAKES constant that
main.ts passes to the session, and a test ties the two together.
--thinking now says that, without the flag, the CLI uses the level
saved in the TUI before the provider default. -k says the key is also
saved as the provider's key. `history --page` is hidden from help: the
CLI never reads it, but it stays accepted so existing scripts keep
working.
The CLI reference shows the corrected help and no longer notes the
wrong --retries default. The CLI README's -k and --thinking rows match.
* fix(cli): name /model in the --thinking help
Readers don't know what "the TUI" is. The level --thinking falls back to
is the one chosen in the model picker, which users open with /model, so
the help, the CLI reference, the overview and the README now say that.
* fix(cli): warn that cline history --page is ignored
cline history lists the newest sessions up to --limit and has never
read --page. The option stays accepted so existing scripts keep
working, but it now prints a deprecation notice to stderr. The
terminal tests that expected --page in help, or ran it as if it
selected a page, are removed.
* fix(cli): say hub upgrade does not wait for --zen tasks
cline hub upgrade waits only until no client is attached. A --zen run
detaches once the hub accepts it, and scheduled runs never attach, so
the upgrade can stop both mid-run. The help text and the hub command
lists in the docs now say so.
* docs: drop dashboard from the root help listing
cline --help no longer lists dashboard; it is cline hub dashboard.
* fix(cli): require a count for --retries; fix connect --restart example
--retries was declared with an optional value, so a bare --retries set
it to true and the CLI crashed calling .trim() on it. The option now
requires a count, and a bare --retries fails with commander's
"argument missing" error.
cline connect passes options after the channel to the channel's
connector, so "cline connect telegram --restart" never reached
connect. The examples now put --stop and --restart before the
channel, and the reference says why.
* docs: scope the JSON line format to agent runs
The JSON section read as the format of every --json, but only agent
runs print typed lines. cline history --json prints one array, and
each cline config target prints its own shape. The heading and both
pages now say the line format is for tasks, and name the others.
---------
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
Co-authored-by: Harshil Mistry <125483347+harshil-mistry@users.noreply.github.com>
Co-authored-by: MarMar Labs <marmar9615@icloud.com>
* fix(cli): keep --header values when cline mcp add opens the wizard
Without --yes, cline mcp add opens the add wizard with the name,
transport and URL filled in, but dropped every --header value. A user
who accepted the prefilled answers saved a remote server without its
Authorization header.
The wizard now selects "Static headers" and fills in the header field.
If the user leaves that field unchanged, the headers are saved exactly
as given on the command line, including values that contain commas,
which the comma-separated field cannot represent.
* fix(cli): parse wizard headers the way --yes does
The add wizard read every header from one comma-separated field and
split it with its own rules: it split on commas, dropped malformed
headers without a word, and accepted names and empty values that
cline mcp add --yes rejects. Its earlier fix kept unedited prefilled
headers by comparing text, so one edit sent them all back through the
comma split.
The wizard now asks for one header per prompt, prefilled from
--header, and checks each with parseMcpHeaders, the parser --yes uses.
A malformed header is rejected at the prompt with the --yes error
message, and placeholder warnings appear in both paths.
The test restores CLINE_MCP_SETTINGS_PATH with vi.unstubAllEnvs, so
an unset variable is removed instead of being set to "undefined".
* fix(cli): warn about placeholder headers before their wizard prompt
The add wizard warned about a placeholder header such as
"Bearer <token>" only after every header had been entered, too late to
fix it there. It now warns just before the prompt that shows a
prefilled placeholder, and again only if the user types a new one.
Clearing a prefilled header now drops that header alone. Before, an
empty answer ended the list, so clearing the first of two prefilled
headers also dropped the second.
---------
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
`ai` had stayed at 7.0.79 while single `@ai-sdk/*` packages were bumped on
their own. Each such bump brought its own `@ai-sdk/provider` /
`provider-utils`, whose types no longer unify with the ones `ai` pins, so
the hand-off to `ai` needed casts. Bumping `@ai-sdk/openai` alone for #14649
would have added two more.
Move `ai` and every `@ai-sdk/*` package to the releases built on
`@ai-sdk/provider-utils` 5.0.50 (all published 2026-09-28): ai 7.0.120,
gateway 4.0.98, anthropic 4.0.67, google 4.0.84, google-vertex 5.0.97,
mistral 4.0.53, openai 4.0.79, openai-compatible 3.0.58, otel 1.0.120,
react 4.0.123, provider 4.0.19. Bedrock 5.0.98 is already on this line and
stays. One copy of each is left in the lockfile; the only other `ai` is
Langfuse's own nested copy, as before. No casts are added.
This also fixes#14649: `@ai-sdk/openai` 4.0.79 knows which GPT-6 models
can turn reasoning off and drops the setting for the rest, so commit
message generation (which always turns reasoning off) and tasks with
reasoning set to "none" stop getting a 400 from GPT-6 Astra and 6.1 Sol.
GPT-5.x and GPT-6 Sol/Luna still get "none".
It fixes#13203 the same way: `@ai-sdk/anthropic` 4.0.67 leaves
`thinking` out for Claude models that can't turn thinking off (Fable 5,
Opus 5.5) instead of sending `thinking: {type: "disabled"}`, which they
reject. Other Claude models still get `disabled`.
* refactor(cli): scope hub options to their subcommands
* feat(cli): move dashboard under hub and document its usage
---------
Co-authored-by: Cline <cline@users.noreply.github.com>
The CLI logger wrote to CLINE_LOG_PATH when it was set, but cline doctor
built the default path itself, so `cline doctor log` opened the wrong
file and `doctor --verbose`/`--json` read recently spawned processes
from it.
Move the path into resolveCliLogPath() in logging/log-path.ts and call
it from the logger and from both doctor readers. The module is separate
from the logger so cline doctor doesn't load pino.
The config page, the CLI reference, the proxy troubleshooting page and
the CLI README now say that `cline doctor log` opens the CLINE_LOG_PATH
file.
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
* fix(agents): continue unknown AI SDK completions once
* fix(agents): add hidden user continuation after unknown finish
* fix(core): preserve active attachments during hidden continuation compaction
* docs: correct shared paths, log files, commands and tool names
Several pages repeat the same facts about where Cline keeps its files,
which commands exist and what the built-in tools are called, and many of
them no longer match the shipped CLI and SDK:
- Workflows live in ~/.cline/workflows/, not ~/.cline/data/workflows/.
The session index is ~/.cline/data/db/sessions.db, each session has a
folder of JSON files, and hub locks and logs are under ~/.cline/data/.
- cline start and cline dev log do not exist; the log command is
cline doctor log, and the CLI log is ~/.cline/data/logs/cline.log.
- The built-in tools are run_commands, search_codebase,
fetch_web_content and skills, not bash, search, fetch_web and
use_skill.
- CLINE_HUB_ADDRESS is read only by cline schedule; the hub port is
CLINE_HUB_PORT.
- No CLI 3 release reads CLINE_COMMAND_PERMISSIONS. The pages that
offered it, including the PR review sample, now say the CLI has no
command allow list and point to a PreToolUse hook. The unused
permissionDeniedError string in the VS Code prompts goes with it.
Part of #14853.
Co-authored-by: Mikołaj Kondratek <19799111+mkondratek@users.noreply.github.com>
Co-authored-by: Manpreet Kaur <26463231+Manpreet2298@users.noreply.github.com>
Co-authored-by: Renee Huang <100229782+reneehuang1@users.noreply.github.com>
* docs: qualify log, tool routing and command-approval advice
- cline doctor log always opens the default log file, so say so where
CLINE_LOG_PATH is described.
- The editor and apply_patch choice is a default that SDK callers can
replace with toolRoutingRules.
- The PR review sample now warns that hooks and plugins in the checked-out
pull request run with the job's environment, and says how to keep them
from running before relying on a global PreToolUse hook.
- The conditional-approval example no longer auto-approves git diff,
which runs a configured external diff program, and notes that Git can
run programs named in a repository's config.
* docs: run the PR review sample with a read-only token
The sample gave an auto-approved Cline run a token that can write pull
requests. Split it into two jobs: `review` runs Cline with read-only
permissions on a checkout of the base branch and writes review.md;
`post` runs no repository or model code and posts the file with
`gh pr review --comment`.
Skip pull requests from forks and Dependabot, which get no secrets,
and warn against `pull_request_target`. Fence the workflow with four
backticks so the code block inside the prompt no longer ends it early.
---------
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
Co-authored-by: Mikołaj Kondratek <19799111+mkondratek@users.noreply.github.com>
Co-authored-by: Manpreet Kaur <26463231+Manpreet2298@users.noreply.github.com>
Co-authored-by: Renee Huang <100229782+reneehuang1@users.noreply.github.com>
* fix(desktop): let keyless configured providers start sessions
The webview's pre-flight credential gate demanded an API key for every
provider that was not OAuth or local-auth, so a local OpenAI-compatible
endpoint (LM Studio, vLLM, Ollama) migrated from VS Code or added via
Settings failed every turn with "Missing API key" even though the
sidecar already reported it as configured via base URL + model.
Carry the catalog's host-computed `configured` readiness into the chat
config and skip the API-key requirement when the host accepts the
provider, matching the runtime's own keyless handling.
* fix(desktop): gate sessions on the shared apiKeyOptional provider fact
Address review: instead of a desktop-only providerConfigured readiness
flag threaded through the chat config, make the credential requirement
explicit in the shared provider contract.
- @cline/shared: GatewayProviderMetadata.apiKeyOptional, mirrored into
ProviderAuthInfo via resolveProviderApiKeyOptional (same pattern as
localCliCommand -> localCli).
- @cline/llms: declare it on openai-compatible, ollama, lmstudio, litellm,
vertex, and bedrock.
- @cline/core: listLocalProviders carries the fact in ProviderListItem.auth;
user-added endpoints registered from providers.json / models.json declare
it too (their key is already optional in the desktop form).
- desktop: resolveCredentialError consults auth.apiKeyOptional and no
longer needs the extra config field.
* docs: state telemetry defaults and scope accurately
The Enterprise and monitoring pages called Cline telemetry opt-in and
anonymous, and said code never leaves the machine. Telemetry is on by
default in the VS Code and JetBrains extensions, Cline Desktop and the
CLI. It identifies signed-in accounts and organizations, and includes
prompts for requests to the Cline and ClinePass providers.
Rewrite the telemetry page around what is collected and how to turn it
off in each product. Scope the remote-configuration restrictions to the
products that enforce them, add a per-product support table, and tell
admins to ignore the folders Cline writes into workspaces. Align the VS
Code setting description and host-telemetry warning with the docs.
Part of #14853
* docs: drop bold from remote-config support table rows
The bold marked dashboard switch names, but nothing on the page said so,
so the rows looked inconsistent.
* docs: address review of the telemetry and remote-config pages
State only what the telemetry setting enforces in the extensions: the
lock, and that members can't turn telemetry on when the organization
turns it off. Scope the support-table introduction to the controls
marked Yes, since no product enforces YOLO or Kanban. Use recursive
.gitignore patterns and say why: the cached settings can include prompt
storage access keys, and a member may open a subfolder of a repository.
Narrow the indexing card to content: Cline lists file paths to search
them but doesn't index or embed file contents.
* docs: say products support remote-config controls, not enforce them
Organization rules and workflows reach sessions as instructions that a
member can edit, so "enforces" overstated what the CLI does with them.
The section heading already says "support".
---------
Co-authored-by: Dominic Cooney <55120+dominiccooney@users.noreply.github.com>
The 3s default connect budget silently dropped every npx/uvx-launched
MCP server on Windows, where reaching initialize through cmd.exe
routinely takes 3-6s even with a warm cache. The model never saw the
server's tools and nothing was logged. 10s covers those launchers while
the doubled worst case (newline + framed attempts) still clears the 30s
hub session.create deadline with headroom.
* feat(desktop): render Mermaid diagrams in chat
Render model-authored Mermaid fences as interactive SVGs in Desktop without depending on model image-input support.
- extract the strict lazy Mermaid DiagramPlugin into @cline/ui
- keep shared defaults diagram-free and add explicit opt-in controls
- enable copy, download, fullscreen, and pan/zoom in Desktop
- preserve initial bundle size through dynamic Mermaid imports
- cover lazy loading, strict security, failures, and streaming fences
Refs #13568
* test(desktop): harden Mermaid rendering coverage
* test(desktop): stub scrollTo for streamdown 2.6 in Markdown interaction tests
streamdown 2.6 (pulled in by main) scrolls streaming code blocks with element.scrollTo, which jsdom does not implement. Stub it the same way chat-messages.test.tsx and channels-view.test.tsx already do.
* fix(ui): stop Mermaid diagram links from bypassing host link policy
Mermaid's `securityLevel: "strict"` blocks script execution and dangerous URL
schemes, but still renders a `click <node> "https://…"` directive as a live
`<a xlink:href>` anchor inside the SVG. Streamdown injects that SVG with
`dangerouslySetInnerHTML`, so those anchors never pass through the `a`
component a product supplies — bypassing the deceptive-link confirmation and
the external-open routing that ordinary Markdown links go through, with no
rel="noreferrer", and letting a click navigate the desktop webview away from
the app itself.
A diagram label is authored independently of its destination, so these links
are deceptive by construction: the desktop app's own isDeceptiveLink rule
would flag every one of them.
- neutralize rendered diagram links in @cline/ui so they cannot navigate on
their own, preserving an http(s) destination on data-cline-diagram-href
- reattach them in Desktop to the existing confirmation modal, which shows the
real destination before anything opens
- recover the anchor from pointerdown: Streamdown's pan/zoom surface takes
pointer capture, so a real click is retargeted away from the anchor; a press
that moves more than a few pixels is treated as a pan, not a link click
- drop non-http(s) destinations rather than surfacing them, so a renderer
change cannot widen what the app will open
- assert the packed Mermaid control shape instead of a "not false" check that
also accepted undefined or an empty object
Verified against real Mermaid 11.16.1 in a browser: script, event-handler,
iframe, foreignObject and javascript:/data:/vbscript:/file: payloads are all
neutralized by strict mode, and `%%{init}%%` / YAML frontmatter cannot
downgrade securityLevel. The http(s) `click` anchor was the one live escape.
Stacked on #13721, which adds the shared lazy Mermaid plugin this hardens.
Refs #13568
Co-authored-by: yiaany <ilyaantonievich@gmail.com>
Co-authored-by: yiheng-kkk <lij921093@gmail.com>
* feat(ui): theme Mermaid diagrams with the Cline design system
Replace Streamdown's built-in Mermaid block in Desktop with an owned
`@cline/ui` block (`createMermaidRenderer` from
`@cline/ui/components/mermaid-block`):
- Mermaid's `base` theme with variables resolved from the live design tokens
(`--card`, `--foreground`, `--primary`, ...), following light/dark and the
accent palette and re-rendering when either changes; a diagram's own
`%%{init}%%`, frontmatter `config:`, `classDef` and `style` still win
- a filename header from the fence title (```mermaid title="my-diagram"),
frontmatter `title:`, or a name derived from the diagram
- zoom, fullscreen, copy, and PNG / `.mmd` downloads; PNGs are opaque, 2-3x,
capped at 4096px and kept under the image attachment limit
- renders are serialized through one queue, since Mermaid is a process-wide
singleton that is not safe to render concurrently
The owned block injects the SVG itself, so diagram link neutralization moves
into the shared render service and covers both this block and the Streamdown
diagram plugin. Desktop keeps routing diagram link clicks through the existing
confirmation modal.
Refs #13568
* fix(ui): avoid polynomial backtracking in Mermaid helpers
* fix(ui): make diagram label extraction linear-time
Replaces the backtracking label-regexes CodeQL flagged (ReDoS, PR #14757) with single-pass scanners and line-column parsing.
* refactor(ui): share the Mermaid render service and drop dead naming helper
createLazyMermaidPlugin now delegates import/retry/queueing/link-neutralization to createMermaidService instead of duplicating that path, keeping only theme-keyed config. Removes deriveMermaidDiagramName, which had no consumer outside its own tests.
---------
Co-authored-by: harrisonofcline <harrison@cline.bot>
Co-authored-by: yiheng-kkk <lij921093@gmail.com>
* fix: omit refusal fallbacks for custom Anthropic endpoints (#14816)
* fix(llms): gate Anthropic refusal fallback on the official endpoint
Move the endpoint check into an isOfficialAnthropicEndpoint URL helper and
keep it in the rule's build step so custom endpoints retain the generic
fanout suppression. Add an identity test that a custom endpoint changes
nothing but `fallbacks`, plus an HTTP-boundary test through the real
handler that checks the body and the server-side-fallback beta header.
Co-authored-by: Dante <duanjl.china@gmail.com>
---------
Co-authored-by: Dante <duanjl.china@gmail.com>
* refactor(core): select and order session rules in one place
The rules section of a session's system prompt was selected in several
places: `listEnabledRulesFromWatcher` (enabled only, sorted by name) for the
single-workspace plugin, and an inline filter without the sort in the
combined user-instruction service. Callers outside a session that need the
same section had nowhere to reach it and would have grown a third copy.
Add `listEnabledRulesFromRecords` / `loadRulesForSystemPromptFromRecords`
next to the watcher variants, make the watcher variants delegate to them,
and use the records variant in the combined service. Export the loader from
`@cline/core`.
Behavior change: the combined service now orders rules by name like the
single-workspace path does, instead of in listing order.
* fix(vscode): apply the user's rules when generating commit messages
"Generate Commit Message with Cline" built its prompt from a hardcoded
system prompt and never loaded `.clinerules`, so commit conventions users
had written down (language, format, ticket references) were honored in
chat and silently dropped by the button.
`Controller.getRulesForSystemPrompt` takes the enabled rules from the
user-instruction watcher the controller already runs for the workspace,
through core's shared `loadRulesForSystemPromptFromRecords`, and the
commit-message system prompt appends them behind a short preamble telling
the model which rules are relevant to a commit message. The button sees the
rule set a chat session in the workspace sees, including a rule that has
`disabled: true` frontmatter being left out of both. If the rules can't be
read, the base prompt is used.
Known limitation: the Rules panel's on/off toggles live in extension state
the SDK doesn't read, so a rule switched off there is still sent to chat
and to the button alike (CLINE-3120).
The new rules load is one more await before the request; the existing
cancel check before `createMessage` covers it, and a test pins that.
Fixes#9410
* fix(vscode): let Stop end a commit generation still waiting for rules
The first generation in a workspace waits for the user-instruction watcher's
initial scan of rules, skills and workflows. Stop was honored after that
await (no request went out), but the generation and its SCM progress
indicator stayed pending until the scan finished, which can take a while on
a slow filesystem.
Race the rules load against the generation's abort signal so Stop ends the
generation at once. The scan carries on in the background and warms the
watcher chat uses; nothing waits on it any more.
* fix(core): render hub client rules through the shared selection
The hub's client user-instruction proxy filtered and formatted rules inline,
in listing order, while the combined service now goes through the shared
`loadRulesForSystemPromptFromRecords`, which sorts by name. runtime-builder
wraps the client proxy in the combined service when host plugin skills are
present, even though the plugin service contributes no rules, so adding a
host plugin reordered the same client rules in the session prompt.
Render the hub snapshot's rules through the shared helper too. Every path
that builds a session's rules section now selects and orders rules the same
way; hub client sessions now get their rules sorted by name. A boundary test
renders reversed names plus a disabled rule through the proxy alone and
through the combined service, and expects the same output from both.
* docs(mcp): correct the CLI mcp config path
* docs(tools): correct the same stale .cline/mcp.json reference
* docs(cli): correct the MCP config entry in the configuration tree
The CLI reference listed `mcp.json` under the project-root `.cline/` tree,
but `resolveMcpSettingsPath()` only ever resolves a global path:
`~/.cline/data/settings/cline_mcp_settings.json` (overridable via
`CLINE_MCP_SETTINGS_PATH`). There is no project-level MCP config reader.
Move the entry to the `~/.cline/data/settings/` tree where the resolver
actually looks, and drop the project-root entry.
Three in-site links point at anchors that no longer exist, so they load
the target page without jumping anywhere. Verified against the live docs
DOM by counting the rendered heading ids.
* fix(cli): expose yolo mode
Show `-y/--yolo` in CLI help with a clear sandbox warning so unsupervised
benchmark and CI runs can opt in deliberately.
* revert: drop unrelated desktop sidecar hub-reconnect change
* fix(desktop): reconnect chat sessions after Cline Hub loss
Retry session rebuild for up to a minute when the hub transport closes or the session is missing, then end the turn as interrupted so the user can resend. Surface reconnect status in the webview instead of treating it as an error.
* fix(desktop): scope hub-loss recovery to lost sessions
- Probe the hub before rebuilding so a session it still holds is left alone
- Cancel the reconnect loop on stop/abort/reset and undo a racing rebuild
- Recover queued sends too, re-queueing once the session is back
- Show the resend notice as an error-role bubble that history sync keeps
- Recognize missing sessions wrapped as generic hub command failures
* fix(desktop): share hub recovery and preserve session ownership
* fix(desktop): isolate replacement recovery and avoid duplicate queued sends
* fix(desktop): serialize recovery across session replacements
* fix(desktop): bound the entire shared recovery lifecycle
OpenAI-compatible adapters send the AI SDK's top-level reasoning value to
the endpoint unchanged as reasoning_effort, but the gateway resolved that
value from the raw request. The models.dev effort ladder was only applied
when composing provider options, after portable reasoning had already been
split off, so it never reached the wire. Endpoints with a short ladder
were sent levels they reject: Kimi K3 accepts only low, high and max, yet
received medium for the default thinking level and minimal for minimal.
For the openai-compatible and cline adapters, snap the portable level to
the nearest level the model advertises. When that nearest level is max,
which the portable setting cannot carry yet, keep the requested level
instead of lowering it. Adapters with their own per-model effort maps and
models without catalog facts are unchanged.
* Add GitHub Actions workflow to deploy Storybook
* Update path for Storybook deployment
* Update Storybook deployment workflow for dependencies
* Update Storybook build command in workflow
* Update Storybook deployment path and build command
* fix(llms): stop emitting hyphenated providerOptions keys for openai-compatible providers
`@ai-sdk/openai-compatible` 3.0.30 reads `providerOptions[<name>]` and its
camelCase alias, and logs a deprecation warning on every stream chunk when
the hyphenated raw name is present:
DeprecationWarning: AI SDK Warning (openai-compatible.chat / ...):
Deprecated: "providerOptions key 'openai-compatible'". Use
'openaiCompatible' instead.
Cline wrote its thinking, reasoning and prompt-cache patches under the raw
provider id (`openai-compatible`, `vercel-ai-gateway`, user-defined ids) as
well as the camelCase alias, so every chunk of every stream through the
generic provider spammed the warning to stderr.
Providers whose options target is `openai-compatible` now write only the
camelCase bucket. The SDK reads that alias for every provider name, so no
request-body passthrough is lost. Native and community vendor targets
(`openai-codex`, `claude-code`, ...) keep their raw id and alias as before.
* fix: resolve provider options PR review concerns
The lazy `config` wrapper declares its own `--json` option, so Commander
consumes the flag before the remaining arguments are forwarded to the
real config command. `cline config --json` therefore reached the runtime
command without the flag and launched the interactive view, which fails
without a TTY, while `cline --json config` worked because the inner
command also reads the root option. `cline config --json mcp` silently
printed text for the same reason.
Copy the wrapper's parsed value onto the runtime command before parsing
the forwarded arguments, and add a non-TTY e2e check that both flag
placements produce the same JSON inventory.
Co-authored-by: Dante <duanjl.china@gmail.com>
* feat(llms): opt-in Langfuse tracing for BYOK providers plus env tags, metadata and environment
Langfuse tracing was limited to the cline and cline-pass providers, so an
operator pointing LANGFUSE_* credentials at their own instance could not trace
OpenRouter or any other BYOK provider. CLINE_LANGFUSE_ALL_PROVIDERS=1 now opts
third-party providers in. They are exported only through the isolated direct
exporter and never through the host OTLP relay, so BYOK prompts cannot reach a
collector the operator did not configure themselves.
Benchmark and isolated-environment runs can label every trace from the
environment: LANGFUSE_TRACING_ENVIRONMENT sets the Langfuse environment on the
direct exporter, CLINE_LANGFUSE_TAGS adds comma-separated trace tags, and
CLINE_LANGFUSE_METADATA adds trace metadata as a JSON object or key=value
pairs. Env values merge under the runtime's own attributes, and env-only
attributes propagate even when a call supplies none of its own.
* docs(llms): state that Langfuse tracing covers streamed language requests only
Dedicated image generation uses the AI SDK's generateImage, which takes no
telemetry option and has no Langfuse integration hook, so it has never been
traced for any provider. Document that scope in the resolver and the runbook
rather than implying the BYOK opt-in covers it.
* desktop: add Connectors 'What's new' catch-up
* desktop: tighten Suggested combos copy to fit two lines
* desktop: give the Connectors catch-up its own spotlight layout with an Open Connectors CTA
* desktop: move connector logos and pitch into the What's new body, make the example clickable
* desktop: let the What's new dialog scroll in short windows
Saoud Rizwan