Skip to content
~$ seal

Config reference

CLI configuration loaded from config files.

Resolution order (highest priority wins):

  1. CLI flags (override everything)
  2. Project-local: .seal/config.toml
  3. User global — path resolved in order: $SEAL_CONFIG (full-path env override), $XDG_CONFIG_HOME/seal/config.toml, $HOME/.config/seal/config.toml (XDG default), then on macOS only the legacy $HOME/Library/Application Support/seal/config.toml as a fallback when no XDG file exists.
  4. Defaults

Future: enterprise signed policy will slot in above CLI flags.

cli

Section titled “cli”
Typeobject

CLI process behavior, including approval prompting, logging, and dev-mode controls.

always_approve

Section titled “always_approve”
TypebooleanDefaultfalse

Always show the manifest approval prompt, even when the signature is valid. Useful for enterprise environments where teams want to review grants before every session.

dev_mode

Section titled “dev_mode”
TypestringDefault”disabled”

Which VCS to use when rendering the dev-mode status row’s build info. Controls presentation only — Git shows short SHA, Jj shows change ID. Disabled hides the dev row entirely and disables all dev-mode hotkeys.

Allowed values: "disabled", "git", "jj".

log_level

Section titled “log_level”
TypestringDefault”warn”

Log level for debug output. Logs are written to ~/.seal/internal/logs/cli.log. Valid values: “off”, “error”, “warn”, “info”, “debug”, “trace”. Default: “warn” so warnings and errors are captured without opt-in — post-mortems of /restart and other client-side failures depend on this. Set to “off” to silence logging entirely.

daemon

Section titled “daemon”
Typeobject

Daemon process behavior used when the CLI starts or reconnects to seal-daemon.

log_level

Section titled “log_level”
TypestringDefault""

Log level for the daemon. Passed as SEAL_DAEMON_LOG env var when spawning the daemon. Logs written to ~/.seal/internal/logs/daemon-debug.log. Valid values: “off”, “error”, “warn”, “info”, “debug”, “trace”. Default: "" (empty — the daemon treats this as no logging).

tui

Section titled “tui”
Typeobject

TUI runtime configuration. The copy-on-select policy lives here because it’s a behavior-of-the-chat-view knob, not a process-level startup setting (which is where [cli] lives). Future TUI knobs (status-bar density, hint visibility, color theme overrides) slot in here.

copy_on_select

Section titled “copy_on_select”
TypestringDefault”auto”

Copy-on-select policy for the chat view. Three values:

  • Auto (default): copy-on-select fires when the kitty keyboard protocol is NOT available, off when it is. Kitty support means the user can press cmd+c (which arrives as SUPER+c) to commit explicitly, so the implicit-on-mouse_up clobber risk isn’t worth running. On terminals without kitty support (Terminal.app, VSCode integrated terminal, Zed integrated terminal) there’s no key combination that reaches seal as a copy gesture — without copy-on-select, the user can only commit via ctrl+y, which is unintuitive. Default is to restore the implicit-copy convention on those terminals so cmd+c works at the terminal layer (the terminal sees seal’s OSC 52 write and treats its own clipboard as having the selected text).
  • On: always copy-on-select, regardless of kitty support. Lets users force the implicit behavior even on kitty terminals where cmd+c would otherwise be the explicit path.
  • Off: never copy-on-select. Users must use cmd+c / ctrl+shift+c (kitty terminals only) or ctrl+y (universal) to commit. Selection is visual-only.

Allowed values: "auto", "on", "off".

notifications

Section titled “notifications”
TypestringDefault”auto”

Desktop-notification backend for “agent finished a turn” / “permission prompt ready” events.

  • Auto detects terminal capability + zellij: inside zellij, on a host that speaks the kitty OSC 99 protocol (kitty, foot) it emits OSC 99 (zellij forwards it to the host, which renders it without a bell marker); inside zellij on a host that lacks OSC 99 (Ghostty, iTerm2, WezTerm, Warp) it falls back to BEL, since zellij drops OSC 9 entirely and forwarding OSC 99 to a host that can’t parse it is silently lost. Outside zellij, an OSC 9-capable terminal (Ghostty, iTerm2, kitty, WezTerm, Warp) emits OSC 9; it falls back to BEL elsewhere.
  • Osc9 forces the OSC 9 sequence regardless of terminal — useful for terminals we haven’t classified that do support OSC 9. Dropped silently by zellij.
  • Osc99 forces the Kitty OSC 99 sequence — the one a multiplexer like zellij forwards to the host terminal. Only reaches a notification if the host speaks OSC 99 (kitty, foot).
  • Bel forces the BEL byte. Cheap, universally accepted, often surfaces as a Zed-style tab attention indicator even on terminals that don’t speak OSC 9. Inside zellij it sets a sticky [!] marker — which is the only attention signal that reaches a Ghostty host through zellij, so Auto routes there automatically.
  • Off suppresses notifications entirely. The terminal-title spinner / action-required still updates if terminal_title is on.

Allowed values: "auto", "osc9", "osc99", "bel", "off".

terminal_title

Section titled “terminal_title”
TypebooleanDefaulttrue

Write OSC 0 terminal-window title updates while the chat runs (seal — Working ⠋ — my-project etc.). Default true; set false to leave the terminal title alone.