agent loop detected: cycling between nmap and masscan scans failed to complete on authorized subnet

TL;DR

The agent alternates tools because each one's failure looks like a cue to try the other, and neither failure is ever recorded. Replace the ping-pong with a scan plan: each phase, fast sweep then detail, runs once per subnet, records its outcome, and the agent only advances, never alternates.

(agent alternates: masscan fails -> nmap fails -> masscan fails ... same subnet)

Use this when

• The agent log shows nmap and masscan trading off against the same authorized subnet, each failing.
• No phase ever reports completion.

Not for this skill when

• One tool works and the other is a deliberate fallback. That is a plan, not a loop.
• The subnet is out of scope. Stop entirely, do not replan.

Steps

1. Confirm the alternation: list the last 10 scan commands in order. Verify: the pattern is A,B,A,B against the same target set.
2. Halt both and record each tool's last failure reason separately. Verify: the state now says "masscan failed" and "nmap failed" with reasons, instead of "not done".
3. Write the scan plan as an ordered phase list: phase 1 masscan sweep once, phase 2 nmap detail once, each with its own success criteria. Verify: the plan has no step that says "if failed, try the other tool".
4. Execute the plan strictly in order, marking each phase complete, partial, or failed with evidence. Verify: a failed phase does not re-trigger the other tool.
5. If both phases fail, escalate the subnet as unscannable with both error logs attached. Verify: the tester gets one clear escalation, not an infinite alternation.

Variant phrasings

agent alternates nmap masscan never finishes

The ping-pong phrasing.

scan plan loops between two tools

The planner phrasing.

agent fallback loop port scanning

The fallback-logic phrasing.

Compatibility: harness-level fix, any nmap and masscan versions.

Why it happens

Fallback logic without memory is just a loop with extra steps. "If masscan fails, try nmap" is reasonable once; without recording that nmap already failed too, the rule fires forever in both directions.

Edge cases / pitfalls

• Partial results are still results: a masscan run that covered half the subnet before dying should feed nmap a smaller target list, not trigger a full re-sweep.
• Time-box each phase. An unbounded phase 1 means phase 2 never starts even without a loop.
• Keep the raw logs from both tools: "unscannable" needs evidence, and the two failure modes together often diagnose the network problem.
• Review the fallback rules after the engagement; every "try the other tool" rule needs a memory of what was already tried.

Provenance

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