Scan always fails at seal step: `scan-manifest.json: expected a regular file inside the scan directory` — reproducible on Windows AND Linux

[onurtirpan]

Summary

codex-security scan fails deterministically at the seal step. The scan runs to completion (models are invoked, tokens billed), preflight reports zero issues, then the tool errors trying to save the manifest and leaves the scan output directory completely empty on disk. Failure is independent of repo size, platform, and path length. Reproduced on both Windows and Linux.

Repro

mkdir C:\tmp\repro\empty
cd C:\tmp\repro\empty
git init
"print('hi')" > hello.py
git add . ; git commit -m init
codex-security scan

Same failure occurs on real repos of any size.

Error output

codex-security: Could not save the Codex Security scan: scan-manifest.json: expected a regular file inside the scan directory.
codex-security: Partial output was kept at <scan-dir>.

Post-failure filesystem state

The "partial output" directory is completely empty — verified via dir /a /s on Windows and find -type f on Linux. No files, hidden or otherwise. The tool never persisted findings, coverage, or the manifest to disk.

Meanwhile the state DB (workbench.sqlite3) DOES record the scan:

• scans.status = 'failed'
• scans.phase = 'preflight' (never advanced per DB, even though 3–5 min of model work occurred and was billed)
• scans.seal_manifest_digest = NULL
• scan_artifacts, findings, finding_occurrences tables all have 0 rows

Environment

• Windows: Server 2025 Datacenter 10.0.26100 on an AWS EC2 developer workstation (accessed via RDP), Node v24.18.0, LongPathsEnabled=1 (not a MAX_PATH issue)
• Linux (Docker repro): Ubuntu 24.04.4 LTS, kernel 6.17.0-1017-aws, Node v22.23.1, running as root in a container with a bind-mounted repo + credentials dir
• codex-security CLI: 0.1.1
• codexSdkVersion: 0.144.6
• bundledPluginVersion: 0.1.14
• Model: gpt-5.6-sol at xhigh reasoning, multi_agent_v2 (9 concurrent threads)

Cross-platform confirmation

#	Platform	Node	Repo size	Cost	Error
1	Windows Server 2025	24.18.0	656 files	$2.96	same
2	Windows Server 2025	24.18.0	656 files (retry)	$2.64	same
3	Windows Server 2025	24.18.0	77 files	$0.86	same
4	Windows Server 2025	24.18.0	3 files	$1.82	same
5	Windows Server 2025	24.18.0	3 files (--output-dir <short-path>)	$2.42	same
6	Ubuntu 24.04 (Docker)	22.23.1	3 files	$3.09	same

Total burned across 6 failed scans: $13.79. Zero findings persisted to disk. Every attempt calls the model and throws at the seal step regardless.

Likely root cause (guess)

The seal step calls fs.statSync('scan-manifest.json') in the scan output directory and rejects if !stat.isFile(). When the file was never written, the error gets rewrapped into "expected a regular file". Some prior write to that path silently failed, so the seal step tries to stat a file that was never created.

Impact

Blocks all usage (both Windows and Linux). Every retry burns real money against the user's OpenAI account. No way to recover any of the billed findings after failure — the scan runs to completion but nothing is persisted.

Requested fix

Version 0.1.1 is currently the only usable version on npm (0.1.0 was initial). Please cut a 0.1.2 that either:

1. Fails fast at preflight before invoking models (no charge for known-broken save path), OR
2. Actually fixes the seal step so findings persist

[onurtirpan]

Code-level trace pinpointing the failure

Cloned openai/codex-security @ current main and traced the throw site:

Failure point: sdk/typescript/_bundled_plugin/scripts/workbench_db.py line 1499

if scan["recipe_json"] is not None:
    manifest = read_json_object(
        artifact_path(scan_dir, ARTIFACTS["manifest"], required=True)   # ← throws
    )
    ...

artifact_path(..., required=True) at that line calls into workbench_db.py:3492 which raises:

raise SystemExit(
    f"{file_name}: expected a regular file inside the scan directory."
) from exc

when candidate.resolve(strict=True) raises FileNotFoundError because scan-manifest.json doesn't exist yet on disk.

Why it doesn't exist yet

On a fresh scan (no prior run), scan-manifest.json is written by _write_prepared_scan_finalization in finalize_scan_contract.py:2146 — which is called at workbench_db.py:1512, 13 lines after the failing read at line 1499. The read happens BEFORE the write.

The DB row for a failed scan confirms this exact configuration triggers it:

scan.recipe_json != NULL   (multi_agent_v2 enabled, model gpt-5.6-sol, xhigh reasoning)
scan.status = 'failed'
scan.phase = 'preflight'
scan.seal_manifest_digest = NULL
scan_artifacts rows = 0

Every scan started via the CLI has recipe_json set (the --mode standard/deep config), so the failing branch fires unconditionally on fresh scans.

Suggested fix

Two candidate patches, pick whichever fits the intended lifecycle:

Option A — treat the file as optional on this pre-completion read (workbench_db.py:1498-1503):

if scan["recipe_json"] is not None:
    manifest_path = artifact_path(scan_dir, ARTIFACTS["manifest"], required=False)
    if manifest_path is not None:
        manifest = read_json_object(manifest_path)
        manifest_scan = manifest.get("scan")
        if isinstance(manifest_scan, dict) and manifest_scan.get("sealedAt") is not None:
            completion_binding["startedAt"] = manifest_scan.get("startedAt")
            completion_binding["completedAt"] = manifest_scan.get("completedAt")

Option B — gate on scan state — only attempt the read when the scan was previously sealed:

if scan["recipe_json"] is not None and scan.get("seal_manifest_digest"):
    manifest = read_json_object(
        artifact_path(scan_dir, ARTIFACTS["manifest"], required=True)
    )
    ...

Option A is safer (idempotent for both fresh and resumed scans). Option B is semantically clearer if the read is only meant for resumed/re-completed scans.

Cost note (please consider)

Because the failure happens AT completion, the entire model run is billed before the crash. Six failed scans across two OSes racked up $13.79 on a user's OpenAI account with zero findings persisted. A cheap short-term mitigation is to move this read (and any other similar validators) BEFORE the model invocation in the scan lifecycle, so fresh-scan bugs fail fast at $0.

[onurtirpan]

Follow-up: patched fix validated, deeper root cause uncovered

Applied the suggested patch (Option A from the earlier comment) to workbench_db.py:1499 locally on both Windows and Linux (Docker) installs. Ran the SDK's existing bun test suite — 355 pass, 0 fail (no regression). Then executed a real scan end-to-end on both platforms with the patched plugin.

Result: the patch fixes the immediate throw at workbench_db.py:1499 cleanly. The scan advances past that read into the _prepare_scan_finalization phase — where it now hits a second reader of the same missing file:

codex-security: Could not save the Codex Security scan:
  scan-manifest.json: expected a file inside the scan directory

This second error originates from finalize_scan_contract.py:2017:

def _prepare_scan_finalization(scan_dir, ...):
    scan_dir = _require_scan_directory(scan_dir)
    schema_dir = schema_dir or ...
    manifest = _read_scan_local_json(scan_dir, "scan-manifest.json", "scan-manifest.json")   # ← throws
    ...

_prepare_scan_finalization unconditionally reads scan-manifest.json as its first step, then decides was_sealed from what it read. The function has no path where the file legitimately doesn't exist — it assumes an upstream step has already produced a draft.

Where is scan-manifest.json supposed to come from?

sdk/typescript/_bundled_plugin/skills/security-scan/SKILL.md line 14:

"Author scan-manifest.json as an unsealed draft without scan.sealedAt or scan.artifacts, and let complete_codex_security_scan seal the final canonical artifacts."

And line 28:

"Write scan-manifest.json, findings.json, and coverage.json using ../../references/final-report.md."

So the draft manifest is supposed to be authored by the agent (gpt-5.6-sol per codex-security info) during the scan work, before completion reads it. In all 7 reproduced failures now — including a fresh Linux Docker run — the agent completes its work (models are billed, scan.status transitions in DB) but the scan-manifest.json draft is never written to disk.

Where the actual upstream bug likely lives

The failing symptom is universal:

• scan_dir on disk stays empty after completion (no findings.json, no coverage.json, no report.md, no scan-manifest.json, no report.html)
• scan_artifacts table has 0 rows
• scans.phase = 'preflight' (never advances)
• Multi-agent v2 with max_concurrent_threads_per_session=9 at xhigh reasoning runs to completion and is billed
• recipe_json has "multi_agent_v2":{"enabled":true}

Suspects (best guesses without source access to the agent runtime):

1. The recipe for the standard scan mode isn't wiring the "scan-local write" tool into the agent's tool bag — so when the SKILL prompt instructs the model to write files, the model has no write tool available and silently completes without writing.
2. complete_codex_security_scan MCP tool is being invoked with a scan_dir that was cleaned/rotated between the agent's writes and the completion call.
3. The agent's writes go to a temp/staging path that isn't the same scan_dir the completion step reads from.

Cost update

Total spend across 8 attempts on this bug now:

#	Platform	Cost
1–5	Windows (unpatched)	$10.70
6	Linux Docker (unpatched)	$3.09
7	Windows (patched, different downstream error)	~$1.50
8	Linux Docker (patched, this run)	~$1.60
	Total	~$16.88

Every attempt costs money. Please add a preflight check that verifies the recipe can actually produce the required draft artifacts before invoking any models, so bugs of this shape fail at $0 instead of $3.

No PR possible

Confirming what CONTRIBUTING.md states: "External pull requests cannot be imported into the canonical source." This comment is offered as diagnostic context for the maintainers rather than as a proposed patch path.

[onurtirpan]

Opened PR #83 with the guard for workbench_db.complete_scan referenced above. Public SDK test suite passes on the patched main (367 pass, 23 expected skips, 0 fail). Submitted as a diff artifact — happy to close it if the change lands via the canonical mirror instead.

[mldangelo-oai]

Maintainer reproduction on the current public release, @openai/codex-security@0.1.4:

• macOS arm64 with Node.js 24.15.0.
• Stored ChatGPT authentication; standard, single-file-scoped scan using gpt-5.6-terra with low reasoning effort.
• The model ran for approximately 49 seconds and consumed approximately $0.13 before completion failed with: scan-manifest.json: expected a regular file inside the scan directory.
• The selected output directory was completely empty. The workbench recorded status=failed and phase=preflight despite the completed, billed model turn.

This confirms the issue is still present in 0.1.4 and is not Windows-specific. PR #83 bypasses the first missing-manifest read but, as noted above, does not solve the deeper problem that the scan agent never writes the required draft artifacts. The fix should restore authoritative artifact production and fail before model execution whenever that capability is unavailable.

[mldangelo-oai]

Correction to my reproduction above after inspecting the Codex rollout: this particular macOS run was launched inside an already-sandboxed Codex desktop command. The inner scan agent failed every shell command before execution with sandbox-exec: sandbox_apply: Operation not permitted, so it could not produce any draft artifacts. Rerunning the CLI outside that outer sandbox allowed it to create discovery artifacts; that second attempt was intentionally stopped by a low scan-cost limit before finalization.

Therefore my first run reproduces the same missing-manifest symptom but has a confirmed nested-sandbox environmental cause and does not independently establish that issue #73 has the same underlying root cause. It does reinforce the need to verify scan-agent shell/write capability before incurring model spend and to surface the actual sandbox failure rather than only the downstream missing-manifest error.

[zac343]

The maintainer correction is important because the same missing-manifest symptom can sit behind different upstream failures. For the original eight runs, I would preserve a per-attempt evidence boundary rather than infer one root cause from the final error:

1. take each Codex rollout/session separately and use last_token_usage deltas, not cumulative snapshots;
2. mark the first non-zero model usage and the final usage before the seal failure;
3. deduplicate repeated response fragments and child-session replay prefixes;
4. keep the confirmed local cost lower bound separate from the manually reported provider charge;
5. attach the shell/write-capability failure evidence next to that timeline, without treating zero-usage tool rows as hidden billed calls.

That produces a cleaner support/refund artifact: model work definitely occurred, no durable artifact was delivered, and any unproved server-side multiplier stays explicitly unproved.

I built a local-only Codex usage auditor for this workflow: https://mailcheck.agentcartai.com/tools/agent-cost-auditor/?utm_source=github&utm_medium=issue_comment&utm_campaign=codex_security_manifest_billed_73&platform=codex

It reads selected rollout files in the browser; prompts/messages are not uploaded, and it cannot read OpenAI's server ledger, so the result is deliberately a local evidence lower bound. The free result shows the expensive/failed sessions and duplicate evidence; an optional private evidence pack is 1 native USDC on Base Mainnet.