Codex App can render reasoning snippets after the final assistant response

What version of the Codex App are you using (From “About Codex” dialog)?

Codex CLI 0.144.0 in an app-server-backed environment. I do not have the Desktop About dialog version available from this runtime.

What subscription do you have?

Pro

What platform is your computer?

macOS arm64 (Darwin arm64)

What issue are you seeing?

Reasoning/progress snippets can appear in the conversation after the visible final assistant response for the same turn. Sanitized symptom: the final answer is rendered, then a reasoning/status snippet appears below it, which makes the turn look like it continued thinking after it already answered.

This looks like a rendering/event-ordering issue rather than model text intentionally included in the final answer. I am filing this instead of a PR because docs/contributing.md says external code contributions are invitation-only, and the likely Desktop/webview renderer path does not appear to be public in this repository.

I searched for related reports first:

• #30793 covers VS Code hiding reasoning summaries even when app-server emits them. This is adjacent, but it is about reasoning not rendering, not reasoning rendering after the final response.
• #31216 covers TUI reasoning summaries not rendering live or on replay.
• #31664 covers literal <!-- --> placeholders in reasoning text and was marked server-side/resolved; this report is not about placeholder content.
• #30767 / #8648 cover stale final-response ownership broadly. This report may share a turn-boundary theme, but the specific visible symptom is late reasoning/progress content below a final answer.

Public-code notes from the current repository:

• codex-rs/app-server/README.md documents that clients render item/* notifications and that per-item lifecycle is item/started -> deltas -> item/completed, with final turn state coming from turn/completed.
• codex-rs/core/src/session/turn.rs forwards ResponseEvent::ReasoningSummaryDelta / ReasoningSummaryDone into EventMsg::ReasoningContentDelta while an active reasoning item is streaming.
• codex-rs/app-server-protocol/src/protocol/event_mapping.rs maps those to item/reasoning/summaryTextDelta / item/reasoning/summaryPartAdded notifications and maps ItemCompleted independently.
• codex-rs/app-server/src/bespoke_event_handling.rs forwards reasoning deltas and item completions as server notifications. I did not find an invariant in this public path that prevents a client from appending late reasoning events below an already-rendered final agentMessage item for the same turn.

Given the above, the likely fix is in the app client/rendering layer: if a reasoning item or reasoning delta for the current turn arrives after a final-answer agentMessage has already rendered, the client should keep it associated with the turn's activity/reasoning region rather than appending it beneath the final answer. If the ordering guarantee is intended to live in app-server instead, the protocol should make that explicit so clients can rely on it.

What steps can reproduce the bug?

I do not have a minimal deterministic repro yet. The observed shape is:

1. Use a Codex App/app-server-backed conversation with reasoning summaries enabled (model_reasoning_summary not none).
2. Run a multi-step/tool-using turn that produces both reasoning/progress snippets and a final assistant response.
3. Observe that after the final assistant response is visible, a reasoning/progress snippet can be rendered below it.

What is the expected behavior?

For a single turn, user-visible reasoning/progress should be rendered before the final answer, grouped with the turn activity, or collapsed/attached to that turn. A final assistant response should be the visual terminal item for the turn.

If late reasoning events arrive after a final answer item, the client should buffer/reorder/attach them to the turn activity region, not append them as new content below the final answer.

Additional information

I intentionally omitted prompts, session contents, and screenshots because the available evidence came from a private working session. The symptom above is sanitized to the display-order behavior only.