OpenAI’s Codex Security CLI guidance asks reviewers to examine coverage alongside findings and interpret results within their documented scope. Its native output separates the run record, security claims, review boundary, and readable report. This dispatch explains how those artifacts work together and applies that guidance to enterprise review and handoff. The artifact model and underlying guidance belong to OpenAI. [1][2]
The practical question is what remains attached to a result as it moves from an engineer’s terminal into a ticket, review meeting, or delivery decision. A finding count becomes less useful when the target, supporting evidence, or unresolved work disappears from the explanation.
The run record establishes context
scan-manifest.json records the target, scope, producer, and sealed artifacts. It answers the starting question: what ran? [1]
For an enterprise reviewer, that context determines which assessment is being discussed. Evidence about a selected scope should support a conclusion about that scope. Before applying it to a delivery decision, establish its relationship to the code under consideration. Luminity recommends preserving that relationship through subsequent handoffs.
Findings state bounded security claims
findings.json records severity, confidence, locations, evidence, and remediation for each finding. [1]
Read severity and confidence as distinct attributes. Review the supporting evidence before deciding how to act. A finding’s presence alone should not be treated as proof of successful dynamic reproduction: OpenAI’s SDK documentation explains that a reportable validation disposition can rely on static analysis. [2]
The enterprise review should preserve what supports the claim and what remains uncertain when proposing a fix or requesting further investigation.
Coverage qualifies the review’s reach
coverage.json records reviewed surfaces, exclusions, deferred work, open questions, and completeness. OpenAI identifies coverage as complete, partial, or unknown and instructs reviewers to examine deferrals and open questions. [1]
Coverage qualifies the result’s reach. A completed review of its stated scope does not establish that every vulnerability has been discovered. OpenAI explicitly cautions that a report with no findings does not establish repository security. [2]
Keep those qualifications visible whenever findings are summarized.
The report carries the result forward
report.md provides the human-readable result; supporting artifacts and exports may also be present in the output directory. [1]
The report is the natural starting point for many reviewers. The surrounding files provide the context needed to assess its conclusions. Luminity recommends checking that any downstream summary preserves material scope limitations and evidence gaps. A readable handoff should make the review easier without broadening the claim.
© 2026 Luminity Digital, Inc. All rights reserved. OpenAI technologies and guidance belong to OpenAI. Practitioner explanation and architectural interpretation by Luminity Digital.
Read the four files together
The files answer related questions: what ran, what was reported, what was reviewed, and how the result is communicated. Their relationship is interpretive; this explanation does not establish a file-generation sequence.
Consider a hypothetical scan that reports no findings while deferring review of a sensitive component. The defensible handoff is: “No findings were reported in the assessed scope; the deferred component still requires review.” A repository-wide security conclusion would exceed that evidence. This is an illustrative example, not an actual scan result.
Luminity recommends reconciling the run context, findings, coverage, and report before carrying a conclusion into enterprise review. If they leave a material question unresolved, preserve that question with the result.
Across repositories, preserve the evidence gaps
So far, we have considered one repository scan attempt. When an enterprise scans multiple repositories as a coordinated campaign, reviewers also need to establish which repositories and revisions were intended for assessment, which attempts ran, and where their evidence can be found. OpenAI’s bulk-scan guidance provides campaign-level records for that purpose. [4]
Campaign manifest.json records the repository inventory, pinned revisions, scopes, modes, and instructions. The append-only results.jsonl ledger records repository attempts, statuses, artifact locations, and available cost or error details. Each repository attempt has its own artifacts. Campaign manifest.json remains distinct from per-attempt scan-manifest.json. [4]
OpenAI’s review guidance proceeds from inventory to attempt status, then coverage and findings. It also calls for recording the next action for each repository and carrying the scanned commit and supporting evidence into handoff. Successful completion does not establish vulnerability absence. [5]
Apply that guidance without collapsing three different situations: an available result with no findings, an available result with incomplete coverage, and missing artifacts or no usable result.
If one intended repository has a result and another has no usable evidence, the second remains unresolved. Missing evidence must never become a clean pass. Luminity recommends accounting for every intended repository at its pinned revision and scope, retaining which attempt supports each conclusion and preserving earlier attempt history.
Enterprise review needs an accountable handoff
Luminity recommends assigning responsibility for interpreting the result, following up on gaps, and retaining the evidence. A finding ticket should retain a reference to its scan attempt and material coverage qualifications. A campaign summary should keep unresolved repositories visible alongside completed assessments.
Retention also needs deliberate handling. OpenAI cautions that scan outputs can contain sensitive source and vulnerability information and recommends private storage with an appropriate retention policy. [2][4] Our recommendation is to preserve the connected evidence under enterprise access and retention rules, with controlled references where copying sensitive artifacts would be inappropriate.
Limits and authority boundaries
Complete coverage does not mean secure. Sealed artifacts do not mean certification. Scan completion does not mean enterprise approval. These are limits on the conclusions an enterprise should draw, not additional guarantees supplied by the files.
The CLI is report-only by default, and its severity policy and incomplete-result behavior affect process outcomes. SDK callers separately determine their process exit status. [2][3] Neither should be substituted for enterprise acceptance.
Our architectural boundary is explicit: scan evidence informs decisions about investigation and remediation; authorization to modify, merge, deploy, or accept residual risk remains governed by the enterprise’s controls.
Security evidence must retain its context and limitations through every review and handoff.
OpenAI’s artifact guidance provides the foundation. Luminity’s enterprise application is to preserve those relationships as evidence moves between teams and decisions. The conclusion remains credible only while a reviewer can trace what was assessed, what supports the claim, and what remains unresolved.
