Codex --run-batches --scan-after-import exits 1 after successful import because new queue blocks its scan

Open
  • Is something wrong?
#856 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
cli

Research direction

Start with run_followup_scan in app/commands/runner/codex_batch.py, where force_queue_bypass defaults to false, and trace how the import's queued findings reach the scan gate. Check the --force-followup-scan message against review --help, and read closed #394 for the earlier decision. Done means the maintainers have chosen a lifecycle, either a successful exit with clear next steps or an honored scan that keeps the plan intact, and the command no longer exits 1 after a successful import.

Written by the indexing model from the issue text.

Description

The documented Codex batch command imports its review successfully, then exits with status 1 because its own follow-up scan is rejected by the execution-queue gate.

This appears related to #394, which is closed with a comment that the behavior was fixed in 0.9.6. I reproduced it with desloppify 1.0 on Python 3.12.3/Linux.

Reproduction

In a Python project with a completed initial scan, run:

desloppify --lang python review --path ./apps \
  --run-batches --runner codex --parallel \
  --max-parallel-batches 3 --scan-after-import

All 20 review batches completed and their durable assessments imported. The import added 45 review findings to the execution queue. The final output was:

Running follow-up scan...
45 items remaining in your queue.
Scanning mid-cycle regenerates issue IDs and breaks triage state.
Work through items with `desloppify next`, then scan when clear.
...
Error: follow-up scan failed with exit code 1.

The command exited 1 even though the review results were successfully retained.

Relevant implementation

app/commands/runner/codex_batch.py::run_followup_scan defaults force_queue_bypass to false. Follow-up scan callers do not consistently enable a bypass, and the normal scan gate rejects the findings that the import just queued. The helper still mentions --force-followup-scan in its message, but that option is absent from the installed review --help.

Expected behavior

Please clarify the supported lifecycle for the documented command: either honor the explicitly requested follow-up scan without damaging the newly imported plan, or defer it with a successful review-completion status and clear instructions. A blind switch to --force-rescan can reset plan-start state, so I left the queue intact rather than applying that workaround.

No private source code or review findings are included in this report.

Dominant language
Python
Stars
3.8k
Forks
301
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from peteromallet/desloppify

All issues in peteromallet/desloppify

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.