Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Codex Desktop: hard-coded 30s timeout for commit_message generation fails on large diffs [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#19527•Fetched 2026-04-26 05:15:52
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
mushan0x0mushan0x0
Participants
mushan0x0mushan0x0
Timeline (top)
labeled ×3

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.

Error Message

inputTokens=93340 outputTokens=87 ... status=error

Root Cause

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.

Code Example

[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
RAW_BUFFERClick to expand / collapse

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)

extent analysis

TL;DR

Increase the timeout value or make it configurable to accommodate larger input sizes.

Guidance

  • Identify the line of code where the timeout is set (var Ht=3e4 in workspace-root-drop-handler-*.js) and consider increasing this value for larger input sizes.
  • Explore making the timeout value configurable, allowing users to adjust it based on their specific needs.
  • Investigate trimming or capping the context fed to the commit-message generator to reduce the input size and prevent timeouts.
  • Verify the relationship between input size and timeout by testing with different input sizes and measuring the time it takes for the model to finish.

Example

No code snippet is provided as the issue does not contain enough information to create a specific example.

Notes

The current implementation has a deterministic pattern, where inputs larger than 66k tokens always time out, indicating a clear correlation between input size and timeout.

Recommendation

Apply a workaround by increasing the timeout value or making it configurable, as upgrading to a fixed version is not mentioned in the issue. This will allow for larger input sizes to be processed without timing out.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#docker error#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING