Dashboard

Web UI started by serve. Use it to finish setup, add repositories, run init / sync, tune auto-review, watch jobs, and manage remote review tokens. Webhooks and the job worker run in the same process as the UI.

What it is for

Before you open

/dashboard redirects to /.

Webhook reachability

A fresh serve defaults to http://localhost:<port>/github/webhook, which GitHub cannot route to, so automatic reviews silently never arrive. Every repo Overview states this: a bad-address notice when the configured webhook URL host is loopback, 0.0.0.0, or a private range, and a "No webhook delivery yet" notice when nothing has been received. Both name the current URL and link to Settings.

Once a delivery has arrived, the page shows Last webhook delivery instead. The check only inspects the host. A single-label internal name and any public host pass, and serve and set still accept every URL they did before.

Adding a repository

Add repository runs the same read-only probe the CLI runs, server side, then shows the recommended init command with an estimated job count, token range, time and cost. Nothing is written until Add and start init is pressed, and that confirmation stores the plan's flags, limits and sources for the repo before the init job is queued, so the run matches what was approved.

The estimate says whether it used this repository's recorded jobs or the cm-dx-lab calibration, and whether it priced dollars from OpenRouter. See probe for how the recommendation is derived.

The same step asks who gets a review. It lists the review policy templates with a sentence each. The server default is selected and you decide. Leaving it on the server default keeps the repository following it.

Sign in

Open http://<host>:<port>/.

• Password: printed once on the first serve start, or set with --password=.... Change it in Settings.
• GitHub (optional): Continue with GitHub for the one allowed user. OAuth setup lives on serve.

Sessions use an HttpOnly, SameSite=Lax cookie (Secure on HTTPS).

Get started (/setup)

Onboarding checklist: models and API key, GitHub access, GitHub App. Each step links to Settings to fix gaps.

The home page carries the same idea as a Finish setup card until an install is complete: models and API key, GitHub App, webhook reachable (see Webhook reachability), first repository, first review, and CLI connected (a remote token exists). Each row links to the settings card that fixes it, the header shows how many are done, and the card disappears once all six are. A fresh install therefore says what to do next on its landing page, not only on /setup.

This page is not in the top bar. After sign-in, open http://<host>:<port>/setup, or use the Finish setup card on the home page. You can skip it and configure the same items under Settings at any time.

Routes

Top bar: Activity, Usage (/analytics), Settings, signed-in user.

Per-repo tabs: Overview, Pull requests, Knowledge, Remote reviews, Pushes, Repository settings. The overview carries the Commit watch card.

PR titles are not stored in app.db, so lists show #number only.

Settings (global)

Single page with sections (anchor links in the sidebar):

Saving PAT, App key, or OAuth values is validated against GitHub first. Bad scopes return 422 and nothing is stored.

Who gets a review

Each repository has a Who gets a review card under its Settings. It is where the review policy lives. The summary under In short says in plain sentences what the current choice does, and it updates as you edit the rules. Save stays off while the policy is not valid and the message says what to fix. A repository on Simple switches shows the three switches it had before. One on a policy shows How reviews run, which holds only the review scope and codegraph.

On Activity, Pull requests we skipped names the rule that decided, and a pull request that is waiting for a request has a Review now button.

Custom review instructions

Each repository also has a Custom review instructions card under its Settings. The text is added to the reviewer's built-in instructions for every review of that repository, as a CUSTOM REVIEW INSTRUCTIONS section. Leave it blank for none. Maximum characters caps the text, defaults to 8000, and 0 or -1 means no limit. The command line form and the per-run flags are on Review.

Clearing knowledge

Knowledge carries a Clear knowledge card: it deletes that repository's guides and saved settings, and a checkbox also drops the cached evidence (pull request listings, costs, clones and worktrees). The next Sync builds the knowledge from scratch. See Caching: Clearing.

Settings ends with Clear all knowledge, which does the same for every repository on the server. Repository records, review history and tokens stay. Both actions ask about work in flight first: queued jobs are canceled, a running review can be stopped, and a running sync is waited out because it cannot be interrupted. Nothing is deleted until that question is answered.

UI behavior

• Failed API calls show a toast and Retry.
• Toggles roll back if save fails.
• serve --inject-500 (or CM_INJECT_500=1) forces mutating /api/* calls except login to fail, for testing error UI.

Linux

Linux (WSL included) is the recommended platform for serve and the dashboard:

• SQLite FFI, advisory locks, and POSIX signals behave more predictably.
• Windows is supported but treated as unstable.
• serve logs a one-line warning when not on Linux.

Updating

Forward-only app.db migrations. Do not downgrade the CLI after a newer version has run.

1. Stop serve.
2. npm install -g co-maintainer@latest
3. Start serve again with the same data directory.

Restart after upgrading. Details also on serve: Updating.