Settings reference

Settings is seventeen tabs in four groups. Ctrl+Alt+S opens it, and the sidebar is the only navigation - a tab that is several screens long is a real collection of pages rather than one scrolling document.

Workspace

Tab	What it owns
General	Application-wide behaviour that does not belong to a subsystem below.
Projects	The Project registry, and most per-Project switches: the control plane opt-ins, the land queue, and the authority fields that decide what an agent may do in this repository.
Terminals	The PTY supervisor, session recovery and its checkpoints, multi-device input, and terminal behaviour.
Git	Polling cadence, comparison refs, and worktree defaults.
Processes	Process discovery, preview ownership, and preview lifetime.

Agents

Tab	What it owns
Harnesses	Each harness, its detection state, the executable it resolved to, an override for that path, and launch profiles.
Accounts	Three pages: Provider accounts (saved logins and switching), Model provider (the endpoint and key), and Models - the single place every model setting in the application is edited.
Prompt queue	Six pages: Overview, Auto-delivery, Approvals, Agent messaging, Agent actuation, and Queue history.
Automation	Status only, and a link to the Automation dashboard's Policy tab, which is the one editor that can turn an automation off.
Usage	Spend views and the budget caps.

Interface

Tab	What it owns
Appearance	Theme, density, which drawer tabs are drawn and in what order, and whether the rail shows icons or titles.
Input	Five pages: Pointer, Mobile terminal, Clipboard history, Touch gestures, and Keyboard shortcuts.
Text editor	The note and Markdown editor's own behaviour.
Voice	Five pages: Read aloud, Talk and dictation, Voice commands, Mux assistant, and Diagnostics.

System

Tab	What it owns
Alerts	Notification preferences, per device, plus sounds.
Remote	The listeners, the Tailscale integration, and Serve. This is where the access boundary is configured, and the unsupported bindings are refused rather than merely warned about.
Diagnostics	Health, logs, the software-update check, and the frozen-app rebuild on Windows.

Which scope a setting has, and why

GlobalWritten to config.toml in the data directory. This is the daemon's own configuration, and it is what a second device sees too.
Per ProjectAnything that decides how much swe-mux does: the control plane, automation, the scan timeline, the code graph, the land queue, and the authority fields. The point is that most of your Projects are not the one you want a scan budget spent on.
Per deviceWritten by the browser, in settings.json. Autoplay, gestures, notification preferences, the theme - the things that are properties of the screen you are at rather than of the install.

Two rules the panel is built on

Two controls never write one key. Where a value is shown in a second place, it is read-only and links to its editor. That is why every feature tab names its model without offering a picker.
A gate can only turn something on. A surface that needs a switch enabled can enable it in place; turning it off is always the owning editor's. That asymmetry is what makes a write reachable from a drawer pane safe.

Editing the file directly

config.toml in the data directory is the same configuration, and it is schema-versioned with a pre-migration backup written beside it. Settings is the better route because it validates; a config that does not validate is the single most common reason a daemon will not start, and mux doctor names it as the first failing check when it happens.