What causes "asset '{asset_name}' not found in SHA256SUMS" in zeroclaw-labs/zeroclaw?

Compare the filename in the error with the filenames inside the target release's SHA256SUMS; the mismatch (suffix, prefix, case) is usually visible immediately.

zeroclaw-labs/zeroclaw · error · anyhow::Error

asset ' ' not found in SHA256SUMS

Error message

asset '{asset_name}' not found in SHA256SUMS

What it means

During `zeroclaw update`, the updater derives the asset filename from the download URL's last path segment (asset_name_from_url) and searches every SHA256SUMS line for that exact name (after trimming a leading '*'). This error fires when no line in the manifest matches, so there is no expected digest to verify against and the update is aborted before install.

Solutions

Compare the filename in the error with the filenames inside the target release's SHA256SUMS; the mismatch (suffix, prefix, case) is usually visible immediately.
If you publish releases: regenerate SHA256SUMS from the final uploaded asset set and re-publish.
If you run the updater: update to a zeroclaw version whose asset-naming convention matches the release layout, or install the asset manually from the release page.
Verify you are not mixing releases (e.g. pinned old SHA256SUMS URL with a new asset URL) if you drive the update flow programmatically.

Example fix

# before: manifest names do not match uploaded assets
abc...  zeroclaw-x86_64-unknown-linux-gnu.tar.gz
# after: regenerate after upload so names match exactly
sha256sum zeroclaw-x86_64-linux.tar.gz > SHA256SUMS

Defensive patterns

Strategy: validation

Validate before calling

fn manifest_covers_asset(sums: &str, asset: &str) -> bool {
    sums.lines().any(|l| {
        l.split_whitespace()
            .nth(1)
            .map(|n| n.trim_start_matches('*') == asset)
            .unwrap_or(false)
    })
}
// before triggering the update, diff the manifest's filenames against the
// release's actual asset list and fail fast with a clear message

Try / catch

match run_update().await {
    Err(e) if e.to_string().contains("not found in SHA256SUMS") => {
        // asset-name drift between release assets and manifest: surface the
        // expected vs actual filename, keep the current binary installed
    }
    other => other,
}

Prevention

Regenerate SHA256SUMS from the final uploaded asset set as the last release step, after any renaming.
Assert in CI that every uploaded asset filename appears exactly once in the manifest.
When changing asset naming conventions, bump and document the zeroclaw version that expects the new names.

When it happens

Trigger: Calling `zeroclaw update` when the release's SHA256SUMS lists different filenames than the uploaded assets: renamed asset (e.g. 'zeroclaw-x86_64-unknown-linux-gnu.tar.gz' in the manifest vs 'zeroclaw-x86_64-linux.tar.gz' uploaded), an asset added after the manifest was generated, case differences, or a manifest copied from a different release.

Common situations: Release tooling renames assets (adds/removes suffixes like .zip vs .tar.gz, musl vs gnu) without regenerating SHA256SUMS; partial republish of a release; zeroclaw version whose expected asset-name convention predates a naming change in newer releases.

Related errors

AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23). Data as JSON: /api/errors/05887b7c7f6709a1. Report an issue: GitHub.

Appendix: source

Thrown at src/commands/update.rs:578

        let Some(digest) = parts.next() else {
            continue;
        };
        let Some(name) = parts.next() else {
            continue;
        };
        let name = name.trim_start_matches('*');
        if name == asset_name {
            if parts.next().is_some() {
                bail!("invalid SHA256SUMS entry for '{asset_name}'");
            }
            if !is_sha256_hex(digest) {
                bail!("invalid SHA256SUMS entry for '{asset_name}'");
            }
            return Ok(digest);
        }
    }

    bail!("asset '{asset_name}' not found in SHA256SUMS")
}

fn is_sha256_hex(value: &str) -> bool {
    value.len() == 64 && value.bytes().all(|b| b.is_ascii_hexdigit())
}

fn main_binary_name() -> &'static str {
    if cfg!(windows) {
        "zeroclaw.exe"
    } else {
        "zeroclaw"
    }
}

/// Names of top-level *file* artifacts (not directories) the release archive is
/// allowed to install next to the running binary, beyond the main `zeroclaw`
/// executable itself. Anything else in the archive's top level is warned about
/// and skipped — symmetric with how unknown top-level *directories* are

View on GitHub (pinned to 88bb9c8533)