Skip to content

Standard full-repository scan shows only generic heartbeat for 40+ minutes — expected behavior? #70

Description

@hujm2023

Summary

A standard full-repository scan has been running for more than 43 minutes while the CLI prints only a generic Running scan heartbeat once per second. There are no phase changes, completed/planned worker counts, file coverage, estimated cost, or indication of whether the active model request is making progress.

The related processes are still alive, so I cannot tell whether this is an expected long-running request or a stalled scan. Is this duration and lack of phase-level progress expected for a standard scan? If so, could the CLI expose enough progress to distinguish a healthy long request from a hang?

The repository identity and contents are intentionally omitted. It is a large private, multi-service Go monorepo (about 9.4 GB on disk).

Environment

  • Codex Security CLI: 0.1.1
  • Node.js: v26.4.0
  • npm: 12.0.1
  • Python: 3.14.6
  • OS: macOS 26.5.2 (25F84), Apple Silicon (arm64)
  • Authentication: stored ChatGPT/Codex credentials (--auth chatgpt)
  • Scan mode: standard
  • Default model reported by dry-run: gpt-5.6-sol
  • Default reasoning effort reported by dry-run: xhigh
  • Preflight reported delegation support for up to 6 worker slots

Reproduction

codex-security scan /path/to/private-repository \
  --output-dir /path/outside/repository/results \
  --auth chatgpt

The preceding dry-run succeeded:

[00:00] Validating scan inputs
[00:00] Preflight complete
dryRun: true
mode: standard
authentication:
  method: stored_credentials
  verified: false
model: gpt-5.6-sol
reasoningEffort: xhigh

The actual scan then reported:

[00:05] Authentication: stored Codex credentials.
[00:14] Running scan
[01:00] Preflight: worker delegation supported (up to 6 worker slots).
[43:00] Running scan

No other phase or progress messages appeared between those lines. At 43 minutes, the CLI process, its codex exec child, and codex-code-mode-host were all still alive.

Questions / expected behavior

  1. Is a 40+ minute in-flight period with no phase updates expected for a standard scan of a large repository?
  2. Is there a supported way to inspect current phase, worker completion, files reviewed, or model-request health while the scan runs?
  3. Should the CLI periodically report model request in progress, last progress timestamp, phase, and completed/planned workers?
  4. Should there be a configurable no-progress timeout or warning distinct from a total scan timeout?

This overlaps with #29 on long-running scan observability, but this report is specifically about the inability to distinguish healthy progress from a stalled standard scan. #53 also shows that scans can run much longer while exposing phase and worker transitions; those transitions are absent here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions