Summary
Codex Security plugin v0.1.22 produced a terminal local scan directory whose semantic scan artifacts exist, but the canonical identity envelopes were not fully assembled:
scan-manifest.json contains a valid canonical scan.id;findings.json exists but has no scanId;coverage.json exists but has no scanId;- the scan is unsealed (
sealedAt absent) and has no report.md;
- the terminal finalizer fails closed with:
findings.scanId: must match manifest scan id
The artifacts have not been manually modified.
Investigation so far
The installed v0.1.22 finalizer correctly requires the manifest, findings, and coverage scan identities to agree. It does not synthesize missing findings.scanId / coverage.scanId without the trusted internal completion binding.
The installed CLI exposes no documented terminal resume/reassembly command for this state. Manually adding the IDs or calling undocumented internal completion-binding APIs would bypass the intended evidence chain, so we have not done that.
We also reviewed the newer explicit recover-scan-results path. As documented in later releases, it applies to registered failed, non-canceled workbench scans with validated retained checkpoints; this local terminal scan is not an authoritative registered workbench row and does not appear eligible for that recovery path.
Policy / recovery question
For this exact condition, what is the supported operator recovery path?
- Deterministic resume/reassembly of the existing unsealed scan — if supported, please provide the public/operator-supported command or procedure for reconstructing the canonical findings/coverage identity envelopes from trusted state; or
- Preserve the incomplete scan and start a fresh scan — if that is the intended policy, please confirm that the unsealed directory should remain preserved as incomplete evidence and that a new scan with a new scan ID/directory is the supported next step.
If a newer plugin version supports recovery of this specific v0.1.22 terminal state, please identify the minimum compatible version and whether it can safely adopt/recover the existing terminal directory.
We are intentionally not retrying the finalizer, rewriting the JSON envelopes, deleting the incomplete scan, or starting a replacement scan until the supported recovery contract is clear.
Summary
Codex Security plugin
v0.1.22produced a terminal local scan directory whose semantic scan artifacts exist, but the canonical identity envelopes were not fully assembled:scan-manifest.jsoncontains a valid canonicalscan.id;findings.jsonexists but has noscanId;coverage.jsonexists but has noscanId;sealedAtabsent) and has noreport.md;The artifacts have not been manually modified.
Investigation so far
The installed
v0.1.22finalizer correctly requires the manifest, findings, and coverage scan identities to agree. It does not synthesize missingfindings.scanId/coverage.scanIdwithout the trusted internal completion binding.The installed CLI exposes no documented terminal resume/reassembly command for this state. Manually adding the IDs or calling undocumented internal completion-binding APIs would bypass the intended evidence chain, so we have not done that.
We also reviewed the newer explicit
recover-scan-resultspath. As documented in later releases, it applies to registered failed, non-canceled workbench scans with validated retained checkpoints; this local terminal scan is not an authoritative registered workbench row and does not appear eligible for that recovery path.Policy / recovery question
For this exact condition, what is the supported operator recovery path?
If a newer plugin version supports recovery of this specific
v0.1.22terminal state, please identify the minimum compatible version and whether it can safely adopt/recover the existing terminal directory.We are intentionally not retrying the finalizer, rewriting the JSON envelopes, deleting the incomplete scan, or starting a replacement scan until the supported recovery contract is clear.