Primary agent prematurely emits final during explicit persistent long-running tasks

What issue are you seeing?

In a long-running Codex Desktop task with an explicit instruction to continue until completion, the primary agent repeatedly emitted a terminal final response while the task's completion criteria were still unmet.

This happened even after the user explicitly corrected the behavior multiple times (“continue until fully implemented”, then “it stopped again”). The final messages were not real completion reports; they were partial status such as “still fixing”, “waiting for a long test”, or “will continue”.

A terminal final ends the active turn and requires the user to send another message to resume supervision. In this case it repeatedly interrupted a multi-step implementation/acceptance workflow.

Reproduction pattern

1. Start a long coding task that needs multiple tool calls, subagents, tests, commits, and integration.
2. State a hard persistence requirement, e.g. “continue until fully implemented; do not stop at an intermediate status”.
3. Have the primary agent make partial progress but leave a known blocking test, validation gate, or merge step unfinished.
4. Observe the primary agent emit a final response containing an intermediate status instead of continuing through the remaining authorized work.
5. Send “continue” or point out that it stopped.
6. The same behavior can repeat after the next partial checkpoint.

Expected behavior

When the user has explicitly requested persistent completion and the task still has authorized, executable work:

• The primary agent should continue working and use commentary updates for intermediate status.
• It should not emit a terminal final merely because a single command timed out, a subagent is still running, or only one acceptance gate remains.
• A final should be reserved for actual completion, a real authorization boundary, or a genuine blocker that requires user input.
• If a background/subagent task is running, the primary agent should keep supervising it rather than terminating the main turn.

Impact

This makes long autonomous workflows unreliable. The user has to repeatedly notice that the task was prematurely ended and manually send another prompt, even though the unfinished work and next safe action are already known. It is especially disruptive for root-agent acceptance workflows where the agent has to wait for long tests and then commit/merge only after they pass.

Environment

• Codex Desktop on Windows
• Long local-repository task with tool calls and subagents
• The issue appears to concern primary-agent turn/persistence behavior, not a repository-specific failure.

Additional context

The premature finals occurred around:

• a full test command exceeding a per-command timeout;
• waiting for a long-running production corpus test;
• waiting for a delegated regression repair;
• a merge/rebase acceptance sequence.

In each case there was still a clear, authorized next action and no need for user input.