jdx/mise · warning

{plugin} is defined in {p} which overrides the global config

Error message

{plugin} is defined in {p} which overrides the global config ({global})

What it means

`mise use` (warn_if_hidden) warns "{plugin} is defined in {p} which overrides the global config ({global})" when a tool you are setting is already defined in a local config file (mise.toml/.tool-versions) whose path differs from the global config. It flags that the local definition will shadow the global one, which can surprise users editing the "wrong" file.

Source

Thrown at src/cli/use.rs:437

            // Tool-level options cannot be represented in .tool-versions or idiomatic
            // version files. Keep the selected directory, but write the hook to its
            // default TOML config rather than unexpectedly selecting a TOML file above it.
            path.set_file_name(&*env::MISE_DEFAULT_CONFIG_FILENAME);
        }

        config_file::parse_or_init(&path).await
    }

    async fn warn_if_hidden(&self, config: &Arc<Config>, global: &Path) {
        let ts = ToolsetBuilder::new()
            .build(config)
            .await
            .unwrap_or_default();
        let warn = |targ: &ToolArg, p| {
            let plugin = &targ.ba;
            let p = display_path(p);
            let global = display_path(global);
            warn!("{plugin} is defined in {p} which overrides the global config ({global})");
        };
        for target in &self.tools {
            let targ = &target.tool;
            if let Some(tv) = ts.versions.get(targ.ba.as_ref())
                && let ToolSource::MiseToml(p) | ToolSource::ToolVersions(p) = &tv.source
                && !file::same_file(p, global)
                && !config::is_system_config(p)
            {
                warn(targ, p);
            }
        }
    }

    fn render_success_message(
        &self,
        cf: &dyn ConfigFile,
        versions: &[ToolVersion],
        remove: &[BackendArg],

View on GitHub (pinned to afd2eddd3a)

Solutions

  1. Edit the file that actually takes precedence (the local path printed in the warning) if you intended a project-local change.
  2. Use `mise use -g` deliberately and remove/adjust the conflicting local pin if the global value should win.
  3. Run `mise ls` to see which config defines each tool (`source` info).
  4. Consolidate duplicate tool definitions into one config to stop the shadowing.

Example fix

// before
# ~/.config/mise/config.toml
[tools]
node = "20"   # shadowed by project mise.toml pinning node = "18"
// after
# project mise.toml
[tools]
node = "20"   # single source of truth; global pin removed
Defensive patterns

Strategy: validation

Validate before calling

mise ls  # inspect each tool's source config file before running mise use

Prevention

When it happens

Trigger: Running `mise use <tool>` where the resolved tool version's `ToolSource` is a local MiseToml/ToolVersions file and that file is not the same file as the global config (`!file::same_file(p, global)`).

Common situations: A project-level mise.toml pins a tool while the global config also defines it; user runs `mise use -g tool@x` expecting the change to take effect but a local file wins; confusion after cd-ing into a project with inherited configs.

Related errors


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