Codex Desktop marks in-progress commentary as task_complete while plan is incomplete, silently ending long-running turn

Open 💬 1 comment Opened Jul 2, 2026 by bingo-soft

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 with turn_completed_with_incomplete_plan in logs.
  • #23673: Windows crash involving turn_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.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗