zeroclaw-labs/zeroclaw · error · anyhow::Error
asset '{asset_name}' 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.
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* areView on GitHub (pinned to 88bb9c8533)
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
- purge_namespace not supported by this memory backend
- purge_session not supported by this memory backend
- purge_session_for_agent not supported by this memory backend
- archive does not contain a '{target_name}' binary
- downloaded binary does not appear to be zeroclaw
AI-assisted analysis of zeroclaw-labs/zeroclaw@88bb9c8533 (2026-08-23).
Data as JSON: /api/errors/05887b7c7f6709a1.
Report an issue: GitHub.