What causes "binary not found: {}" in nikivdev/code?

Run `cargo build --release` before publishing so the binaries exist in target/release.

binary not found: {}

Error message

binary not found: {}

What it means

publish collects built release binaries from target/release and hashes them for upload. Before hashing, it checks each expected binary exists; if a binary listed in the package manifest is missing from target/release, publish aborts with 'binary not found: <path>'.

Source

Thrown at src/registry.rs:136

    let registry_url = resolve_registry_url(opts.registry.as_deref(), registry_cfg)?;
    let package = resolve_package_name(opts.package.clone(), cfg, registry_cfg, &project_root)?;
    let bins = resolve_bins(&package, opts.bin.clone(), registry_cfg);
    let default_bin = resolve_default_bin(&package, &bins, registry_cfg);
    let version = resolve_registry_version(cfg, opts.version.clone(), &registry_url, &package)?;
    let latest = resolve_latest_flag(opts.latest, opts.no_latest, registry_cfg);

    if !opts.no_build {
        build_binaries(&project_root, &bins)?;
    }

    let target = detect_target_triple()?;
    let mut binaries = BTreeMap::new();
    let mut sha256_map = BTreeMap::new();
    for bin in &bins {
        let path = project_root.join("target").join("release").join(bin);
        if !path.exists() {
            bail!("binary not found: {}", path.display());
        }
        let sha = sha256_file(&path)?;
        let key = format!("packages/{}/{}/{}/{}", package, version, target, bin);
        binaries.insert(bin.clone(), key);
        sha256_map.insert(bin.clone(), sha);
    }

    let mut targets = BTreeMap::new();
    targets.insert(
        target.clone(),
        RegistryTarget {
            binaries,
            sha256: sha256_map,
        },
    );

    let manifest = RegistryManifest {
        name: package.clone(),

View on GitHub (pinned to a747e741ae)

Solutions

Run `cargo build --release` before publishing so the binaries exist in target/release.
Verify the binary names in your publish config match the actual artifacts in target/release.
If cross-compiling, ensure the release binary is placed at target/release/<bin> or adjust the publish flow.

Example fix

// before
mytool publish   # fails: target/release/mybin missing

// after
cargo build --release && mytool publish

Defensive patterns

Strategy: validation

Validate before calling

let missing: Vec<_> = bins.iter()
    .map(|b| project_root.join("target/release").join(b))
    .filter(|p| !p.exists())
    .collect();
if !missing.is_empty() {
    return Err(format!("build first: missing {:?}", missing));
}
// all present — safe to call publish

Try / catch

match publish(opts) {
    Err(e) if e.to_string().starts_with("binary not found:") => {
        eprintln!("Run `cargo build --release` and verify bin names in config, then retry.");
        std::process::exit(1);
    }
    other => other,
}

Prevention

Always run `cargo build --release` immediately before publish (chain them in CI).
Keep binary names in publish config in sync with Cargo.toml [[bin]] entries.
Avoid `cargo clean` between build and publish.
In CI, cache/restore the target/release directory or build in the publish job.

When it happens

Trigger: Calling publish when `target/release/<bin>` does not exist — typically because `cargo build --release` was not run, the binary name in the config doesn't match the built artifact, or the build was cleaned.

Common situations: Forgetting to build in release mode (only debug artifacts exist); typo in the bin name in config; `cargo clean` run after building; cross-compiling so binaries land in target/<triple>/release instead of target/release.

Related errors

AI-assisted analysis of nikivdev/code@a747e741ae (2026-09-01). Data as JSON: /api/errors/55f9d2080b4c0b7c. Report an issue: GitHub.