jdx/mise · error

Unknown setting: {}

Error message

Unknown setting: {}

What it means

`mise settings set KEY VALUE` (and unset-adjacent paths) look the key up in SETTINGS_META before writing; a key that is not a known setting bails 'Unknown setting: KEY' so misspelled names never silently create dead config entries. The metadata registry is generated from settings.toml, so it exactly matches the settings this mise version understands.

Source

Thrown at src/cli/settings/set.rs:46

        match self.value {
            Some(value) => set(&self.setting, &value, false, self.local),
            None => {
                let (key, value) = self.setting.split_once('=').ok_or_else(|| {
                    eyre!(
                        "Usage: mise settings set <KEY>=<VALUE> or mise settings set <KEY> <VALUE>"
                    )
                })?;
                set(key, value, false, self.local)
            }
        }
    }
}

pub(super) fn set(mut key: &str, value: &str, add: bool, local: bool) -> Result<()> {
    let meta = match SETTINGS_META.get(key) {
        Some(meta) => meta,
        None => {
            bail!("Unknown setting: {}", key);
        }
    };

    // Writing it would succeed and then be ignored, and `mise settings get` would report the
    // stored value as if it were live. See https://github.com/jdx/mise/discussions/5791.
    // `mise settings unset` is deliberately still allowed, so anyone who already has one of
    // these in a config can remove it.
    if meta.env_only {
        bail!(
            "{key} cannot be set in a config file: mise reads it before config files load. Use the {} environment variable instead.",
            meta.env.unwrap_or("matching MISE_*")
        );
    }

    let value = match meta.type_ {
        SettingsType::Bool => parse_bool(value)?,
        SettingsType::Integer => parse_i64(value)?,
        SettingsType::Duration => parse_duration(value)?,

View on GitHub (pinned to 6f52dcdf99)

Solutions

  1. Copy the exact key from `mise settings ls` and retry
  2. Align the script with the installed version's settings reference (docs/settings.toml)
  3. Pin or upgrade mise across machines so settings names match your automation

Example fix

# before
mise settings set auto_instal true   # Unknown setting: auto_instal

# after
mise settings ls
mise settings set auto_install true
Defensive patterns

Strategy: type-guard

Validate before calling

# fail fast with the valid key list on typos
mise settings ls 2>/dev/null | awk '{print $1}' | grep -qx "$key" \
  || { echo "unknown setting: $key" >&2; exit 2; }
mise settings set "$key" "$value"

Type guard

is_known_setting() { mise settings ls 2>/dev/null | awk '{print $1}' | grep -qx "$1"; }

Try / catch

Catch 'Unknown setting' from `mise settings set` and abort automation with the settings list attached; never ignore it — a typo here means your intended setting was NOT applied.

Prevention

When it happens

Trigger: Running `mise settings set invalid_key true`, or a script setting a key that no longer exists / was renamed in the installed mise version.

Common situations: Typos in automation; drift between a machine's mise version and the version docs/scripts were written for; stale CI pipelines after a settings rename.

Related errors


AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/e7cbb74731b57bbd. Report an issue: GitHub.