trusted_config_paths has no effect

[gdlx]

Describe the bug
Since upgrading Mise last week, I have issues with config trust.
I have a Mise config file in a Python project:

# ~/projects/myproject > cat .mise.toml
[tools]
kustomize = 'prefix:5.3'

Config file isn't trusted by default since v2024.11.24 (it's trusted by default when downgrading to v2024.11.23), while global files are still trusted:

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

The consequence is my kustomize install isn't considered current anymore.
Even if it is installed globally, I could need a different version in my project, so my code checks it's installed with --current:

# ~/projects/myproject > mise list kustomize --installed --current
Tool  Version  Config Source Requested

# ~/projects/myproject > mise list kustomize --installed
Tool       Version  Config Source Requested
kustomize  5.3.0

Everything works fine when trusting the file directly:

# ~/projects/myproject > mise trust
mise trusted /home/gdlx/projects/myproject/.mise.toml

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: trusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool       Version  Config Source                   Requested
kustomize  5.3.0    ~/projects/myproject/.mise.toml prefix:5.3

But I don't want to do this because I have multiple projects with the same setup and I don't want to trust every config file. I'd prefer doing it with the MISE_TRUSTED_CONFIG_PATHS, globally for all projects on the ~/projects directory or even in each project dir by setting the variable on execution.

My problem is thas the setting seems to be completely ignored.

To Reproduce

# ~/projects/myproject > mise trust --untrust
mise untrusted /home/gdlx/projects/myproject/.mise.toml
mise ERROR error parsing config file: ~/projects/myproject/.mise.toml
mise ERROR Config file ~/projects/myproject/.mise.toml is not trusted.
Trust it with `mise trust`.
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

# ~/projects/myproject > mise doctor |grep trust
  trusted_config_paths = ["~/projects"]

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: untrusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool  Version  Config Source Requested

trusted_config_paths just seems to be ignored.

I tried with setting MISE_TRUSTED_CONFIG_PATHS to multiple paths and syntaxes with the same result:

• ~/projects/
• ~/projects/myproject
• ~/projects/myproject/
• ~/projects/myproject/.mise.toml
• /home/gdlx/projects/myproject
• /home/gdlx/projects/myproject/
• /home/gdlx/projects/myproject/.mise.toml

Expected behavior
Unless I misunderstood something, the config file should just be trusted:

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

# ~/projects/myproject > mise doctor |grep trust
  trusted_config_paths = ["~/projects"]

# ~/projects/myproject > mise trust --show
~/.config/mise/config.toml: trusted
~/.mise.toml: trusted
~/projects/myproject/.mise.toml: trusted

# ~/projects/myproject > mise list kustomize --installed --current
Tool       Version  Config Source                   Requested
kustomize  5.3.0    ~/projects/myproject/.mise.toml prefix:5.3

mise doctor output

With MISE_TRUSTED_CONFIG_PATHS unset (I've shown above that trusted_config_paths is correctly set when I set the variable):

❯ mise doctor
version: 2024.11.30 linux-x64 (2024-11-26)
activated: yes
shims_on_path: no

build_info:
  Target: x86_64-unknown-linux-gnu
  Features: DEFAULT, NATIVE_TLS
  Built: Tue, 26 Nov 2024 20:28:19 +0000
  Rust Version: rustc 1.82.0 (f6e511eec 2024-10-15) (Homebrew)
  Profile: release

shell:
  /usr/bin/zsh
  zsh 5.9 (x86_64-ubuntu-linux-gnu)

dirs:
  cache: ~/.cache/mise
  config: ~/.config/mise
  data: ~/.local/share/mise
  shims: ~/.local/share/mise/shims
  state: ~/.local/state/mise

config_files:
  ~/.config/mise/config.toml
  ~/.mise.toml

backends:
  aqua
  asdf
  cargo
  core
  gem
  go
  npm
  pipx
  spm
  ubi
  vfox

plugins:
  cilium-cli  https://github.com/carnei-ro/asdf-cilium-cli.git#89c7711
  flux2       https://github.com/tablexi/asdf-flux2.git#771755e
  helm        https://github.com/Antiarchitect/asdf-helm.git#085651c
  kubectl     https://github.com/asdf-community/asdf-kubectl.git#2fb3b57
  kustomize   https://github.com/Banno/asdf-kustomize.git#8e929af
  pulumi      https://github.com/canha/asdf-pulumi.git#99d675b
  usage       https://github.com/jdx/mise-usage.git#fe3888a

toolset:
  aqua:kubernetes-sigs/aws-iam-authenticator@0.6.27
  asdf:cilium-cli@0.16.20
  asdf:flux2@2.3.0
  asdf:helm@3.12.3
  asdf:kubectl@1.30.7
  asdf:usage@1.3.3

env_vars:
  MISE_SHELL=zsh

settings:
  activate_aggressive = false
  all_compile = false
  always_keep_download = false
  always_keep_install = false
  asdf_compat = false
  cache_prune_age = "30d"
  ci = false
  color = true
  debug = false
  disable_backends = []
  disable_default_registry = false
  disable_hints = ["outdated_bump"]
  disable_tools = []
  exec_auto_install = true
  experimental = false
  fetch_remote_versions_cache = "1h"
  fetch_remote_versions_timeout = "10s"
  go_default_packages_file = "~/.default-go-packages"
  go_download_mirror = "https://dl.google.com/go"
  go_repo = "https://github.com/golang/go"
  go_set_gopath = false
  go_set_goroot = true
  go_skip_checksum = false
  http_timeout = "30s"
  ignored_config_paths = []
  jobs = 4
  legacy_version_file = true
  legacy_version_file_disable_tools = []
  libgit2 = true
  lockfile = true
  log_level = "info"
  not_found_auto_install = true
  paranoid = false
  pin = false
  plugin_autoupdate_last_check_duration = "7d"
  quiet = false
  raw = false
  task_run_auto_install = true
  task_skip = []
  trace = false
  trusted_config_paths = []
  unix_default_file_shell_args = ["sh"]
  unix_default_inline_shell_args = [
      "sh",
      "-c",
  ]
  use_file_shell_for_executable_tasks = false
  use_versions_host = true
  verbose = false
  windows_default_file_shell_args = [
      "cmd",
      "/c",
  ]
  windows_default_inline_shell_args = [
      "cmd",
      "/c",
  ]
  windows_executable_extensions = [
      "exe",
      "bat",
      "cmd",
      "com",
      "ps1",
      "vbs",
  ]
  yes = false

  [aqua]
  cosign = true
  slsa = true

  [cargo]
  binstall = true

  [node]

  [npm]
  bun = false

  [pipx]
  uvx = false

  [python]
  default_packages_file = "~/.default-python-packages"
  pyenv_repo = "https://github.com/pyenv/pyenv.git"
  venv_auto_create = false
  venv_stdlib = false

  [ruby]
  default_packages_file = "~/.default-gems"
  ruby_build_repo = "https://github.com/rbenv/ruby-build.git"
  ruby_install = false
  ruby_install_repo = "https://github.com/postmodern/ruby-install.git"

  [status]
  missing_tools = "if_other_versions_installed"
  show_env = false
  show_tools = false

No problems found

Additional context

I've seen nothing relevant with --debug or --trace.

[jdx]

¯\_(ツ)_/¯ it's working for me if I set MISE_TRUSTED_CONFIG_PATHS=~ and every other thing I can think of. Is there a symlink in the paths maybe that's screwing things up?

here's the code which might give you an idea of what it is that is going awry:

mise/src/config/config_file/mod.rs

Lines 248 to 295 in f246584

	pub fn is_trusted(path: &Path) -> bool {
	let canonicalized_path = match path.canonicalize() {
	Ok(p) => p,
	Err(err) => {
	debug!("trust canonicalize: {err}");
	return false;
	}
	};
	if is_ignored(canonicalized_path.as_path()) {
	return false;
	}
	if IS_TRUSTED
	.lock()
	.unwrap()
	.contains(canonicalized_path.as_path())
	{
	return true;
	}
	if config::is_global_config(path) {
	add_trusted(canonicalized_path.to_path_buf());
	return true;
	}
	let settings = Settings::get();
	for p in settings.trusted_config_paths() {
	if canonicalized_path.starts_with(p) {
	add_trusted(canonicalized_path.to_path_buf());
	return true;
	}
	}
	if settings.paranoid {
	let trusted = trust_file_hash(path).unwrap_or_else(|e| {
	warn!("trust_file_hash: {e}");
	false
	});
	if !trusted {
	return false;
	}
	} else if cfg!(test) || ci_info::is_ci() {
	// in tests/CI we trust everything
	return true;
	} else if !trust_path(path).exists() {
	// the file isn't trusted, and we're not on a CI system where we generally assume we can
	// trust config files
	return false;
	}
	add_trusted(canonicalized_path.to_path_buf());
	true
	}

[gdlx]

Ok, that's weird.
I tried with MISE_TRUSTED_CONFIG_PATHS=~ with no more success (and it wouldn't be really safe).
I have no symlink in the path, but maybe using WSL could have some impact ? (I don't think so)

[jdx]

are you actually setting it as an env var?

[gdlx]

Sure, as shown in my To Reproduce block:

# ~/projects/myproject > export MISE_TRUSTED_CONFIG_PATHS=~/projects

[kattouf]

Hello @gdlx,

I had a similar experience to what you described and spent a couple of hours trying to figure out what was going on.

Eventually, I decided to pull the mise repository and debug it. I discovered that my configuration was untrusted because it was “ignored.” Here’s the relevant code snippet:

pub fn is_trusted(path: &Path) -> bool {
    let canonicalized_path = match path.canonicalize() {
        Ok(p) => p,
        Err(err) => {
            debug!("trust canonicalize: {err}");
            return false;
        }
    };
    if is_ignored(canonicalized_path.as_path()) {
        return false; // my code returns here
    }

I believe this happened when mise prompted me with:
mise config files in {some path} are not trusted. Trust them?
At that time, I had answered No.

To fix this, you can remove your target configuration from the “ignore list” by temporarily trusting it:

mise trust --all

Then, you can “untrust” the configuration by running:

mise trust --untrust

At this point, the configuration will no longer be in either the “ignore” or “trust” lists, allowing you to test the behavior from scratch:

export MISE_TRUSTED_CONFIG_PATHS=~/projects
mise trust --show

(or just visit MISE_STATE_DIR and manage all it manually)

I hope this helps! Let me know if you need further clarification.

[jdx]

note that this logic changed significantly in the last release, previously it tracked files but now it tracks the directory so you don't need to trust every .config/conf.d/*.toml config individually

I did try to make it backwards-compatible where previously tracked individual files will still be trusted

[jdx]

I believe this happened when mise prompted me with:
mise config files in {some path} are not trusted. Trust them?
At that time, I had answered No.

fwiw this is the intended behavior, otherwise we would prompt all the time and it would never go away

[kattouf]

I agree with you, I just did it (implicitly added to permanent ignore by clicking "No" in the "do you trust" question) and forgot after that, so at the moment I was confused

[JamBalaya56562]

This should now be fixed by #11152, which was merged today.

The root cause was that is_trusted() consulted the persisted ignore list (paths dismissed via the trust prompt or mise trust --ignore / --untrust) before checking trusted_config_paths, so the setting never took effect — which also contradicted the mise trust warning that a settings-trusted path "will still be trusted".

The precedence is now:

1. ignored_config_paths — explicit hard block (unchanged)
2. trusted_config_paths / MISE_TRUSTED_CONFIG_PATHS — overrides the persisted ignore list
3. persisted ignore list (dismissed prompt / mise trust --ignore)

So in your case, setting MISE_TRUSTED_CONFIG_PATHS=~/projects will now cause ~/projects/myproject/.mise.toml to be treated as trusted, discovered, and loaded (env vars included), and mise trust --show / mise doctor will reflect it — even if you had previously answered "No" to the prompt or run mise trust --untrust on it.

The fix should land in the next release. Thanks for the detailed report!

This comment was generated by an AI coding assistant.