git-sweep has been red for three mornings because gitleaks refuses to commit a news-image URL that contains an auth token, inside a build backup nobody meant to commit. The hook is right. The fix is to not commit the backup.
PDB/logs/plan-day.log since 9-11: '[git-sweep] FAIL JARBUS: commit blocked/failed (gitleaks?)' while '[git-sweep] OK PDB: swept' continues. The git-sweep-fail alert is at count 3 and the heartbeat has not been written since 9-10, which is why STATUS.md reports 'last successful run 76h ago'. The blocker is one file: projects/el-nino-atlas/drafts/build-2026-09-10-backup-ba8cgkmz/public/data/coverage.json, where a GDELT image URL carries auth=... in its query string and matches the generic-api-key rule.
A pre-commit hook is a script git runs before it records a commit; if it exits non-zero, the commit does not happen. JARBUS and PDB both carry a gitleaks hook (installed 2026-06-08) that scans the staged changes for anything shaped like a secret. git_sweep.py stages everything and commits; when the hook blocks, the sweep reports FAIL and - by design - never bypasses it. The heartbeat ping is written only on a clean exit, so the 'last successful run' number is honest, not stale.
Is this a real secret? It is a token in a public news-image CDN URL, sitting in a data file that is itself a copy of a build. Not your credential, not something an attacker gains from - but gitleaks cannot know that, and the right question is upstream: should a folder named build-2026-09-10-backup-<random> be in a source repo at all? A backup of a build, with package-lock.json and ten data files, is scratch. Scratch does not get committed; it gets deleted or ignored.
The two honest resolutions, in order of preference: (1) remove the backup folder from the working tree (and from the index, since git_sweep already staged it) so the sweep has nothing to scan; (2) if the folder must stay, add a path-scoped allowlist entry to JARBUS/.gitleaks.toml for that data file. What is never on the list: git commit --no-verify. That teaches the sweep to lie.
See the block with the value redacted, then clear it by removing the backup.
cd /Users/tom/Claude/JARBUS
gitleaks git --staged --redact --no-banner # shows Finding/RuleID/File with the token masked
# resolution (1): the backup is scratch - unstage and delete it
git restore --staged projects/el-nino-atlas/drafts/build-2026-09-10-backup-ba8cgkmz
rm -rf projects/el-nino-atlas/drafts/build-2026-09-10-backup-ba8cgkmz
# then let the sweep prove it
python3 /Users/tom/Claude/PDB/scripts/git_sweep.py
When the secret scanner blocks, the first question is not 'how do I get past it' but 'why is this file here'.