jdx/mise · error · eyre::Report

Tool '{}' does not have an executable named '{}'. Available

Error message

Tool '{}' does not have an executable named '{}'. Available executables: {}

What it means

Same BinPathError::BinNotFound path as error 291, but the tool ships other executables — mise lists them in the message (src/cli/tool_stub.rs:607) so you can see the correct name. The requested bin simply isn't one of them.

Source

Thrown at src/cli/tool_stub.rs:607

            crate::cli::exec::exec_program(bin_path, args, env, &Default::default(), false).await
        }
        Err(e) => match e {
            BinPathError::ToolNotFound(tool_name) => {
                bail!("Tool '{}' not found", tool_name);
            }
            BinPathError::BinNotFound {
                tool_name,
                bin,
                available_bins,
            } => {
                if available_bins.is_empty() {
                    bail!(
                        "Tool '{}' does not have an executable named '{}'",
                        tool_name,
                        bin
                    );
                } else {
                    bail!(
                        "Tool '{}' does not have an executable named '{}'. Available executables: {}",
                        tool_name,
                        bin,
                        available_bins.join(", ")
                    );
                }
            }
        },
    }
}

/// Execute a tool stub
///
/// Tool stubs are executable files containing TOML configuration that specify
/// which tool to run and how to run it. They provide a convenient way to create
/// portable, self-contained executables that automatically manage tool installation
/// and execution.
///

View on GitHub (pinned to 9dcfcaa0dc)

Solutions

Use one of the executables listed in the error message verbatim
For python-style version-suffixed bins, list bins via mise (`mise ls bins <tool>` if available) or ls the install's bin dir, then adjust the script
If an older version had that bin name, pin it: `mise use <tool>@<older-version>`

Example fix

# before
$ mise x --lang python python3.12 -V
# error: Tool 'python' does not have an executable named 'python3.12'. Available executables: python, python3, ...

# after
$ mise x python -- python3 -V

Defensive patterns

Strategy: validation

Validate before calling

tool="python"; want="python3"
inst="$(mise where "$tool")"
ls "$inst/bin" | grep -qx "$want" || { echo "$tool lacks '$want'; available:"; ls "$inst/bin"; exit 1; }
"$inst/bin/$want" -V

Try / catch

mise x "$tool" -- "$bin" "$@" || { echo "use one of the executables listed in the error message" >&2; exit 1; }

Prevention

Don't hardcode version-suffixed binary names; call the stable name (python3, not python3.12)
Script against the 'Available executables:' list the error prints when bootstrapping new tool versions

When it happens

Trigger: Running a shim/executable name that differs from what the installed tool version provides — e.g. `python3.12` when the version ships `python3`, or a plugin-provided bin renamed across major versions.

Common situations: Scripts hardcoding version-suffixed binary names (python3.11 vs python3.12); switching tools where bin names differ (bun vs node ecosystem); typo'd shim names.

Related errors

AI-assisted analysis of jdx/mise@9dcfcaa0dc (2026-08-17). Data as JSON: /api/errors/a969ef44d231ebf3. Report an issue: GitHub.