Codex Desktop: hard-coded 30s timeout for commit_message generation fails on large diffs
Open 💬 2 comments Opened Apr 25, 2026 by mushan0x0
Summary
Codex Desktop's commit-message generation has a hard-coded 30s timeout (var Ht=3e4 in workspace-root-drop-handler-*.js). For large diffs / long thread context where the model needs >30s to finish, the call always fails with Timed out waiting for structured result., even though the model is still streaming output successfully.
Reproduction
- Open a workspace with a sizable thread / accumulated context (~90k+ input tokens).
- Stage a non-trivial diff and click Generate commit message.
- Watch
~/Library/Logs/com.openai.codex/<date>/codex-desktop-*-t0-*.log.
Observed
[ephemeral-generation] ephemeral_generation_token_usage feature=commit_message
inputTokens=93340 outputTokens=87 ... status=error
[electron-fetch-handler] Failed to generate commit message
errorMessage="Timed out waiting for structured result."
stack: workspace-root-drop-handler-*.js:196
In our case inputTokens<=66k always succeeds; inputTokens~=93k always times out. Pattern is deterministic — the model is producing output (outputTokens>0), it just doesn't finish within 30s.
Expected
Either:
- Make the timeout configurable / scale with input size, or
- Trim/cap the context that's fed to the commit-message generator (it shouldn't need the full thread history just to summarize a staged diff).
Environment
- Codex Desktop 0.125.0-alpha.3
- macOS 26.4.1 (arm64)
2 Comments
I can reproduce a related failure on Windows in Codex App.
Environment:
git push --dry-runsucceeds for affected local repositories.Observed:
generate-commit-messagetimes out withTimed out waiting for structured result.turn/startedevent that the desktop app logs as an unknown conversation.generate-thread-title, so this appears broader than commit message generation alone.Redacted log pattern:
Across local logs I found 8
Failed to generate commit messageevents:For each of the 8 failures, there is a preceding
Received turn/started for unknown conversationentry exactly 30 seconds before the timeout.Two older failures also include token usage, showing the generation task started but ended with status
error:Expected:
Adding a current Windows reproduction that is not explained by a large diff or the 30-second timeout.
Environment:
User-visible behavior:
A representative pre-reset failure completed generation in about four seconds, well below the timeout:
Received turn/started for unknown conversation conversationId=<redacted>
ephemeral_generation_token_usage feature=commit_message inputTokens=20936 outputTokens=23 status=success totalTokens=20959
Received turn/completed for unknown conversation conversationId=<redacted>
Despite status=success, the desktop UI discarded the result and showed the generic failure toast. Fresh post-reset logs immediately reproduce the same unknown-conversation routing pattern for another successful structured generation (thread_summary), and the user confirms the Commit or push failure persists after reset.
This appears to overlap the renderer/app-server event-correlation defect tracked in #21167: the structured generation completes, but its lifecycle/result is associated with a conversation the renderer does not know. Unlike the original large-context report here, this reproduction uses about 21k input tokens and completes quickly, suggesting there is also a result-routing failure independent of the hard-coded timeout.
Expected:
No prompts, repository contents, account identifiers, conversation IDs, or full local paths are included.