Bug: rename_exe renames wrong binary when archive contains multiple executables (github backend)

[GaMoCh]

Description

When using the github backend with a tool that ships multiple executables in its release archive, rename_exe renames the wrong binary. The function rename_executable_in_dir iterates the directory and renames the first executable it finds, which is non-deterministic (readdir order). It does not use the tool_name hint available to it.

Steps to reproduce

# ~/.config/mise/config.toml
[tools."github:thought-machine/please"]
version = "17.28.0"
filter_bins = "please"
rename_exe = "plz"

mise install --force "github:thought-machine/please@17.28.0"

The archive please_17.28.0_darwin_arm64.tar.gz contains 3 binaries: build_langserver, please, please_sandbox.

Expected behavior

please is renamed to plz, and only plz is exposed via shims.

Actual behavior

build_langserver (or whichever binary readdir returns first) is renamed to plz. please remains untouched. The filter_bins then fails to find please since it wasn't renamed, and the shim directory ends up empty.

With MISE_TRACE=1:

mv build_langserver → plz
Renamed build_langserver to plz

Root cause

rename_executable_in_dir picks the first executable that passes should_skip_file, ignoring the tool_name parameter which is only used in the second pass (for non-executable files in ZIP archives). With multiple executables, this is essentially random.

Additionally, rename_exe and filter_bins don't coordinate — rename_exe runs inside install_artifact before filter_bins runs in create_symlink_bin_dir, so filter_bins searches for a binary name that may have already been (incorrectly) renamed.

Workaround

The only working alternative is the ubi backend, which has its own rename logic via the ubi library:

[tools."ubi:thought-machine/please"]
version = "17.28.0"
exe = "please"
rename_exe = "plz"

However, the ubi backend is deprecated and emits a warning on every install:

mise WARN  deprecated [ubi]: The ubi backend is deprecated. Use the github backend instead (e.g., github:owner/repo)

So currently there is no way to achieve this with a non-deprecated backend.