mise x node@X -- yarn … runs yarn's child processes on a different Node when another version's bin dir is already on PATH

[ghprince]

Summary

When PATH already contains another Node version's install dir (e.g. left over from a snapshotted/frozen environment of a previously activated shell), mise x node@22 -- <cmd> correctly resolves the direct command, but everything that resolves node via PATH inside the process tree (subshells, #!/usr/bin/env node shebangs, package managers spawning tools) still gets the other version. The result is a very confusing split-brain: node --version says 22, while the process actually running your tests is 24.

Environment

• mise 2026.6.3 macos-arm64 (2026-06-11)
• macOS 26.5.1 (arm64)
• node 22.19.0 and 24.13.0 installed via mise; corepack yarn shims present in both installs

~/.zprofile: eval "$(mise activate zsh --shims)"
~/.zshrc:    eval "$(mise activate zsh)"

Reproduction

mise install node@22.19.0 node@24

# Simulate a frozen env from a shell where node@24 was the active/global tool —
# this is what IDE terminals and AI-agent harnesses end up with, since they
# snapshot the activated shell's env once and `mise activate`'s per-directory
# hook never runs again in non-interactive children:
export PATH="$HOME/.local/share/mise/installs/node/24/bin:$PATH"

mise x node@22 -- node --version
# v22.19.0  ✅ direct command is remapped

mise x node@22 -- sh -c 'which node && node --version'
# ~/.local/share/mise/installs/node/24/bin/node
# v24.13.0  ❌ PATH lookup inside the tree finds the stale entry

mise x node@22 -- yarn node -e 'console.log(process.version)'
# v24.13.0  ❌ yarn (and anything yarn spawns: vitest, its workers, …) runs on 24

Inspecting PATH inside mise x node@22 -- sh -c 'echo $PATH' shows why: the pre-existing installs/node/24/bin entry stays ahead of the installs/node/22/bin entry that mise x adds, so every env node / PATH lookup wins for 24, while the literal node argument to mise x is resolved against the requested version.

Questions

1. Is this expected behavior for mise x — i.e. is it intentional that a pre-existing tool bin dir on PATH outranks the dir mise x injects for the requested version? If so, would it be reasonable for mise x node@X to strip or demote other mise-managed install dirs for the same tool from the child PATH?
2. What's the recommended setup for non-interactive consumers (IDE terminals, CI wrappers, AI-agent harnesses) that inherit a one-shot env snapshot?

[JamBalaya56562]

Fixed in #10422 (merged) — ships in the next release.

mise x <tool>@<ver> -- … was leaving stale mise install dirs (from the ambient/outer toolset) on the child PATH, so child processes — e.g. yarn spawning node — could resolve a different version than the one you requested. The exec environment now drops install dirs that do not belong to the resolved toolset, so child processes use the version you asked for.