Instalacja

Control Center działa na dwa sposoby: jako aplikacja webowa pod adresem app.usectrl.dev, bez niczego do pobrania, albo jako aplikacja desktopowa, którą instalujesz. To ta sama aplikacja z tymi samymi funkcjami. Jedyna różnica to miejsce, w którym działa serwer — a aplikacja webowa nie uruchomi go za Ciebie.

Używaj w przeglądarce

app.usectrl.dev to ta aplikacja skompilowana dla przeglądarki. Niczego nie trzeba instalować ani aktualizować. Otwórz ją i połącz się.

Karta przeglądarki nie może natomiast być serwerem. Każdy klient — desktopowy, webowy, telefoniczny — to cienka warstwa renderująca nad headless cc_server, który jest właścicielem bazy danych i wykonuje całą pracę, więc aplikacja webowa zawsze rozmawia z prowadzonym przez Ciebie serwerem. Dwa sposoby, by go jej dać:

Serwer na własnym komputerze. Uruchom cc_server lokalnie i wskaż aplikacji webowej ws://localhost:9030. Przeglądarki uznają localhost za godny zaufania, więc nie potrzeba certyfikatu ani tunelu. To najszybszy sposób, by wypróbować aplikację webową, a Twoje dane nigdy nie opuszczają Twojego komputera.

Serwer na innym komputerze. Ponieważ app.usectrl.dev jest serwowany przez HTTPS, serwer inny niż lokalny musi być osiągalny przez wss:// z certyfikatem, któremu przeglądarka już ufa. cc_server odmawia bindowania adresu spoza pętli zwrotnej bez TLS, wybierz więc jedną z opcji:

nadaj mu certyfikat bezpośrednio, przez --tls-cert i --tls-key
postaw go za reverse proxy kończącym TLS i uruchom z --insecure
wystaw go przez tunel lub VPN, który dostarcza certyfikat — Tailscale, cloudflared albo podobny. W Ustawienia → Serwer → Połączenie i status wbudowana opcja tunelu znajduje się pod Udostępnij ten serwer.

Gdy serwer stoi za proxy, NAT lub tunelem, ustaw --public-url na adres, pod który klienci mają faktycznie się łączyć. Domyślnie przyjmuje lokalny bind, więc bez tego klienci próbują trafić pod zły host.

Kilka rzeczy pozostaje wyłącznie w wersji desktopowej, bo wymagają natywnego okna albo własnych urządzeń audio komputera: pływająca pigułka trybu skupienia, powiadomienia systemowe (centrum powiadomień w aplikacji działa wszędzie), „Rozpocznij nagrywanie i powiąż” z wydarzenia w kalendarzu oraz ponowne uruchomienie podsumowania spotkania. Wszystko inne — przestrzenie, agenci, recenzja pull requestów, potoki, zgłoszenia, pamięć i samo nagrywanie spotkań — działa tak samo.

Aby połączyć aplikację webową z serwerem, postępuj zgodnie z Połącz się ze zdalnym serwerem. Aby hostować serwer, postępuj zgodnie z Uruchom serwer headless.

Wymagania systemowe aplikacji desktopowej

Wymaganie	macOS	Windows	Linux
Wersja systemu	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ lub inna dystrybucja z glibc 2.35+ i GTK 3
Architektura	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Wymagany	Wymagany	Wymagany
Miejsce na dysku	~200 MB dla aplikacji plus katalog danych serwera	~200 MB	~200 MB

Dla Maców z procesorami Intel nie ma gotowego pliku do pobrania. Zamiast tego zbuduj ze źródeł.

Katalog danych serwera rośnie bardziej niż sama aplikacja. Przy pierwszym uruchomieniu cc_server wymusza instalację modeli działających na urządzeniu — embeddingów tekstu (~90 MB), diaryzacji mówców (~35 MB) i wybranego modelu mowy (domyślnie Parakeet TDT v3, ~600 MB; warianty Whisper 198–626 MB) — a także wbudowanego builda code-server; ponadto każda rozmowa agenta otrzymuje worktree z kopiowaniem przy zapisie (copy-on-write) repozytoriów, na których pracuje (zwykły git worktree w Windows). Mowa nie jest opcjonalna: bez modelu ASR operacje spotkań i dyktowania nie są obsługiwane. Pierwsze pobranie modelu mowy nadal wymaga jednego restartu, zanim nagrywanie zacznie działać.

Aplikacja desktopowa wskazuje swój serwer na katalog wsparcia aplikacji dla użytkownika w systemie. Uruchomiony ręcznie cc_server bez --data-dir domyślnie używa <application data>/control-center — ~/Library/Application Support/control-center w macOS, %APPDATA%\control-center w Windows, $XDG_DATA_HOME/control-center (albo ~/.local/share/control-center) w Linuksie.

Pobieranie

Każdy z poniższych artefaktów pochodzi z GitHub Releases.

macOS (Apple Silicon)

Pobierz Control-Center-<version>-arm64.dmg, otwórz go i przeciągnij Control Center do folderu Aplikacje. Build jest podpisany Developer ID i notaryzowany przez Apple, więc otwiera się normalnie.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: instalator dla użytkownika.
Control-Center-<version>-windows-x64.zip: przenośny plik zip.
Control-Center-<version>-arm64-setup.exe: instalator dla użytkownika.
Control-Center-<version>-windows-arm64.zip: przenośny plik zip.

Windows używa git worktree do checkoutów przestrzeni (bez copy-on-write).

Linux (x86_64)

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

AppImage niesie informacje o aktualizacjach, więc AppImageUpdate albo appimaged mogą zaktualizować go w miejscu do najnowszego wydania, pobierając tylko to, co się zmieniło.

Oba są zbudowane na Ubuntu 22.04 i działają na nim lub na czymś nowszym (Debian 12, Fedora 36 i późniejsze): linkują glibc 2.35 i libstdc++ z GCC 12 oraz korzystają z GTK 3 dostarczanego przez system. Nieliczne biblioteki, których może brakować w standardowym systemie, podróżują w ich wnętrzu, więc nic więcej nie trzeba instalować. Dźwięk — odtwarzanie spotkań, pejzaż dźwiękowy, dźwięk rigów i dźwięki powiadomień — odtwarza się przez systemowe libmpv (libmpv1 na Ubuntu 22.04, libmpv2 na nowszym Ubuntu i Debianie, mpv-libs na Fedorze); bez niego aplikacja startuje z tymi elementami sterującymi ukrytymi.

Samodzielny serwer

Każde wydanie zawiera też sam serwer headless osobno — 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 — obok obrazów cc-server, cc-webapp i cc-remote w GHCR. Zobacz Uruchom serwer headless.

Archiwum dla Linuksa jest zbudowane na Ubuntu 22.04, a dołączone do niego biblioteki natywne linkują glibc 2.35 i libstdc++ z GCC 12, wymaga więc hosta co najmniej tak nowego (Ubuntu 22.04, Debian 12, Fedora 36 lub późniejsza). Na starszej dystrybucji uruchom zamiast tego obraz cc-server — kontener wnosi własny userland, więc tylko jądro musi być Twoje.

Backend agenta

Control Center wysyła agentów przez adaptery. Są dwa, lista jest stała, a wykrywanie odbywa się automatycznie — nie ma sposobu, by zarejestrować kolejny.

Adapter Control Center (built-in) nie wymaga zewnętrznego CLI: pętla agenta działa wewnątrz serwera i komunikuje się z dostawcami modeli przez HTTP, więc jest zawsze dostępny. Połącz dostawcę w Ustawienia → Serwer → Dostawcy modeli. OpenAI, Codex, Cursor i Kimi Code oferują logowanie w przeglądarce; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai i Moonshot przyjmują klucz API. Codex i Cursor to dostawcy w tym runnerze, a nie osobne CLI. z.ai występuje dwukrotnie celowo: z.ai to otwarta platforma rozliczana za użycie, płatna z salda Twojego konta, a z.ai GLM Coding Plan to subskrypcja. To ten sam klucz konta, ale z.ai obsługuje ten plan z innego hosta — jeśli wkleisz klucz planu codingowego do zwykłego kafelka z.ai, każde żądanie wróci jako 429 … "Insufficient balance or no resource package", bo ten plan nie ma salda, z którego mógłby korzystać. Subskrypcja Claude Pro/Max to nie logowanie do API Anthropic; do tego planu dotrzesz przez adapter Claude Code. To, co możesz dodać na tej stronie, to dostawca własny — dowolny punkt końcowy zgodny z OpenAI albo z Anthropic (Ollama, LM Studio, vLLM, prywatne wdrożenie) w sekcji Dostawcy własni → Dodaj dostawcę.

Drugi adapter opakowuje zewnętrzne CLI:

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

Wykrywanie sonduje PATH maszyny, na której działa cc_server — tej samej, gdy aplikacja desktopowa prowadzi własny serwer, a w przeciwnym razie zdalnego hosta. Zainstaluj CLI Claude Code tam, nie na kliencie. Przycisk Odśwież na tej stronie ponawia sondowanie.

Listy modeli są serwowane na bieżąco przez każdego połączonego dostawcę; models.dev dostarcza tylko metadane o cenie i oknie kontekstu. Zobacz Zarządzaj adapterami i modelami.

Uwierzytelnianie w GitHub

Poświadczenie GitHub jest Twoje i mieszka na serwerze, przypisane do Twojego identyfikatora użytkownika — a nie w pęku kluczy systemu klienta. Każde urządzenie, z którego się logujesz, korzysta z tego samego, a żaden inny członek nie może go odczytać.

Jeśli na serwerze jest zarejestrowana GitHub App (Utwórz GitHub App), Ustawienia → Obszar roboczy → Profil i tożsamość → Hosting kodu oferuje Zaloguj się przez GitHub (przepływ z kodem urządzenia, który prowadzi serwer). W przeciwnym razie wklej osobisty token dostępu:

Klasyczny: repo i read:org
Drobnoziarnisty: Contents i Pull requests (odczyt i zapis), Checks i Actions (odczyt)

Utwórz go w GitHub → Settings → Developer settings → Personal access tokens. Serwer sonduje token pod kątem nazwy konta w postaci, w jakiej jest zapisany, więc wiersz może pokazać „zalogowano jako …“; nieudane sondowanie nadal zapisuje token, a literówka albo brakujący zakres ujawni się później jako nieudane żądanie.

Pierwszy krok onboardingu to właśnie to połączenie. Później ta sama karta służy do jego zastąpienia lub usunięcia. GitLab i Bitbucket korzystają z tej samej karty; zobacz Połącz host kodu.

Wybierz, gdzie działa serwer

Control Center to cienki klient nad procesem headless cc_server, który jest właścicielem bazy danych i wykonuje całą pracę; Wdrażanie i klienci wyjaśnia, co ten podział oznacza dla wersji desktopowej, webowej i telefonicznej.

Przy pierwszym uruchomieniu aplikacja desktopowa pyta: „Jak ma działać Control Center?“:

Uruchom w tej aplikacji: aplikacja desktopowa uruchamia i nadzoruje cc_server na tym komputerze i rozmawia z nim przez pętlę zwrotną. Niczego więcej nie trzeba konfigurować. To konfiguracja, którą zakłada Szybki start.
Połącz ze zdalną instancją: wskaż aplikacji desktopowej cc_server działający gdzie indziej, podając jego adres URL WebSocket, identyfikator urządzenia oraz klucz parowania albo jednorazowy kod zaproszenia. To ten serwer jest właścicielem danych; ten desktop tylko je renderuje.

Serwery dodasz lub zmienisz później w Ustawienia → Serwer → Połączenie i status. Przełączenie łączy od nowa w miejscu — bez restartu. Przeglądarka nie może uruchomić serwera, więc klient webowy jest zawsze zdalny; zobacz Połącz się ze zdalnym serwerem.

Aby samodzielnie hostować serwer, postępuj zgodnie z Uruchom serwer headless. Opisuje budowanie binarki, wygenerowanie klucza parowania przed pierwszym startem oraz flagi --data-dir / --port / --bind.

Zweryfikuj konfigurację

Ustawienia → Serwer → Dostawcy modeli wylicza oba adaptery. „Control Center (built-in)” jest wykrywany z wersją built-in; Claude Code jest wykrywany, jeśli jego CLI znajduje się w PATH hosta serwera. Jeśli go brakuje, naciśnij Odśwież.
Ustawienia → Obszar roboczy → Repozytoria wylicza repozytoria tego obszaru roboczego, a Dodaj repozytorium przegląda foldery hosta serwera.
Ustawienia → Obszar roboczy → Agenci wylicza pięciu agentów, których utworzył Twój pierwszy obszar roboczy. Dla każdego trzeba ustawić Adapter i Model, zanim będzie mógł zadziałać.
Ustawienia → Serwer → Diagnostyka i prywatność raportuje backendy sandboxa oferowane przez ten host, stan modelu embeddingów i logowanie.

Zbuduj ze źródeł

Biblioteki natywne są wymagane i nie ma trybu zdegradowanego: brak jednej to twardy błąd startu, a nie wolniejsza ścieżka. Przygotuj je, zanim zrobisz cokolwiek innego. Każde polecenie Fluttera i Darta przechodzi przez fvm, bo wersja SDK jest przypięta przez repozytorium.

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

W macOS bezpieczny magazyn (logowanie do GitHub, Linear i Google) wymaga aplikacji podpisanej przez zespół Apple — wystarczy darmowe Apple ID, a to jednorazowa konfiguracja opisana w sekcji podpisywanie na potrzeby lokalnego rozwoju. Bez tego aplikacja nadal się uruchamia; niedostępny jest tylko bezpieczny magazyn. Windows i Linux nie wymagają podpisywania.

Aby zbudować binarkę serwera headless, najpierw przygotuj biblioteki natywne w ten sam sposób, a potem:

cd apps/cc_server
fvm dart build cli

Hook budowania kopiuje do pakietu to, co już znajduje się w build/natives/, więc zbudowanie przed przygotowaniem bibliotek daje pakiet bez bibliotek natywnych i serwer, który odmawia startu.

Dla klienta webowego użyj scripts/build_web.sh (--target remote dla PWA na telefon). To właśnie uruchamia CI: zwykłe flutter build web pomija stempel tożsamości builda, regenerację Web Workera, manifest wdrożenia i sprawdzenie budżetu zasobów.