What version of Codex are you using?
- Codex CLI bundled with the desktop app:
0.146.0-alpha.3.1
- Codex Security plugin:
0.1.14
- macOS
26.5.2, arm64
What happened?
I ran a repository-wide Codex Security Deep scan twice. The latest run completed
all substantive work and reached:
- Building report
- 25 / 25 report artifacts
- 21 validated findings
The canonical scan-manifest.json, findings.json, and coverage.json exist.
All 21 per-finding write-ups and their PoC support files exist as regular files.
An isolated copy of the artifact bundle validates and generates the Markdown
projection successfully with the Codex bundled Python 3.12 runtime.
The app-backed scan nevertheless remains permanently stuck at Building
report, with no report available.
The first completion attempt returned:
Codex Security scan completion failed.
Working-tree contents changed while the scan was running. Start a new scan.
The repository HEAD had not changed. The scan had started with one pre-existing
working-tree delta in a lockfile; that file was later restored while the scan
was running. The UI and error did not identify the changed path, expected
digest, current digest, or any recovery action.
A later continuation attempt returned:
Codex Security scan completion failed.
Scan completion is owned by another continuation.
The original handoff token had to be recovered from local task history. After
using it, the scan again reached the generic snapshot error.
I then reconstructed the exact original lockfile blob from Git and verified
that it reproduced the scan's required snapshot digest byte-for-byte. This
demonstrates that the completed analysis can be bound to its original target
without repeating discovery, but the public app workflow provides no supported,
user-visible way to do that recovery or adopt the completed artifacts.
I have not included private scan IDs, handoff tokens, absolute local paths, or
finding contents in this issue.
Why this is severe
These are expensive, multi-hour scans. I ran the scan twice and consumed
essentially 100% of my weekly Codex usage, yet received no final report even
though every analysis and report artifact was complete. I am extremely
frustrated that a finalization-state problem can discard that much paid usage
and then instruct me to start over.
The product must not treat a recoverable finalization mismatch as a reason to
repeat the entire Deep scan.
Expected behavior
- Finalization should identify the exact changed paths and show expected and
current snapshot metadata, without exposing secrets.
- The workspace should offer a supported Restore/rebind and finalize or
Adopt completed artifacts recovery action.
- Supplying the original handoff token should reclaim continuation ownership
deterministically.
- If the exact original target digest is restored, completion should seal the
existing canonical artifacts idempotently.
- If sealing still cannot proceed, the UI should allow downloading the
validated unsealed findings bundle instead of hiding all useful output.
- Recovery must not run discovery, validation, or write-up generation again or
charge the user for a third scan.
Related issues
This issue is specifically about a Deep scan reaching 25/25 with validated
findings, then becoming unrecoverable across snapshot and continuation-ownership
guards despite intact, locally valid artifacts.
What version of Codex are you using?
0.146.0-alpha.3.10.1.1426.5.2, arm64What happened?
I ran a repository-wide Codex Security Deep scan twice. The latest run completed
all substantive work and reached:
The canonical
scan-manifest.json,findings.json, andcoverage.jsonexist.All 21 per-finding write-ups and their PoC support files exist as regular files.
An isolated copy of the artifact bundle validates and generates the Markdown
projection successfully with the Codex bundled Python 3.12 runtime.
The app-backed scan nevertheless remains permanently stuck at Building
report, with no report available.
The first completion attempt returned:
The repository HEAD had not changed. The scan had started with one pre-existing
working-tree delta in a lockfile; that file was later restored while the scan
was running. The UI and error did not identify the changed path, expected
digest, current digest, or any recovery action.
A later continuation attempt returned:
The original handoff token had to be recovered from local task history. After
using it, the scan again reached the generic snapshot error.
I then reconstructed the exact original lockfile blob from Git and verified
that it reproduced the scan's required snapshot digest byte-for-byte. This
demonstrates that the completed analysis can be bound to its original target
without repeating discovery, but the public app workflow provides no supported,
user-visible way to do that recovery or adopt the completed artifacts.
I have not included private scan IDs, handoff tokens, absolute local paths, or
finding contents in this issue.
Why this is severe
These are expensive, multi-hour scans. I ran the scan twice and consumed
essentially 100% of my weekly Codex usage, yet received no final report even
though every analysis and report artifact was complete. I am extremely
frustrated that a finalization-state problem can discard that much paid usage
and then instruct me to start over.
The product must not treat a recoverable finalization mismatch as a reason to
repeat the entire Deep scan.
Expected behavior
current snapshot metadata, without exposing secrets.
Adopt completed artifacts recovery action.
deterministically.
existing canonical artifacts idempotently.
validated unsealed findings bundle instead of hiding all useful output.
charge the user for a third scan.
Related issues
completed scan, but under a broader scan-stalling issue.
orchestration state is missing.
This issue is specifically about a Deep scan reaching 25/25 with validated
findings, then becoming unrecoverable across snapshot and continuation-ownership
guards despite intact, locally valid artifacts.