[Windows Desktop] 'Pausing' is shown while a non-Goal thread remains active and keeps executing tools

[edwardswhiskeyblues-alt]

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

26.924.6891.0

What subscription do you have?

Paid ChatGPT subscription

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Windows Codex desktop app displayed a pause-semantic progress label (Pausing after [step]) during a long-running local chat even though the thread had not paused and continued executing tools and writing files.

At the same time the label was visible, the canonical thread state remained active, the latest turn was inProgress, activeFlags was empty, and no error was present. Without any user interaction, subsequent reasoning, command execution, and completed file edits appeared in the rollout log. There was no pause lifecycle transition or aborted turn.

The turn later produced a normal final answer and a normal task_complete event, after which the thread became idle. The affected chat did not have an active Goal, so this was not a user-requested Goal pause.

This makes the UI status operationally misleading: a user can reasonably interpret “Pausing” as confirmation that execution is winding down or is safely paused, while the agent is still actively changing files.

What steps can reproduce the bug?

This was observed in a long-running, tool-heavy local chat:

1. Start a normal local Codex turn (no active Goal) that performs many sequential tool calls and spans context compaction.
2. Let the turn run without sending follow-ups or requesting a pause.
3. During execution, observe the activity/progress text change to Pausing after [step].
4. Do not interact with the chat.
5. Observe that the thread remains active / inProgress and continues to execute commands and complete file edits.
6. The turn eventually returns a normal final response and only then transitions to idle.

I cannot yet provide a minimal deterministic prompt, but the state mismatch was verified while it was happening rather than inferred from the final transcript.

What is the expected behavior?

Pause-semantic UI text should be derived from, or reconciled with, the canonical thread/turn/Goal lifecycle.

If the model emits a progress summary containing wording such as “Pausing after …” but the turn is still active and subsequent tool activity occurs, the app should continue to show a neutral working state rather than a pause state. The label should also be cleared or corrected immediately when new tool activity is received.

Additional information

This appears distinct from reports where an explicit Goal pause leaves the backend active. Here there was no active Goal and no pause request; the UI suggested a pause while execution continued normally.

Suggested regression test:

• normal long-running turn, no Goal;
• progress/reasoning text contains Pausing after [step];
• a later tool call or file edit completes;
• the UI must remain working/active and must not expose a pause-semantic status unless the canonical lifecycle actually enters a paused state.

No private project names, paths, prompts, or thread identifiers are included in this report.