## TL;DR
The agent re-fuzzes because the failed run left no usable result, so the endpoint looks unfuzzed. Compare result signatures between runs, status-code histogram plus match count; when two runs match, serve the cached result and require a changed input, different wordlist, extensions, or filters, before any new run.

```text
(agent re-runs: ffuf -u YOUR_TARGET_HOST/FUZZ -w WORDLIST after failure)
```

## Use this when
- The agent log shows the same ffuf command against the same authorized endpoint repeating after failures.
- The runs produce nothing the agent will accept as a result.

## Not for this skill when
- Ffuf crashes outright. That is the crash-recovery skill.
- The agent varies the wordlist or flags between runs. That is iteration, not a loop.

## Steps
1. Confirm the repetition: diff the last two ffuf invocations and their outputs. Verify: identical command lines mean a loop, not exploration.
2. Define the result signature: exit code, HTTP status histogram, and match count. Verify: you can compute it from any completed or failed run's output.
3. Cache the signature per endpoint, wordlist, and flags. Verify: the failed run's signature is stored instead of discarded.
4. Guard new runs: an identical planned run returns the cached signature with a "previously attempted" note. Verify: the duplicate process never launches.
5. Allow a genuinely new attempt only with a changed input: a different wordlist, extension list, or adjusted match and filter flags. Verify: the new run differs in at least one input dimension.

## Variant phrasings
### agent reruns ffuf same wordlist
The repetition phrasing.
### ffuf fuzzing loop no new results
The symptom phrasing.
### agent stuck fuzzing same endpoint
The endpoint-shaped phrasing.

Compatibility: harness-level fix; ffuf 1.x/2.x underneath.

## Why it happens
Failed fuzz runs produce thin or missing output, which reads as "not done" to the planner. Since fuzzing is the agent's main discovery move, "not done" triggers the move again with the same inputs, producing the same thin output.

## Edge cases / pitfalls
- A cached failure is not a permanent verdict: if the endpoint changes with a new deploy, the tester should invalidate the cache for that endpoint.
- Signature comparison needs the failure modes too: "connection refused" twice is a repeated failure worth escalating, not just caching silently.
- Watch the clock: fuzz loops are the fastest way to burn an engagement's request budget against one endpoint.
- The same signature-cache pattern fixes the gobuster repeat loop; implement it once in the harness and share it across tools.

## Provenance

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