What causes "brew-cask: command wrapper '{}' was not staged" in jdx/mise?

Uninstall the cask and install again so all staging steps rerun from a clean caskroom.

brew-cask: command wrapper '{}' was not staged

Error message

brew-cask: command wrapper '{}' was not staged

What it means

link_command_wrapper symlinks a staged command wrapper (a small script mise generated into the caskroom from 'content' or 'executable') into the target bin directory. Before linking it checks the staged file exists; if wrapper.caskroom_path(caskroom) is not a file, staging never wrote the wrapper and mise bails with the wrapper's name.

Source

Thrown at src/system/packages/brew/cask.rs:4899

            );
        }
        bail!(
            "brew-cask: binary artifact '{}' was not staged",
            binary.source
        );
    }
    let target = binary.target_path(appdir)?;
    if let Some(parent) = target.parent() {
        create_dir_all_elevating(parent)?;
    }
    make_symlink_elevating(&caskroom_binary, &target)?;
    Ok(())
}

fn link_command_wrapper(caskroom: &Path, wrapper: &CommandWrapperArtifact) -> Result<()> {
    let source = wrapper.caskroom_path(caskroom);
    if !source.is_file() {
        bail!(
            "brew-cask: command wrapper '{}' was not staged",
            wrapper.name
        );
    }
    let target = wrapper.target_path()?;
    if let Some(parent) = target.parent() {
        create_dir_all_elevating(parent)?;
    }
    make_symlink_elevating(&source, &target)?;
    Ok(())
}

fn caskroom_binary_path(
    caskroom: &Path,
    appdir: &Path,
    binary: &BinaryArtifact,
) -> Result<PathBuf> {
    let target = binary.target_path(appdir)?;

View on GitHub (pinned to 6f52dcdf99)

Solutions

Uninstall the cask and install again so all staging steps rerun from a clean caskroom.
Verify the staged caskroom contains a file named after the wrapper; if not, find why staging skipped it (check earlier errors in the same install run).
Ensure the wrapper name in the cask stanza is a plain name without path components (see error 755) so writer and linker agree on the path.

Defensive patterns

Strategy: validation

Validate before calling

if ! wrapper.caskroom_path(&caskroom).is_file() {
    return Err(eyre!("staging incomplete for '{}'; re-run install", wrapper.name));
}

Prevention

Never resume a half-finished install; uninstall then reinstall to restage atomically.
Keep wrapper names plain so writer and linker compute the same path.
Check earlier errors in the same install run — staging failures cascade into link failures.

When it happens

Trigger: The command_wrapper artifact was parsed but never staged — e.g. an earlier staging step failed partway and the install continued, the wrapper's caskroom path computation disagrees with the writer (name mismatch), or a code path skips writer execution for the artifact.

Common situations: Interrupted installs leaving partial caskroom state; mismatch between the wrapper name used at write time and at link time; custom cask metadata where the wrapper name contains characters that get sanitized differently in each path computation.

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@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/a7a6c7e0acca7bad. Report an issue: GitHub.