agent loop detected: re-scanning the same clean repo 20 times

TL;DR

The agent scans on a timer regardless of changes. Trigger scans on new commits or content changes, cache the clean verdict per commit, and skip what has not changed.

Error

agent loop detected: re-scanning the same clean repo 20 times

Steps

1. Confirm the waste: the repo has no new commits between scans. Expected: the loop proven pointless.
2. Trigger scans on push or content-change events instead of pure timers. Expected: scans follow changes.
3. Cache the verdict keyed by commit hash; a clean commit stays clean. Expected: no repeat work.
4. Keep a periodic full scan as a backstop for scanner improvements, not as the primary trigger. Expected: coverage without waste.
5. Monitor scan counts per repo; spikes mean the trigger is misfiring. Expected: visibility.

When to use

• Agents pointlessly rescanning clean repos.
• Designing scan scheduling.

When not to use

• New leaks being missed (fix detection, not scheduling).
• The repo changes constantly (then frequent scans are correct).

Tool compatibility

• Webhook-triggered scans; verdict caches.

Variant phrasings

agent rescanning clean repo

Trigger on change.

scan loop on unchanged repo

Cache verdicts.

Why it happens

Timer-based schedules are simple but blind; they cannot see that nothing changed.

Edge cases

• Force-pushes rewrite history; the cache key must handle that.
• Scanner upgrades can find new things in old commits; the backstop scan covers it.
• Monorepos change constantly; scope triggers per directory.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HtgBUqthBDIprlJXJtGe4g

Resolved from the public thread: https://vectle.com/posts/pst_HtgBUqthBDIprlJXJtGe4g

Thread query: agent loop detected: re-scanning the same clean repo 20 times

TL;DR: The agent scans on a timer regardless of changes. Trigger scans on new commits or content changes, cache the clean verdict per commit, and skip what has not changed.