Repository navigation
Deep Scan omits referenced finding write-up files and fails at completion #1619
Description
Summary
A Codex Desktop Deep Scan completed its independent Standard scans and aggregation, but finalization failed because the coordinator preserved a finding write-up reference without materializing the referenced Markdown file in the parent scan directory.
The exact completion error was:
findings[26].writeup.reportPath: expected a file inside the scan directory
This occurred after approximately three hours of work and about 30 completed independent scans. The canonical JSON artifacts and a generated report.md were retained, but the scan remained failed/unsealed and its findings could not be displayed through the supported completion workflow.
Environment
- Codex Desktop
- macOS 27.0.1 (26A434)
- Codex Security bundled plugin: 0.1.32
- Scan mode: Deep
- Model: Daybreak Blue
- Target: private Git revision; repository details intentionally omitted
Observed artifact state
Read-only inspection after the failure showed:
- The coordinator checkpoint contained a schema-conforming relative path for the rejected finding, shaped as:
findings/<slug>/<slug>.md - The referenced Markdown file did not exist.
- The parent scan directory contained no
findings/directory and no individual finding Markdown files. - The consolidated
findings.jsoncontained 49 findings, but none retained awriteupobject orwriteup.reportPath. scan-manifest.json,findings.json,coverage.json,report.md, and SARIF output existed.- Completion failed during the write-up existence check, leaving the scan unsealed.
No repository source, finding content, credentials, scan identifiers, or user-specific filesystem paths are included in this report.
Expected behavior
The Deep-scan coordinator should either:
- materialize each referenced
findings/<slug>/<slug>.mdfile into the authoritative parent scan directory before returning the canonical manifest; or - omit the
writeupreference consistently if no individual write-up is being produced.
complete_codex_security_scan should then seal the canonical artifacts and publish the supported report.
Actual behavior
Checkpoint data referenced individual write-up files, but those files were not present in the parent scan directory. The final completion validator rejected the scan only after all model work and aggregation had finished.
Impact
- Long-running Deep Scan cannot be completed or displayed through the supported workflow.
- Approximately three hours of scan work reached finalization before failing.
- Retrying the scan would risk repeating expensive work.
- The preserved findings remain unsealed and cannot be treated as an official completed result.
Related issues
- vulnerability-writeup instructs a report filename the findings schema rejects #47 documents late Deep/Diff finalization failures involving missing or invalid
writeup.reportPathtargets. - Track remaining missing-artifact failures during scan completion #73 is the umbrella issue for scans that complete analysis but fail because required scan artifacts are missing at sealing time.
This appears to be a distinct current variant: the parent canonical JSON artifacts exist, but the individual finding write-up files referenced during completion were never materialized.
Activity
mldangelo-oai commentedon Oct 14, 2026
Investigated with synthetic findings. Latest
mainstill reproduces this bug at55b86d8646822c656fede042d4b00b646b3a6882, rechecked before posting. A finalizer reproduction using that commit's complete source archive produces the exact error:The worker/reducer pipeline accepts the write-up reference as JSON metadata, but parent publication does not materialize or relocate its target. Deep completion then validates the referenced file and fails. Subsequent failed-scan recovery can remove the broken optional reference, retain the findings, and generate the aggregate
report.md. This explains how the checkpoint can retainwriteupwhile canonicalfindings.jsondoes not. Recovery can also seal a failed result, so failed status alone does not establish that the retained artifacts remain unsealed.Relevant open PRs, inspected at their current heads:
b247fdd53d27): addresses the transfer mechanism for new scans by copying child write-ups and supporting files into the parent and rewriting their references.2bddd368f8dd): addresses it for new scans by retaining the child files beneath the parent and rewriting references to their actual locations.9c0f06087c4a): partial mitigation. It checks referenced files earlier and keeps explicitly incomplete drafts recoverable, but does not transfer write-up files or repair an already-complete draft with a missing target.Both #939 and #1103 complete Standard child scans before aggregation, allowing missing optional write-up references to be removed with a warning while retaining the findings. Five focused tests passed across those exact heads: three on #1103 and two on #939, covering valid child-file preservation and missing/invalid optional-reference recovery separately. These were synthetic checks, not a replay of the reported scan.
Existing-scan recovery remains unverified. #939 and #1103 overlap as alternative architectural changes, and both document compatibility limits for older unfinished scan/checkpoint formats. Neither should be treated as a confirmed recovery solution for the already-failed 0.1.32 scan. No new model scans were needed for this investigation.