[Windows App 26.820.7780.0] Composer stays disabled after the first completed turn in a new task

Environment

• Codex Desktop package: OpenAI.Codex 26.820.7780.0
• Bundled app server: codex-cli 0.150.0-alpha.8
• Platform: Windows x64, OS version 10.0.26200 (build 26200.9168, 25H2)
• Task target: Local, projectless workspace
• Shell: PowerShell
• Model in the captured occurrence: gpt-5.6-sol, reasoning effort xhigh
• Approximate occurrence time: 2026-08-26 19:29, UTC+08:00

Task IDs, local paths, account details, and prompt contents are omitted for privacy.

Preconditions

1. The user had deleted all conversations visible in the UI before testing.
2. Codex Desktop was running normally and could create a new local task.
3. No approval dialog was open or pending.
4. The first prompt was short plaintext with no attachment.

Deleting the visible conversations did not make the local Codex state empty. A later read-only inspection still found a substantial local thread index. That is an observation and a possible amplifier, not a confirmed cause.

Minimal reproduction

1. Open Codex Desktop on Windows.
2. Create a new local task.
3. Send a short plaintext first message.
4. Wait for the assistant response to finish rendering.
5. Type a short second plaintext message in the composer.
6. Attempt to send it.

Actual result

The second message remains in the composer and cannot be submitted. The Send button stays disabled/grey even though the first turn has already completed.

For the captured occurrence:

• the assistant response was fully generated;
• the rollout transcript ended with an authoritative task_complete event;
• the task index later reported the task as idle;
• nevertheless, the visible composer remained locked.

This appears to be a Desktop UI / local state synchronization failure. The available evidence does not establish the underlying root cause.

Expected result

After the first turn reaches its terminal completed/idle state:

• the composer should become enabled;
• the second message should produce a new turn/start;
• if state reconciliation fails, the app should show an actionable error and provide a recovery action instead of leaving the composer disabled indefinitely.

Frequency

The user reports that this occurs on the second message in every new task attempted after deleting all visible conversations.

One occurrence was correlated precisely with local logs and the rollout transcript. The report does not claim a fully automated deterministic reproduction.

Captured timeline and logs

The affected task was created at approximately 19:28:54.

19:29:02  first turn_input submitted
19:29:09  assistant message output completed
19:29:10  post-sampling state:
          full_context_window_limit_reached=false
          token_limit_reached=false
          model_needs_follow_up=false
          has_pending_input=false
          needs_follow_up=false

The rollout was small (16 records, approximately 136 KB) and ended with:

event_msg task_complete

The task index subsequently reported the affected task as idle.

Two transport warnings occurred during startup/turn preparation:

startup websocket prewarm setup failed:
stream disconnected before completion: tls handshake eof

incremental request failed:
websocket reuse properties didn't match

The response still completed after these warnings, so they are included as correlation only and are not claimed as the cause.

At app startup, the local app-server also emitted repeated thread-index reconciliation warnings:

state db list_threads returned stale rollout path
state db discrepancy during list_threads_db: stale_db_path_retained

A read-only local maintenance report found:

active thread rows: 136
active title characters: 3,791,975
active first_user_message characters: 3,792,320
maximum title / first_user_message length: 77,059
titles over configured limit: 114
first_user_message values over configured limit: 113
first_user_message values over 10k characters: 109
metadata repair candidates: 115
active rollout size: 1.781 GB
archived rollout size: 68.178 GB
current log size: 10.6 MB

This metadata/index bloat may increase the likelihood of a renderer or reconciliation failure, but it has not yet been repaired and A/B tested, so it is not a confirmed root cause.

Items already ruled out or localized

• First-turn model/backend failure: ruled out for the captured occurrence; the assistant reply and task_complete were persisted.
• Turn still legitimately active: ruled out by task_complete, no pending input/follow-up flags, and the later idle task status.
• Context/token exhaustion: the captured log explicitly reports both context and token limits as not reached.
• Approval wait: no approval request was present; the task used a no-approval/full-access profile.
• Oversized current conversation: the affected new task contained only 16 rollout records and was approximately 136 KB.
• Large current log database: the active log database was only approximately 10.6 MB.
• Optional MCP startup failures: unavailable optional MCP servers were omitted for the affected turn and the thread was created with zero dynamic tools. Earlier MCP connection errors therefore do not establish the cause of this composer lock.

Temporary recovery / workarounds

• Fully quitting and relaunching Codex causes the persisted task to be recognized as idle again.
• This is only a partial workaround: the user reports that the same second-message failure returns in new tasks.
• Starting another new task and deleting visible chat history did not resolve the problem.
• A local thread-metadata repair has been proposed but not yet executed, so it should not be treated as a verified workaround.

Possibly related issues

• #40794 — same app version and a second manual-message freeze, but that report requires cross-task message injection and localizes the failed click before turn/start.
• #14251 — composer remains disabled after an interrupted turn, but that case is missing task_complete; this occurrence has a valid terminal event.
• #32982 — the inverse timing race, where the composer enables before authoritative turn completion.
• #21211 — unbounded thread metadata and eager history hydration.
• #24263 — Desktop renderer/turn-state reconciliation failures.

Sanitized structural logs can be provided if maintainers need additional detail.

Start by tracing the Desktop composer’s enabled state from the first turn’s task_complete event through the task index’s idle state, using the captured timeline and logs as the reproduction oracle. Compare the related cases in #40794, #14251, #32982, and #24263, then verify that a second message reaches turn/start or produces a recovery error instead of remaining disabled.