What causes "Tool stub file does not exist: {}" in jdx/mise?

First run `mise generate tool-stub --output ` without --lock to create the stub, then rerun with --lock.

Tool stub file does not exist: {}

Error message

Tool stub file does not exist: {}

What it means

`mise generate tool-stub --lock` (lock_stub) resolves and pins exact versions plus per-platform lock info into an existing tool stub file. It requires the output stub file to already exist because locking is an update operation, not a creation step. mise bails with this error when the --output path does not exist on disk.

Source

Thrown at src/cli/generate/tool_stub.rs:770

        // Strategy 3: If there's only one executable total, use it
        if executables.len() == 1 {
            return Ok(executables[0].clone());
        }

        // No good match found, provide helpful error message
        let mut exe_list = executables.to_vec();
        exe_list.sort();

        bail!(
            "Could not determine which executable to use for '{}'. Available executables:\n  {}\n\nUse --bin to specify the correct binary path.",
            tool_name,
            exe_list.join("\n  ")
        );
    }

    async fn lock_stub(&self) -> Result<String> {
        if !self.output.exists() {
            bail!(
                "Tool stub file does not exist: {}",
                display_path(&self.output)
            );
        }

        let mut stub = ToolStubFile::from_file(&self.output)?;
        let config = Config::get().await?;

        // Allow --version to override the version in the stub for bumping
        if self.version != "latest" {
            stub.version = self.version.clone();
        }

        // Create tool request and resolve version
        let request = stub.to_tool_request(&self.output)?;
        let backend = request.ba().backend()?;
        let resolve_opts = ResolveOptions {
            use_locked_version: false,

View on GitHub (pinned to afd2eddd3a)

Solutions

First run `mise generate tool-stub --output <path>` without --lock to create the stub, then rerun with --lock.
Check the --output path for typos or a changed working directory; pass the exact existing stub path.
If the stub was deleted, regenerate it rather than trying to lock a missing file.

Example fix

// before (fails: no stub yet)
mise generate tool-stub --lock --output ./bin/tool
// after
mise generate tool-stub --output ./bin/tool
mise generate tool-stub --lock --output ./bin/tool

Defensive patterns

Strategy: validation

Validate before calling

# shell: check the stub exists before locking
[ -f "./bin/tool" ] || mise generate tool-stub --output ./bin/tool
mise generate tool-stub --lock --output ./bin/tool

Prevention

Always generate the stub before running --lock or --checksums.
Use a single variable for the stub path across generate steps to avoid path drift.
In CI, order steps: generate -> lock -> fetch-checksums, each with the same --output.

When it happens

Trigger: Running `mise generate tool-stub --lock --output <path>` (or the tool-stub lock code path) where self.output does not exist on disk — i.e. locking before ever generating the stub, or pointing --output at a wrong/typo'd path.

Common situations: Developers run `generate tool-stub --lock` on a fresh project without first generating the stub; the stub was deleted or moved after generation; the --output flag points at a path different from where the stub was actually written.

Understand the failure class

Background: "File not found" and ENOENT errors: why libraries can't find a file that should exist — this error's family across 50 libraries.

Related errors

AI-assisted analysis of jdx/mise@afd2eddd3a (2026-09-09). Data as JSON: /api/errors/849997085dc2a4b8. Report an issue: GitHub.