Progress checklist can remain stale when work completes without update_plan calls

Summary

The Codex app progress checklist can show stale/incomplete progress even after the task has actually been implemented and verified, because the visible progress UI appears to rely only on explicit model update_plan calls.

This makes the UI state diverge from the real workspace/task state and places too much responsibility on the model to manually keep the progress bar synchronized.

Environment

• OS: macOS 26.3.1 (a), build 25D771280a
• Architecture: arm64
• Codex CLI: codex-cli 0.128.0

What happened

In a Looper implementation task, Codex created the requested feature branch and then completed the rest of the implementation:

• added config support
• added resolver logic
• injected prompt text into role prompts
• exposed status / config / prompt-preview visibility
• added smoke and unit tests
• ran verification successfully

However, the progress panel still showed only the first checklist item as complete. The remaining items stayed unchecked until the user explicitly pointed out the mismatch and the model made a follow-up update_plan call.

Expected behavior

The progress UI should not rely solely on model discipline to remain accurate. Ideally, Codex should either:

• automatically reconcile progress state when a final answer says the task is complete and the workspace contains matching changes, or
• warn the model/client when a final response is sent while plan items are still marked incomplete, or
• provide a stronger product-level mechanism that prevents a stale checklist from being shown as authoritative after completion.

Actual behavior

The work was complete, but the progress panel still showed stale incomplete items because the model skipped intermediate update_plan calls.

Why this matters

Users reasonably interpret the progress panel as product state, not just model narration. If it remains stale, the user may think only part of the task was done, even when the code, tests, and final answer all indicate completion.

This should be solved at the product/client layer instead of relying only on model capability or behavior.

Suggested direction

Treat this as a synchronization/UX bug between model plan state and task completion state. At minimum, consider a guard before final response when active plan items remain incomplete.