mirror of https://github.com/cline/cline.git synced 2026-10-24 23:34:55 +08:00

Files

T

BeeandSaoud Rizwan 83ea9a41d1 refactor: Start the desktop and SSH remote hubs through the bundled Cline CLI (#14792 )

* Let hosts choose the hub daemon launcher and defer spawn-only setup

Adds setHubDaemonLauncher so an embedding process can start the hub
daemon through a bundled Cline CLI instead of its own executable, and a
beforeSpawn hook on ensureDetachedHubServer that only runs when a new
daemon is actually started.

* Add programmatic options to cline hub ensure

hub ensure/start gain --json (URL + auth token), --allow-port-fallback,
--no-connectors and --login-shell-path, and the hub command accepts
--discovery-path for a dedicated discovery record. These let the desktop
app and SSH remotes start or reuse a hub through the CLI.

Also extracts the standalone binary compile step into
script/compile-binary.ts so other packages can build the CLI binary.

* Run SSH remote hubs through the Cline CLI

SSH remotes now upload the Cline CLI binary and start or reuse the remote
hub with 'cline hub ensure --json --discovery-path ...', stopping it with
'cline hub stop'. The dedicated remote helper entrypoint is removed;
cleanup records from older releases still stop through the old flag.

* Run the desktop backend on the bundled Cline CLI

The desktop app no longer compiles its own executable. It bundles the
self-contained Cline CLI (externalBin cline-cli) plus the backend as a JS
bundle that runs on the CLI's embedded runtime. At startup the backend has
the CLI run 'hub ensure', which reuses a compatible healthy Hub or starts
one, and any Hub it starts later also goes through the CLI binary. Linux
CLI copies are bundled for SSH remotes.

* Launch the desktop backend through the bundled Cline CLI

The Tauri shell resolves the bundled cline-cli and the backend bundle
(per-platform resource layouts) and starts 'cline-cli run' on it. The
Windows installer stops users of cline-cli.exe, and also stops and removes
the backend executable of earlier releases on upgrade.

* Recognize the CLI-hosted desktop backend in cline doctor --fix

* Update desktop publish workflow and docs for the bundled Cline CLI

Telemetry selfchecks and smoke tests run the backend bundle on the
bundled CLI, and the Windows signature gate verifies cline-cli.exe.

* fix(desktop): address runtime packaging review findings

* fix(desktop): preserve failed hub cleanup and handle exited daemons

* fix(hub): distinguish missing discovery records from read failures

* fix(hub): preserve discovery recovery while enforcing strict shutdown reads

* fix(cli): do not count hub commands as CLI activations (#14870)

* fix(cli): do not count hub commands as CLI activations

The desktop app runs `cline-cli hub ensure` on every launch and the SSH
remote flow runs `cline hub ensure` on every connect. Both went through
runCli(), which captured user.extension_activated unconditionally, so each
desktop launch was double-counted as a CLI activation and every SSH remote
host (with its own distinct id) showed up as a new CLI user.

Skip the activation capture for the hub subcommand; it is plumbing other
clients invoke, not a user activation. Hub-owned task telemetry is
unaffected since the daemon path never enters runCli().

* test(cli): clear the hub command mock between main.test.ts cases

* test(cli): stop stubbing the hub command module in main.test.ts

The module-wide vi.mock("./commands/hub") replaced createHubCommand with
a no-op, so `cline hub dashboard` (routed through createHubCommand) never
reached the dashboard mock and three dashboard tests failed. Drop the
module mock and assert the activation exclusion through
`hub dashboard --no-open`, which is already mocked.

---------

Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>

2026-10-13 21:58:41 -07:00

agents

Revert "fix(vscode): preserve attachments in pending question responses (#14986 )" (#15058 )

2026-10-13 07:31:32 -07:00

core

refactor: Start the desktop and SSH remote hubs through the bundled Cline CLI (#14792 )

2026-10-13 21:58:41 -07:00

llms

chore(sdk): release v0.0.93

2026-10-13 00:52:03 -07:00

sdk

chore(sdk): release v0.0.93

2026-10-13 00:52:03 -07:00

shared

refactor: Start the desktop and SSH remote hubs through the bundled Cline CLI (#14792 )

2026-10-13 21:58:41 -07:00

fix(desktop): keep Cloud setup cards visible (#14954 )

2026-10-12 10:32:32 -07:00

README.md

feat(ui): add shared Cline theme package (#12285 )

2026-07-15 00:04:08 -07:00

tsconfig.base.json

chore: publish only dist artifacts in package exports (#52 )

2026-05-07 11:58:43 -07:00

README.md

Packages Overview

This directory is the single documentation source for package-level responsibilities.

High-level package roles: this file (packages/README.md)
Package interaction and runtime flows: ARCHITECTURE.md

Package Responsibilities

Package	Primary responsibility	Typical consumers	Internal deps
`@cline/shared`	Cross-package shared primitives (path resolution, session common types, indexing helpers)	`@cline/agents`, `@cline/core`, apps	None
`@cline/llms`	Model catalog + provider settings schema + handler creation SDK	`@cline/agents`, `@cline/core`, apps	None
`@cline/agents`	Stateless agent runtime loop (tools, hooks, extensions, teams, streaming)	`@cline/core`, apps	`@cline/llms`, `@cline/shared`
`@cline/core`	Stateful runtime orchestration (runtime composition, session lifecycle/storage, local and hub runtime services, hub discovery and client helpers)	CLI/Desktop apps	`@cline/agents`, `@cline/llms`, `@cline/shared`
`@cline/ui`	Internal framework-neutral web theme, Tailwind adapter, and optional base styles	Cline web apps	None

How Packages Work Together

@cline/llms defines model/provider capabilities and builds concrete handlers.
@cline/agents runs the agent loop on top of those handlers and tool execution primitives.
@cline/core composes runtime behavior with persistent sessions/storage and local or hub-backed runtime services.
@cline/core hub services orchestrate scheduled runtime execution, execution history, and schedule command handling.
@cline/core/hub exposes discovery, the detached hub daemon, and session-oriented client APIs (HubSessionClient, HubUIClient) when hosts need a shared daemon.
@cline/shared provides the shared contracts and path/session primitives used across the stack.

Practical Boundary Rules

Put provider/model schema, cataloging, and handler wiring in @cline/llms.
Put loop/tool/hook/team execution behavior in @cline/agents.
Put persistence, session lifecycle, and runtime assembly in @cline/core.
Put scheduled execution and schedule persistence in @cline/core hub services.
Put hub discovery, attach flows, and session-oriented client adapters in @cline/core/hub.
Put cross-package utility types and path/session constants in @cline/shared.
Put remote-config schemas, materialization, telemetry normalization, and blob upload primitives in @cline/shared/remote-config.
Put shared web tokens and visual foundations in @cline/ui; keep fonts, shell layout, and product-specific animation with each consuming app.

Runtime Entry Points

Node-oriented imports exist where packages expose a distinct Node alias.
@cline/core itself is now the Node/runtime-oriented entry point for host/session services.
Browser entry points still exist in packages that intentionally publish a browser surface, but @cline/core no longer does.

Notes for Doc Consolidation

Nested package README.md and ARCHITECTURE.md files can be reduced or removed after references are updated to point here.