jdx/mise · error

trusted settings resolution requires the base settings to be

Error message

trusted settings resolution requires the base settings to be loaded

What it means

This error is thrown by Settings::load_sources_from when the requested load policy demands trusted-only settings resolution (SettingsTrustPolicy::TrustedOnly) but the global base settings have not yet been loaded into process state (is_loaded() is false). Trusted project-file resolution depends on the trust list and state established by the initial base settings load, so calling it first is an ordering violation.

Source

Thrown at src/config/settings.rs:986

        }
        // Environment-only: the CLI layer plus `MISE_*`. It skips config discovery, which is both
        // what makes it survive the failure that sent us here and why its answer is a fallback
        // rather than the real one.
        let mut settings =
            Self::load_sources_from(None, SettingsLoadPolicy::ENVIRONMENT_ONLY).ok()?;
        normalize_verbosity(&mut settings);
        Some(settings.log_level())
    }

    /// Load settings sources for an explicit root, or the current directory when `root` is `None`.
    ///
    /// This shares source ordering and file parsing with the normal settings load. It deliberately
    /// does not update process-global settings state or apply the post-load process side effects in
    /// [`Self::try_get`]. Root-specific callers can require trusted project files without
    /// reproducing config discovery or precedence rules.
    fn load_sources_from(root: Option<&Path>, policy: SettingsLoadPolicy) -> Result<Self> {
        if policy.trust == SettingsTrustPolicy::TrustedOnly && !is_loaded() {
            bail!("trusted settings resolution requires the base settings to be loaded");
        }
        let mut builder = Self::builder().preloaded(Self::cli_settings_layer()).env();
        if policy.source == SettingsSourcePolicy::Hierarchy {
            for layer in Self::settings_layers_from(root, policy.trust) {
                builder = builder.preloaded(layer);
            }
            builder = builder.preloaded(DEFAULT_SETTINGS.clone());
        }
        let mut settings = builder.load()?;
        normalize_storage_dirs(&mut settings)?;
        validate_settings_enum_values(&settings)?;
        Ok(settings)
    }

    /// Load eligible config-file settings layers in precedence order and combine settings whose
    /// semantics are additive across files.
    fn settings_layers_from(
        root: Option<&Path>,

View on GitHub (pinned to afd2eddd3a)

Solutions

1. Ensure the base settings are loaded first (call the normal Settings load/try_get path) before requesting trusted-only resolution
2. Switch the call site to the non-TrustedOnly policy if trust filtering is not actually required
3. In tests, initialize settings (e.g. via Settings::try_get or the standard load) before invoking trusted resolution
4. If this occurs in normal CLI startup, report it: it indicates settings-init ordering was broken upstream

Example fix

// before
let s = Settings::load_sources_from(root, policy_trusted_only)?;

// after
let _ = Settings::try_get()?; // ensure base settings loaded first
let s = Settings::load_sources_from(root, policy_trusted_only)?;

// rust: guard before trusted-only resolution
if policy.trust == SettingsTrustPolicy::TrustedOnly && !mise::config::settings::is_loaded() {
    // load base settings first or take the non-trusted path
}

// rust
fn can_resolve_trusted(policy: SettingsLoadPolicy) -> bool {
    policy.trust != SettingsTrustPolicy::TrustedOnly || mise::config::settings::is_loaded()
}

When it happens

Trigger: Calling load_sources_from with a policy whose trust is TrustedOnly (root-specific/trusted project settings resolution) before any normal Settings load has run in the process — e.g. invoking trusted config resolution very early in startup, or in a test/helper, ahead of the base `Settings::try_get`/get flow.

Common situations: Developers adding root-specific trusted-config features call the trusted resolver from a code path that runs before mise's normal settings initialization; tests that call trusted settings helpers without first loading base settings.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• settings.{name} must resolve to an absolute path
• {what} is experimental. Enable it with `mise settings experi
• action prediction payload is too large
• task action manifest has an invalid identity
• task action manifest contains duplicate predictions

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/fc26fe2ac69c52aa. Report an issue: GitHub.