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

  1. Open a workspace with a sizable thread / accumulated context (~90k+ input tokens).
  2. Stage a non-trivial diff and click Generate commit message.
  3. 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)

View original on GitHub ↗

2 Comments

AndyLonly · 3 months ago

I can reproduce a related failure on Windows in Codex App.

Environment:

  • Codex App: 26.429.2026.0
  • OS: Windows 10 Pro, build 26200, 64-bit
  • Git remotes/auth are not the immediate failure point; git push --dry-run succeeds for affected local repositories.

Observed:

  • generate-commit-message times out with Timed out waiting for structured result.
  • The timeout is consistently 30 seconds after an internal turn/started event that the desktop app logs as an unknown conversation.
  • The same structured-generation path also times out for generate-thread-title, so this appears broader than commit message generation alone.

Redacted log pattern:

2026-05-01T15:08:52.430Z error [electron-message-handler]
Received turn/started for unknown conversation conversationId=<redacted>

2026-05-01T15:09:22.435Z warning [electron-fetch-handler]
Failed to generate commit message
errorMessage="Timed out waiting for structured result."
errorStack="Error: Timed out waiting for structured result.
    at Timeout.<anonymous> (.../workspace-root-drop-handler-D_UHIXp9.js:200:834)"

Across local logs I found 8 Failed to generate commit message events:

  • 2 on Codex App 26.417.5275.0
  • 1 on Codex App 26.422.3464.0
  • 5 on Codex App 26.429.2026.0

For each of the 8 failures, there is a preceding Received turn/started for unknown conversation entry exactly 30 seconds before the timeout.

Two older failures also include token usage, showing the generation task started but ended with status error:

feature=commit_message
model=gpt-5.4-mini
inputTokens=117733
cachedInputTokens=117632
outputTokens=1671
reasoningOutputTokens=1034
status=error
totalTokens=119404

Expected:

  • The commit-message generator should either complete reliably, or degrade gracefully by using less context / staged diff only.
  • If the internal structured-generation turn is started, the desktop app should route its completion/error back to the requester instead of logging it as an unknown conversation and timing out.
Mharbulous · 13 days ago

Adding a current Windows reproduction that is not explained by a large diff or the 30-second timeout.

Environment:

  • Windows 11, build 26200, x64
  • Desktop MSIX package: 26.810.4967.0
  • Desktop renderer release: 26.810.41047
  • Bundled app-server: codex-cli 0.148.0-alpha.9
  • Local native-Windows Git repository, not WSL/SSH
  • Ordinary git status works
  • Review state was approximately 218 changed lines

User-visible behavior:

  • Clicking Commit or push shows Couldn't generate a commit message.
  • Windows App Repair did not fix it.
  • Windows App Reset did not fix it.
  • The reset also moved the installation from package 26.803.10989.0 to 26.810.4967.0, and the failure remained.

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:

  • A successful commit_message structured generation should populate the Commit or push interface.
  • Ephemeral structured-generation events should be correlated with their requester rather than discarded as an unknown conversation.

No prompts, repository contents, account identifiers, conversation IDs, or full local paths are included.