2026.9.7: exec reports a global-config npm: tool as 'missing' right after 'already installed' whenever the project has lockfile = true

[diskude]

Summary

Since 2026.9.7, when a project has lockfile = true and a committed mise.lock, every mise exec (and mise install --dry-run) reports an npm: tool that is pinned only in the global config (~/.config/mise/config.toml) as missing, immediately after saying it is already installed:

$ mise exec -- node --version
mise by @jdx – installing 1 tool
mise ⇢ npm:xcodebuildmcp@2.7.0  38ms · already installed
mise ████████████████ 1/1 · installed 0 tools · 1 already installed in 39ms
mise WARN  missing: npm:xcodebuildmcp@2.7.0
v24.21.0

The tool is installed and resolvable (mise which xcodebuildmcp → .../installs/npm-xcodebuildmcp/2.7.0/node_modules/.bin/xcodebuildmcp, mise ls --json → installed: true, active: true). 2026.9.6 and 2026.9.5 are silent on the same machine and config. Exit codes are unaffected; the warning and the install pass repeat on every exec.

Environment

• mise 2026.9.7 macos-arm64 (2026-09-13); compared against 2026.9.6 and 2026.9.5 with the same data dir
• macOS arm64; ~/.config/mise/config.toml pins "npm:xcodebuildmcp" = "2.7.0" (global only)
• project mise.toml pins other tools (node, gh, gitleaks, osv-scanner, …), has [settings] lockfile = true, minimum_release_age = "1d", committed mise.lock at lockfile version 0
• settings at defaults: auto_install = true, exec_auto_install = true, not_found_auto_install = true

What I measured (isolating the cause)

Variation (2026.9.7 binary)	WARN missing
project dir, defaults	yes, on every exec; install --dry-run also singles the tool out
MISE_EXEC_AUTO_INSTALL=0	install pass suppressed, warning still printed
MISE_LOCKFILE=0	no warning
run from a directory with no project config (global only)	no warning
one-time mise install npm:xcodebuildmcp@2.7.0 under 9.7 (creates 2.7.0~aube~<hash>/, repoints latest/2/2.7)	warning persists (so it is not a one-time identity migration)
mise lock (version 0 rewrite) under 9.7	warning persists
mise lock --upgrade (lockfile version 2 + .mise/locks/ sidecar)	warning persists (and the lock is then unreadable by 9.6, as documented)
pin the same tool also in the project mise.toml so it gets a [[tools."npm:xcodebuildmcp"]] entry in mise.lock	no warning, install --dry-run → "all tools are installed"

Other global-only tools on the same machine (aqua/github/core backends: ollama, topgrade, uv, deno, ruby, periphery, yt-dlp, llama.cpp) never trigger it — only the npm: backend tool does.

Expected

A tool that comes from the global config and is installed should not be reported missing because the project lockfile has no entry for it. Either the lockfile check should scope itself to tools declared by the config the lockfile belongs to, or a global-config npm tool absent from the project lock should be a no-op (as in 2026.9.6), not a per-exec warning plus an install pass.

Likely origin

The behaviour appears with the lockfile revision 2 / npm dependency-graph work in 2026.9.7 (#13131, #13146: npm graphs recorded via embedded aube and replayed with a frozen install). The exec path seems to ask the project lockfile for the npm tool's graph, finds none (the tool is not declared in that config), and reports the lock entry as missing using the word missing — while which/ls resolve the install directory and are satisfied.

Workaround

Declare the npm tool in the project mise.toml as well (it then gets a lock entry and the warning disappears), or set MISE_LOCKFILE=0 for that invocation. We chose to stay on 2026.9.6 until this is addressed, because duplicating a global pin into the project lock changes our pin topology and MISE_LOCKFILE=0 disables the supply-chain check we rely on.

Happy to test a fix build on this machine.

Where it appears to come from (read from the v2026.9.7 tag)

mise exec collects tools through list_missing_versions_for_install → backend is_install_satisfied (src/toolset/mod.rs). For embedded aube, is_install_satisfied rejects a request that carries no aube_lock when the request was not resolved from a lockfile and explicit lockfile creation is enabled (lockfile = true). A tool pinned only in the global config is never resolved from a lockfile, and an ordinary install deliberately does not create an absent global lockfile (that needs mise lock --global), so every fresh process produces a graph-less request again: "already installed" (physical dir present) followed by "missing" (graph binding absent), and install --dry-run keeps scheduling it. which searches physically installed versions and ls uses is_version_installed, which is why both stay satisfied. Possibly related: #13168 (pypi tools after 2026.9.7).

mise doctor (2026.9.7 candidate binary)

version: 2026.9.7 macos-arm64 (2026-09-13)
activated: yes
shims_on_path: yes
self_update_available: yes

build_info:
  Target: aarch64-apple-darwin
  Features: openssl, rustls-native-roots, self_update
  Built: Sun, 13 Sep 2026 22:58:46 +0000
  Rust Version: rustc 1.98.1 (48a229cea 2026-09-01)
  Profile: release

shell:
  /bin/zsh
  zsh 5.9 (arm64-apple-darwin25.0)

aqua:
  baked in registry: aquaproj/aqua-registry@8223fac92626614415ffc5cd87c1aa6b76a6ba6d
  baked in registry tools: 2301

dirs:
  cache: ~/Library/Caches/mise
  config: ~/.config/mise
  data: ~/.local/share/mise
  shims: ~/.local/share/mise/shims
  system_shims: /usr/local/share/mise/shims
  state: ~/.local/state/mise

config_files:
  ~/.config/mise/config.toml
  ~/Documents/Codex/health/mise.toml

env_files:
  (none)

ignored_config_files: (none)

backends:
  aqua
  asdf
  cargo
  conda
  core
  dotnet
  forgejo
  gem
  github
  gitlab
  go
  npm
  packslip
  pypi
  pkgx
  spm
  http
  s3
  ubi
  vfox

plugins:

[jdx]

seems like a major bug, working on a fix now, but I suspect mise lock --upgrade and/or mise lock --global will fix this

[jdx]

Correction to my wording above: lockfile = true is invocation-wide because mise merges all [settings]; it is not a project-scoped setting.

The bug is that the new embedded-aube graph path did not follow the separate, existing lockfile-target policy. Since #8707, automatic lockfile maintenance excludes global tool sources, and #11746 kept missing global lockfiles explicit via mise lock --global. Generating a graph-specific install for an unlocked global npm request therefore produced dependency data that no automatic path could persist. On the next resolution, the same version-only request looked unsatisfied and emitted the redundant install/missing behavior.

#13186 now aligns automatic graph creation with that target policy without changing settings scope. Revision 2 global lockfiles that actually contain the npm tool still require and replay their stored graph.

Until the fix ships, mise lock --global is the best workaround I found. I verified that it creates the graph in the owning global lockfile and makes both commands clean. A project-only mise lock --upgrade does not help because it updates the wrong lockfile target. If a global lockfile is not wanted, the existing alternatives are staying on 2026.9.6, duplicating the pin into the project, or using MISE_LOCKFILE=0 for the invocation; the last option disables lockfile behavior for that run.

Thanks for the detailed isolation—it identified the source/lockfile-target boundary precisely.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.