hypatia-cli.sh scan exits 1 with no diagnostic on every consumer-repo CI run

[hyperpolymath]

Symptom

hypatia-cli.sh scan . in the Hypatia Security Scan / Hypatia Self-Scan workflow exits with code 1 on every recent run across multiple repos:

• hyperpolymath/my-lang — every commit to main since the workflow was added
• hyperpolymath/standards — same
• (hyperpolymath/affinescript is currently passing; not yet investigated whether it actually runs Hypatia or skips it)

Reproducible run

hyperpolymath/my-lang run 25654672309 (build of port branch). The scanner installs Elixir 1.19.4 / OTP 28.3, clones hyperpolymath/hypatia, runs mix deps.get + mix escript.build if the binary is missing, then executes:

HYPATIA_FORMAT=json "$HOME/hypatia/hypatia-cli.sh" scan . > hypatia-findings.json

The log shows:

Scanning repository: hyperpolymath/my-lang
Warning: Dependabot alerts unavailable: GITHUB_TOKEN not set — cannot query Dependabot alerts
##[error]Process completed with exit code 1.

The scanner doesn't print any further diagnostic before exiting 1, and hypatia-findings.json isn't produced (so the downstream jq step would also have failed if reached, but the workflow stops at the exit 1).

Likely causes (untriaged)

The Dependabot warning is from inside the scanner — it tried to query the Dependabot API without a token. That's a warning, not the failure cause. Candidates:

1. Scanner internal error past the warning. The scanner may abort on a follow-up step that we don't see in the log (e.g. unhandled exception, missing input file, mix dependency issue).
2. No GITHUB_TOKEN env propagated to the scanner step. The Dependabot warning + exit 1 may be cause-and-effect — the scanner may treat "couldn't query Dependabot" as fatal rather than a warning.
3. hypatia-cli.sh ABI changed. The scan invocation hypatia-cli.sh scan . may have grown a required flag the workflow doesn't pass.
4. Repo content trips a scanner bug. The scanner could be hitting an unhandled file in the repo (e.g. an .affine file the parser doesn't know about, or a binary it tries to UTF-8-decode).

Why this matters

The check sits in actions/checks for every commit and PR across the estate. While the user has been merging through it with --admin, the failure makes it harder to spot real regressions — every PR is preceded by the same red-X.

Suggested investigation order

1. Reproduce locally: clone hyperpolymath/hypatia, cd into a target repo, run hypatia-cli.sh scan . and capture stderr.
2. Pass GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} to the scan step in .github/workflows/hypatia-scan.yml; if that fixes it, it's cause Claude/review scm security t3e cl #2.
3. If the scanner is failing on an estate-specific file type, file an issue against hyperpolymath/hypatia.

Out of scope for this issue

Restoring the scanner's PR-comment + findings-artefact behaviour, which the workflow already wires up downstream of the failing step.

Related

• The scanner repo: https://github.com/hyperpolymath/hypatia
• The workflow file: .github/workflows/hypatia-scan.yml
• Originally flagged in the affinescript#64 closeout comment.