Doctor checks

Doctor lives at Settings ▸ Doctor. It runs the full readiness catalog against your install — one row per check, grouped into five sections — and this page is the complete per-check reference. The tables are generated from the same check catalog the app executes: the Guidance column is the exact hint a non-passing row shows in the app, and Fix action is the one-click button the row offers, when it has one.

If you are starting from a symptom rather than a check, use Troubleshooting instead — it maps the same catalog onto the problems you actually see, in order of likelihood.

How to read a row

• Pass — the real condition was verified: a binary answered on PATH, a service answered its health endpoint, a file exists where expected.
• Fail — genuine breakage that needs your action. Fail is reserved for a missing prerequisite or a missing or partial platform tree; nothing else fails.
• Info — a degraded or not-yet state with a precise cause: a service that is not running, an engine you have not installed, a key you have not set, or a check that cannot run because the service it needs is offline. "Not started yet" is never treated as broken — an install with several info rows can be perfectly healthy.

The Can report column lists which of these states each check can produce — a check that can never report fail cannot block you. Fix actions delegate to the exact same operations the Dashboard's Platform Health card uses; there is no separate Doctor-only mutation path.

Core

The Core group verifies the ground the platform stands on, in four layers:

1. Binaries — Python, Node.js, npm, and the agent CLI (claude) must be on PATH. These are the only checks (besides the platform tree) that can report fail, because nothing above them works without them. Fix by installing from the named vendor; the agent CLI is the one prerequisite Command Center cannot provision for you.
2. Python environments — the six component environments the daemons and MCP servers run in. Fix all six in one pass with the runtime provisioner (python scripts/provision_runtime.py from your install root) rather than creating them by hand; the guidance column shows the per-environment manual command if you prefer it.
3. Configuration — the environment file exists, the two optional Gemini key slots are present and loaded by the running services, and the agent tooling manifest (.mcp.json) has been generated. Key rows deep-link to Settings ▸ API Keys; see the configuration reference for what each key unlocks. A key saved while a service is running is invisible to it until that service restarts — the rows detect and name this state.
4. Platform integrity — the platform tree is present and complete at your install root, shipped doctrine (agents, skills, protocols) can be refreshed after an update without overwriting your edits, stray legacy config is flagged, the fleet-wake and session-resume hooks are installed, and the runtime provisioner stamp is newer than the last platform update.

Check	Can report	Fix action	Guidance
Python	pass · fail · info	—	install Python >= 3.11 from python.org (or use `py` on Windows)
Node.js	pass · fail · info	—	install Node.js >= 22 from nodejs.org — needed for the app UI + video engines
npm	pass · fail · info	—	ships with Node.js — reinstall Node if missing
Agent CLI (claude)	pass · fail · info	—	install Claude Code (claude.ai/code) — needed to use the MCP servers
shared-agent-memory venv	pass · fail	—	cd .claude/mcp-servers/shared-agent-memory && python -m venv .venv && .venv/Scripts/pip install -r requirements.txt
knowledge-base venv (also arcadedb + gemini-direct)	pass · fail	—	cd .claude/mcp-servers/knowledge-base && python -m venv .venv && .venv/Scripts/pip install -r requirements.txt
routines daemon venv	pass · fail	—	cd .claude/mcp-servers/routines-daemon && python -m venv venv && venv/Scripts/pip install -r requirements.txt
observer venv	pass · fail	—	cd .claude/mcp-servers/observer && python -m venv venv && venv/Scripts/pip install -r requirements.txt
email-server venv	pass · fail	—	cd .claude/mcp-servers/email-server && python -m venv .venv && .venv/Scripts/pip install -r requirements.txt
imagegen-daemon venv	pass · fail	—	cd .claude/mcp-servers/imagegen-daemon && python -m venv .venv && .venv/Scripts/pip install -r requirements.txt
.env configured	pass · fail	—	Settings ▸ API Keys writes this file automatically the first time you save a key
Gemini key (KB · memory · embeddings)	pass · info	Open API Keys	set GEMINI_API_KEY in Settings ▸ API Keys (free tier); keyword memory search and graph queries keep working without it
Gemini image key (imagegen)	pass · info	Open API Keys	set GEMINI_IMAGE_API_KEY in Settings ▸ API Keys (paid tier, imagegen only)
.mcp.json (agent config)	pass · info	Generate	writes .mcp.json from .env + the template with real absolute paths
Folder trust (Claude Code)	info	Trust this folder	if this is a brand-new folder, trust it once so Claude Code skips its own trust prompt
Platform tree present	pass · fail	Re-run lay-down here · Re-run lay-down	every daemon/MCP path below is resolving against nothing here — re-run the onboarding wizard's home-folder step, or point Settings ▸ project root at the folder Command Center actually laid the platform down into
Doctrine (agents · skills · protocols)	pass · info	Refresh doctrine	updates add new agents/skills/protocols but never overwrite one you changed — use this only to restore the shipped versions (your copies are backed up first)
Config layout	pass · info	Remove stray file	left by an early install — the shell reads app/.env; this file is unused and safe to remove
Fleet wake & session-resume hooks	pass · info	—	terminal session-resume and the fleet idle-nudge silently no-op without these — run `python .claude/hooks/cc_install_hooks.py` from the install root (writes machine-correct paths; new pane sessions pick them up)
Runtime provisioner	pass · info	—	run `python scripts/provision_runtime.py` from the install root to bootstrap uv + a pinned Python + all 6 component venvs in one pass

Daemons

One row per background service: the six app-managed daemons, the shared memory service, and the graph database. A stopped daemon is an info row, not a failure — the fix action starts it directly, and Dashboard ▸ Platform Health owns autostart so it comes up with the app from then on. Two rows work differently: Shared Memory is hosted inside an MCP server, so it starts and stops with your agent sessions rather than with a Start button; and ArcadeDB offers to provision a local, no-container instance the first time (a few minutes), after which it gets a plain Start like the rest.

Check	Can report	Fix action	Guidance
Observer	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Routines	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Imagegen	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Voice	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Knowledge Base	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
MCP Gateway	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Email	pass · info	Start	starts on launch when autostart is enabled (Dashboard ▸ Platform Health)
Shared Memory	pass · info	—	hosted inside the shared-agent-memory MCP server — started/stopped with Claude Code
ArcadeDB	pass · info	Provision · Start	check the external ArcadeDB box, or switch to provisioned-local in Settings ▸ Database

Engines

The two video engines are opt-in installs — a fresh install shows both as info rows, which is normal until you decide you want video. The fix action opens the Video tab, where the per-engine install (and its license gate) lives. Once installed, the row also verifies the render browser the engine needs; that fetches automatically on first render.

Check	Can report	Fix action	Guidance
Remotion	pass · info	Open Video tab	opt-in per-engine install — the license gate lives in its own tab, not here
Hyperframes	pass · info	Open Video tab	opt-in per-engine install — the license gate lives in its own tab, not here

Media

Media tooling manages itself: ffmpeg/ffprobe fetches automatically the first time footage preparation or a video engine needs it, and the Whisper speech-to-text models install once from Settings and serve both footage transcription and Voice's local speech-to-text. Both rows need the routines daemon up to report live state; while it is down they show an info row saying exactly that.

Check	Can report	Fix action	Guidance
ffmpeg / ffprobe	pass · info	Fetch now	will auto-fetch on first use once the daemon is running
Whisper models	pass · info	Open Speech-to-Text settings	shared by footage-prep transcription and Voice's local STT — installing once serves both

Account

One row: sign-in and subscription state. Not signed in is the shell baseline, shown as info — sign in from Settings ▸ Account to unlock Pro or Ultra features. When you are signed in, the row shows your tier and verification state, including the offline-grace window; Refresh re-verifies against the subscription service once you are back online.

Check	Can report	Fix action	Guidance
Sign-in / entitlement	pass · info	Sign in · Refresh	sign in from Settings ▸ Account to unlock Pro / Ultra features

When the app will not start

The same checks exist as a zero-dependency terminal script that needs no daemons and no Python packages: run python scripts/doctor.py from your install root. It is the fallback diagnostic for the rare case where the desktop app cannot boot at all — see Troubleshooting for the full escalation path.