Installazione

Control Center funziona in due modi: come app web su app.usectrl.dev, senza nulla da scaricare, oppure come app desktop che installi. Sono la stessa applicazione con le stesse funzionalità. L’unica differenza è dove viene eseguito il server — e l’app web non può eseguirne uno al posto tuo.

Usalo nel browser

app.usectrl.dev è questa applicazione compilata per il browser. Niente da installare, niente da aggiornare. Aprila e connettiti.

Ciò che una scheda del browser non può fare è essere il server. Ogni client — desktop, web, telefono — è un renderer sottile sopra un cc_server headless che possiede il database e svolge il lavoro, quindi l’app web parla sempre con un server che esegui tu. Due modi per fornirglielo:

Un server sulla tua macchina. Avvia cc_server in locale e punta l’app web su ws://localhost:9030. I browser considerano localhost affidabile, quindi non servono né un certificato né un tunnel. È il modo più rapido per provare l’app web e i tuoi dati non lasciano mai la tua macchina.

Un server su un’altra macchina. Poiché app.usectrl.dev è servito in HTTPS, un server non locale deve essere raggiungibile tramite wss:// con un certificato di cui il browser si fida già. cc_server rifiuta di fare il bind di un indirizzo non di loopback senza TLS, quindi scegli una di queste opzioni:

dagli direttamente un certificato, con --tls-cert e --tls-key
mettilo dietro un reverse proxy che termina il TLS e avvialo con --insecure
esponilo tramite un tunnel o una VPN che fornisce il certificato — Tailscale, cloudflared o simili. In Impostazioni → Server → Connessione e stato l’opt-in del tunnel integrato si trova sotto Condividi questo server.

Ogni volta che il server si trova dietro un proxy, un NAT o un tunnel, imposta --public-url sull’indirizzo che i client devono effettivamente contattare. Il valore predefinito è il bind locale, quindi senza di esso i client provano l’host sbagliato.

Alcune cose restano esclusive del desktop, perché richiedono una finestra nativa o i dispositivi audio della macchina stessa: la pillola flottante della modalità focus, gli avvisi di notifica del sistema operativo (il centro notifiche in-app funziona ovunque), «registra e collega» da un evento del calendario e la riesecuzione del riepilogo di una riunione. Tutto il resto — spazi, agenti, revisione delle pull request, pipeline, ticket, memoria e la stessa registrazione delle riunioni — si comporta allo stesso modo.

Per collegare l’app web a un server, segui Connettiti a un server remoto. Per ospitare il server, segui Esegui un server headless.

Requisiti di sistema del desktop

Requisito	macOS	Windows	Linux
Versione del sistema operativo	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ o un’altra distribuzione con glibc 2.35+ e GTK 3
Architettura	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Richiesto	Richiesto	Richiesto
Spazio su disco	~200 MB per l’app, più la directory dati del server	~200 MB	~200 MB

I Mac Intel non hanno un download precompilato. In alternativa, esegui la build dai sorgenti.

La directory dati del server cresce molto più dell’app. Al primo avvio cc_server installa forzatamente i modelli sul dispositivo — embedding di testo (~90 MB), diarizzazione degli interlocutori (~35 MB) e il modello vocale selezionato (Parakeet TDT v3 per impostazione predefinita, ~600 MB; le varianti Whisper 198–626 MB) — più una build integrata di code-server, e ogni conversazione con un agente riceve un worktree copy-on-write dei repo su cui lavora (git worktree normale su Windows). La voce non è facoltativa: senza il modello ASR, le operazioni di riunione e dettatura non vengono servite. Il primo download del modello vocale richiede comunque un riavvio prima che la registrazione si attivi.

Il desktop punta il suo server sulla directory di supporto applicazioni per utente del sistema operativo. Un cc_server avviato a mano senza --data-dir usa per impostazione predefinita <application data>/control-center — ~/Library/Application Support/control-center su macOS, %APPDATA%\control-center su Windows, $XDG_DATA_HOME/control-center (o ~/.local/share/control-center) su Linux.

Download

Ogni artefatto qui sotto proviene dalle GitHub Releases.

macOS (Apple Silicon)

Scarica Control-Center-<version>-arm64.dmg, aprilo e trascina Control Center in Applicazioni. La build è firmata con un Developer ID e notarizzata da Apple, quindi si apre normalmente.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: un programma di installazione per utente.
Control-Center-<version>-windows-x64.zip: un archivio zip portatile.
Control-Center-<version>-arm64-setup.exe: un programma di installazione per utente.
Control-Center-<version>-windows-arm64.zip: un archivio zip portatile.

Su Windows gli spazi usano git worktree per i checkout (niente copy-on-write).

Linux (x86_64)

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

L’AppImage contiene le informazioni di aggiornamento, quindi AppImageUpdate o appimaged possono portarla all’ultima release sul posto, scaricando solo ciò che è cambiato.

Entrambi sono compilati su Ubuntu 22.04 e funzionano su quella versione o su versioni più recenti (Debian 12, Fedora 36 e successive): si collegano a glibc 2.35 e alla libstdc++ di GCC 12 e prendono GTK 3 dal sistema. Le poche librerie che un desktop standard potrebbe non avere viaggiano al loro interno, quindi non serve installare nient’altro. L’audio — riproduzione delle riunioni, paesaggio sonoro, audio dei rig e suoni di notifica — viene riprodotto tramite la libmpv di sistema (libmpv1 su Ubuntu 22.04, libmpv2 su Ubuntu e Debian più recenti, mpv-libs su Fedora); senza di essa l’app si avvia con quei controlli nascosti.

Server autonomo

Ogni release include anche il server headless a sé stante — 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 — insieme alle immagini cc-server, cc-webapp e cc-remote su GHCR. Vedi Esegui un server headless.

L’archivio Linux è compilato su Ubuntu 22.04 e le sue librerie native incluse si collegano a glibc 2.35 e alla libstdc++ di GCC 12, quindi richiede un host almeno altrettanto recente (Ubuntu 22.04, Debian 12, Fedora 36 o successivi). Su una distribuzione più vecchia esegui invece l’immagine cc-server — un container porta con sé il proprio userland, quindi solo il kernel deve essere il tuo.

Backend degli agenti

Control Center invia gli agenti tramite adattatori. Ce ne sono due, l’elenco è fisso e vengono rilevati automaticamente — non c’è modo di registrarne un altro.

L’adattatore Control Center (built-in) non richiede alcuna CLI esterna: il ciclo dell’agente gira dentro il server e comunica con i fornitori di modelli via HTTP, quindi è sempre disponibile. Collega un fornitore in Impostazioni → Server → Fornitori di modelli. OpenAI, Codex, Cursor e Kimi Code offrono un accesso dal browser; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai e Moonshot richiedono una chiave API. Codex e Cursor sono fornitori di questo runner, non CLI separate. z.ai è elencato due volte di proposito: z.ai è la piattaforma aperta a consumo, fatturata sul saldo del tuo account, mentre z.ai GLM Coding Plan è l’abbonamento. È la stessa chiave dell’account, ma z.ai serve il piano da un host diverso — incolla una chiave del piano di codifica nel riquadro z.ai semplice e ogni richiesta torna 429 … "Insufficient balance or no resource package", perché il piano non ha saldo da spendere. Un abbonamento Claude Pro/Max non è un accesso API di Anthropic; per quel piano usa invece l’adattatore Claude Code. Ciò che puoi aggiungere su quella pagina è un fornitore personalizzato — qualsiasi endpoint compatibile con OpenAI o Anthropic (Ollama, LM Studio, vLLM, un deployment privato) sotto Provider personalizzati → Aggiungi provider.

L’altro adattatore avvolge una CLI esterna:

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

Il rilevamento sonda il PATH della macchina che esegue cc_server — la stessa macchina quando il desktop esegue il proprio server, l’host remoto altrimenti. Installa la CLI di Claude Code lì, non sul client. Il pulsante Aggiorna su quella pagina riesegue la sonda.

Gli elenchi dei modelli sono serviti in tempo reale da ogni fornitore collegato; models.dev fornisce solo i metadati su prezzo e finestra di contesto. Vedi Gestisci adattatori e modelli.

Autenticazione GitHub

Una credenziale GitHub è tua e risiede sul server, indicizzata per il tuo ID utente — non nel portachiavi del sistema operativo del client. Ogni dispositivo da cui accedi usa la stessa, e nessun altro membro può leggerla.

Se sul server è registrata una GitHub App (Crea la GitHub App), Impostazioni → Spazio di lavoro → Profilo e identità → Hosting del codice offre Accedi con GitHub (un device flow eseguito dal server). Altrimenti incolla un personal access token:

Classico: repo e read:org
A granularità fine: Contents e Pull requests (lettura e scrittura), Checks e Actions (lettura)

Creane uno su GitHub → Settings → Developer settings → Personal access tokens. Il server sonda il token per ricavare il nome dell’account nel momento in cui viene salvato, quindi la riga può mostrare «hai eseguito l’accesso come …»; una sonda fallita salva comunque il token, e un refuso o uno scope mancante si manifesta più tardi come una richiesta fallita.

Il primo passo dell’onboarding è questa connessione. Dopodiché la stessa scheda è dove la sostituisci o la cancelli. GitLab e Bitbucket usano la stessa scheda; vedi Collega un host di codice.

Scegli dove viene eseguito il server

Control Center è un thin client sopra un processo cc_server headless che possiede il database e fa tutto il lavoro; Deployment e client spiega cosa significa questa separazione per desktop, web e telefono.

Al primo avvio il desktop chiede «Come eseguire Control Center?»:

Esegui in questa app: il desktop avvia e supervisiona un cc_server su questa macchina e comunica con esso tramite loopback. Nient’altro da configurare. È la configurazione che presuppone l’avvio rapido.
Connetti a un’istanza remota: punta il desktop su un cc_server in esecuzione altrove con il suo URL WebSocket, un ID dispositivo e una chiave di abbinamento oppure un codice di invito monouso. Quel server possiede i dati; questo desktop si limita a renderizzarli.

Puoi aggiungere o cambiare server più tardi in Impostazioni → Server → Connessione e stato. Il cambio si riconnette sul posto — senza riavvio. Un browser non può eseguire un server, quindi il client web è sempre remoto; vedi Connettiti a un server remoto.

Per ospitare tu stesso un server, segui Esegui un server headless. Copre la compilazione del binario, la generazione di una chiave di abbinamento prima del primo avvio e i flag --data-dir / --port / --bind.

Verifica la configurazione

Impostazioni → Server → Fornitori di modelli elenca entrambi gli adattatori. «Control Center (built-in)» risulta trovato con versione built-in; Claude Code risulta trovato se la sua CLI è nel PATH dell’host del server. Premi Aggiorna se manca.
Impostazioni → Spazio di lavoro → Repository elenca i repo di questo spazio di lavoro, e Aggiungi repository sfoglia le cartelle dell’host del server.
Impostazioni → Spazio di lavoro → Agenti elenca i cinque agenti creati dal tuo primo spazio di lavoro. Ognuno deve avere un Adattatore e un Modello impostati prima di poter essere eseguito.
Impostazioni → Server → Diagnostica e privacy riporta i backend del sandbox offerti da questo host, lo stato del modello di embedding e la registrazione dei log.

Esegui la build dai sorgenti

Le librerie native sono obbligatorie e non esiste una modalità degradata: se ne manca una, l’avvio fallisce del tutto, non diventa semplicemente più lento. Preparale prima di ogni altra cosa. Ogni comando Flutter e Dart passa da fvm, perché la versione dell’SDK è fissata dal 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

Su macOS, l’archiviazione sicura (accesso a GitHub, Linear e Google) richiede che l’app sia firmata da un team Apple — basta un Apple ID gratuito, ed è una configurazione una tantum descritta in local development signing. Senza di essa l’app si avvia comunque; solo l’archiviazione sicura non è disponibile. Windows e Linux non richiedono alcuna firma.

Per compilare il binario del server headless, prepara prima le librerie native allo stesso modo, poi:

cd apps/cc_server
fvm dart build cli

L’hook di build copia nel bundle qualunque cosa si trovi già in build/natives/, quindi compilare prima di preparare le librerie produce un bundle senza native e un server che rifiuta di avviarsi.

Per il client web usa scripts/build_web.sh (--target remote per la PWA del telefono). È ciò che esegue la CI: un semplice flutter build web salta il timbro dell’identità di build, la rigenerazione dei Web Worker, il manifest di deploy e il controllo del budget degli asset.