Codex Security Deep Scan spends ~3 hours in discovery at 16/40 reviews with high resource use #46740

Implementation update — October 14, 2026

PR #1630 is merged as 1595fe4d. Deep Scan now waits for the reducer's result/novelty check before dispatching additional reviews; already-running reviews and accepted results are retained.

Closed after the related fix merged. The controlled regression and live fixture checks establish the dispatch fix, but the original three-hour run is still uncorrelated with this defect. Broader resource-use diagnosis, pre-scan controls, and usage/coverage reporting are not established as resolved by this merge.

What issue are you seeing?

A Codex Security Deep Security Scan launched from the Codex desktop app spent nearly three hours in discovery on a local repository whose inventory contained 63 files. It had completed 16 independent discovery reviews out of the default maximum of 40 when the user asked us to cancel. The user reports this is the fifth time a security-audit workflow has consumed substantial tokens/time with little result. The earlier four occurrences have not been independently correlated with this scan.

This is an anomalous performance/resource-use report, not a claim that an infinite loop has been proven. Read-only status and process checks indicated the run was active at points. We need diagnostics to distinguish expensive intended independent passes, repeated work after worker/context restarts, an ineffective novelty stop, or a phase-transition stall.

Environment

• Codex desktop on macOS, Codex Security plugin installed (package directory reports 0.1.24; the running scan's exact loaded version was not separately attested)
• Repository-wide Deep Security Scan, local worktree, 63-file inventory
• Observed 2026-09-19
• Default maximum of 40 discovery runs was shown in scan context; no measured repository coverage percentage or exact token/cost total was available from the status checks

Steps / observations

1. Start a repository-wide Deep Security Scan through Codex on a local codebase.
2. Observe discovery for nearly three hours. One snapshot showed 15 completed independent reviews and 4 active; just before cancellation it showed 16 completed and 0 active, with a maximum of 40. The 16/40 count is 40% of the review cap, not 40% of repository coverage.
3. The user sets a final five-minute deadline and requests cancellation. The scan is confirmed canceled; no consolidated or sealed Deep Scan report is emitted. We do not classify the lack of a report after explicit cancellation as a separate finalization bug.
4. No automatic replacement scan was started.

Expected behavior

• Expose elapsed time, actual source coverage, per-worker novelty, token/cost use, and a useful ETA or warning early in a disproportionately expensive run.
• Detect genuinely repeated/stalled work and surface whether the 40-pass default or stop_after_no_new is driving the continued discovery.
• Offer a readily visible bounded time/cost setting before a desktop Deep Scan; on reaching that limit, preserve completed evidence and produce a clearly marked partial result where supported.
• Provide a private diagnostic path to correlate this occurrence with previous runs without publishing repository contents or session logs.

The documented deep-scan default of up to 40 independent reviews may explain some of the duration, but not whether these five reported high-use/low-output occurrences share a worker/coordinator defect. This needs investigation rather than an assumption of a literal loop.

Related but distinct: #38453 (missing discovery artifact and automatic rerun) and #35912 (completed scan could not finalize). This run was explicitly canceled at 16/40, with neither failure observed.

I have omitted repository identity/path, source code, scan ID, handoff tokens, and local logs from this public report. Sanitized diagnostics can be supplied privately after review.

CLI/SDK project triage, October 13, 2026

Scope: determine why a small-repository Deep Scan spends hours in discovery and whether existing stop criteria work as intended. Reuse this report rather than file a new generic performance issue.

Public report #46740 describes the September 19 macOS desktop run above. The installed plugin directory reported 0.1.24, but the exact version loaded by that run was not independently attested. The inventory contained 63 files. Nearly three hours produced 16 completed independent reviews out of a 40-review maximum, followed by explicit user cancellation. This is not evidence of an infinite loop, 40% source coverage, or a separate finalization bug caused by cancellation. Four earlier incidents mentioned by the user were not correlated.

Current and proposed behavior: main already exposes durable independent-review counts through onDeepProgress and supports time/cost controls. The existence of those controls does not establish that the reported run's duration was correct. PR #939 and PR #1103 are still-open alternative changes to compose batches of Standard scans and retain child work. They apply stop criteria at batch boundaries and document continuation incompatibilities. They are relevant proposals, not verified fixes for this incident. PR #907 is an open accepted-work recovery proposal.

Completion: reproduce or explain the duration with pinned settings. Measure time spent in useful independent discovery, duplicate findings, retries/restarts, reduction, and waits. Verify convergence and existing time/cost stops. Make clear whether work continues because new issues are being found, a batch is finishing, or a worker is stalled. On a supported bounded stop, preserve accepted evidence with accurate incomplete coverage. Do not promise an ETA derived solely from the 40-review cap.

Medium priority because this is an older version-specific performance investigation with substantial impact but no demonstrated current root cause. Keep it related to #46819 rather than infer that both reports share a billing defect.