jdx/mise · error · eyre::Report

locked mode requires lockfile to be enabled hint: Remove `lo

Error message

locked mode requires lockfile to be enabled
hint: Remove `lockfile = false` or set `lockfile = true`, or disable locked mode

What it means

Locked mode (`mise install --locked` or settings.locked = true) works by validating every install against mise.lock, so it fundamentally requires the lockfile feature. If settings explicitly set `lockfile = false`, the two options contradict each other and Backend::install fails fast before any work — including dry-runs, which the guard deliberately precedes.

Source

Thrown at src/backend/mod.rs:3216

        None
    }

    async fn install_version(
        &self,
        ctx: InstallContext,
        mut tv: ToolVersion,
    ) -> eyre::Result<ToolVersion> {
        // Toolset installs preflight these options before doing any work, but
        // direct callers such as `install-into` must be protected here too.
        tv.request.ensure_safe_install_options()?;

        // Check for --locked mode: if enabled and no lockfile URL exists, fail early
        // Exempt tool stubs from lockfile requirements since they are ephemeral
        // Also exempt backends that don't support URL locking (e.g., Rust uses rustup)
        // This must run before the dry-run check so that --locked --dry-run still validates
        let settings = Settings::get();
        if (ctx.locked || settings.locked) && settings.lockfile == Some(false) {
            bail!(
                "locked mode requires lockfile to be enabled\n\
                hint: Remove `lockfile = false` or set `lockfile = true`, or disable locked mode"
            );
        }
        if ctx.locked && !tv.request.source().is_tool_stub() && self.supports_lockfile_url() {
            let platform_key = self.get_platform_key();
            let has_lockfile_url = tv
                .lock_platforms
                .get(&platform_key)
                .and_then(|p| p.url.as_ref())
                .is_some();
            if !has_lockfile_url {
                bail!(
                    "No lockfile URL found for {} on platform {} (--locked mode)\n\
                    hint: Run `mise lock` to generate lockfile URLs, or disable locked mode",
                    tv.style(),
                    platform_key
                );

View on GitHub (pinned to 6f52dcdf99)

Solutions

1. Remove `lockfile = false` (or set `lockfile = true`) in settings/env
2. Drop locked mode if the lockfile is intentionally disabled
3. Audit with `mise settings ls` for both keys to find where each is set (global vs project)

Example fix

# before (~/.config/mise/settings.toml)
lockfile = false
locked = true
# after
locked = true

# fail fast in CI if settings combine contradictory flags
[ "$(mise settings get lockfile)" = "false" ] && [ "$MISE_LOCKED" = "1" ] && { echo 'lockfile=false + locked is invalid'; exit 1; }

When it happens

Trigger: settings.toml (or env) contains `lockfile = false` while the user runs `mise install --locked` or has `locked = true` in settings; commonly a leftover `lockfile = false` from an old experiment when adopting locked mode.

Common situations: Teams adopting `--locked` in CI while a developer's global settings still disable lockfile; copy-pasted settings snippets that combine both; env-var MISE_LOCKFILE=false in pipelines that also pass --locked.

Related errors

• No matching complete lockfile artifact list found for {} on
• No lockfile URL found for {} on platform {} (--locked mode)
• {}@{} is not in the lockfile hint: {hint}
• cargo-binstall cannot honor cargo install-only tool option(s
• Invalid checksum: {checksum}

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