Deep Scan fails when parent agent exits before discovery orchestration completes #1967

Activity

1. mldangelo-oai commented on Oct 25, 2026

   

   mldangelo-oai

   on Oct 25, 2026

   Collaborator

   More actions

   I reproduced this on main at d329d8dc with a simulated parent turn and the real CLI scan machinery. Before the turn ended, the coordinator was running and the scan was resumable. The SDK then tried to finalize, hit the manifest error you saw, and marked both the scan and the coordinator as failed. At that point scans resume rejected the scan. I couldn't find a supported way to resume a scan already in that state.

   #1912 fixed the related case for workbench-owned scans. The CLI path that runs through a parent session still has this bug. I reproduced the state change on Linux; I haven't established why the parent in your Windows run exited early.
2. mldangelo-oai

   added

   bugSomething isn't workingSomething isn't working

   area:deep-scanDeep Scan coordination, worker scheduling, coverage, convergence, and resume.Deep Scan coordination, worker scheduling, coverage, convergence, and resume.

   priority:p1High-impact scan failure, integrity gap, or user-blocking regressionHigh-impact scan failure, integrity gap, or user-blocking regression

   on Oct 25, 2026
3. DarkInnocence commented on Oct 25, 2026

   

   DarkInnocence

   on Oct 25, 2026

   Author

   More actions

   Thanks for reproducing and investigating this.

   From my original logs, the parent agent ran for approximately 45 minutes before ending its turn, despite acknowledging that the Deep Scan coordinator was still running. Shortly afterward, the scan transitioned to failed with the manifest persistence error.

   This occurred on Windows using CLI 0.6.0, with 4 workers, 3 subagents, and xhigh reasoning. A smaller Deep Scan with 1 worker and no subagents completed successfully.

   Would the parent-session logs surrounding the premature exit help identify why the turn ended? I can provide sanitized excerpts, execution timestamps, and relevant diagnostic information.

   Also, is there any planned fix for the CLI parent-session path similar to #1912, including preserving resumability when the parent exits unexpectedly?
4. mldangelo-oai commented on Oct 25, 2026

   

   mldangelo-oai

   on Oct 25, 2026

   Collaborator

   More actions

   I confirmed the failure on the published CLI 0.6.0 as well as on current main. A control completed normally when discovery finished before the parent returned. This is consistent with your smaller run. I am preparing a fix that preserves the original scan for explicit resume; it is not in 0.6.0.

   Yes, a short sanitized event sequence would help identify why the Windows parent ended. The most useful details are the timestamp and event type of the last Deep Scan tool response, whether the parent then emitted turn.completed or an error/disconnect, any parent process exit code or signal, and the timestamp of the first manifest error. Event names and timing are enough; no prompts, scan findings, repository paths or full logs are needed.

   For a scan already marked failed, scans resume cannot reopen it. I checked the workbench helper shipped in npm 0.6.0: it can republish validated checkpoints from a failed, non-canceled scan. On a copy of a failed 0.6.0 scan, it retained the original finding, produced a stable report on repeat and made no model calls. It cannot reconstruct provisional findings that were never written.

   For a global npm install on Windows, the corresponding PowerShell commands are below. Use the same Codex state directory as the original scan and replace the example ID. If Python was configured explicitly, use that interpreter in place of py -3.

   $scanId = 'your-scan-id'
   $wb = Join-Path (npm root -g) '@openai/codex-security/_bundled_plugin/scripts/workbench_db.py'
   py -3 $wb recover-scan-results --scan-id $scanId
   codex-security scans show $scanId --json

   Use the helper bundled with the npm CLI that created the scan. The older Desktop Marketplace plugin rejected these CLI artifacts in my test.
5. DarkInnocence commented on Oct 25, 2026

   

   DarkInnocence

   on Oct 25, 2026

   Author

   More actions

   Thanks for investigating and identifying the recovery option.

   I reviewed the original Windows logs and extracted the following event sequence (UTC, October 24):

   • 20:19:27.385 — start_codex_security_deep_scan invoked.
   • 21:03:42.214 — Last wait tool response: Script running with cell ID 5.
   • 21:03:52.830 — Parent emitted its final message, explicitly acknowledging that the coordinator was still running.
   • 21:03:53.283 — Parent emitted task_complete.
   • 21:04:06.788 — Scan recorded as failed with the discovery manifest persistence error.

   There was no observed parent-session error or disconnect event. The logs show task_complete rather than turn.completed. I couldn't establish a parent process exit code or signal from the available events.

   The parent ran for approximately 45 minutes before completing its turn, while the Deep Scan was still active.

   I'll try the recover-scan-results helper against the failed scan and report the outcome.

   Thanks again for working on the CLI fix, particularly preserving scan resumability when the parent exits prematurely.
6. mldangelo-oai commented on Oct 25, 2026

   

   mldangelo-oai

   on Oct 25, 2026

   Last edited by mldangelo-oai

   Collaborator

   More actions

   The sanitized event sequence helped reproduce the failure on the published CLI 0.6.0 and on main. With code mode, the coordinator call can return a still-running cell. If the parent ends its turn then, its MCP host closes while the reducer is still working. The CLI attempts to finalize without the completed coordinator manifest and marks the scan failed. I reproduced that sequence on Linux with stock Codex 0.163 and 0.164, scripted model responses, and real worker processes; I haven’t replayed the original Windows scan.

   PR #2007 merged the fix to main. In the installed CLI comparison, the original reducer finished and the first command exited successfully, with no follow-up prompt or manual resume. The latest release, 0.6.0, predates the fix. Follow-up PR #2012 addresses tool configuration compatibility. On its ab47a485 revision I also ran the ordinary CLI against 12,500 synthetic files in 3,700 directories outside Git, with four workers, three subagents per worker and a 120-discovery limit. Ten discoveries and two reducers succeeded; the coordinator returned the sealed manifest at 72 seconds in the original parent turn. The fixture used a local scripted model, so this confirms the lifecycle at that size, not the findings or the 45-minute interval in the original report.

   For a new scan on npm 0.6.0, with the default bundled plugin and no custom direct-only namespace list, this command worked from the target directory:

   pnpm dlx @openai/codex-security@0.6.0 scan . --mode deep --codex "features.code_mode.direct_only_tool_namespaces=['mcp__codex_security','codex_security']"

   With the same published package and its stock Codex 0.163.0 binary on Linux, the unmodified command yielded while the coordinator was active and exited 2. With the override and a reducer deliberately held for 40 seconds, the direct call returned the original completed manifest after 43.9 seconds; the first CLI command exited 0 without another user prompt. The native CLI, MCP plugin, reducer, and workbench were real; model responses were scripted locally. Both PowerShell 7 argument-passing modes preserved the argument through pnpm on Linux; this was not an end-to-end Windows run. The override replaces the list for that invocation. Keep any deliberately configured entries; custom server naming is tracked in #2012.

   Recovery depends on the saved state:

   • running: Run codex-security scans resume SCAN_ID. In a separate Linux test, I killed the top-level CLI after three discoveries. Its native writer survived temporarily, so immediate resume reported an active writer. Once that writer exited naturally, the same command completed the original scan and all three saved discovery checksums matched.
   • failed: scans resume cannot reopen it. The PowerShell recovery instructions recover validated findings already saved on disk; they cannot reconstruct findings that were only provisional.

   ❤️React with ❤️1Reacted by Kaam25Hai
7. mldangelo-oai

   added a commit that references this issue on Oct 25, 2026

   fix(deep-scan): wait for the coordinator before ending CLI scans (#2007)

   ...

   28a1860
8. mldangelo-oai

   closed this as completedin #2007on Oct 25, 2026