›_ Codex Issues
Codex Issues / #14251

Thread stays stuck in generating state after interrupted turn; composer remains disabled until local session log is manually completed

Open 💬 2 comments Opened Mar 10, 2026 by sri299792458
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.306.996.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On March 10, 2026, a Codex desktop thread became stuck in a permanent generating state after what appears to have been an interrupted or disconnected turn. The thread could still be opened, but it continued to look active and the composer stayed disabled, so I could not send any new messages.

Restarting or reopening did not clear it.

The thread only became usable again after manually appending a terminal assistant message and a missing task_complete event to the local session log.

Affected thread id: 019cd391-57b8-70b3-9b43-6011980b9540.

What steps can reproduce the bug?

  1. Use the Codex desktop app on Windows in a normal workspace-backed thread.
  2. Let a turn run long enough that a backend disconnect or interruption can occur mid-turn.
  3. Reopen the thread after the interruption.
  4. The thread may remain in a generating state indefinitely, and the message composer remains disabled.

In my occurrence:

  • Thread id: 019cd391-57b8-70b3-9b43-6011980b9540
  • Interrupted turn id: 019cd8a4-cab0-7773-a3b1-1766efcd0c1e
  • Model seen in local session context: gpt-5.4
  • Local thread state recorded cli_version: 0.112.0-alpha.3

I do not yet have a minimal deterministic repro; this report is based on a real occurrence.

What is the expected behavior?

If a turn is interrupted or the stream disconnects, the thread should transition to a terminal interrupted or failed state, show that status in the UI, and re-enable the composer so the conversation can continue without manual local-state repair.

Additional information

  • The local backend log showed a stream disconnect and shutdown around March 10, 2026 at about 3:10 PM America/Chicago.
  • The local session log for this thread did not end with a terminal task_complete event for the interrupted turn.
  • Manual workaround that restored the thread: append a terminal assistant message plus task_complete to the local session file under C:\Users\<redacted>\.codex\sessions\..., then reopen the thread.
  • The SQLite state DB appeared locked while the app was running, so I could not update the thread row live; however, the session-log repair alone was enough to unblock the thread.
  • I can provide a redacted tail of the session log if that would help, but I do not want to post the full session log publicly because it may contain prompts and local paths.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14220
  • #12382
  • #12843
  • #12515

Powered by Codex Action

fibo-blip · 1 month ago

I hit the same class of issue on a current Windows Codex Desktop build, and the local-session-log workaround still fixes it.

Environment:

  • Windows Codex Desktop
  • App build observed in logs: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0, release field 26.623.81905
  • WSL mode enabled; agent runtime itself was WSL/Linux and otherwise healthy
  • codex doctor for the Desktop WSL profile reported auth/network/websocket OK (16 ok, 0 fail)

User-visible symptom:

  • Desktop showed Unable to send message / Loading...
  • Composer stayed blocked after app restart
  • Disabling recently added plugins did not fix it

Relevant Desktop log pattern on reopening the affected thread:

maybe_resume_success
latestTurnStatus=interrupted
markedStreaming=true

A fresh log also showed the app was no longer selecting a stale remote host in this run:

hostId=local
refresh_remote_control_completed ... nextConnectionCount=0
codex-home request hostId=local

The affected session JSONL tail had this shape:

task_complete              # previous successful turn
task_started               # new turn
turn_context
user message
user_message
session_meta
user interrupt marker
turn_aborted               # interrupted turn terminal marker

But there was no terminal assistant message and no task_complete for that interrupted turn.

Workaround that fixed it:

  1. Closed Codex Desktop.
  2. Backed up the affected session JSONL.
  3. Appended a small terminal assistant message and a task_complete event for the interrupted turn_id.
  4. Reopened Codex Desktop.
  5. The composer became usable again and messages sent normally.

So this still appears to be a stale Desktop streaming/composer state problem after an interrupted turn, not a WSL runtime, auth, network, or plugin problem. The key bad state is latestTurnStatus=interrupted being resumed as markedStreaming=true.

I am intentionally not posting full local logs, session ids, paths, or prompts because they contain private workspace details.