checksums.txt does not contain {}. Refusing to install. Set

Error message

checksums.txt does not contain {}. Refusing to install.
Set FLOW_UPGRADE_INSECURE=1 to bypass (not recommended).

What it means

In the upgrade `run` flow (src/upgrade.rs:~675), if the fetched checksums.txt has no entry for the tarball asset, checksum verification is impossible. Unless `FLOW_UPGRADE_INSECURE=1` is set, the upgrade bails rather than installing an unverifiable artifact.

Source

Thrown at src/upgrade.rs:679

        if let Some(expected) = parse_sha256_from_checksums(&checksums, &tarball_asset.name) {
            let actual = sha256_file(&temp_tarball)?;
            if expected.to_lowercase() != actual.to_lowercase() {
                bail!(
                    "checksum mismatch for {} (expected {}, got {})",
                    tarball_asset.name,
                    expected,
                    actual
                );
            }
            println!("Checksum verified.");
        } else if insecure {
            eprintln!(
                "Warning: checksums.txt does not contain {}; skipping checksum verification (FLOW_UPGRADE_INSECURE=1).",
                tarball_asset.name
            );
        } else {
            bail!(
                "checksums.txt does not contain {}. Refusing to install.\n\
                 Set FLOW_UPGRADE_INSECURE=1 to bypass (not recommended).",
                tarball_asset.name
            );
        }
        let _ = fs::remove_file(&temp_checksums);
    } else if insecure {
        eprintln!(
            "Warning: checksums.txt not found in release assets; skipping checksum verification (FLOW_UPGRADE_INSECURE=1)."
        );
    } else {
        // Back-compat for older releases (e.g. v0.1.0) that don't ship checksums.txt.
        eprintln!(
            "Warning: checksums.txt not found in release assets; skipping checksum verification."
        );
    }

    // Extract and find the binary

View on GitHub (pinned to a747e741ae)

Solutions

Verify the release is trustworthy, then temporarily bypass: `FLOW_UPGRADE_INSECURE=1 f upgrade` (at your own risk).
Compare the asset name in the release with lines in checksums.txt (`curl <checksums-url>`) to spot naming drift.
Update the fork/release pipeline to include the new asset in checksums.txt.
Pin to a previous release whose checksums are complete, or install via package manager.

Example fix

// before
f upgrade
// after (only if you trust the release)
FLOW_UPGRADE_INSECURE=1 f upgrade

Defensive patterns

Strategy: validation

Validate before calling

# confirm the asset is listed before upgrading
curl -fsSL "$CHECKSUMS_URL" | grep -q -F "$ASSET_NAME" || echo "asset missing from checksums.txt — refuse or set FLOW_UPGRADE_INSECURE=1"

Prevention

Check checksums.txt lists the exact asset filename before upgrading.
Never set FLOW_UPGRADE_INSECURE=1 in automation; fix the release instead.
Keep release CI generating checksums.txt for every asset, including renames.
When forking, regenerate checksums.txt after any asset changes.

When it happens

Trigger: `parse_sha256_from_checksums(&checksums, &tarball_asset.name)` returns None and `insecure` is false — the asset filename is absent from checksums.txt (name changed, new asset added without checksums, or checksums.txt belongs to a different release).

Common situations: Upgrading a fork that publishes assets but forgot to regenerate checksums.txt; asset renamed (e.g. target triple changed) while checksums.txt still lists the old name; release automation skipped the checksum step.

Related errors

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