NousResearch/hermes-agent · error · RuntimeError

Could not find {binary_name} inside downloaded archive (memb

Error message

Could not find {binary_name} inside downloaded archive (members: {[m.name for m in tf.getmembers()[:5]]}...)

What it means

After checksum verification, the installer opens the tar.gz and looks for a regular-file member whose basename equals the platform binary name (rejecting absolute paths and '..' traversal). If no member matches, it refuses to extract and lists the first five member names it saw. This guards against both archive layout changes and malicious archives that hide the payload at an unexpected path.

Source

Thrown at agent/proxy_sources/iron_proxy.py:670

def _pick_tar_member(tf: tarfile.TarFile, binary_name: str) -> tarfile.TarInfo:
    """Find the binary inside the upstream tar.

    iron-proxy's archive is typically flat (binary at root) but we tolerate
    a top-level directory.  Members must be regular files with a leaf name
    matching ``binary_name``, no absolute paths, and no ``..`` traversal.
    """

    candidates: List[tarfile.TarInfo] = []
    for member in tf.getmembers():
        if not member.isfile():
            continue
        if member.name.startswith("/") or ".." in Path(member.name).parts:
            continue
        if Path(member.name).name == binary_name:
            candidates.append(member)
    if not candidates:
        raise RuntimeError(
            f"Could not find {binary_name} inside downloaded archive "
            f"(members: {[m.name for m in tf.getmembers()[:5]]}...)"
        )
    candidates.sort(key=lambda m: len(m.name))
    return candidates[0]


def iron_proxy_version(binary: Path) -> str:
    """Return ``iron-proxy --version`` output, stripped.  Empty on failure.

    Cached by binary path: ``get_status`` is called per Docker container
    create, but the version string is constant for a given binary.  A
    single subprocess invocation is plenty.
    """

    key = str(binary)
    cached = _VERSION_CACHE.get(key)
    if cached is not None:

View on GitHub (pinned to c896c09c42)

Solutions

1. Inspect the actual archive (`tar -tzf <asset>`) for the release in question and align _platform_binary_name() with the real member name.
2. Pin/roll back _IRON_PROXY_VERSION to the last release whose layout matches, or update Hermes to a version that supports the new layout.
3. As a workaround, extract and install the binary manually into the location find_iron_proxy() checks.

import tarfile

def archive_contains(tar_path: str, binary_name: str) -> bool:
    with tarfile.open(tar_path, "r:gz") as tf:
        return any(m.name.endswith("/" + binary_name) or m.name == binary_name
                   for m in tf.getmembers() if m.isfile())

try:
    find_iron_proxy(install_if_missing=True)
except RuntimeError as e:
    if "inside downloaded archive" in str(e):
        raise  # layout drift — update binary-name constant or pin older release

When it happens

Trigger: find_iron_proxy(install_if_missing=True) when the downloaded archive is valid but its layout changed — the binary sits in a differently-named file, the release started shipping a top-level directory with a version-suffixed binary name, or the 'archive' is actually an HTML error page that happened to be a valid gzipped tar (rare given the checksum check).

Common situations: Upstream release restructured the tarball between versions while _IRON_PROXY_VERSION points at the new one; the platform binary name constant drifted from the shipped name.

Related errors

• No checksum entry for {asset_name} in {checksum_file.name}
• Unsupported platform for iron-proxy auto-install: {system} {
• Failed to download {url}: {exc}
• iron-proxy checksums.txt failed GPG signature verification —
• iron-proxy binary not available — run `hermes egress install

AI-assisted analysis of NousResearch/hermes-agent@c896c09c42 (2026-08-14). Data as JSON: /api/errors/6c5dbeb76d37663b. Report an issue: GitHub.