Embedded aube sets npm_execpath to mise, causing npm scripts to run as mise tasks

[sosheskaz]

Summary

When mise installs an npm tool through embedded aube, a dependency lifecycle script can receive npm_execpath pointing to the mise executable. A script that uses the standard ${npm_execpath} run <script> pattern therefore invokes mise run <script> instead of an npm-compatible package manager.

With Renovate 44.64.1 and re2 1.26.1, this makes verification of a valid downloaded native binary fail with mise's no tasks defined error. re2 then unnecessarily compiles from source. The overall installation can still succeed, which makes this easy to mistake for a bad prebuilt binary.

Reproduction

[tools]
node = "24.20.0"
"npm:renovate" = { version = "44.64.1", allow_builds = ["re2"] }

Run mise install on Linux x64 with mise 2026.9.1. The relevant output is:

mise npm:renovate@44.64.1 [1/3] installing 611/611 pkgs · 46.4 MiB
Trying https://github.com/uhop/node-re2/releases/download/1.26.1/linux-x64-137.br ...
Writing to build/Release/re2.node ...
The verification has failed: building from sources ...
Building locally ...
mise ERROR no tasks defined in ~/.local/share/mise/installs/npm-renovate/44.64.1/node_modules/.mise/re2@1.26.1/node_modules/re2. Are you in a project directory?
mise ERROR Version: 2026.9.1 linux-x64 (2026-09-02)
mise ERROR Run with --verbose or MISE_VERBOSE=1 for more information
The rebuild has failed: exit code 1.

The enclosing re2 install script subsequently falls back to node-gyp -j max rebuild, so installation succeeds after compiling RE2 locally.

Environment

The failure occurred on an ephemeral Linux x64 GitHub Actions runner, so a complete mise doctor capture is not available from that completed run.

Relevant values:

mise: 2026.9.1 linux-x64
node: 24.20.0
OS: Ubuntu 24.04
glibc: 2.39
npm tool: renovate 44.64.1
native dependency: re2 1.26.1

What I found

The downloaded linux-x64-137.br artifact itself is valid. Its verification script succeeds with Node 24.20.0 on amd64 Ubuntu 24.04/glibc 2.39 when invoked with npm.

install-artifact-from-github 1.8.1 invokes verification and rebuilding through ${npm_execpath} run .... That behavior was introduced to fix uhop/install-artifact-from-github#30, where hard-coded npm run was incompatible with Corepack-selected package managers.

Under embedded aube, npm_execpath resolves to the current host executable, which is mise. Verification consequently becomes equivalent to:

mise run verify-build

Mise interprets verify-build as a mise task and reports that no tasks are defined. The RE2 smoke test never actually runs.

Related prior fixes

This appears to be another instance of embedded aube leaking or re-executing its host identity:

• Discussion #11317 and PR #11308 fixed aube's node-gyp bootstrap using current_exe() and re-executing mise as though it were aube.
• PR #12429 fixed a later node-gyp bootstrap trampoline that became mise run __node-gyp-bootstrap and produced the same no tasks defined failure.
• Discussion #11742 and aubepkg/aube PR #1236 fixed embedded aube deriving the invalid command mise deprecations --transitive from its active host name.
• aubepkg/aube PR #879 added the npm lifecycle environment, including npm_execpath.

The earlier fixes appear specific to their respective node-gyp and deprecation call sites; they do not cover third-party lifecycle scripts that legitimately execute ${npm_execpath} run ....

Expected behavior

npm_execpath supplied to npm lifecycle scripts should identify an executable that implements npm-compatible commands such as run, rather than the embedding mise executable. Alternatively, embedded aube needs a shim or dispatch boundary that preserves those npm lifecycle semantics without routing arbitrary npm commands through mise's task runner.

Impact and workaround

Packages may reject valid prebuilt artifacts, perform slow source builds, require compilers/Python unnecessarily, or fail installation when no source-build fallback is available.

Using mise's shell-out npm backend avoids the embedded-aube lifecycle environment and makes the RE2 verification pass:

[settings.npm]
package_manager = "npm"

MISE_NPM_SHELL_OUT=1 mise install is the equivalent one-off workaround.

[jdx]

Confirmed, and your analysis is exactly right. Reproduced on mise 2026.9.12 (embedded aube 2.2.17) with just "npm:re2" = { version = "1.26.1", allow_builds = ["re2"] } — the verification fails, RE2 compiles from source (~9s plus a C++ toolchain), while MISE_NPM_SHELL_OUT=1 accepts the same prebuilt artifact in 1.6s.

Root cause is where you pointed: aube-scripts stamps npm_execpath from std::env::current_exe(), which is the mise binary when aube is embedded, so ${npm_execpath} run verify-build becomes mise run verify-build. Still unfixed on aube main, and it's wider than verification — any $npm_execpath <npm verb> in any lifecycle script hits it.

Fixed upstream in aubepkg/aube#1565: embedded aube now exports a shim that re-enters aube's own CLI through the host, using a private argv token — the same trampoline contract the node-gyp shims already use, which is why that path works today and this one didn't. A mise PR implementing the interception follows once that lands in an aube release; I'll link it here.

Your [settings.npm] package_manager = "npm" workaround is the right one until then.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: 2.1.270.

[jdx]

Opened the mise half as #13484 — it answers aube's private trampoline the same way mise already answers the node-gyp one, so a ${npm_execpath} run … from a lifecycle script reaches aube's run instead of mise's task runner.

It is deliberately blocked on the aube side landing and being released: embed::CLI_TRAMPOLINE_ARG only exists there, so it will not build against the currently pinned aube 2.2.17. Both should go in with the dependency bump.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: 2.1.270.