jdx/mise · error

{} {err}

Error message

{} {err}

What it means

`mise exec` (and run) reached the point of exec'ing the target program and the exec failed; the error prefixes the sandboxed or target program path with the underlying std::process error. Because exec replaces the process, any failure surfaces here as a bail.

Solutions

1. Check the exact program name/path in the message and verify it exists (`which <prog>` or full path)
2. Ensure the tool providing the binary is installed and its bin dir is on the mise-built PATH
3. Check execute permissions on the file
4. See the following resolution hint error (285) for installed-but-unconfigured tool hints

Example fix

// before
mise exec -- mytool --version   # mytool not installed
// after
mise use node@20        # or install the tool providing mytool
mise exec -- mytool --version

command -v mytool >/dev/null || echo 'mytool not on PATH'

When it happens

Trigger: exec::Command::new(...).exec() returns an error — most commonly ENOENT because the program or a sandbox-exec wrapper path does not exist, or EACCES for a non-executable file. On macOS this fires for the sandboxed program when sandbox.apply rewrote the command.

Common situations: Typo in the binary name passed to `mise exec`, tool installed but bin missing, non-executable file, or macOS sandbox-exec wrapper path invalid.

Related errors

• bootstrap from repository failed with
• {msg}
• repos: command is required
• a branch name is required
• a glob is required

AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17). Data as JSON: /api/errors/2c978f90b3e4a732. Report an issue: GitHub.

Appendix: source

Thrown at src/cli/exec.rs:546

    };
    if crate::file::is_active_mise_shim(std::path::Path::new(&program)) {
        return Err(eyre::eyre!(
            "recursive shim invocation detected: {}",
            program.to_string_lossy()
        ));
    }
    env::remove_var(env::MISE_SHIM_PATH_ENV);
    // Apply sandbox (Landlock/seccomp on Linux, sandbox-exec on macOS)
    let args_str: Vec<String> = args
        .iter()
        .map(|a| a.to_string_lossy().into_owned())
        .collect();
    if let Some(sandboxed) = sandbox.apply(&program.to_string_lossy(), &args_str).await? {
        // macOS: exec through sandbox-exec
        let err = exec::Command::new(&sandboxed.program)
            .args(&sandboxed.args)
            .exec();
        bail!("{} {err}", sandboxed.program);
    }

    let err = exec::Command::new(program.clone()).args(&args).exec();
    let mut msg = format!("{:?} {err}", program.to_string_lossy());
    // The bin never resolved on PATH. If an installed-but-unconfigured tool
    // would have provided it, say so instead of leaving the user with a bare
    // ENOENT (discussion #4407).
    if resolution_failed && let Some(hint) = crate::shims::exec_resolution_hint(&program_name).await
    {
        msg.push_str("\n\n");
        msg.push_str(&hint);
    }
    bail!("{msg}")
}

/// The opaque `cannot find binary path`, plus an explanation when an
/// installed-but-unconfigured tool would have provided the bin. `mise install`
/// writes to no config file, so its tool dirs never join the PATH `mise exec`

View on GitHub (pinned to 533346cc37)