pentest agent stuck on waiting for scan with no progress on authorized target
Gets a pentest agent unstuck when it sits waiting on a scan that shows no progress against an authorized target. Use when the agent blocks indefinitely on one scan instead of timing out, chunking, or moving on. Not for scans that are slow but visibly progressing.
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 targetUse 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
- 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. - 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.
- 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.
- 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.
- 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