conflicting options for {key}: multiple requests share the s

Error message

conflicting options for {key}: multiple requests share the same install destination

What it means

ensure_compatible_install_requests groups tool install requests by their install destination (tool_key). If two requests target the same destination but carry different ToolVersionOptions, the outcome of the shared install would be ambiguous, so mise bails with this conflict message.

Source

Thrown at src/toolset/tool_deps.rs:27

pub(super) type ToolKey = String;

/// Creates a unique key for a ToolRequest
pub(crate) fn tool_key(tr: &ToolRequest) -> ToolKey {
    format!("{}@{}", tr.ba().short, tr.version())
}

/// Multiple option variants cannot safely share one install destination.
/// Reject them before any install job starts instead of letting one variant
/// silently satisfy (or race with) another.
pub(crate) fn ensure_compatible_install_requests(requests: &[ToolRequest]) -> Result<()> {
    let mut options_by_destination = std::collections::HashMap::new();
    for request in requests {
        let key = tool_key(request);
        let options = request.options();
        if let Some(existing) = options_by_destination.get(&key)
            && existing != &options
        {
            bail!(
                "conflicting options for {key}: multiple requests share the same install destination"
            );
        }
        options_by_destination.insert(key, options);
    }
    Ok(())
}

/// Manages a dependency graph of tools for installation scheduling.
/// Thin wrapper around `DepsGraph<ToolKey, ToolRequest>` with
/// tool-specific dependency resolution.
#[derive(Debug)]
pub(super) struct ToolDeps {
    inner: DepsGraph<ToolKey, ToolRequest>,
}

impl ToolDeps {
    /// Creates a new ToolDeps from a list of tool requests.

View on GitHub (pinned to afd2eddd3a)

Solutions

Unify the options for the duplicated tool entry across all config files that declare it
Remove the redundant duplicate entry so only one request per destination exists
Use different versions so the requests map to distinct destinations if you truly need both option sets
Check `mise config ls` and each config's [tools] section to locate the conflicting declarations

Example fix

// before: global config
tools = { python = { version = '3.12', venv = '.venv' } }
// project config
python = { version = '3.12' }
// after: make options identical or drop the duplicate
python = { version = '3.12', venv = '.venv' }

Defensive patterns

Strategy: validation

Validate before calling

// detect duplicate tool entries with differing options across configs
const byKey = {}; for (const r of requests) { const k = toolKey(r); if (byKey[k] && JSON.stringify(byKey[k].options) !== JSON.stringify(r.options())) throw new Error('conflict: '+k); byKey[k]=r; }

Try / catch

try { installTools(requests) } catch (e) { if (String(e).includes('conflicting options')) { showConfigSources(e); } else { throw e; } }

Prevention

Keep tool options identical wherever the same tool+version is declared
Deduplicate tool entries across global/local config files
Use env-scoped configs deliberately and consistently
Run `mise config ls` to audit which files declare each tool

When it happens

Trigger: install_runtimes/install_missing_runtimes/Toolset::new/install_all_versions_with_progress are given two requests for tools resolving to the same install key with differing options — e.g. the same tool+version requested with different settings (flags, env, or install options) from different config files.

Common situations: A global and a project mise.toml both specify the same tool but with different options (e.g. different python settings or npm flags); env-scoped configs overriding the same tool version with incompatible options; tasks requesting the same tool with different options.

Related errors

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