Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it

What version of the Codex App are you using?

Codex Desktop 26.513.31313 on macOS arm64.

What platform is your computer?

macOS 26.4.1, Apple Silicon.

What issue are you seeing?

After Codex Desktop had been running for about 3 days and 11 hours, existing threads started failing to submit new messages with "Error submitting message". Restarting Codex Desktop immediately cleared the issue.

This did not look like an upstream model/API error. The affected turns had completed normally, but follow-up turn/start or turn/steer requests from the Desktop app to the local app-server/MCP path timed out after 30 seconds. At the same time, the Desktop logs showed many stale or missing conversation state errors.

I am intentionally omitting full local paths, full logs, thread IDs, and Sentry event IDs from this public issue. I can provide them privately if useful.

Observed behavior

Two existing Codex Desktop threads hit the issue:

• Thread A completed a turn successfully. About 30 seconds later, a queued follow-up turn/start timed out with pendingCount=11.
• Thread B completed a turn successfully, then a steering turn timed out. Later attempts to submit normal follow-ups repeatedly timed out with pendingCount increasing from 15 to 20.

Representative redacted log lines:

2026-05-19T19:09:37.316Z warning [electron-message-handler] mcp_request_timeout conversationId=<thread A> method=turn/start pendingCount=11 requestId=<redacted> timeoutMs=30000
2026-05-19T19:09:37.353Z error [electron-message-handler] [queued-followups] Failed to send queued follow-up for conversationId=<thread A> reason=Timeout

2026-05-19T19:21:30.700Z warning [electron-message-handler] mcp_request_timeout conversationId=<thread B> method=turn/steer pendingCount=14 requestId=<redacted> timeoutMs=30000
2026-05-19T19:21:30.771Z error [electron-message-handler] Error submitting steering turn for conversation conversationId=<thread B> errorMessage=Timeout errorName=Error

2026-05-19T20:54:41.729Z warning [electron-message-handler] mcp_request_timeout conversationId=<thread B> method=turn/start pendingCount=20 requestId=<redacted> timeoutMs=30000
2026-05-19T20:54:41.824Z error [electron-message-handler] [Composer] submit failed cwd=<redacted> errorMessage=Timeout errorName=Error followUp=local mode=local

2026-05-19T21:43:20.549Z warning [electron-message-handler] mcp_request_timeout conversationId=<thread B> method=turn/start pendingCount=20 requestId=<redacted> timeoutMs=30000
2026-05-19T21:43:20.669Z error [electron-message-handler] [Composer] submit failed cwd=<redacted> errorMessage=Timeout errorName=Error followUp=local mode=local

Nearby log lines repeatedly contained errors like:

[electron-message-handler] Conversation state not found conversationId=<redacted>
[electron-message-handler] Received item/started for unknown conversation conversationId=<redacted>
[electron-message-handler] Received item/completed for unknown conversation conversationId=<redacted>
[electron-message-handler] No turns for conversation conversationId=<redacted>
[electron-message-handler] Item not found in turn state itemId=<redacted>

The local Sentry/app-state snapshot around the same period showed:

pending_request_count=20
thread_count_active=15
thread_count_streaming_owner=6
thread_count_streaming_without_active_runtime=13
inflight_turn_count=2
thread_count_total=110
thread_count_loaded_recent=65
item_count_total_loaded=22550
max_items_in_single_turn=2892
delta_events_total≈338k
delta_bytes_total_estimate≈201MB
host_child_app_server_process_count=21

Expected behavior

Submitting a new message should either start a new turn or fail with a specific recoverable error. Stale conversation or streaming state should not permanently block future submits in existing threads.

Actual behavior

Composer submit and steering submit timed out after 30 seconds and continued failing until the Desktop app was restarted.

Workaround

Fully quitting and restarting Codex Desktop fixed the issue immediately.

Suspected area

This looks related to renderer/main-process conversation state, app-server request lifecycle, or stale streaming route cleanup. The repeated unknown conversation, Conversation state not found, and streaming_without_active_runtime signals suggest some conversation/turn routes were left in a stale state and continued to block later turn/start / turn/steer requests.