Desktop: "Error submitting message" — turn/start times out (30s) while app-server sidecar stalls silently for minutes #27395

What version of the Codex App are you using?

26.608.12217 (codex core 0.138.0-alpha.7, originator Codex_Desktop, auth mode ChatGPT)

What subscription do you have?

What platform is your computer?

macOS 26.5.1, Apple Silicon (arm64)

What issue are you seeing?

Submitting a message in a Desktop thread intermittently fails with the inline banner "Error submitting message". Re-sending the exact same message a minute or two later succeeds.

Desktop renderer log shows the composer giving up after a 30-second RPC timeout on turn/start:

2026-06-10T13:05:09.164Z warning [electron-message-handler] mcp_request_timeout
    conversationId=019eb19c-84da-7933-a03c-cbfbb4e11d57 method=turn/start
    pendingCount=13 requestId=654d3396-... timeoutMs=30000
2026-06-10T13:05:09.173Z error [electron-message-handler] [Composer] submit failed
    cwd=~/Documents/Codex/2026-06-10/... errorMessage=Timeout errorName=Error
    errorStack="Error: Timeout\n at Object.error (app://-/assets/vscode-api-....js:...)\n at ks (app://-/assets/composer-....js:...)" followUp=local mode=local

7 occurrences on 2026-06-10 (first at 10:48:42Z), zero occurrences in the preceding 13 days of desktop logs. All 7 timeouts are method=turn/start; pendingCount grows across the day (2 → 5 → 6 → 13), so requests pile up against the same app-server sidecar.

Root-cause evidence from the app-server side (~/.codex/logs_2.sqlite, logs table): the main app-server sidecar process stops emitting any log rows at all for multiple minutes, and every submit failure falls inside one of those silent windows. Example: the sidecar wrote ~1000 rows during 23:04 local while a turn was streaming, then wrote nothing from 23:05 through 23:11 — exactly bracketing three consecutive submit timeouts at 23:05:09, 23:06:50 and 23:10:33 (UTC+10 local; 13:05/13:06/13:10Z in the desktop log above).

The stalled thread's previous turn never finalizes: e.g. thread 019eb19b-dae6-7192-be60-8d0432f9587c logged its final answer and token usage at 12:57:27Z (needs_follow_up=false has_pending_input=false), then the thread never logged another line and never emitted turn/completed; the next turn/start for that thread (12:57:44Z) timed out at 12:58:14Z. The desktop also logs Received turn/started for unknown conversation for the ephemeral title-generation thread during the same window.

Possibly relevant: the stall windows coincided with elevated concurrency on the shared ~/.codex SQLite databases — 3–4 distinct codex processes (per process_uuid in the logs table) writing to logs_2.sqlite at the failure minutes vs. 1 normally (nested codex exec runs spawned by an agent, plus agent turns querying ~/.codex/state_5.sqlite / logs_2.sqlite directly). logs_2.sqlite had grown to 1.4 GB with a multi-MB WAL.

Ruled out locally: plugin hooks (UserPromptSubmit/Stop hook binaries exit in <1 s when run by hand), the notify turn-ended client (unchanged binary), network-proxy feature (same log lines appear on prior, healthy days), leftover nested codex processes (none running; only the sidecar holds the DBs), and a newly added <name>.config.toml profile-v2 file (never loaded without --profile).

What steps can reproduce the bug?

Not deterministic, but reliably reproduced today with this pattern:

1. Run an agent thread in the Desktop app that heavily reads ~/.codex itself (e.g. SQLite queries against a large logs_2.sqlite, rg over ~/.codex) and/or spawns nested codex exec / codex --profile <name> exec subprocesses, so several codex processes share the ~/.codex SQLite databases concurrently.
2. While that turn is running (or just after its final answer), submit another message — either a follow-up in the same thread or a message in another thread owned by the same sidecar.
3. If the sidecar is in one of its silent stall windows, the submit shows "Error submitting message" after ~30 s.
4. Wait 1–5 minutes; resubmitting the identical message succeeds.

Affected thread/session ids from 2026-06-10 (in case server-side lookup helps):
019eb122-5dbf-7462-ac2d-a0ea9ac9a39f, 019eb12c-1a8d-7551-990f-768161dd4a28, 019eb12d-befb-71e0-88c2-e77aaeefc885, 019eb19b-dae6-7192-be60-8d0432f9587c, 019eb19c-84da-7933-a03c-cbfbb4e11d57

What is the expected behavior?

• turn/start should be acknowledged promptly (or fail fast with a real error) even when the thread's previous turn is still finalizing or the sidecar is under I/O pressure; a queued/steered message should not surface a generic "Error submitting message".
• A turn that has produced its final answer should always reach turn/completed; the per-thread session loop should not wedge silently with no log output.
• Consider rotating/pruning logs_2.sqlite — unbounded growth (1.4 GB here) amplifies any DB-contention stall.

Additional information

• Timezone note: desktop log timestamps are UTC; app-server sqlite analysis above is local (UTC+10).
• Happy to provide redacted log excerpts or run diagnostics on request.