[Windows][Desktop] Turn ends by itself after reasoning: task_complete with last_agent_message=null, composer returns to Send

Summary

On Windows Codex Desktop, a turn can stop by itself after a successful tool round and a reasoning item. The composer returns to Send (the user did not press Stop). The rollout records task_complete with last_agent_message: null and no error / stream_error / interrupt event. There is no final assistant reply.

This has happened repeatedly on Word-document tasks in the same day.

Environment

• OS: Windows 11 Pro Insider Preview 10.0.26340
• App: OpenAI.Codex 26.831.2377.0
• Surface: Codex desktop app (not CLI)
• model_provider = "custom"
• model = "grok-4.6"
• wire_api = "responses"
• model_reasoning_effort = "high"
• model_context_window = 1000000 (session token_count also reported model_context_window: 855000)
• model_auto_compact_token_limit = 900000

What the user sees

1. Start a local desktop thread and ask Codex to edit/inspect a Word document.
2. Codex runs several shell/tool calls and shows in-progress commentary.
3. The user does not click Stop.
4. After a thinking/reasoning step, the run ends by itself.
5. The composer button is Send again.
6. There is no final answer for that turn.

The user then has to send another message such as “the task stopped again”.

Local rollout evidence (this thread)

Session: 01a06178-1a71-7d50-8294-92b9e0684189
Rollout: ~/.codex/sessions/2026/09/02/rollout-2026-09-02T17-34-16-01a06178-1a71-7d50-8294-92b9e0684189.jsonl

Turn A

• task_started 01a06179-980b-7240-a775-05648a507f77 at 2026-09-02T09:35:54Z
• Multiple successful CommandExecution items
• Last sequence:
  • two function_call / function_call_output (exit 0)
  • token_count
  • item_completed / reasoning
  • token_count
  • task_complete
• duration_ms: 204779
• time_to_first_token_ms: 8112
• last_agent_message: null
• No EventMsg::Error

Turn B (user follow-up: continue with LibreOffice)

• task_started 01a0617d-fa52-7a10-a544-3ce2a8013a28 at 2026-09-02T09:40:41Z
• Assistant commentary was emitted, then one successful exec_command
• Last sequence:
  • function_call_output
  • token_count
  • item_completed / reasoning
  • token_count
  • task_complete
• duration_ms: 67499
• time_to_first_token_ms: 51905
• last_agent_message: null
• User’s next message (“why did it stop?”) was sent after this task_complete, so it did not interrupt Turn B.

Token / quota (not the cause)

From token_count in this session:

• model_context_window: 855000
• Last-turn total_tokens around 66k–352k, well below the window and below model_auto_compact_token_limit
• rate_limits.primary/secondary/credits/rate_limit_reached_type: all null

This is therefore not the compaction-full early-return described in #25619 (those silent completes were 2–12s, zero last_token_usage, no model sampling). Here the model did sample, tools did run, then the turn ended after reasoning with no assistant message.

Same-day repeat

Thread 01a0603c-6a39-7840-9d3c-0d63042f1f61 (another Word-document task, same machine):

• Turn 01a0604c-7c2e-7680-99ca-28c6bc27cf6b
• duration_ms: 23317
• last_agent_message: null
• Same ending: tool output → reasoning → task_complete with no assistant message
• User report in that thread: looking back at Word in Codex often ends the task this way

Other turns in that thread did finish with an assistant message after reasoning, so it is intermittent, not every turn.

Expected

• If the model/provider stream ends without a final assistant message, the turn should be failed or interrupted with a visible error (or at least an error event), not a clean completed.
• The composer should not return to Send as if the agent finished the job, unless a user-visible final message exists.
• Related: #25619 asked for a wire-visible error instead of silent task_complete(last_agent_message=null).

Actual

Desktop treats the turn as completed. UI idle / Send. Rollout task_complete + last_agent_message: null. No error event.

Related

• #25619 — same silent last_agent_message=null completion, but from compaction early-return (different path)
• #27352 — turn marked complete before the promised next action
• #41989 — custom-model stream closed before response.completed (we did not see that reconnect error in this session)

Happy to attach a sanitized rollout excerpt if useful. The Word files themselves are customer documents and are not attached.

Start by examining the rollout sequences in ~/.codex/sessions/2026/09/02/rollout-2026-09-02T17-34-16-01a06178-1a71-7d50-8294-92b9e0684189.jsonl and compare them with the related cases in #25619, #27352, and #41989. Trace how a reasoning item followed by successful tool output becomes task_complete when last_agent_message is null. Done means the turn is visibly failed or interrupted, rather than cleanly completed, when no final assistant message exists.