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

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.