Codex Security scan stalls at Mapping attack surface until the user sends another message

Open 💬 2 comments Opened Jul 17, 2026 by gitnobtemp
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

A Codex Security Review changes scan in the Codex desktop app appeared to hang indefinitely at Mapping attack surface. There was no visible request for input, but the scan only resumed after the user sent another chat message.

This behavior has occurred repeatedly for the user, not just once.

Steps to reproduce

  1. Start a Codex Security Review changes scan for a dirty Git working tree.
  2. Wait until the workspace shows:
  • Progress: Starting
  • Current stage: Mapping attack surface
  • Validated findings: Pending validation
  1. Do not send another message.
  2. The workspace remains at that stage for a long time (about two hours in this run).
  3. Send a message such as “are you stuck?”
  4. The agent resumes and can update the scan phase and continue discovery.

Expected behavior

The security scan should continue autonomously when no user choice is needed. If the underlying task is paused or requires a new model turn, the UI should show a clear “needs attention” state and the exact required action instead of presenting an active scan stage.

Actual behavior

The UI stayed on Mapping attack surface although threat-model artifacts had already been created. No input request was displayed. A new user chat message was required to make visible progress.

Additional coverage issue observed in the same run

The initial discovery worklist showed 18 changed/new files. Final reconciliation against the captured working tree found 23 in-scope changed/new files. Five files had been omitted from the initial worklist and had to be added manually before completion.

Environment and diagnostics

  • Codex CLI/app build visible to the feedback flow: 0.145.0-alpha.18
  • Codex Security plugin: 0.1.11
  • Scan mode: diff / working tree
  • Security scan ID: b16bc291-03e9-4e80-a1d6-d4a0d581a220
  • Target revision: 1db5672cbe8081e6fe816219046960c379864fd0
  • Scan started: 2026-07-17T18:02:39Z
  • Feedback thread ID: 019f7160-107f-7450-b27c-ba3d9a9a3324
  • Feedback was recorded through /feedback without uploading session logs.
  • A screenshot exists showing the scan stuck at Mapping attack surface.

Suggested investigation

  • Check whether long-running security workflows lose their continuation/wakeup after a model turn ends or after context compaction.
  • Persist and display phase transitions immediately when artifacts are completed.
  • Reconcile the discovery worklist with the authoritative captured diff before review starts, including intended untracked files.
  • Expose a paused/waiting state when progress requires another user/model turn.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #33398
  • #32714

Powered by Codex Action

gitnobtemp · 1 month ago

Additional failure observed during the same run: after all 23 worklist rows were closed and canonical artifacts were prepared, complete_codex_security_scan rejected completion with Working-tree contents changed while the scan was running. Start a new scan. No application source file was edited during the audit; the intervening actions were read-only review, pint --test, PHP lint, node --test, git diff --check, and scan-artifact writes outside the repository. This leaves the workspace stuck in reporting even though the report bundle can be validated locally. It may share the same snapshot/worklist reconciliation problem.