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
- Edit the file that actually takes precedence (the local path printed in the warning) if you intended a project-local change.
- Use `mise use -g` deliberately and remove/adjust the conflicting local pin if the global value should win.
- Run `mise ls` to see which config defines each tool (`source` info).
- 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
- Check the tool's `source` in `mise ls` to know which file wins.
- Keep tool pins in one place: either global or per-project, not both.
- Use `mise use -g` intentionally and clean up local duplicates afterwards.
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
- invalid command wrapper name: {name:?}
- {bin_name} is a mise bin however it is not currently active.
- failed to parse registry option {k} as a TOML value: {e}
- locked mode requires lockfile to be enabled hint: Remove `lo
- URL must use s3:// scheme, got: {}
AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09).
Data as JSON: /api/errors/fc5f004ab37fd358.
Report an issue: GitHub.