agent loop detected: nmap re-scan of the same authorized target failed to finish

TL;DR

The agent re-issues the same nmap command because it never records the attempt as failed, so its planner sees an unscanned target forever. Give every scan an idempotency key built from target, port set, and flags, cap retries at two, and write the failure reason to the run log so the planner can move on.

(agent re-runs: nmap -sS -p- TARGET, attempt 3, 4, 5 ... never completes)

Use this when

• Your pentest agent's log shows the identical nmap invocation repeating against the same authorized target.
• Each attempt times out or errors the same way.

Not for this skill when

• Nmap fails differently each time. That is a target or network problem, not a loop.
• The target is out of scope. Loops never justify scanning new hosts.

Steps

1. Confirm the loop: search the agent log for the nmap command line and count identical invocations. Verify: three or more identical attempts with no new output means a loop, not bad luck.
2. Kill the current attempt and record the failure mode, timeout, host down, or permission, in the run state. Verify: the state file now says this scan failed for a named reason.
3. Add the idempotency key: hash the target, port range, and flags, and refuse to run a scan whose key already has two recorded failures. Verify: a third identical request is rejected by the guard instead of executed.
4. Route the failure to the planner with the evidence: last error line, attempt count, elapsed time. Verify: the planner marks the target scan-failed and picks the next target.
5. If the scan matters, schedule one manual retry with different parameters, fewer ports or a longer timeout, as a distinct keyed scan. Verify: it is a new deliberate attempt, not the loop restarting.

Variant phrasings

agent keeps rescanning same target nmap

The planner-behavior phrasing.

nmap scan never completes agent retry loop

The symptom phrasing.

pentest agent repeats failed nmap scan

The engagement-context phrasing.

Compatibility: any agent harness that shells out to nmap. The fix lives in the harness retry logic, not in nmap.

Why it happens

Most agent loops come from a planner that only understands success: a scan with no result file looks like a scan that never ran. With no failure memory, the rational next step is always "run it again", forever.

Edge cases / pitfalls

• A retry cap of two is a starting point; flaky lab networks may need three. Tune the cap, do not remove it.
• Recording failures per key means a genuinely fixed target needs a key-reset path. Give the tester a manual "clear failure" action.
• The loop can also be the scan succeeding while the parser fails to read the output. Check the parser before assuming nmap is at fault.
• Log the guard's rejections where the tester can see them; silent skips look like missing coverage in the report.

Provenance

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