Config files

Almost everything Brisal keeps on disk — providers, models, agents, workspace metadata — is app-owned: you create and change it through the UI, and the files are an implementation detail you never need to open. Two formats are readable and editable by hand: a theme palette (below) and a workspace’s keybindings. For both, the UI is the supported path; the file is just the source of truth behind it.

Theme palettes

A palette is a plain CSS file listing color tokens — one custom property per line. Brisal ships one built-in palette (default) and lets a workspace select one; you can also drop your own .css file into a themes folder (see below) and it appears in the palette picker. See Appearance & theming for how selection and the two theming axes (light/dark × palette) work — this page is the field reference for the file itself.

File shape

A palette defines the same tokens twice: once under :root for the light variant and once under .dark for the dark variant. Every value is a plain hex color (or a number, for the opacity and radius tokens):

:root {
  --background: #fdf6f1;
  --foreground: #1f120a;
  --primary: #ea580c;
  /* …one line per token… */
}

.dark {
  --background: #120a07;
  --foreground: #f7ece2;
  --primary: #ff8205;
  /* …the same tokens, dark values… */
}

Surface & text tokens

The core colors for panels, text, and controls. Each *-foreground token is the text/icon color that sits on the matching surface.

Sidebar tokens

The sidebar is themed separately so it can read as its own surface. The set mirrors the core tokens above:

Backdrop tokens

Brisal paints a soft “aurora flame” gradient and a faint hex-grid behind the content. These tokens tune it — the defaults are deliberately muted, especially on dark, and turning the opacities up quickly gets loud.

Chart tokens

Five colors used in sequence for any data visualization.

Adding your own palette

Save a .css file into a themes folder and it joins the palette picker alongside the built-in. Two locations exist:

The palette name is the file’s stem (ember.css → the “ember” palette). If a workspace and the system tier both define a palette of the same name, the workspace file wins. The built-in default is always available.

Naming rules. A palette name must be lowercase a–z, digits, and single hyphens (my-theme.css ✓). Files with capitals, spaces, or a non-.css extension are skipped and won’t appear in the picker.

Brisal never renders broken. If a selected palette is missing or unreadable it falls back to default (with a toast); a font size outside 12–20 is clamped rather than rejected; a file with no :root/.dark blocks is treated as absent. A bad theme file degrades gracefully — it never blanks the UI.

Keybindings

Each workspace can carry a keybindings.toml that overrides the default keyboard shortcuts. The supported way to change bindings is the Settings → Hotkeys editor — this file is what it writes, and what you’d hand-edit for the same effect.

The file is a sparse override: it lists only what differs from the shipped defaults, resolved workspace → system → built-in. An omitted field inherits.

# Remap the leader and lengthen the sequence timeout
leader = "ctrl+a"
sequence_timeout = 3000

# Bind a sequence to an action (args are optional, per action)
[bindings."ctrl+a g s"]
action = "goto"
args = { scope = "sessions" }

# Unbind a shipped default: point its sequence at the special "none" action
[bindings."ctrl+b b"]
action = "none"

Action ids and the full default binding set are documented under Keyboard shortcuts; the command palette (Ctrl+P) also shows every action’s id-backed label and its current bindings.

App-owned files (not for hand-editing)

For reference only — you don’t edit these directly. Providers, models, and agents are stored as small TOML files per workspace (an agent is a .toml plus a sibling .md holding its system prompt), created and changed through their UI forms. If one of these files is somehow corrupted, Brisal skips just that entry and logs it rather than failing to load the rest — so a single bad file never empties a picker or breaks the workspace.

What to read next

• Appearance & theming — the two theming axes, how a workspace selects a palette, and where theme files live.
• Layout — the surfaces (header, sidebar, panes) the tokens above color.