Instalar

O Control Center funciona de duas formas: como aplicação web em app.usectrl.dev, sem nada para descarregar, ou como aplicação de ambiente de trabalho que instala. São a mesma aplicação, com as mesmas funcionalidades. A única diferença é onde é executado o servidor — e a aplicação web não consegue executar um por si.

Utilize-o no navegador

app.usectrl.dev é esta aplicação compilada para o navegador. Nada para instalar, nada para atualizar. Abra-a e ligue-se.

O que um separador do navegador não consegue fazer é ser o servidor. Todos os clientes — de ambiente de trabalho, web e telemóvel — são um renderizador leve sobre um cc_server headless que detém a base de dados e faz o trabalho, pelo que a aplicação web fala sempre com um servidor executado por si. Há duas formas de lhe dar um:

Um servidor na sua própria máquina. Inicie o cc_server localmente e aponte a aplicação web para ws://localhost:9030. Os navegadores consideram o localhost fiável, pelo que isto não precisa de certificado nem de túnel. É a forma mais rápida de experimentar a aplicação web, e os seus dados nunca saem da sua máquina.

Um servidor noutra máquina. Como o app.usectrl.dev é servido por HTTPS, um servidor não local tem de estar acessível por wss:// com um certificado em que o navegador já confie. O cc_server recusa, à partida, associar um endereço que não seja de loopback sem TLS, pelo que escolha uma destas opções:

• dar-lhe um certificado diretamente, com --tls-cert e --tls-key
• colocá-lo atrás de um proxy inverso que termina o TLS e iniciá-lo com --insecure
• expô-lo através de um túnel ou VPN que forneça o certificado — Tailscale, cloudflared ou semelhante. Definições → Servidor → Ligação e status tem a ativação do túnel integrado em Partilhar este servidor.

Sempre que o servidor estiver atrás de um proxy, NAT ou túnel, defina --public-url com o endereço a que os clientes se devem realmente ligar. Por predefinição, é o endereço de escuta local, pelo que, sem ela, os clientes tentam o anfitrião errado.

Aloja a sua própria cópia do cliente web?

O cc_server só aceita origens de navegador que constem da sua lista --allowed-origins, cuja predefinição é https://app.usectrl.dev. Acrescente aí a sua própria origem se alojar a compilação web por conta própria. O loopback e os clientes nativos são sempre permitidos, independentemente dessa lista.

Algumas coisas continuam exclusivas da aplicação de ambiente de trabalho, porque precisam de uma janela nativa ou dos próprios dispositivos de áudio da máquina: a pastilha flutuante do modo de concentração, as notificações do sistema operativo (o centro de notificações da aplicação funciona em todo o lado), «Gravar e vincular» a partir de um evento de calendário, e voltar a executar o resumo de uma reunião. Todo o resto — espaços, agentes, revisão de pull requests, pipelines, tickets, memória e a própria gravação de reuniões — comporta-se da mesma forma.

Para ligar a aplicação web a um servidor, siga Ligar a um servidor remoto. Para alojar o servidor, siga Executar um servidor headless.

Requisitos de sistema para a aplicação de ambiente de trabalho

Requisito	macOS	Windows	Linux
Versão do sistema operativo	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ ou outra distribuição com glibc 2.35+ e GTK 3
Arquitetura	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Obrigatório	Obrigatório	Obrigatório
Espaço em disco	~200 MB para a aplicação, mais o diretório de dados do servidor	~200 MB	~200 MB

Os Macs com Intel não têm transferência pré-compilada. Em alternativa, compile a partir do código-fonte.

O diretório de dados do servidor cresce muito mais do que a aplicação. No primeiro arranque, o cc_server instala à força os modelos no dispositivo — embeddings de texto (~90 MB), diarização de falantes (~35 MB) e o modelo de voz selecionado (Parakeet TDT v3 por predefinição, ~600 MB; variantes Whisper 198–626 MB) —, além de uma compilação do code-server incorporada, e cada conversa de agente recebe uma worktree copy-on-write dos repos em que trabalha (git worktree simples no Windows). A voz não é opcional: sem o modelo ASR, as operações de reunião e de ditado não são servidas. A primeira transferência do modelo de voz ainda precisa de um reinício antes de a gravação ficar ativa.

A aplicação de ambiente de trabalho aponta o seu servidor para o diretório de suporte à aplicação por utilizador do sistema operativo. Um cc_server iniciado manualmente e sem --data-dir usa por predefinição <application data>/control-center — ~/Library/Application Support/control-center no macOS, %APPDATA%\control-center no Windows, $XDG_DATA_HOME/control-center (ou ~/.local/share/control-center) no Linux.

Transferência

Todos os artefactos abaixo provêm das GitHub Releases.

macOS (Apple Silicon)

Descarregue o Control-Center-<version>-arm64.dmg, abra-o e arraste o Control Center para Aplicações. A compilação está assinada com um Developer ID e notarizada pela Apple, pelo que abre normalmente.

Windows (x64, ARM64)

• Control-Center-<version>-x64-setup.exe: um instalador por utilizador.
• Control-Center-<version>-windows-x64.zip: um zip portátil.
• Control-Center-<version>-arm64-setup.exe: um instalador por utilizador.
• Control-Center-<version>-windows-arm64.zip: um zip portátil.

O Windows usa git worktree para os checkouts dos espaços (sem copy-on-write).

Linux (x86_64)

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

O AppImage contém informação de atualização, pelo que o AppImageUpdate ou o appimaged o podem atualizar para a versão mais recente no próprio local, descarregando apenas o que mudou.

Ambos são compilados no Ubuntu 22.04 e funcionam nele ou em qualquer versão mais recente (Debian 12, Fedora 36 e posteriores): ligam-se à glibc 2.35 e à libstdc++ do GCC 12 e usam a GTK 3 do sistema. As poucas bibliotecas de que um ambiente de trabalho convencional possa carecer viajam dentro deles, pelo que não é preciso instalar mais nada. O som — reprodução de reuniões, a paisagem sonora, o áudio dos rigs e os sons de notificação — é reproduzido através da libmpv do sistema (libmpv1 no Ubuntu 22.04, libmpv2 no Ubuntu e Debian mais recentes, mpv-libs no Fedora); sem ela, a aplicação arranca com esses controlos ocultos.

Servidor autónomo

Cada versão também traz o servidor headless isoladamente — 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 — a par das imagens cc-server, cc-webapp e cc-remote no GHCR. Consulte Executar um servidor headless.

O arquivo Linux é compilado no Ubuntu 22.04 e as suas bibliotecas nativas incluídas ligam-se à glibc 2.35 e à libstdc++ do GCC 12, pelo que precisa de um anfitrião pelo menos tão recente (Ubuntu 22.04, Debian 12, Fedora 36 ou posterior). Numa distribuição mais antiga, execute antes a imagem cc-server — um contentor traz o seu próprio userland, pelo que só o kernel tem de ser o seu.

Backend de agentes

O Control Center despacha agentes através de adaptadores. Existem dois, a lista é fixa e são detetados automaticamente — não há forma de registar outro.

O adaptador Control Center (built-in) não precisa de nenhuma CLI externa: o ciclo de agente é executado dentro do servidor e comunica com os fornecedores de modelos por HTTP, pelo que está sempre disponível. Ligue um fornecedor em Definições → Servidor → Fornecedores de modelos. A OpenAI, o Codex, o Cursor e o Kimi Code oferecem início de sessão no navegador; a Anthropic, o OpenRouter, o Google Gemini, o DeepSeek, o Mistral, o xAI, o z.ai e o Moonshot aceitam uma chave de API. O Codex e o Cursor são fornecedores deste executor, e não CLIs separadas. O z.ai aparece duas vezes de propósito: o z.ai é a plataforma aberta paga ao consumo, faturada contra o saldo da sua conta, enquanto o z.ai GLM Coding Plan é a subscrição. É a mesma chave de conta, mas o z.ai serve o plano a partir de um anfitrião diferente — cole uma chave do plano de programação no mosaico simples do z.ai e todos os pedidos devolvem 429 … "Insufficient balance or no resource package", porque o plano não tem saldo para gastar. Uma subscrição Claude Pro/Max não é um início de sessão na API da Anthropic; para esse plano, use antes o adaptador Claude Code. Aquilo que pode acrescentar nessa página é um fornecedor personalizado — qualquer endpoint compatível com OpenAI ou Anthropic (Ollama, LM Studio, vLLM, uma implementação privada) em Fornecedores personalizados → Adicionar fornecedor.

O outro adaptador envolve uma CLI externa:

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

A deteção sonda o PATH da máquina que executa o cc_server — a mesma máquina quando a aplicação de ambiente de trabalho executa o seu próprio servidor, o anfitrião remoto caso contrário. Instale aí a CLI do Claude Code, e não no cliente. O botão Atualizar dessa página volta a executar a sonda.

As listas de modelos são servidas em tempo real por cada fornecedor ligado; o models.dev fornece apenas metadados de preço e de janela de contexto. Consulte Gerir adaptadores e modelos.

Autenticação no GitHub

Uma credencial do GitHub é sua e reside no servidor, associada ao id do seu utilizador — não no porta-chaves do sistema operativo do cliente. Todos os dispositivos a partir dos quais inicia sessão usam a mesma, e nenhum outro membro a consegue ler.

Se o servidor tiver uma GitHub App registada (Criar a GitHub App), Definições → Espaço de trabalho → Perfil e identidade → Hospedagem de código oferece Entrar com o GitHub (um fluxo por código de dispositivo executado pelo servidor). Caso contrário, cole um token de acesso pessoal:

• Clássico: repo e read:org
• Granular: Contents e Pull requests (leitura e escrita), Checks e Actions (leitura)

Crie um em GitHub → Settings → Developer settings → Personal access tokens. O servidor sonda o token para obter o nome da conta tal como está guardado, pelo que a linha pode indicar «sessão iniciada como …»; uma sondagem falhada continua a guardar o token, e um erro de escrita ou um escopo em falta manifesta-se mais tarde como um pedido falhado.

O primeiro passo da configuração inicial é esta ligação. Depois disso, é no mesmo cartão que a substitui ou remove. O GitLab e o Bitbucket usam o mesmo cartão; consulte Ligar um host de código.

Escolher onde o servidor é executado

O Control Center é um cliente leve sobre um processo cc_server headless que detém a base de dados e faz todo o trabalho; Implementação e clientes explica o que essa separação significa para a aplicação de ambiente de trabalho, a web e o telemóvel.

No primeiro arranque, a aplicação de ambiente de trabalho pergunta Como o Control Center deve ser executado?:

• Executar nesta aplicação: a aplicação de ambiente de trabalho lança e supervisiona um cc_server nesta máquina e comunica com ele por loopback. Nada mais para configurar. Esta é a configuração que o Início rápido pressupõe.
• Ligar a uma instância remota: aponte a aplicação de ambiente de trabalho a um cc_server executado noutro sítio, com o seu URL de WebSocket, um id de dispositivo e uma chave de emparelhamento ou um código de convite de utilização única. Esse servidor detém os dados; esta aplicação de ambiente de trabalho apenas os apresenta.

Adicione ou alterne de servidor mais tarde em Definições → Servidor → Ligação e status. A alternância volta a ligar no próprio local — sem reiniciar. Um navegador não consegue executar um servidor, pelo que o cliente web é sempre remoto; consulte Ligar a um servidor remoto.

Para alojar um servidor por sua conta, siga Executar um servidor headless. Aborda a compilação do binário, a emissão de uma chave de emparelhamento antes do primeiro arranque e as flags --data-dir / --port / --bind.

Verificar a configuração

1. Definições → Servidor → Fornecedores de modelos lista ambos os adaptadores. «Control Center (built-in)» aparece como encontrado com a versão built-in; o Claude Code aparece como encontrado se a sua CLI estiver no PATH do anfitrião do servidor. Carregue em Atualizar se estiver em falta.
2. Definições → Espaço de trabalho → Repositórios lista os repos deste espaço de trabalho, e Adicionar repositório permite navegar pelas pastas do anfitrião do servidor.
3. Definições → Espaço de trabalho → Agentes lista os cinco agentes que o seu primeiro espaço de trabalho criou. Cada um precisa de um Adaptador e de um Modelo definidos antes de poder ser executado.
4. Definições → Servidor → Diagnóstico e privacidade indica os backends de sandbox que este anfitrião oferece, o estado do modelo de embedding e o registo.

Compilar a partir do código-fonte

As bibliotecas nativas são obrigatórias e não existe um modo degradado: uma biblioteca em falta é uma falha de arranque definitiva, e não um caminho mais lento. Prepare-as antes de qualquer outra coisa. Todos os comandos Flutter e Dart passam pelo fvm, porque a versão do SDK está fixada pelo 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

No macOS, o armazenamento seguro (início de sessão no GitHub, no Linear e no Google) precisa de a aplicação estar assinada por uma equipa Apple — basta um Apple ID gratuito, e é uma configuração única descrita em assinatura para desenvolvimento local. Sem ela, a aplicação continua a arrancar; apenas o armazenamento seguro fica indisponível. O Windows e o Linux não precisam de assinatura.

Para compilar o binário do servidor headless, prepare primeiro as bibliotecas nativas da mesma forma e, em seguida:

cd apps/cc_server
fvm dart build cli

O hook de compilação copia para o pacote tudo o que já esteja em build/natives/, pelo que compilar antes de preparar as bibliotecas produz um pacote sem bibliotecas nativas e um servidor que recusa arrancar.

Para o cliente web, use scripts/build_web.sh (--target remote para a PWA do telemóvel). É o que a CI executa: um simples flutter build web ignora o carimbo de identidade da compilação, a regeneração do Web Worker, o manifesto de implementação e a verificação do orçamento de recursos.