›_ Codex Issues
Codex Issues / #23644

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

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

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #23035
  • #22969

Powered by Codex Action

JoeyTeng · 3 months ago

By the way GPT-5.5 automatically raised this issue for me while I only say "I don't know where to report; this is the official Codex Desktop app" without explicitly expressing my intention to create this issue... I'm using "Auto-review" mode. Can't really submit a feedback via the desktop app, maybe because of the enterprise policy.

<img width="463" height="43" alt="Image" src="https://github.com/user-attachments/assets/a92b26ff-1679-4be2-9538-53369e0fcc2a" />

Maple1222 · 3 months ago

I am seeing a very similar failure mode in Codex Desktop, including composer submit timeouts and stale conversation/UI state.

Environment:

  • Codex Desktop: 26.519.81530, app build 3178
  • macOS: 26.4, build 25E246
  • Hardware: Apple M5 Max, 128 GB RAM

This does not appear to be normal machine resource pressure:

  • swapins/swapouts: 0
  • Codex-related RSS total was high during the session, around 46 GB
  • CodexBar was around 11.5 GB RSS
  • app-server had around 49-51 child processes
  • ~/.codex/logs_2.sqlite was around 2.2 GB, with about 1,012,943 rows
  • ~/.codex/state_5.sqlite was around 12 MB, with about 2,210 threads

User-visible symptoms:

  • Toast: タスクの作成中にエラーが発生しました timeout / An error occurred while creating the task: timeout
  • UI sometimes jumps back to a previous question/thread while the underlying process continues
  • Opening a new window can show the stale/previous view again
  • In some cases, submitting a prompt becomes impossible until forking the thread

Sanitized local log evidence from 2026-05-29:

[Composer] submit failed ... errorMessage=timeout

In one project, the same local log showed multiple composer submit timeouts around:

2026-05-29 07:09:01Z
2026-05-29 07:18:29Z
2026-05-29 07:21:13Z
2026-05-29 08:03:28Z

After method=thread/fork, the newly forked thread immediately hit:

Conversation state not found
No cwd found for local task

The same log also contained a large number of state mismatch messages:

Received item/started for unknown conversation
Received item/completed for unknown conversation
Item not found in turn state
browser-session-registry IAB_LIFECYCLE ignored duplicate turn route capture

This looks close to the stale renderer/app-server state described here and also close to #24263, where the backend continues while the renderer/thread state is out of sync.

I can provide more sanitized excerpts if useful, but the raw log contains private local paths and workspace names.

phillbee · 15 days ago

I hit the same user-visible failure on a current Codex Desktop build, with a little more evidence about where the submit stopped.

Environment:

  • Codex Desktop 26.803.61601 (build 6396)
  • bundled CLI 0.147.0-alpha.6.5
  • macOS 26.5.2, arm64

An existing thread completed its previous turn normally at 07:33:57 local time. Two later attempts to send a follow-up behaved as follows:

  • the Send button spun for about 30 seconds, then returned without sending;
  • at 07:39:19 the composer failed with errorMessage=Timeout;
  • at 07:40:28 it failed with App server request expired while queued;
  • neither attempt reached turn/start, and neither message was persisted in the rollout.

The prerequisite that timed out was a critical config/read request:

app_server_client_request_queue_rejected
method=config/read priority=critical
inFlightRequestCount=6
queuedInteractiveRequestCount=8
queueWaitMs=30001
reason=queue-expired

[Composer] submit failed
errorMessage="App server request expired while queued"

Nearby background config/read, permissionProfile/list, thread/list and thread/turns/list requests were also expiring after 30–60 seconds.

The affected thread is unusually large: its rollout is about 154 MB with 55,815 JSONL records. It had also produced a Timed out waiting for MCP response to thread/read error shortly before the failed sends. This may overlap the large-history loading problem in #21211.

One other potentially relevant observation: an orphaned codex_chronicle process from the previous app session remained parented to launchd. The current Desktop process logged Waiting to acquire lock (owned by pid=...) every ten seconds, matching the lifecycle problem described in #19516. I cannot establish that this caused the request queue stall, since normal app-server requests initially continued despite the Chronicle lock wait.

This does not appear to be a model-capacity failure. The message submission stopped in the Desktop/app-server request path before a model turn was started.

twentyOne2x · 14 hours ago

Current macOS startup variant

Adding a current macOS 26.820.60940 (build 7119) reproduction of the same Composer/app-server failure family. During three failed relaunches, startup hydration repeatedly filled all six request slots; queuedInteractiveRequestCount reached 64, and config/model/thread/Composer operations expired. User-observed recovery followed a full reboot, although a just-completed primary-runtime installation is a recovery confounder.

The full sanitized queue timeline, hang evidence, resource negative controls, and proof limits are documented here: https://github.com/openai/codex/issues/36914#issuecomment-5445515814

This differs from the original multi-day-uptime report because the unusable state was reconstructed during startup restoration. It supports strict priority for turn/start, Composer, selected-task reads, config, and model metadata over background hydration, plus a recovery path for dispatched requests that stop completing.