multiscan resume skips corrupted artifacts without validating the scan contract

Summary

When a completed multiscan campaign is resumed, the supervisor checks only whether four required artifact paths exist and are regular files. It does not parse the JSON documents, validate their schemas, or verify the sealed artifact digests.

As a result, a corrupted artifact bundle is still counted as completed and skipped instead of being rescanned.

Affected version and environment

• Released package: @openai/codex-security@0.1.1
• Originally reproduced at commit e94d6bef9797a192febfde89a26ec7f831bc09b2
• Confirmed still present on current main at f22d4a36f26d16287bcdfd707b369116e02a08c3
• Microsoft Windows NT 10.0.19045.0
• Node.js 24.18.0

Steps to reproduce

I used a source-level test harness modeled on tests-ts/multiscan.test.ts, so the reproduction does not require an API call:

1. Create a temporary local Git repository and commit one file.
2. Create a one-row inventory CSV containing the repository path and full commit SHA.
3. Provide a test createSecurity() client whose run() method increments a counter, writes the four required artifact files, and returns complete coverage.
4. Run runMultiscan() once and confirm that the security client was called once.
5. Replace the completed attempt's scan-manifest.json with invalid JSON while leaving all four files present:

{broken json

6. Run runMultiscan() again with the same inventory and output directory.

Observed result:

{
  "first": {
    "completed": 1,
    "failed": 0,
    "skipped": 0
  },
  "second": {
    "completed": 1,
    "failed": 0,
    "skipped": 1
  },
  "securityRunCalls": 1,
  "corruptedArtifactPreserved": true
}

Expected behavior

The resumed campaign should validate the completed artifact bundle. If the contract or seal is invalid, the task should be treated as pending and a new attempt should be created.

Actual behavior

The task is reported as completed and skipped solely because the four paths remain regular files. The corrupted bundle is preserved as the latest successful result.

Impact

Interrupted writes, manual edits, filesystem corruption, or incomplete artifact restoration can leave a bundle that is unusable or no longer sealed. Subsequent bulk scans can still report the repository as completed without repairing or rerunning it.

Relevant code

• Resume decision: https://github.com/openai/codex-security/blob/f22d4a36f26d16287bcdfd707b369116e02a08c3/sdk/typescript/src/multiscan.ts#L109-L123
• Artifact existence check: https://github.com/openai/codex-security/blob/f22d4a36f26d16287bcdfd707b369116e02a08c3/sdk/typescript/src/multiscan.ts#L338-L347
• The current test helper also treats four {} files as a completed bundle: https://github.com/openai/codex-security/blob/f22d4a36f26d16287bcdfd707b369116e02a08c3/sdk/typescript/tests-ts/multiscan.test.ts#L79-L89

Suggested direction

Possible approaches:

1. Reuse the existing contract/seal validation before accepting a completed receipt.
2. Alternatively, record artifact digests in the receipt and verify them during resume.
3. If validation fails, preserve the old attempt for inspection and create a new attempt rather than overwriting it.
4. Add regression cases for malformed JSON, schema-invalid JSON, and a changed sealed artifact.

Start in sdk/typescript/src/multiscan.ts at the resume decision and artifact existence check, then read the helper in sdk/typescript/tests-ts/multiscan.test.ts. Run the multiscan tests and add regression coverage for malformed JSON, schema-invalid artifacts, and changed sealed artifacts. Done means invalid bundles are treated as pending, preserved for inspection, and rescanned.