[Windows Desktop] Goal-mode task becomes idle mid-work while command and goal remain active

Component and environment

• Codex Desktop for Windows
• MSIX package: 26.727.6591.0
• Product/file version: 150.0.7871.182
• Windows: Microsoft Windows NT 10.0.26200.0
• Local project task
• Persistent Goal mode active
• Cross-thread follow-up/resume through the Desktop app

Summary

A persistent local Goal repeatedly transitions from active/inProgress to idle/completed while it is explicitly still working. The turn ends without a final answer, error, approval request, blocked-state transition, or completed Goal.

The last assistant item is often nonterminal commentary saying that a long build is still running or that it is proceeding to the next required phase. The owned build process can remain alive after the Codex turn is marked completed.

This requires another thread, a scheduled heartbeat, or the user to send a new follow-up every few minutes. Prompt instructions such as “continue until completion,” an active Goal, and explicit non-blocking gate rules do not prevent the stop.

Sanitized observed sequence

This reproduced repeatedly in one session:

| Turn duration | Last visible assistant state | Desktop thread state immediately afterward |
| ---: | --- | --- |
| 250,965 ms | Config work committed; clean package rebuild still running | idle / turn completed |
| 262,043 ms | Owned package build still active; agent says it will collect completion | idle / turn completed |
| 159,666 ms | Rebuilt package passed startup smoke; agent says it is proceeding to extracted behavior acceptance | idle / turn completed |

In each case:

• no final answer was emitted;
• no tool error or approval was pending;
• the Goal was not marked complete or blocked;
• eligible work remained;
• a follow-up message immediately resumed the same objective;
• the same premature transition occurred again.

In one case, the exact owned PowerShell build process was still alive after the turn became idle. A later follow-up found the process, waited for it, and successfully collected the artifact.

Reproduction outline

1. Open a local project in Codex Desktop on Windows.
2. Start a persistent Goal with multiple implementation and verification phases.
3. Include a repository build or test lasting longer than a few minutes.
4. Let Codex begin the build and state that it will wait for completion and continue.
5. Observe the task status.
6. The turn may become completed and the thread idle while the command or objective remains active.
7. Send a follow-up telling it to resume.
8. Observe that work continues normally, then may silently stop again at another intermediate boundary.

This also reproduces when another Desktop thread sends the follow-up through cross-thread orchestration.

Expected behavior

Goal mode is documented as persistent long-running work. While the Goal remains active:

1. A per-turn wall-clock or tool-call boundary should schedule an automatic continuation rather than silently idling the thread.
2. A live owned command session should keep the turn active, or its continuation should be durably attached to the next automatic turn.
3. If the runtime must pause, the task should expose an explicit pause reason and state rather than completed.
4. The task should only become idle after:

• the Goal is complete;
• the Goal is blocked and records the required user input;
• the user pauses/stops it; or
• a visible runtime error explains the interruption.

Actual behavior

The Goal remains unfinished and apparently active in Goal state, but the thread silently becomes idle. The only workaround is repeated user/external continuation messages.

This makes unattended paid local-agent work unreliable and can leave child processes running without an active agent turn supervising cleanup.

Current workaround

• A scheduled in-chat heartbeat checks the task every minute and sends another follow-up whenever it becomes idle prematurely.
• Long commands are being kept attached to an exec session and polled rather than launched in the background.

This reduces the interruption window but does not make Goal mode continuous.

Suggested regression coverage

• Run a Goal-mode local task with a deterministic command that exceeds the normal turn duration.
• Assert that the thread never becomes idle while the Goal is active and the command or eligible phase remains.
• Assert that a turn boundary automatically starts a continuation with the same Goal.
• Assert that an attached command result is delivered to that continuation.
• Assert that any forced pause records a visible reason and does not masquerade as completed.

Related issues

• #25779 — Desktop session/turn state and active-turn ownership meta-bug
• #14923 — cross-thread orchestration
• #24434 — post-tool continuation stall

Privacy

This report omits repository names, local paths, credentials, database information, conversation IDs, and task prompts. In-product diagnostics can be supplied privately if requested.