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

downloaded binary does not appear to be zeroclaw

Error message

downloaded binary does not appear to be zeroclaw

What it means

The final check in validate_binary runs the downloaded binary with --version and requires the string 'zeroclaw' to appear in stdout. Exit status was zero but the output did not identify itself as zeroclaw, so the updater refuses to install a file that is probably the wrong executable.

Source

Thrown at src/commands/update.rs:726

    // Check binary architecture before attempting execution so we can give
    // a clear diagnostic instead of the opaque "Exec format error (os error 8)".
    check_binary_arch(path).await?;

    // Quick check: try running --version
    let output = tokio::process::Command::new(path)
        .arg("--version")
        .output()
        .await
        .context("cannot execute downloaded binary")?;

    if !output.status.success() {
        bail!("downloaded binary --version check failed");
    }

    let stdout = String::from_utf8_lossy(&output.stdout);
    if !stdout.contains("zeroclaw") {
        bail!("downloaded binary does not appear to be zeroclaw");
    }

    Ok(())
}

async fn check_binary_arch(path: &Path) -> Result<()> {
    use tokio::io::AsyncReadExt;

    // Read only the header — enough to cover a PE file's DOS stub and reach the
    // COFF machine field pointed to by `e_lfanew` (well under 4 KiB in practice)
    // — instead of pulling the whole multi-megabyte binary into memory.
    let mut header = Vec::new();
    tokio::fs::File::open(path)
        .await
        .context("failed to open binary to read header")?
        .take(4096)
        .read_to_end(&mut header)
        .await

View on GitHub (pinned to 88bb9c8533)

Solutions

1. Run the downloaded binary's --version manually and compare its output with a known zeroclaw release.
2. Check the release page: if the asset is mispackaged, report it and use the previous version.
3. Clear any HTTP cache/mirror between you and the download URL and retry.
4. If you maintain the release: ensure --version output keeps containing 'zeroclaw', since the updater relies on it.

match run_update().await {
    Err(e) if e.to_string().contains("does not appear to be zeroclaw") => {
        // wrong executable shipped: keep current install, report release
    }
    other => other,
}

When it happens

Trigger: `zeroclaw update` when the downloaded archive contains a different (working) binary under the expected name: mispackaged release where another project's binary was shipped, a mirror or cache serving a substituted file, or a wrapper/renamed binary inside the archive.

Common situations: Release packaging scripts copying the wrong build artifact; artifact-name collisions in CI caches; a future version whose --version output stops containing the literal product name (regression).

Related errors

• architecture mismatch: downloaded binary is {bin} but this h
• asset '{asset_name}' not found in SHA256SUMS
• archive does not contain a '{target_name}' binary
• downloaded binary --version check failed
• downloaded file too small to be a valid binary

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