In a headless session there is no one to click Approve — any tool not pre-allowlisted in settings.json silently auto-denies. That single fact is why the Aug 3 job sweep did nothing.
Your Sunday job sweep has now failed twice in a row (Jul 27, Aug 3 — the open jobhunt-sweep incident in the alert ledger, count 2). The Aug 3 log is a beautiful autopsy: the session loaded your profile, loaded the 20-lead dedup state, planned 6 query families — then found every single web path blocked and exited having touched nothing.
Interactive Claude Code asks permission per tool and you click through. Headless (`claude -p`, what every cron job uses) can't ask — so the permission system falls back to settings.json: allowlisted tools run, everything else auto-denies. A job that needs WebSearch in a session where WebSearch was never allowlisted isn't 'slow' — it's structurally impossible.
The failure was well-behaved, which is the system working: the sweep deliberately wrote nothing (an empty findings file would poison the next diff by reading as 'ran, found nothing'), and the wrapper's verify leg caught the failure and fired the deduped 🚨 task. Fail-loud, no corruption. But two Sundays of zero sweeps means the fix itself is now the task.
Related discovery: six deny rules in your settings.json use Glob(/Users/tom/Documents/**) syntax — and the permission engine warns, in every single headless log, that Glob() rules don't match file reads; they need to be Read() rules. Those warnings have been scrolling past for weeks. Malformed deny rules are worse than noise: the directories you meant to protect aren't protected.
See both problems in one minute:
# The starvation, in the sweep's own words:
tail -40 /Users/tom/Claude/JobHunt/logs/sweep.err
# The malformed deny rules (printed at the top of every headless run):
grep -m6 'Permission deny rule' /Users/tom/Claude/PDB/logs/plan-day.log
A headless session's capabilities are frozen at launch by settings.json — if the job needs a tool, the allowlist IS the job's hands.