Codex Desktop marks in-progress commentary as task_complete while plan is incomplete, silently ending long-running turn
What version of the Codex App are you using (From “About Codex” dialog)?
26.623.11225.0
What subscription do you have?
Plus
What platform is your computer?
Windows 11 x64
What issue are you seeing?
Codex Desktop on Windows intermittently and silently ends a long-running local turn even though the assistant is still mid-work and has only emitted an in-progress commentary update.
The local session JSONL records task_complete immediately after a commentary message, using that commentary as last_agent_message. The Desktop log also records turn_completed_with_incomplete_plan.
This does not look like a workflow blocker, command failure, MCP failure, approval wait, or sub-agent failure. It looks like a Desktop/host/model-turn orchestration issue where an in-progress progress update is accepted as a terminal assistant response.
Impact
For long-running governed workflows, Codex can stop at an arbitrary point without any visible terminal state:
- no
COMPLETE - no
BLOCKED - no
CHECKPOINT - no tool error
- no failed command
- no pending approval
- no user-visible crash
The user sees a normal progress message as the last response, but the underlying turn is marked complete. This makes long-running release/finalization workflows unsafe because the agent may stop before branch checks, artifact generation, commits, or final handoff.
What steps can reproduce the bug?
This is intermittent, but appears more likely during:
- long-running local Desktop turns,
- tool/reference-heavy workflows,
- large context,
- repeated progress/commentary updates,
- Windows Desktop app version
26.623.11225.0.
In the concrete case below, the stop happened during a custom skill workflow in a local repository. The assistant had not yet called the remote/MCP tool it was describing; the stop happened before that.
What is the expected behavior?
Codex Desktop should not mark a turn complete when the last assistant message is only an in-progress commentary/progress update.
If the model or host cannot continue, the turn should end with a real terminal state:
- final assistant response,
- explicit interruption/error,
- resumable checkpoint,
- or host-visible failure reason.
If a plan exists and completedPlanStepCount < planStepCount, Desktop should not silently present the last commentary as a completed result unless the model explicitly produced a final response.
Additional information
Evidence 1: Release workflow stopped after commentary
Session file:
C:\Users\...\.codex\sessions\2026\07\02\rollout-2026-07-02T20-21-23-019f23d9-5a0f-77c2-b0fe-13950da798a9.jsonl
Relevant session records:
84: event_msg agent_message phase=commentary:
"There’s no local deferred-followups ledger, so this release will lean on the git range plus any release-impact fragments. The remote points at internal GitLab; because release/tag history is history-sensitive, I’m checking whether the configured Custom MCP read-only source is available before I decide whether local evidence is sufficient."
85: response_item message phase=commentary:
same text as line 84
86: event_msg token_count
87: event_msg task_complete:
turn_id="019f23d9-7ead-74d3-80c4-35a82140b2fd"
last_agent_message=same in-progress commentary text
duration_ms=124142
There is no intervening MCP call, no failed shell command, no approval request, and no explicit final answer.
Desktop log file:
C:\Users\...\AppData\Local\Codex\Logs\2026\07\02\codex-desktop-ffe1b6d3-e2a4-4279-ad6f-1ecd131c80ba-17652-t0-i1-172040-0.log
Relevant desktop log record:
188: 2026-07-02T17:23:28.389Z info [electron-message-handler]
turn_completed_with_incomplete_plan
completedPlanStepCount=0
conversationId=019f23d9-5a0f-77c2-b0fe-13950da798a9
planStepCount=6
turnId=019f23d9-7ead-74d3-80c4-35a82140b2fd
Evidence 2: Same signature in another local thread
Session file:
C:\Users\...\.codex\sessions\2026\06\09\rollout-2026-06-09T09-33-13-019eab15-ad89-7c22-bbb7-eb56b5940dc0.jsonl
Relevant session records:
40372: event_msg agent_message phase=commentary:
"I found the specific smoking gun in the local Codex session record. The failed Custom skill turn has no Custom MCP call after the last progress line; the host recorded task_complete almost immediately after that line, using the progress line itself as the last agent message."
40373: response_item message phase=commentary:
same text as line 40372
40375: event_msg token_count
40376: event_msg task_complete:
turn_id="019f23e3-dd35-76c3-8fd9-2f376038bde0"
last_agent_message=same in-progress commentary text
duration_ms=235133
Again, no final answer was emitted.
Related issues
I found related issues, but not an exact duplicate of this task_complete after commentary plus turn_completed_with_incomplete_plan signature:
#24287: Desktop UI/session state desynchronization.#22655: Windows end-of-turn hangs/exits withturn_completed_with_incomplete_planin logs.#23673: Windows crash involvingturn_completed_with_incomplete_plan, but different trigger.#30013: Silent hangs during long-running Desktop work, but macOS/tool-action oriented.
Suggested diagnosis
This appears to be a Codex Desktop / local host / model stream orchestration bug. An in-progress commentary response is being persisted and surfaced as the terminal last_agent_message, while the turn is marked task_complete even though the plan is incomplete.
The host should either continue the turn, expose an interruption/error, or synthesize a safe resumable checkpoint rather than marking the commentary as a completed response.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗