mirror of
https://github.com/cline/cline.git
synced 2026-09-21 13:21:23 +08:00
BeeandSaoud Rizwan
6138bdfe40
* feat: Enforce a production singleton Cline Hub This PR changes local Hub startup/discovery so production uses one stable daemon per user machine instead of silently creating additional hubs on random ports. Replace resolveSharedHubOwnerContext with resolveProductionHubOwnerContext across doctor and hub server lifecycle management to scope hub discovery to the production owner. Additionally: - Preserve and propagate auth tokens when retiring incompatible hubs - Throw a clear error when a compatible hub is already running but its discovery record is missing, guiding users to run 'cline doctor fix' - Gate port fallback behind an explicit allowPortFallback override - Update tests to mock the new production hub owner context * patches * fix * hasExplicitPort * Restored daemon cron startup, made discovery auth tokens required again, and fixed graceful hub stop/restart paths to use the selected production/shared owner context. * clean up * patches * fix Polynomial regular expression * test * fix: require explicit hub port fallback in production * fix(cli): stop pgrep from parsing the hub daemon marker as an option pgrep treats the "--cline-hub-daemon" pattern as an unknown long option and exits 2, so doctor never found stale daemons from compiled-binary installs, which are exactly the processes 'cline doctor fix' is told to clean up. Pass "--" before the pattern to end option parsing. * fix(hub): retire legacy shared-owner hubs on production startup Pre-singleton production builds tracked the local hub under the shared owner discovery path and spawned daemons on random fallback ports. The production owner context never reads that path, so upgrades would leave those daemons running indefinitely with no way to reuse or stop them. Retire the recorded legacy hub (its record carries the auth token and pid needed for a graceful stop) and clear the legacy record before resolving the production hub. * refactor(hub): simplify stale discovery clearing, share capability list shouldClearStaleHubDiscovery was only ever called with discoveredVerified=false (the true assignment sits on a return path), so the expected-hub probe and compatibility check had no effect and the condition reduced to "a discovery record exists and was not reused". Replace it with a plain conditional and drop the tests that exercised unreachable states. Also move the hub capability list into a typed HUB_CAPABILITIES constant in @cline/shared next to HubCapabilityName so the server cannot drift from the type. --------- Co-authored-by: Saoud Rizwan <7799382+saoudrizwan@users.noreply.github.com>
Preview
Architecture Overview
Any Client (CLI, VS Code, agents)
│
│ ws:// ui.notify / ui.show_window commands
▼
Hub WebSocket Server (@cline/core/hub/server.ts)
│
│ broadcasts ui.notify / ui.show_window events to ALL subscribers
▼
Menu Bar Sidecar (apps/examples/menubar/sidecar/index.ts) ← TypeScript/Bun process
│
│ JSON lines on stdout: hub_state / notification / ready
▼
Rust Tauri App (apps/examples/menubar/src-tauri/src/main.rs)
│
├── Hub Monitor Window (ui/index.html)
│ ● Live hub status, uptime, clients, sessions
│ ● Running session tracker and inspector
│ ● Recent events and background-session launcher
│
│
├── System Tray Icon with dynamic menu
│ ● Hub Connected — 3 clients, 2 sessions
│ ─────────────────
│ 5 notifications
│ ─────────────────
│ Quit Cline Hub
│
└── Logs notifications to stderr (with severity)
Dev Commands
From apps/examples/menubar/:
bun run dev:ui- run only the Hub Monitor UI athttp://127.0.0.1:3466/with preview databun run dev- run the full Tauri app with the real hub sidecarbun run typecheck- TypeScript check