agent's scan timed out on a large authorized scope with no checkpoint saved

Not specified by the original author.

TL;DR

A long scan that only writes results at the end loses everything to one timeout. Checkpoint incrementally: persist each target's result and status the moment it finishes, keep a run manifest of what is done, and on timeout resume from the first unfinished target instead of restarting the authorized scope from zero.

agent's scan timed out on a large authorized scope with no checkpoint saved

Use this when

• A scan of a large authorized scope timed out and the agent has nothing to show for hours of running.
• The harness writes one output file only when the whole job completes.

Not for this skill when

• The timeout is the target actively resetting connections. Checkpointing helps bookkeeping, but pacing and client coordination come first.
• The scope is small enough to rescan in minutes. Simplicity beats machinery there.

Steps

1. Define the unit of checkpoint: one target, or one target and tool pair, with its result file and a status of done, failed, or pending in a manifest. Verify: Verify: the manifest format can represent a half-finished scope without ambiguity.
2. Change the runner to write each unit's output and update the manifest immediately on completion, fsynced, before starting the next unit. Verify: Verify: killing the runner mid-scope leaves every completed unit readable.
3. On timeout, have the agent read the manifest first and build its work list from pending and failed units only. Verify: Verify: a resumed run's plan skips every unit marked done.
4. Make unit outputs immutable once done, written to per-unit filenames, so a resume can never overwrite good data with a partial rerun. Verify: Verify: output filenames are unique per unit and no step writes into a completed unit's file.
5. Surface progress from the manifest in the run report: units done, pending, and failed, with timestamps. Verify: Verify: at any moment the report can state exact coverage without waiting for completion.

Variant phrasings

agent scan timeout no checkpoint resume manifest

The design phrasing.

large scope scan loses progress agent restart

The symptom phrasing.

per target checkpointing scanner agent pipeline

The implementation phrasing.

Compatibility: Compatibility: any agent harness that runs tools per target; needs only a JSON or sqlite manifest on the tester box.

Why it happens

Timeouts on large scopes are not anomalies; they are the expected end of many runs, from harness limits, laptop sleep, and target slowness. A design that treats completion as the only save point converts every timeout into total loss. Incremental checkpointing matches the save pattern to the failure pattern, and the manifest doubles as the coverage record the report needs anyway.

Edge cases / pitfalls

• A checkpoint written but not flushed to disk still vanishes in a crash; flush and close per unit, not per run.
• Failed units need their failure reason in the manifest, or the resume retries deterministic failures forever.
• Checkpoint state is engagement data; store it under the same handling rules as results.

Provenance

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

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

Thread query: agent's scan timed out on a large authorized scope with no checkpoint saved

TL;DR: A long scan that only writes results at the end loses everything to one timeout. Checkpoint incrementally: persist each target's result and status the moment it finishes, keep a run manifest of what is done, and on timeout resume from the first unfinished target instead of restarting the authorized scope from zero.