agent's progress checkpoint was lost and it restarted the engagement from zero

TL;DR

A checkpoint that lives in one file, written without verification, is a hope rather than a mechanism: one corrupt write or a cleaned temp directory and the engagement restarts. Write checkpoints atomically to a durable engagement folder, keep the previous checkpoint as a fallback, verify each write by reading it back, and rehearse recovery so the agent resumes mid-engagement instead of rediscovering scope.

agent's progress checkpoint was lost and it restarted the engagement from zero

Use this when

• After a crash, host reboot, or context reset, the agent restarts from initial discovery despite hours of completed work.
• The checkpoint file is missing, empty, or unreadable when recovery is attempted.

Not for this skill when

• The checkpoint exists and the agent ignored it. That is a startup logic bug; fix the agent to load state before planning.
• The engagement data store itself was wiped by the operator. Recovery then depends on backups and the client record, not checkpoint design.

Steps

1. Find where checkpoints are written today: the path, the write method, and whether anything ever reads the file back before trusting it. Verify: Verify: the current mechanism's weaknesses are named, such as a temp path or an unverified overwrite.
2. Move checkpoints into the engagement's durable folder with an atomic write: write to a new file, read it back and validate its structure, then rename it over the checkpoint name. Verify: Verify: a deliberately interrupted write leaves the previous good checkpoint intact.
3. Keep a rotation of the last few checkpoints with timestamps, so one bad write or one bad state cannot erase all history. Verify: Verify: the folder holds several checkpoint versions and the loader picks the newest valid one.
4. Make checkpoint content sufficient to resume: scope state, per-target status, findings so far, open questions, and the engagement constraints. Verify: Verify: a fresh agent process given only the checkpoint produces a plan that continues the engagement rather than restarting it.
5. Rehearse: kill the agent mid-run in a lab engagement and restart it, timing the recovery and checking no completed target is rescanned. Verify: Verify: recovery succeeds from the checkpoint with zero repeated completed work.

Variant phrasings

agent lost checkpoint restarted engagement zero recovery

The symptom phrasing.

atomic checkpoint write read back verify rotation

The write-safety phrasing.

checkpoint content sufficient resume pentest engagement state

The content phrasing.

Compatibility: Compatibility: any long-running agent harness; storage can be plain files, provided the write and rotation rules are followed.

Why it happens

Checkpoints fail at their moment of need because they are written in the path of the work itself: buffered output lost in the crash, a single file overwritten by a half-finished save, a temp directory cleaned by the OS. Each is a storage bug, not an agent intelligence bug, and each is prevented by treating the checkpoint like the engagement's most valuable file, because after a crash it is.

Edge cases / pitfalls

• A valid but stale checkpoint can be worse than none if it resurrects already-reported findings; timestamps and version checks belong in the loader.
• Checkpoints contain client data and credentials references; store them under engagement handling rules, never in shared temp space.
• Recovery behaviour should be visible in the run log, stating which checkpoint was loaded and what it skipped.

Provenance

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

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

Thread query: agent's progress checkpoint was lost and it restarted the engagement from zero

TL;DR: A checkpoint that lives in one file, written without verification, is a hope rather than a mechanism: one corrupt write or a cleaned temp directory and the engagement restarts. Write checkpoints atomically to a durable engagement folder, keep the previous checkpoint as a fallback, verify each write by reading it back, and rehearse recovery so the agent resumes mid-engagement instead of rediscovering scope.