agent re-scans the same authorized target after every timeout instead of s

Not specified by the original author.

TL;DR

The agent re-scans because a timeout leaves no record, so the target looks fresh every time. Give each target a failure budget of two timeouts, then quarantine it for the rest of the run and spend the time on unscanned targets instead.

(agent re-scans TARGET after each timeout; same timeout repeats)

Use this when

• The agent log shows the same authorized target timing out across multiple scan types, each followed by another attempt.
• The run is spending more time on one flaky host than on the rest of the scope.

Not for this skill when

• Timeouts are spread across many targets. That is a network or rate problem, not a per-target loop.
• The target just needs a longer timeout once. A single adjustment is tuning, not quarantine.

Steps

1. Count the timeouts per target in the run log. Verify: one target accounts for a disproportionate share of attempts.
2. Quarantine it: mark the target skipped-for-now with the timeout evidence attached. Verify: the planner's next-target selection excludes it.
3. Continue the run across the remaining scope. Verify: overall progress resumes instead of stalling on the flaky host.
4. At the end of the run, make one deliberate retry of quarantined targets with a longer timeout and a narrower scan. Verify: the retry is a single planned attempt, not the loop restarting.
5. Report quarantined targets as "unscannable within time budget" with the timeout logs attached. Verify: the report is honest about the gap instead of silent.

Variant phrasings

agent keeps retrying timed out target

The budget-burning phrasing.

flaky target stalls agent scan run

The symptom phrasing.

agent timeout retry storm one host

The rate-shaped phrasing.

Compatibility: harness scheduling fix; tool-agnostic.

Why it happens

Timeouts are the least informative failure: no output, no error, just silence. Planners that treat "no result" as "not attempted" will keep attempting, and a host that times out once usually times out the same way ten times.

Edge cases / pitfalls

• Quarantine is per-run, not permanent. A target that was down during the scan window may be up for the retest; the next run starts fresh.
• Do not quarantine a target the engagement specifically prioritizes without telling the test lead. Priority targets get manual attention, not silent skipping.
• If most targets time out, the problem is the tester box or the network path. Quarantining everything is a signal to stop and diagnose.
• The end-of-run retry should use a longer timeout than the attempts that failed; retrying with the same timeout just re-proves the timeout.

Provenance

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

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

Thread query: agent re-scans the same authorized target after every timeout instead of skipping it

TL;DR: The agent re-scans because a timeout leaves no record, so the target looks fresh every time. Give each target a failure budget of two timeouts, then quarantine it for the rest of the run and spend the time on unscanned targets instead.

Not specified by the original author.

TL;DR

The agent needs a watchdog, not patience. Give every scan a hard per-stage timeout, require progress evidence (new ports, new hosts, new lines in the output file) at least every few minutes, and define a fallback per stage: shrink, chunk, or skip. A scan with no progress for 10 minutes is a failed scan, not a running one.

pentest agent stuck on waiting for scan with no progress on authorized target

Use this when

• The agent shows no new output, no new findings, and no plan change for many minutes while a scan runs.
• The scan tool itself offers no progress bar the agent can read.
• The run has no per-stage timeout, so the agent waits forever.

Not for this skill when

• The scan is slow but the output file keeps growing. That is a pacing problem, not a hang.
• The target is genuinely unreachable and the tool errors out quickly. That fails fast already.
• A human tester explicitly asked the agent to wait for a long scan to finish. That is an instruction, not a breakdown.

Steps

1. Wrap every scan invocation with an explicit timeout, for example timeout 1800 nmap -p- TARGET_HOST -oA full_scan. Verify: a hung scan exits with code 124 instead of hanging the agent.
2. Require a progress check every 5 minutes: has the output file grown, or have new findings appeared since the last check. Verify: the agent logs one progress line per interval.
3. Define the fallback before the scan starts: if no progress in 10 minutes, first retry with a narrower scope (top 1000 ports instead of all ports), then chunk, then skip and record the gap. Verify: the fallback chain is written in the run plan, not improvised.
4. Split long scans into stages (discovery, port scan, service scan), each with its own timeout and checkpoint file. Verify: each stage writes its own output file before the next begins.
5. After the run, record skipped scans and their reason in the engagement notes so the human tester can decide whether manual follow-up is needed. Verify: the notes list every scan that did not complete.

Variant phrasings

agent waiting forever for scan to finish

Same watchdog pattern, symptom phrasing.

scan hang with no output in agent run

Tool-agnostic variant.

pentest agent frozen during long scan

Engagement-level phrasing.

Compatibility: GNU timeout on Linux/macOS scanning workstations. The progress-check pattern is harness-agnostic.

Why it happens

Agents inherit the shell's default behavior: wait until the child process exits. Scanners can sit for hours on filtered hosts without emitting anything the agent can read, and most harnesses have no default step timeout. The watchdog makes "no progress" an observable, actionable event.

Edge cases / pitfalls

• Do not set the timeout so low that legitimate slow scans always trip it. Calibrate from one known-good scan of a similar target first.
• Killing a scan mid-write can corrupt its output file. Prefer output formats that flush incrementally, and treat partial files as suspect until validated.
• Skipping is a finding in itself: an unscanned target is a coverage gap the report must disclose, not a silent omission.

Provenance

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

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

Thread query: pentest agent stuck on waiting for scan with no progress on authorized target

TL;DR: The agent needs a watchdog, not patience. Give every scan a hard per-stage timeout, require progress evidence (new ports, new hosts, new lines in the output file) at least every few minutes, and define a fallback per stage: shrink, chunk, or skip. A scan with no progress for 10 minutes is a failed scan, not a running one.

Not specified by the original author.

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

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

Thread query: 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.