Instalare

Control Center rulează în două moduri: ca aplicație web la app.usectrl.dev, fără nimic de descărcat, sau ca aplicație desktop pe care o instalezi. Sunt aceeași aplicație, cu aceleași funcții. Singura diferență este unde rulează serverul — iar aplicația web nu poate rula unul pentru tine.

Folosește-o în browser

app.usectrl.dev este această aplicație compilată pentru browser. Nimic de instalat, nimic de actualizat. Deschide-o și conectează-te.

Ce nu poate face un tab de browser este să fie serverul. Fiecare client — desktop, web, telefon — este un renderizator subțire peste un cc_server headless care deține baza de date și face treaba, așa că aplicația web vorbește întotdeauna cu un server pe care îl rulezi tu. Două moduri de a-i da unul:

Un server pe propria mașină. Pornește cc_server local și îndreaptă aplicația web spre ws://localhost:9030. Browserele tratează localhost ca fiind de încredere, așa că nu e nevoie de certificat și nici de tunel. Este cea mai rapidă cale de a încerca aplicația web, iar datele tale nu părăsesc niciodată mașina.

Un server pe altă mașină. Deoarece app.usectrl.dev este servit prin HTTPS, un server non-local trebuie să fie accesibil prin wss:// cu un certificat în care browserul are deja încredere. cc_server refuză să asocieze o adresă non-loopback fără TLS, așa că alege una dintre variante:

îi dai direct un certificat, cu --tls-cert și --tls-key
îl pui în spatele unui proxy invers care termină TLS și îl pornești cu --insecure
îl expui printr-un tunel sau VPN care furnizează certificatul — Tailscale, cloudflared sau similar. Setări → Server → Conexiune și stare are opt-in-ul pentru tunelul integrat, sub Partajează acest server.

Ori de câte ori serverul stă în spatele unui proxy, NAT sau tunel, setează --public-url la adresa pe care clienții ar trebui să o acceseze efectiv. Valoarea implicită este asocierea locală, așa că fără ea clienții încearcă gazda greșită.

Câteva lucruri rămân doar pentru desktop, pentru că au nevoie de o fereastră nativă sau de dispozitivele audio ale mașinii: pastila flotantă din modul focus, notificările de sistem sub formă de toast (centrul de notificări din aplicație funcționează peste tot), „Pornește înregistrarea și leagă” dintr-un eveniment de calendar și rerularea unui rezumat de întâlnire. Tot restul — spații, agenți, revizuirea pull request-urilor, pipeline-uri, tichete, memorie și înregistrarea întâlnirilor în sine — se comportă la fel.

Pentru a conecta aplicația web la un server, urmează Conectează-te la un server remote. Pentru a găzdui serverul, urmează Rulează un server headless.

Cerințe de sistem pentru desktop

Cerință	macOS	Windows	Linux
Versiune de sistem	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ sau altă distribuție cu glibc 2.35+ și GTK 3
Arhitectură	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Necesar	Necesar	Necesar
Spațiu pe disc	~200 MB pentru aplicație, plus directorul de date al serverului	~200 MB	~200 MB

Macurile Intel nu au nicio descărcare precompilată. În schimb, construiește din sursă.

Directorul de date al serverului depășește cu mult aplicația. La prima pornire, cc_server instalează forțat modelele de pe dispozitiv — embeddinguri de text (~90 MB), diarizarea vorbitorilor (~35 MB) și modelul de voce selectat (Parakeet TDT v3 implicit, ~600 MB; variantele Whisper 198–626 MB) — plus un build code-server integrat, iar fiecare conversație de agent primește un worktree copy-on-write al repo-urilor pe care lucrează (git worktree simplu pe Windows). Vocea nu este opțională: fără modelul ASR, operațiile de întâlniri și de dictare nu sunt servite. Prima descărcare a modelului de voce mai are nevoie de o repornire înainte ca înregistrarea să devină disponibilă.

Aplicația desktop își îndreaptă serverul spre directorul de suport pentru aplicații per utilizator al sistemului. Un cc_server pornit manual, fără --data-dir, folosește implicit <application data>/control-center — ~/Library/Application Support/control-center pe macOS, %APPDATA%\control-center pe Windows, $XDG_DATA_HOME/control-center (sau ~/.local/share/control-center) pe Linux.

Descărcare

Fiecare artefact de mai jos provine din GitHub Releases.

macOS (Apple Silicon)

Descarcă Control-Center-<version>-arm64.dmg, deschide-l și trage Control Center în dosarul Applications. Buildul este semnat cu un Developer ID și notarizat de Apple, așa că se deschide normal.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: un instalator per utilizator.
Control-Center-<version>-windows-x64.zip: un zip portabil.
Control-Center-<version>-arm64-setup.exe: un instalator per utilizator.
Control-Center-<version>-windows-arm64.zip: un zip portabil.

Windows folosește git worktree pentru check-out-urile spațiilor (fără copy-on-write).

Linux (x86_64)

Control-Center-<version>-x86_64.AppImage
Control-Center-<version>-linux-x64.tar.gz

AppImage-ul conține informații de actualizare, așa că AppImageUpdate sau appimaged îl pot aduce pe loc la ultima versiune, descărcând doar ce s-a schimbat.

Ambele sunt construite pe Ubuntu 22.04 și rulează pe el sau pe ceva mai nou (Debian 12, Fedora 36 și versiunile ulterioare): se leagă la glibc 2.35 și la libstdc++ din GCC 12 și preiau GTK 3 din sistem. Puținele biblioteci care pot lipsi de pe un desktop obișnuit călătoresc în interiorul lor, așa că nu mai trebuie instalat nimic altceva. Sunetul — redarea întâlnirilor, peisajul sonor, audio-ul din stații și sunetele de notificare — redă prin libmpv-ul sistemului (libmpv1 pe Ubuntu 22.04, libmpv2 pe Ubuntu și Debian mai noi, mpv-libs pe Fedora); fără el, aplicația pornește cu acele controale ascunse.

Server autonom

Fiecare versiune include și serverul headless separat — cc_server-<version>-macos-arm64.tar.gz, cc_server-<version>-linux-x64.tar.gz, cc_server-<version>-windows-x64.zip, cc_server-<version>-windows-arm64.zip — alături de imaginile cc-server, cc-webapp și cc-remote de pe GHCR. Vezi Rulează un server headless.

Arhiva Linux este construită pe Ubuntu 22.04, iar bibliotecile native incluse se leagă la glibc 2.35 și la libstdc++ din GCC 12, așa că are nevoie de o gazdă cel puțin la fel de nouă (Ubuntu 22.04, Debian 12, Fedora 36 sau mai nou). Pe o distribuție mai veche, rulează în schimb imaginea cc-server — un container își aduce propriul userland, așa că doar kernelul trebuie să fie al tău.

Backend de agenți

Control Center trimite agenții prin adaptoare. Există două, lista este fixă și sunt detectate automat — nu există nicio modalitate de a înregistra altul.

Adaptorul Control Center (built-in) nu are nevoie de niciun CLI extern: bucla agentului rulează în interiorul serverului și comunică cu providerii de modele prin HTTP, așa că este mereu disponibil. Conectează un provider în Setări → Server → Provideri de modele. OpenAI, Codex, Cursor și Kimi Code oferă autentificare în browser; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai și Moonshot cer o cheie API. Codex și Cursor sunt provideri pe acest runner, nu CLI-uri separate. z.ai apare de două ori intenționat: z.ai este platforma deschisă cu plată pe măsură ce consumi, facturată din soldul contului tău, în timp ce z.ai GLM Coding Plan este abonamentul. Este aceeași cheie de cont, dar z.ai servește planul de pe alt host — lipește o cheie de plan de programare în cardul simplu z.ai și fiecare cerere întoarce 429 … "Insufficient balance or no resource package", pentru că planul nu are sold de cheltuit. Un abonament Claude Pro/Max nu este o autentificare în API-ul Anthropic; ajunge la acel plan prin adaptorul Claude Code. Ce poți adăuga pe acea pagină este un provider personalizat — orice endpoint compatibil OpenAI sau Anthropic (Ollama, LM Studio, vLLM, o implementare privată) sub Provideri personalizați → Adaugă provider.

Celălalt adaptor împachetează un CLI extern:

Claude Code (claude): npm install -g @anthropic-ai/claude-code

Detectarea sondează PATH-ul mașinii care rulează cc_server — aceeași mașină când desktopul își rulează propriul server, altfel gazda remote. Instalează CLI-ul Claude Code acolo, nu pe client. Butonul Reîmprospătează de pe acea pagină reia sondarea.

Listele de modele sunt servite live de fiecare provider conectat; models.dev furnizează doar metadate despre preț și fereastra de context. Vezi Gestionează adaptoarele și modelele.

Autentificare GitHub

O acreditare GitHub este a ta și trăiește pe server, indexată după id-ul tău de utilizator — nu în keychainul sistemului de operare al clientului. Fiecare dispozitiv de pe care te autentifici o folosește pe aceeași, iar niciun alt membru nu o poate citi.

Dacă serverul are înregistrată o GitHub App (Creează GitHub App), Setări → Spațiu de lucru → Profil și identitate → Găzduire de cod oferă Autentifică-te cu GitHub (un device flow rulat de server). În caz contrar, lipește un token de acces personal:

Clasic: repo și read:org
Cu granularitate fină: Contents și Pull requests (citire și scriere), Checks și Actions (citire)

Creează unul la GitHub → Settings → Developer settings → Personal access tokens. Serverul sondează tokenul pentru numele de cont în momentul în care este salvat, așa că rândul poate afișa „autentificat ca …”; o sondare eșuată salvează totuși tokenul, iar o greșeală de tastare sau un scope lipsă se manifestă mai târziu ca o cerere eșuată.

Primul pas al onboardingului este această conexiune. După aceea, același card este locul unde o înlocuiești sau o ștergi. GitLab și Bitbucket folosesc același card; vezi Conectează un host de cod.

Alege unde rulează serverul

Control Center este un client subțire peste un proces cc_server headless care deține baza de date și face toată treaba; Implementare și clienți explică ce înseamnă această separare pentru desktop, web și telefon.

La prima lansare, desktopul întreabă „Cum ar trebui să ruleze Control Center?”:

Rulează în această aplicație: desktopul pornește și supraveghează un cc_server pe această mașină și comunică cu el prin loopback. Nimic altceva de configurat. Aceasta este configurația pe care o presupune pornirea rapidă.
Conectează-te la o instanță remote: îndreaptă desktopul spre un cc_server care rulează în altă parte, cu URL-ul său WebSocket, un id de dispozitiv și fie o cheie de asociere, fie un cod de invitație de unică folosință. Acel server deține datele; acest desktop doar le afișează.

Adaugă sau comută servere mai târziu în Setări → Server → Conexiune și stare. Comutarea se reconectează pe loc — fără repornire. Un browser nu poate rula un server, așa că clientul web este întotdeauna remote; vezi Conectează-te la un server remote.

Pentru a găzdui singur un server, urmează Rulează un server headless. Acesta acoperă construirea binarului, generarea unei chei de asociere înainte de prima pornire și flagurile --data-dir / --port / --bind.

Verifică-ți configurarea

Setări → Server → Provideri de modele listează ambele adaptoare. „Control Center (built-in)” apare ca găsit, cu versiunea built-in; Claude Code apare ca găsit dacă CLI-ul său se află în PATH-ul gazdei serverului. Apasă Reîmprospătează dacă lipsește.
Setări → Spațiu de lucru → Depozite listează repo-urile acestui spațiu de lucru, iar Adaugă depozit răsfoiește folderele gazdei serverului.
Setări → Spațiu de lucru → Agenți listează cei cinci agenți creați implicit în primul tău spațiu de lucru. Fiecare are nevoie de un Adaptor și de un Model setate înainte de a putea rula.
Setări → Server → Diagnosticări și confidențialitate raportează backend-urile sandbox oferite de această gazdă, starea modelului de embedding și jurnalizarea.

Construiește din sursă

Bibliotecile native sunt obligatorii și nu există un mod degradat: una lipsă este o eroare fatală la pornire, nu o cale mai lentă. Pregătește-le înainte de orice altceva. Fiecare comandă Flutter și Dart trece prin fvm, pentru că versiunea SDK-ului este fixată de repo.

git clone https://github.com/SamuelAlev/control-center.git
cd control-center
scripts/natives/build_natives.sh
fvm flutter pub get
fvm flutter pub run build_runner build --delete-conflicting-outputs
fvm flutter gen-l10n
fvm flutter run -d macos  # or -d windows, -d linux

Pe macOS, stocarea securizată (autentificarea GitHub, Linear și Google) are nevoie ca aplicația să fie semnată de o echipă Apple — un Apple ID gratuit este suficient, iar configurarea se face o singură dată, conform semnării pentru dezvoltare locală. Fără ea, aplicația tot pornește; doar stocarea securizată nu este disponibilă. Windows și Linux nu au nevoie de semnare.

Pentru a construi binarul serverului headless, pregătește întâi bibliotecile native în același mod, apoi:

cd apps/cc_server
fvm dart build cli

Hook-ul de build copiază tot ce se află deja în build/natives/ în pachet, așa că dacă construiești înainte de a pregăti bibliotecile obții un pachet fără native și un server care refuză să pornească.

Pentru clientul web folosește scripts/build_web.sh (--target remote pentru PWA-ul de telefon). Este ceea ce rulează CI: un simplu flutter build web sare peste ștampila de identitate a buildului, regenerarea Web Worker, manifestul de deploy și verificarea bugetului de asseturi.