What causes "no usable {shell} completion for {}: {}" in jdx/mise?

Read the joined reasons in the message to find the root cause of each failed source.

no usable {shell} completion for {}: {}

Error message

no usable {shell} completion for {}: {}

What it means

completion_script tries every declared completion source in order (cached file, completion files, cli-spec derivation, exec generators). Each failed attempt is recorded; if every source fails or produces empty output, mise bails with this aggregate error listing all the individual skip reasons joined by '; '. It is the terminal error of the whole completion lookup.

Source

Thrown at src/packslip.rs:1267

            }
        };
        match attempt {
            Ok(script) if script.trim().is_empty() => {
                skipped.push("nothing was printed".to_string())
            }
            Ok(script) => {
                if ran_tool
                    && let Some(dir) = cache.parent()
                    && file::create_dir_all(dir).is_ok()
                {
                    let _ = file::write_atomic(&cache, &script);
                }
                return Ok(script);
            }
            Err(err) => skipped.push(err.to_string()),
        }
    }
    bail!(
        "no usable {shell} completion for {}: {}",
        tv.style(),
        skipped.join("; ")
    )
}

/// Take turns generating, so that of the shells completing one command at
/// once the first runs the tool and the rest read what it cached. The lock
/// lives beside the cache, shared by every process that shares the install,
/// and is taken off the runtime's threads.
///
/// A read-only install cannot be locked and does not need to be: nothing
/// will be cached there either, so each shell generates its own script
/// rather than being refused a completion.
async fn lock_generation(cache: &Path) -> Option<fslock::LockFile> {
    let lock_path = cache.with_extension("lock");
    let taken = tokio::task::spawn_blocking(move || -> Result<fslock::LockFile> {
        if let Some(dir) = lock_path.parent() {

View on GitHub (pinned to afd2eddd3a)

Solutions

Read the joined reasons in the message to find the root cause of each failed source.
Reinstall the tool version to repopulate missing resources: `mise uninstall <tool> && mise install <tool>`.
Run the tool's own completion command manually to see if it errors (e.g. `<tool> --completion bash`).
Clear any stale/empty cache: remove resources/completions-v2/<bin>/ under the install path and retry.
Report or fix the packslip if its declared sources are all broken for this release.

Example fix

// before
cargo build  # tool renamed its completion command; exec source prints nothing
// after: pin a release whose generator works, or add a static completion file
[[resource]]
type = "completion"
path = "completions/mytool.bash"

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check the cheapest source before invoking mise:
let tool_ok = std::process::Command::new(tool).arg("--help").output().is_ok();

Try / catch

match completion_script(&config, tool, shell) {
    Ok(script) => install(script),
    Err(e) => {
        // e already lists every failed source, joined by "; "
        eprintln!("completion generation failed: {e}");
        install_fallback_completion(tool, shell);
    }
}

Prevention

Read the joined per-source reasons in the message; they pinpoint the failing sources.
Keep completion generator commands stable across tool releases or declare static completion files.
Clear the completions-v2 cache if an interrupted generation left an empty file.
Avoid concurrent first-time completion generation across many shells on the same read-only install.

When it happens

Trigger: Running `mise completion <shell> --tool <tool>` when every declared source fails: cached file empty, completion files unreadable, spec format unsupported, exec generator returning nothing or erroring (e.g. the tool's completion subcommand missing).

Common situations: A tool whose completion generator command changed between versions; exec generator crashing; spec parse failures ('invalid usage specification'); read-only installs where files are unreadable; multiple simultaneous shells racing on generation.

Understand the failure class

Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.

Related errors

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