recon agent stuck repeating gobuster dir scan on same authorized host

TL;DR

The agent repeats the gobuster run because it cannot tell "finished with nothing found" from "never ran". Hash each run's result signature, exit code plus finding count plus output hash, and stop when two consecutive runs produce the identical signature.

(agent re-runs: gobuster dir -u YOUR_TARGET_HOST/ -w WORDLIST, identical output each time)

Use this when

• The recon agent's history shows the same gobuster dir invocation against the same authorized host, repeatedly.
• The runs complete but the agent acts as if they did not.

Not for this skill when

• Gobuster errors out each time. That is the gobuster error family, not a loop.
• The wordlist or target changes between runs. Different inputs are legitimate retries.

Steps

1. Confirm the loop: compare the last two runs' outputs byte for byte. Verify: identical outputs mean the agent is re-doing finished work.
2. Store a result signature per host, wordlist, and flags after every run: exit code, match count, and a hash of the findings. Verify: the state shows the signature from the previous run.
3. Add the guard: before launching gobuster, compare the planned run's key against stored signatures; if it matches a completed run, return the stored result instead of scanning. Verify: the duplicate run is served from cache, not executed.
4. If the agent distrusts cached results, let it re-run exactly once with a different wordlist and record both. Verify: the second run differs in at least the wordlist, so it is new work.
5. Surface the cached result to the report builder with a "previously completed" flag. Verify: findings flow into the report without another scan.

Variant phrasings

agent reruns gobuster same host no progress

The stuck-recon phrasing.

gobuster dir scan repeated by agent

The tool-specific phrasing.

recon loop directory enumeration

The phase-level phrasing.

Compatibility: harness-level fix; works with any gobuster 3.x underneath.

Why it happens

Directory scans that find nothing produce thin output, and thin output looks like no output to a naive completion check. The agent concludes the scan never happened and helpfully runs it again, producing the same thin output, forever.

Edge cases / pitfalls

• Caching by signature means a target that changes between runs, like a lab reset, serves stale results. Invalidate the cache when the engagement notes say the target was rebuilt.
• Do not cache error runs as completed. Only clean exits with parsed output qualify.
• The same loop pattern hits ffuf and directory scans generally; fix the harness once, not per tool.
• A cached "nothing found" is still a result the report should mention; silence reads as skipped coverage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IN1T6klSUs0onkoX-5CUYA