Codex TUI shows Stop hook failure without active-turn indicator while retrying after exit 2

What variant of Codex are you using?

CLI / TUI

Which version are you using?

codex-cli 0.137.0

What operating system are you using?

Fedora Linux 42 Workstation, kernel 6.19.14-102.fc42.x86_64

Bug description

When a Stop hook exits with code 2, Codex correctly injects the hook failure as a continuation prompt and starts generating a corrected answer. However, after the hook failure is shown in the TUI, there is a visible pause before the corrected answer appears, and during that pause there is no visible active-turn / working / retry indicator.

From the user's perspective, the turn can look finished: the user sees the rejected assistant answer, the hook failure text, and no clear signal that Codex is still working on a retry. The user can reasonably start replying while Codex is actually still preparing the corrected answer.

This is especially confusing because hooks are commonly used as quality gates. The most important moment for clear state signaling is exactly the moment when the assistant answer was rejected and Codex is continuing in the background.

Expected behavior

After a Stop hook returns exit code 2 and Codex continues the turn, the TUI should keep the turn visibly active until the retry response is complete.

At minimum, the TUI should show a persistent status line such as:

Retrying after Stop hook feedback...

or reuse the normal Working (... esc to interrupt) active-turn indicator.

Actual behavior

The hook failure is shown, but the retry phase has no clear visible activity indicator. The corrected assistant response appears only after a noticeable delay.

Steps to reproduce

1. Configure a trusted Stop hook that rejects an assistant response by exiting with code 2 and writing feedback to stderr.
2. Start Codex CLI / TUI with hooks enabled.
3. Ask for a response that intentionally violates the hook rule.
4. Observe that the original assistant response is shown and the hook failure is shown.
5. During the pause before the corrected response appears, observe that the TUI does not clearly indicate that Codex is still working on the retry.

Why this matters

The UI state is ambiguous. A user may treat the hook failure as the final assistant response, even though Codex is still generating the corrected answer. This makes hook-based quality gates harder to trust in interactive use.

Related issues

These are adjacent but do not appear to describe this exact bug:

• #15497 - TUI hook status rendering, but about suppressing hook status messages rather than missing retry activity indication.
• #21753 - hook parity umbrella; mentions Stop continuation and validation gaps.
• #22008 - documents that Stop hook failures can become continuation prompts, but in a hidden memory-consolidation scenario.
• #22858 - Stop hook behavior on Esc interruption, different trigger.

Requested fix

When Stop hook exit code 2 causes continuation:

• keep the turn visually active;
• show a retry/status line during the continuation;
• do not let the UI look idle until the corrected assistant response is complete.