Configuration & reference
Every setting, where secrets live, how a machine move works, and what updates verify before they install.
config.toml
Settings live in config.toml in your platform's config directory, and everything
in it is also editable in Settings. The file is read by every Muster process — the app, the
daemon, the MCP server and the CLI.
| Key | Controls |
|---|---|
default_shell | Shell for new terminals; the platform default when unset. |
scrollback_lines | Lines each terminal retains in memory. |
[scrollback] persist, max_lines | On-disk scrollback across restarts (off by default) and its cap. |
[terminal] font, font_size, theme | Terminal appearance. |
[daemon] keep_running | Keep sessions alive with the window closed. Off by default; takes effect on the next launch. |
[automations] enabled | Global flow kill switch. |
[notifications] enabled, sound, on_states | Desktop notifications, and which task transitions fire them. |
[update] manifest_url | Where update checks look. |
[external_editor] editor, command, open_behavior | What "open in editor" launches. |
[session] restore_layout | Restore panes and layouts on launch. |
[keys] indexed_jumps | Numbered jump shortcuts. |
secret_backend | keyring, database or session-only. |
log_level | Tracing filter, e.g. info or muster=debug. RUST_LOG overrides it. |
keybindings | Per-action shortcut overrides. Defaults use Mod — Cmd on macOS, Ctrl elsewhere. On Windows and Linux the app-action defaults sit on Ctrl+Shift (and Ctrl+Alt), following the terminal convention, so bare Ctrl+C/D/K/W and friends always reach your shell. |
tool_isolation | Which tools get a per-profile config directory. |
post_create_hooks | Commands to run after a worktree is created, per project. |
onboarding_completed | Whether the first-run wizard has been finished or skipped. |
secret_backend under a
[secrets] table, say — is still valid TOML and would otherwise leave the setting
silently at its default.Secret backends
Database passwords, API tokens and SSH key references are never written to config files in plaintext. You choose where they live, and the choice applies to every Muster process.
| Backend | Persistence | Trade-off |
|---|---|---|
keyring | OS keychain | Strongest at rest. May prompt for your login password. The default. |
database | Encrypted in Muster's database | Permanent and keychain-free. Each secret is sealed with XChaCha20-Poly1305 under a key derived (HKDF-SHA256) from two inputs: this machine's hardware id, and a 32-byte random device secret kept in a 0600 sidecar file next to muster.db, never inside it. Weaker at rest than the keychain — anyone who can run code as you on this machine can read the sidecar and re-derive the key — but never plaintext, and a copy of muster.db on its own is inert. The trade: lose the sidecar and you lose every secret in the database, so restoring muster.db without it means re-entering them all. |
session-only | RAM, wiped on quit | Nothing touches disk or the keychain. You re-enter secrets each launch, and separate processes cannot read them. |
session-only is genuinely per-process: the MCP server and the
automations daemon cannot read secrets held in the app's memory, and say so rather than failing
silently.Terminal, panes & session
Terminals are first-class: split panes, saved layouts, and a session that returns exactly as you left it — panes, layouts, drafts and selections.
- Sessions can survive the UI. Turn on
[daemon] keep_running, which is off by default, and relaunch: terminals are then owned by a background daemon, so closing and reopening the window reattaches to the same live processes — an agent that was mid-run is still mid-run, scrollback intact. The relaunch is required because the terminal backend is chosen once at startup, so ticking the box cannot move the session you are already in. - Scrollback retention is configurable, and can optionally persist across restarts. Persistence is off by default because stored terminal output can contain secrets.
- Search within a pane's scrollback, or globally across tasks, files, hosts and databases — regular expressions included.
- Command palette with fuzzy ranking and recents; every global action is bindable, and a malformed or conflicting chord is rejected when saved rather than silently disabling a shortcut.
What leaves your machine
Four things go to us, and that is the complete list:
- Licence activation, once, when you paste your key.
- The daily license validity check.
- Update checks against the release manifest.
- Starting a trial, once per account: your email comes from the account you sign in with, and the card you save goes to Stripe, never to us. No device id is sent — that arrives only when you activate the trial key (item 1).
Your code, databases, credentials, prompts and agent output are never proxied, stored or seen by us. Database and SSH connections go directly from your machine to your servers; tracker calls go directly to your tracker.
Two more requests, and you start both of them
- Testing an AI account reads the stored key and calls that vendor's models endpoint with it, to confirm the key works. The key goes to the vendor, not to us.
- Testing an MCP server over HTTP posts a
tools/listJSON-RPC probe, with whatever headers you entered, to the URL you entered.
Neither fires on its own — both are a button in Settings.
Logs are written locally and pass through a redactor that scrubs tokens, passwords and authorization headers before anything is written — including the background daemon's logs.
Moving to another machine
Export a config bundle: your profiles, AI accounts and hosts, as a single file.
Your config.toml settings ride along inside it for reference, but importing
does not apply them — silently replacing every setting on the new machine is not
something an import of profiles should do, so only profiles, accounts and hosts are written.
- Stored secrets are never exported. Tokens and passwords Muster holds are
omitted — the profile, account and host rows carry only references to them — and any
environment value whose key or value looks sensitive is scrubbed to a placeholder.
One gap: a literal value you pasted into a profile's environment overlay is
scrubbed only on a best-effort match, so a short, ordinary-looking password under an
unremarkable key name (
DB_PW = "hunter2") is exported in plaintext. Treat a bundle as sensitive material. - References are kept, so the importing machine knows precisely which secrets to ask you to re-enter, and what each is for.
- Importing restores the rows — profiles, accounts and hosts arrive with their original identities, so a re-entered token attaches to the right thing.
- Importing twice is safe. The same bundle applied again updates in place rather than creating duplicates.
Your license does not travel in the bundle: it is bound to the device it was activated on.
Updates
The app checks a manifest and can install a new version in place.
- Signature required. A release build verifies an Ed25519 signature over the downloaded artefact against a key compiled in at build time.
- It fails closed. A missing signature is refused outright — never downgraded to "the checksum matched", because a checksum published beside the download proves integrity, not authenticity. A failed verification deletes the download and installs nothing.
- Atomic swap, with a rollback path if the replacement cannot complete.
Release builds also refuse to be produced with a development signing key, so a build that would trust forged licenses cannot be created by accident.
New here? Start the 7-day trial — every feature, card up front, $0 today, key on screen. Or buy outright: $39 once per device, no subscription.