Doctor

Doctor is the platform's self-check and its repair bench in one board. It probes everything the product depends on — what you chose to have installed, required binaries, the Python runtimes, background services, video engines, media tools, your account state, and what agents are currently allowed to do unattended — and shows one row per check. Open it at Settings ▸ Doctor.

It works when you are signed out and when your subscription has lapsed, by design: gating the repair surface on the fault it is meant to diagnose would be perverse.

How it runs

• Checks run automatically when you open the view; the Refresh button in the header re-runs everything.
• Rows fill in independently as each probe resolves — one slow or offline service never blocks the rest of the board.
• The header sub-line summarizes the board: all clear, or how many rows need attention and how many are informational. A healthy machine reads quietly — no wall of red.
• Each row shows a status, a detail line, and — where there is a one-click remedy — a fix button. Running a fix re-probes just that row, so you see the result immediately.
• A row is red only for a genuinely missing prerequisite. Everything else that is off, skipped, or not yet installed is informational, so an install with several info rows can be perfectly healthy.

The groups

Components

What Command Center sets up for you: the managed Python runtime, the knowledge graph, media tools, the video engine runtime, and local speech-to-text. This group is the always-available twin of the first-run wizard's Components step — the same choices, editable at any time — so anything you skipped during setup is one click from Enable. Everything is on unless you turn it off, and Skip only stops future automatic provisioning; it never removes what is already installed, and it never blocks an install you ask for explicitly.

Core

The prerequisites Command Center cannot provide for itself, plus the configuration spine: Node.js and npm, the agent CLI that runs your agents (and an optional second one), the terminal console on Windows, the environment file and API keys, the generated agent tooling manifest, folder trust, the platform tree, and the shipped doctrine set. Failing rows carry the exact install command or a fix action such as Generate (rebuild the agent config) or Trust this folder.

Runtime

Where the Python side is installed, updated, and repaired rather than merely reported: the bootstrap interpreter, uv, one row per background-service environment, and the provisioner itself. Provision builds everything in one pass; Re-provision picks up refreshed dependencies after an app update; a broken environment gets Repair. This is the group that replaces running a setup script by hand.

Daemons

The background services plus the graph database. A stopped daemon gets a Start button; an unprovisioned local database gets Provision. This group overlaps the Dashboard's Platform Health panel on purpose — Platform Health is the live control surface, Doctor is the diagnosis with remedies.

Engines

The video engines (Remotion and Hyperframes). These are opt-in installs — an absent engine is informational, not a failure, until you use the video features.

Media

The media toolchain: ffmpeg/ffprobe, a pinned Node for the video engines, and the Whisper transcription models. Fix actions fetch or install each directly, or take you to the Speech-to-Text settings for model downloads. Each row also carries a Prefer choice — Auto, System, or Managed — deciding which install wins when you have both a managed copy and one on your PATH.

Account

Sign-in and subscription state, with Sign in and Refresh actions that land on Settings ▸ Account. When verification is not current the row names the specific reason rather than guessing at one, and for the one reason a refresh cannot fix it offers Open account instead.

Agent control planes

The live state of each switch governing what agents may do unattended — window and view control, terminal control, calendar writes, email sending, and knowledge-graph writes. A plane you switched off shows as informational, never as a failure, and the row's fix action opens the card that owns them at Settings ▸ Terminals ▸ Agent control planes. The window and terminal planes read a live runtime value, so their rows can also report that a plane is on but paused. The model behind these switches is on Autonomy and controls.

When to run it

• After install — the install flow ends with a green Doctor board; see install.
• After changing configuration — keys, the database backend, daemon endpoints. Doctor verifies the change actually took.
• After an app update — the platform tree moves but your Python environments never do; the Runtime group tells you when they have drifted.
• When a view goes quiet — an offline daemon, a missing key, a skipped component, or a control plane you turned off shows up here with the remedy attached. The troubleshooting section is organized around exactly this flow: start with Doctor, then follow the symptom.

Related pages

• Doctor checks reference — every check in the catalog, one by one
• Troubleshooting — symptom-first fixes seeded from these checks
• Autonomy and controls — what the control planes govern
• Dashboard — the live daemon control surface
• Settings — where the configuration Doctor verifies is written