Settings

The single write surface for configuration — every tab, what it edits, and when a change applies.

Settings is the one place configuration gets written. It is deliberately the only view that cannot pop out into its own window — one window, one writer, no racing edits. Everything it saves lands in a file under your install root or your per-user application data; the configuration reference maps every file and key.

The one idea to carry into every tab: where a setting lives decides when it applies. Secrets and wiring are restart-bound — save, then restart the affected service (Dashboard ▸ Platform Health). Runtime knobs are hot — they apply on the next operation with no restart. Each tab below is labeled accordingly.

How the rail is organized

A left rail lists the tabs, grouped into labeled sections in everyday-reach order — General, Services & Keys, Terminals, Voice, System, and App with Themes pinned last. The pane on the right shows the active tab. The headings below follow the rail exactly, so what you read here is what you scroll past on screen.

General

Account

Desktop sign-in and your plan state. Sign in, refresh your entitlement, or sign out; the tab also shows which modules your tier unlocks — a locked module shows a lock panel in place of its view. Gating here is coarse by design; see tiers for what Pro and Ultra include.

Two more cards live here:

First-run setup re-opens the setup wizard — workspace, components, secrets, knowledge graph, runtime. Re-walking is safe: every step detects what is already configured and shows you that instead of redoing it, and nothing is reset, deleted, or signed out. This is the way back if you skipped a component during onboarding and want it now.
Privacy & data states what the app stores locally and what leaves your machine.

Project

The workspace root — the folder tree the whole platform operates on. Set at first run by the wizard; change it here only deliberately, since every view and daemon resolves paths against it.

The Paths & Outputs card sits in this tab: relocate where each output tree is written — rendered videos, generated images, exported products, harvested reports. Hot: stored in the runtime config, read by the owning service on its next write. Blank means the default location under the workspace root.

Updates

A toggle for automatic checking, the current version, and a manual check.

With automatic checking on, Command Center looks for a new version at launch and every four hours, and tells you when one is available.
Updates are never installed on their own. Installing restarts the app, which would end running agents and terminals, so that step is always yours.
The manual Check for updates button stays available whether or not automatic checking is on.

See how updates work.

Services & Keys

Database

The knowledge-graph backend behind Cortex. Choose between the provisioned-local server the app runs on your own machine (no extra installs) and an external instance you host yourself, and manage the connection settings for either. The backend choice itself is a hot setting; agent sessions pick up a switch after the agent tooling restarts, and the tab spells out what applying costs. See the knowledge graph.

API Keys

The model and service keys the platform uses. Restart-bound: keys live in the environment file, and the panels only ever report whether a key is set — the values stay on your machine. Doctor has dedicated rows that tell you which capabilities are waiting on which key.

Email

Named for its dominant content — the multi-account email registry that the Email cockpit and the email agent both read. The newsletter harvest inbox and the X API fallback credentials live in the same tab. Restart-bound, same as keys.

Daemons

The endpoints and ports of the background services. Defaults are correct for a standard install; this tab exists for the day you need to move a port. Restart-bound.

It also carries Main session MCP transport, which decides how the agent terminals Command Center launches inside your workspace root reach their tool servers:

Own servers (stdio) — the default. Each session starts its own copy of the tool servers.
Shared gateway — those sessions route through the one shared gateway instead, health-gated, falling back to their own servers if the gateway is not answering.

The change takes effect on the next in-root terminal launch, and a session you started outside Command Center always uses its own servers.

Terminals

The behavior of the Terminals workspace, and the switches that decide what agents may do unattended:

Agent control planes — one switch per plane: window and view control, calendar control, email sending, knowledge-graph writes, and terminal control. Each flip applies to the next call with nothing to restart, and persists to the runtime config. Terminal control is the most powerful of them — it can run shell commands. One behaves differently from the rest and is worth knowing before you flip it: Email sending stops your own composer too. While it is off, no mail leaves the machine, agent or human, and drafts still save. Read Autonomy and controls for what each plane refuses when it is off and why they all fail open.
Mission fleet + lint — the fleet worker cap and mission-lint thresholds. Hot: re-read fresh on every fleet operation. Blank means the built-in default.
Session resume — whether agent terminals automatically reload the exact conversation they were running when the app restarts. Capture always runs; this switch only controls automatic resume, and a workspace's context menu offers Resume sessions on demand. A companion switch, Keep agents warm, decides whether opening the Terminals view mounts every workspace at once or resumes each one on first visit.
Drag to reorder — how pane docking behaves when you drag panes, and how wide the dock zones are.

Voice

An Ultra surface: launchers into the Voice view's own settings — connections and providers, the chat settings, and the realtime voice settings. On a plan that does not include Voice the tab renders a lock panel instead of the launchers.

Speech-to-Text

The system-wide dictation setup — engine, models, and the push-to-talk behavior toggled from the title bar. The tab is open to everyone; the OS-global push-to-talk shortcut it configures registers on Pro and above, so on the unsubscribed baseline the key combination is simply never bound.

System

Four surfaces reachable from Settings. Doctor, MCP Servers, and Data Layer each render their complete view inside the pane and have their own guide; the Activity Log's tab here is narrower than the others.

Doctor — health checks with fixes. Deliberately ungated: gating the repair surface on an entitlement problem would be perverse, so Doctor stays available on any signed-in state.
MCP Servers — the tool servers agent sessions load. A Pro surface; on the unsubscribed baseline the tab shows a lock. See MCP Servers.
Data Layer — your local stores and their backups. Also Pro, with the same lock behavior.
Activity Log — this tab holds only the retention window: how many hours of events the durable store keeps before the hourly cleanup removes them. The log itself is read from Dashboard ▸ Live ▸ Log, and is documented at Activity Log.

App

Themes

The full theme picker — all six themes as swatch tiles. The sidebar footer carries a quick switch with the three pinned themes; this tab is where the rest live.

Choosing an agent engine

There is no engine control in Settings, and that is worth stating plainly because it is the first place people look.

Command Center is built and documented around Claude, and that is the path every page here assumes. A second agent CLI — OpenAI's Codex — also ships, and Doctor reports it as an optional binary. Where you pick between them is always the surface that launches the work:

Where	What it sets
The New Terminals dialog	The engine for a pane or a whole workspace, alongside its model and effort
The Routines tab bar	An install-wide default, plus a per-routine choice in the routine's own file
Products	A per-product default and a per-phase override for the pipeline

Anything that names no engine resolves to Claude, so an install that never touches these controls behaves exactly as documented. Treat the second engine as a per-surface choice rather than a whole-install substitution: keep your Claude subscription connected as the primary engine.

After you change something

Hot — the Paths & Outputs card in Project, Terminals, Themes, and the Activity Log retention window. Done; the change is already live or applies on the next operation.
Restart-bound — API Keys, Email, Daemons, Database connection details, and the project root. Restart the affected service from Dashboard ▸ Platform Health; agent sessions pick the change up on their next launch.
Not sure it took? Run Doctor — it verifies keys, config, daemons, and the database against what you just changed.

Configuration reference — every file, every key, every reload cost
Autonomy and controls — what the control planes govern
Doctor — verify a configuration change end to end
How updates work

On this page