Instalar

O Control Center é executado de duas formas: como um aplicativo web em app.usectrl.dev, sem nada para baixar, ou como um aplicativo de desktop que você instala. São o mesmo aplicativo, com os mesmos recursos. A única diferença é onde o servidor é executado — e o aplicativo web não consegue executar um para você.

Usar no navegador

app.usectrl.dev é este aplicativo compilado para o navegador. Nada para instalar, nada para atualizar. Abra e conecte.

O que uma aba de navegador não consegue fazer é ser o servidor. Todo cliente — desktop, web, celular — é um renderizador leve sobre um cc_server headless que é dono do banco de dados e faz o trabalho, então o aplicativo web sempre fala com um servidor que você executa. Há duas formas de fornecer um servidor a ele:

Um servidor na sua própria máquina. Inicie o cc_server localmente e aponte o aplicativo web para ws://localhost:9030. Os navegadores tratam localhost como confiável, então isso não precisa de certificado nem de túnel. É a forma mais rápida de experimentar o aplicativo web, e seus dados nunca saem da sua máquina.

Um servidor em outra máquina. Como app.usectrl.dev é servido por HTTPS, um servidor não local precisa ser acessível por wss:// com um certificado em que o navegador já confie. O cc_server se recusa a vincular um endereço que não seja de loopback sem TLS, então escolha uma destas opções:

• forneça um certificado diretamente, com --tls-cert e --tls-key
• coloque-o atrás de um proxy reverso que termina o TLS e inicie-o com --insecure
• exponha-o por um túnel ou VPN que forneça o certificado — Tailscale, cloudflared ou equivalente. Configurações → Servidor → Conexão e status traz o túnel integrado, com adesão opcional, em Compartilhar este servidor.

Sempre que o servidor estiver atrás de um proxy, NAT ou túnel, defina --public-url como o endereço que os clientes devem realmente acessar. Por padrão ele usa a vinculação local, então sem isso os clientes tentam o host errado.

Vai hospedar sua própria cópia do cliente web?

O cc_server só aceita origens de navegador que estejam na lista --allowed-origins, cujo padrão é https://app.usectrl.dev. Adicione a sua própria origem lá se você hospedar a build web por conta própria. Clientes de loopback e nativos são sempre permitidos, independentemente dessa lista.

Algumas coisas continuam exclusivas do desktop, porque precisam de uma janela nativa ou dos próprios dispositivos de áudio da máquina: a pílula flutuante do modo foco, os avisos pop-up do sistema operacional (a central de notificações no aplicativo funciona em todos os lugares), “Gravar e vincular” a partir de um evento de calendário e refazer um resumo de reunião. Todo o resto — espaços, agentes, revisão de pull request, pipelines, tickets, memória e a própria gravação de reuniões — se comporta da mesma forma.

Para conectar o aplicativo web a um servidor, siga Conectar a um servidor remoto. Para hospedar o servidor, siga Executar um servidor headless.

Requisitos de sistema do desktop

Requisito	macOS	Windows	Linux
Versão do SO	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ ou outra distro 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 o aplicativo, mais o diretório de dados do servidor	~200 MB	~200 MB

Macs com Intel não têm download pré-compilado. Compile a partir do código-fonte.

O diretório de dados do servidor cresce mais que o aplicativo. Na primeira inicialização, 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 fala selecionado (Parakeet TDT v3 por padrão, ~600 MB; variantes do Whisper de 198–626 MB) — além de uma build do code-server incorporada, e cada conversa de agente recebe uma worktree copy-on-write dos repositórios em que trabalha (git worktree comum no Windows). A fala não é opcional: sem o modelo ASR, as operações de reunião e de ditado não são atendidas. O primeiro download do modelo de fala ainda exige uma reinicialização antes de a gravação acender.

O desktop aponta o servidor dele para o diretório de suporte a aplicativos por usuário do sistema operacional. Um cc_server iniciado à mão sem --data-dir usa por padrão <application data>/control-center — ~/Library/Application Support/control-center no macOS, %APPDATA%\control-center no Windows e $XDG_DATA_HOME/control-center (ou ~/.local/share/control-center) no Linux.

Download

Todos os artefatos abaixo vêm do GitHub Releases.

macOS (Apple Silicon)

Baixe Control-Center-<version>-arm64.dmg, abra-o e arraste o Control Center para Aplicativos. A build é assinada com um Developer ID e notarizada pela Apple, então ela abre normalmente.

Windows (x64, ARM64)

• Control-Center-<version>-x64-setup.exe: um instalador por usuário.
• Control-Center-<version>-windows-x64.zip: um zip portátil.
• Control-Center-<version>-arm64-setup.exe: um instalador por usuário.
• 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 carrega informações de atualização, então o AppImageUpdate ou o appimaged podem levá-lo à versão mais recente no lugar, baixando apenas o que mudou.

Os dois são compilados no Ubuntu 22.04 e rodam nele ou em qualquer versão mais nova (Debian 12, Fedora 36 e posteriores): eles linkam a glibc 2.35 e a libstdc++ do GCC 12 e usam a GTK 3 do sistema. As poucas bibliotecas que um desktop padrão pode não ter viajam dentro deles, então nada mais precisa ser instalado. O som — reprodução de reuniões, a paisagem sonora, o áudio dos rigs e os sons de notificação — toca pela libmpv do sistema (libmpv1 no Ubuntu 22.04, libmpv2 em Ubuntu e Debian mais novos, mpv-libs no Fedora); sem ela, o aplicativo inicia com esses controles ocultos.

Servidor autônomo

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

O arquivo do Linux é compilado no Ubuntu 22.04, e as bibliotecas nativas incluídas nele linkam a glibc 2.35 e a libstdc++ do GCC 12, então ele exige um host no mínimo tão novo quanto (Ubuntu 22.04, Debian 12, Fedora 36 ou posterior). Em uma distribuição mais antiga, use a imagem cc-server — um contêiner traz o próprio userland, então só o kernel precisa ser o seu.

Backend de agentes

O Control Center despacha agentes por meio de adaptadores. Existem dois, a lista é fixa e eles são detectados automaticamente — não há como registrar um terceiro.

O adaptador Control Center (built-in) não precisa de nenhuma CLI externa: o loop de agente roda dentro do servidor e fala com provedores de modelos via HTTP, então ele está sempre disponível. Conecte um provedor em Configurações → Servidor → Provedores de modelos. OpenAI, Codex, Cursor e Kimi Code oferecem login pelo navegador; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai e Moonshot exigem uma chave de API. Codex e Cursor são provedores deste executor, e não CLIs separadas. O z.ai aparece duas vezes de propósito: z.ai é a plataforma aberta de pagamento conforme o uso, cobrada do saldo da sua conta, enquanto z.ai GLM Coding Plan é a assinatura. É a mesma chave de conta, mas o z.ai atende o plano a partir de um host diferente — cole uma chave de plano de codificação no bloco simples do z.ai e toda requisição volta com 429 … "Insufficient balance or no resource package", porque o plano não tem saldo para gastar. Uma assinatura Claude Pro/Max não é um login da API da Anthropic; acesse esse plano pelo adaptador Claude Code. O que você pode adicionar nessa página é um provedor personalizado — qualquer endpoint compatível com OpenAI ou com Anthropic (Ollama, LM Studio, vLLM, uma implantaçã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 detecção sonda o PATH da máquina que executa o cc_server — a mesma máquina quando o desktop executa o próprio servidor, o host remoto caso contrário. Instale a CLI do Claude Code lá, e não no cliente. O botão Atualizar dessa página refaz a sondagem.

As listas de modelos são servidas ao vivo por cada provedor conectado; o models.dev fornece apenas metadados de preço e de janela de contexto. Consulte Gerenciar adaptadores e modelos.

Autenticação no GitHub

Uma credencial do GitHub é sua e fica no servidor, associada ao id do seu usuário — não no keychain do sistema operacional do cliente. Todos os dispositivos em que você entrar usam a mesma, e nenhum outro membro consegue lê-la.

Se o servidor tiver um GitHub App registrado (Criar o GitHub App), Configurações → Espaço de trabalho → Perfil e identidade → Hospedagem de código oferece Entrar com GitHub (um fluxo por código de dispositivo que o servidor executa). 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 em busca do nome da conta no momento em que ele é armazenado, para que a linha possa dizer “conectado como …”; uma sondagem malsucedida ainda salva o token, e um erro de digitação ou um escopo ausente aparece como uma requisição malsucedida mais tarde.

O primeiro passo do onboarding é esta conexão. Depois disso, o mesmo cartão é onde você a substitui ou a remove. O GitLab e o Bitbucket usam o mesmo cartão; consulte Conectar um host de código.

Escolher onde o servidor é executado

O Control Center é um cliente leve sobre um processo cc_server headless que é dono do banco de dados e faz todo o trabalho; Implantação e clientes explica o que essa divisão significa para o desktop, a web e o celular.

Na primeira inicialização, o desktop pergunta “Como o Control Center deve ser executado?”:

• Executar neste aplicativo: o desktop inicia e supervisiona um cc_server nesta máquina e fala com ele por loopback. Nada mais a configurar. É a configuração que o início rápido pressupõe.
• Conectar a uma instância remota: aponte o desktop para um cc_server em execução em outro lugar, com a URL do WebSocket, um id de dispositivo e uma chave de emparelhamento ou um código de convite de uso único. Esse servidor é dono dos dados; este desktop apenas os renderiza.

Adicione ou alterne servidores depois em Configurações → Servidor → Conexão e status. A alternância reconecta no mesmo lugar — sem reiniciar. Um navegador não consegue executar um servidor, então o cliente web é sempre remoto; consulte Conectar a um servidor remoto.

Para hospedar um servidor por conta própria, siga Executar um servidor headless. Ele cobre a compilação do binário, a emissão de uma chave de emparelhamento antes da primeira inicialização e as flags --data-dir / --port / --bind.

Verificar sua configuração

1. Configurações → Servidor → Provedores de modelos lista os dois adaptadores. “Control Center (built-in)” aparece como encontrado com a versão built-in; o Claude Code aparece como encontrado se a CLI dele estiver no PATH do host do servidor. Pressione Atualizar se estiver faltando.
2. Configurações → Espaço de trabalho → Repositórios lista os repos deste espaço de trabalho, e Adicionar repositório navega pelas pastas do host do servidor.
3. Configurações → Espaço de trabalho → Agentes lista os cinco agentes que o seu primeiro espaço de trabalho semeou. Cada um precisa de um Adaptador e de um Modelo definidos antes de poder ser executado.
4. Configurações → Servidor → Diagnóstico e privacidade informa os backends de sandbox que este host oferece, o estado do modelo de embeddings e o log.

Compilar a partir do código-fonte

As bibliotecas nativas são obrigatórias e não existe modo degradado: uma ausência é uma falha de inicialização dura, não um caminho mais lento. Prepare-as antes de qualquer outra coisa. Todo comando do Flutter e do Dart passa pelo fvm, porque a versão do SDK é fixada pelo repositório.

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 (login do GitHub, do Linear e do Google) exige que o aplicativo seja assinado por uma equipe da Apple — um Apple ID gratuito basta, e é uma configuração única descrita em assinatura para desenvolvimento local. Sem isso o aplicativo ainda inicia; apenas o armazenamento seguro fica indisponível. Windows e Linux não precisam de assinatura.

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

cd apps/cc_server
fvm dart build cli

O hook de build copia para o pacote tudo o que já estiver em build/natives/, então compilar antes de preparar as nativas gera um pacote sem nativas e um servidor que se recusa a iniciar.

Para o cliente web, use scripts/build_web.sh (--target remote para a PWA do celular). É o que a CI executa: um flutter build web simples pula o carimbo de identidade da build, a regeneração do Web Worker, o manifesto de implantação e a verificação de orçamento de assets.