Install

Control Center runs two ways: as a web app at app.usectrl.dev, with nothing to download, or as a desktop app you install. They are the same application with the same features. The only difference is where the server runs — and the web app cannot run one for you.

Use it in your browser

app.usectrl.dev is this application compiled for the browser. Nothing to install, nothing to update. Open it and connect.

What a browser tab cannot do is be the server. Every client — desktop, web, phone — is a thin renderer over a headless cc_server that owns the database and does the work, so the web app always talks to a server you run. Two ways to give it one:

A server on your own machine. Start cc_server locally and point the web app at ws://localhost:9030. Browsers treat localhost as trustworthy, so this needs no certificate and no tunnel. It is the quickest way to try the web app and your data never leaves your machine.

A server on another machine. Because app.usectrl.dev is served over HTTPS, a non-local server has to be reachable over wss:// with a certificate the browser already trusts. cc_server refuses to bind a non-loopback address without TLS, so choose one of:

• give it a certificate directly, with --tls-cert and --tls-key
• put it behind a TLS-terminating reverse proxy and start it with --insecure
• expose it through a tunnel or VPN that supplies the certificate — Tailscale, cloudflared, or similar. Settings → Server → Connection & status has the built-in tunnel opt-in under Share this server.

Whenever the server sits behind a proxy, NAT, or tunnel, set --public-url to the address clients should actually dial. It defaults to the local bind, so without it clients try the wrong host.

Hosting your own copy of the web client?

cc_server only accepts browser origins on its --allowed-origins list, which defaults to https://app.usectrl.dev. Add your own origin there if you self-host the web build. Loopback and native clients are always allowed regardless of that list.

A few things stay desktop-only, because they need a native window or the machine’s own audio devices: the floating focus-mode pill, OS notification toasts (the in-app notification centre works everywhere), “start recording & link” from a calendar event, and re-running a meeting summary. Everything else — spaces, agents, pull-request review, pipelines, tickets, memory and meeting recording itself — behaves the same.

To connect the web app to a server, follow Connect to a remote server. To host the server, follow Run a headless server.

Desktop system requirements

Requirement	macOS	Windows	Linux
OS version	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ or another distro with glibc 2.35+ and GTK 3
Architecture	Apple Silicon (arm64)	x64	x86_64
Git	Required	Required	Required
Disk space	~200 MB for the app, plus the server’s data directory	~200 MB	~200 MB

Intel Macs have no prebuilt download. Build from source instead.

The server’s data directory outgrows the app. On its first start cc_server force-installs the on-device models — text embeddings (~90 MB), speaker diarization (~35 MB) and the selected speech model (Parakeet TDT v3 by default, ~600 MB; Whisper variants 198–626 MB) — plus an embedded code-server build, and every agent conversation gets a copy-on-write worktree of the repos it works on (plain git worktree on Windows). Speech is not optional: without the ASR model, meeting and dictation ops are not served. The first download of the speech model still needs one restart before recording lights up.

The desktop points its server at the OS per-user application-support directory. A cc_server started by hand with no --data-dir defaults to <application data>/control-center — ~/Library/Application Support/control-center on macOS, %APPDATA%\control-center on Windows, $XDG_DATA_HOME/control-center (or ~/.local/share/control-center) on Linux.

Download

Every artifact below comes from GitHub Releases.

macOS (Apple Silicon)

Download Control-Center-<version>-arm64.dmg, open it, and drag Control Center to Applications. The build is signed with a Developer ID and notarized by Apple, so it opens normally.

Windows (x64)

• Control-Center-<version>-x64-setup.exe: a per-user installer.
• Control-Center-<version>-windows-x64.zip: a portable zip.

Windows uses git worktree for space checkouts (no copy-on-write).

Linux (x86_64)

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

The AppImage carries update information, so AppImageUpdate or appimaged can bring it to the latest release in place, downloading only what changed.

Both are built on Ubuntu 22.04 and run on it or anything newer (Debian 12, Fedora 36 and later): they link glibc 2.35 and the libstdc++ of GCC 12 and take GTK 3 from the system. The few libraries a stock desktop may lack travel inside them, so nothing else needs installing. Sound — meeting playback, the soundscape, rig audio and notification chimes — plays through the system’s libmpv (libmpv1 on Ubuntu 22.04, libmpv2 on newer Ubuntu and Debian, mpv-libs on Fedora); without it the app starts with those controls hidden.

Standalone server

Each release also carries the headless server on its own — cc_server-<version>-macos-arm64.tar.gz, cc_server-<version>-linux-x64.tar.gz, cc_server-<version>-windows-x64.zip — alongside the cc-server, cc-webapp and cc-remote images on GHCR. See Run a headless server.

The Linux archive is built on Ubuntu 22.04 and its bundled native libraries link glibc 2.35 and the libstdc++ of GCC 12, so it needs a host at least that new (Ubuntu 22.04, Debian 12, Fedora 36 or later). On an older distribution run the cc-server image instead — a container brings its own userland, so only the kernel has to be yours.

Agent backend

Control Center dispatches agents through adapters. There are two of them, the list is fixed, and they are detected automatically — there is no way to register another one.

The Control Center (built-in) adapter needs no external CLI: the agent loop runs inside the server and talks to model providers over HTTP, so it is always available. Connect a provider under Settings → Server → Model providers. OpenAI, Codex, Cursor and Kimi Code offer a browser sign-in; Anthropic, OpenRouter, Groq, Google Gemini, DeepSeek, Mistral, xAI, z.ai and Moonshot take an API key. Codex and Cursor are providers on this runner, not separate CLIs. z.ai is listed twice on purpose: z.ai is the pay-as-you-go open platform, billed against your account balance, while z.ai GLM Coding Plan is the subscription. It is the same account key, but z.ai serves the plan from a different host — paste a coding-plan key into the plain z.ai tile and every request comes back 429 … "Insufficient balance or no resource package", because the plan has no balance to spend. A Claude Pro/Max subscription is not an Anthropic API login; reach that plan through the Claude Code adapter instead. What you can add on that page is a custom provider — any OpenAI- or Anthropic-compatible endpoint (Ollama, LM Studio, vLLM, a private deployment) under Custom providers → Add provider.

The other adapter wraps an external CLI:

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

Detection probes the PATH of the machine running cc_server — the same machine when the desktop runs its own server, the remote host otherwise. Install the Claude Code CLI there, not on the client. The Refresh button on that page re-runs the probe.

Model lists are served live by each connected provider; models.dev only supplies price and context-window metadata. See Manage adapters and models.

GitHub authentication

A GitHub credential is yours and lives on the server, keyed by your user id — not in the client OS keychain. Every device you sign in from uses the same one, and no other member can read it.

If the server has a GitHub App registered (Create the GitHub App), Settings → Workspace → Profile & identity → Code hosting offers Sign in with GitHub (a device flow the server runs). Otherwise paste a personal access token:

• Classic: repo and read:org
• Fine-grained: Contents and Pull requests (read and write), Checks and Actions (read)

Create one at GitHub → Settings → Developer settings → Personal access tokens. The server probes the token for the account name as it is stored, so the row can say “signed in as …”; a failed probe still saves the token, and a typo or missing scope shows up as a failed request later.

Onboarding’s first step is this connection. After that the same card is where you replace or clear it. GitLab and Bitbucket use the same card; see Connect a code host.

Choose where the server runs

Control Center is a thin client over a headless cc_server process that owns the database and does all the work; Deployment and clients explains what that split means for the desktop, web and phone.

On first launch the desktop asks “How should Control Center run?”:

• Run in this app: the desktop spawns and supervises a cc_server on this machine and talks to it over loopback. Nothing else to configure. This is the setup the quick start assumes.
• Connect to a remote instance: point the desktop at a cc_server running elsewhere with its WebSocket URL, a device id, and either a pairing key or a one-time invite code. That server owns the data; this desktop only renders it.

Add or switch servers later under Settings → Server → Connection & status. Switching reconnects in place — no restart. A browser cannot run a server, so the web client is always remote; see Connect to a remote server.

To host a server yourself, follow Run a headless server. It covers building the binary, minting a pairing key before first start, and the --data-dir / --port / --bind flags.

Verify your setup

1. Settings → Server → Model providers lists both adapters. “Control Center (built-in)” reads found with version built-in; Claude Code reads found if its CLI is on the server host’s PATH. Press Refresh if it is missing.
2. Settings → Workspace → Repositories lists this workspace’s repos, and Add repository browses the server host’s folders.
3. Settings → Workspace → Agents lists the five agents your first workspace seeded. Each one needs an Adapter and a Model set before it can run.
4. Settings → Server → Diagnostics & privacy reports the sandbox backends this host offers, the embedding model’s state, and logging.

Build from source

Native libraries are required and there is no degraded mode: a missing one is a hard boot failure, not a slower path. Stage them before anything else. Every Flutter and Dart command goes through fvm, because the SDK version is pinned by the 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

On macOS, secure storage (GitHub, Linear and Google sign-in) needs the app signed by an Apple team — a free Apple ID is enough, and it is a one-time setup described under local development signing. Without it the app still launches; only secure storage is unavailable. Windows and Linux need no signing.

To build the headless server binary, stage the natives the same way first, then:

cd apps/cc_server
fvm dart build cli

The build hook copies whatever is already in build/natives/ into the bundle, so building before staging yields a bundle with no natives and a server that refuses to start.

For the web client use scripts/build_web.sh (--target remote for the phone PWA). It is what CI runs: a plain flutter build web skips the build-identity stamp, the Web Worker regeneration, the deploy manifest, and the asset-budget check.