Built-in image_gen repeatedly fails with TooManyRequests before generating any image in Codex Desktop

Summary

The built-in image_gen tool in Codex Desktop repeatedly failed with TooManyRequests before producing any image output. This happened while using the bundled imagegen skill in its default built-in mode, where no OPENAI_API_KEY should be required. The task was blocked completely because the user explicitly required every product-image edit to use imagegen.

This did not look like the usual behavior: the failure occurred three times in a row, including after waiting between attempts, and no new files were written under $CODEX_HOME/generated_images.

Environment

• Product surface: Codex Desktop app
• Codex CLI available locally: codex-cli 0.135.0
• OS: Windows 10 Home Single Language, 64-bit
• OS build: 26200
• Shell: PowerShell Desktop 5.1.26100.8521
• Node.js available locally: v24.16.0
• Local timezone: Asia/Jakarta
• Incident date: 2026-06-06
• Workspace mode: projectless Codex workspace under the user's Documents/Codex folder
• Built-in image workflow: imagegen skill default built-in image_gen tool mode
• Fallback CLI status: OPENAI_API_KEY was not set locally, so the API/CLI fallback was not available without additional user setup

User Request Context

The user provided a ZIP file containing 13 JPG marketplace/product images for a bicycle pedal product and asked Codex to edit the bitmap visuals into Shopee Indonesia-ready commercial product-listing images.

Important constraints from the user:

• Must use imagegen; the process must not skip imagegen.
• Edit images one by one, not as a single combined collage.
• Preserve prior product specifications/information.
• Remove unrelated elements such as Monkey Bike branding or timestamps if present.
• Output at most 9 images; if more than 9 inputs exist, skip simple color-variation duplicates.
• Preserve the product itself and avoid damaging/distorting it.

What Worked Before the Failure

1. The ZIP was inspected successfully.
2. It contained 13 JPG files.
3. The files were extracted successfully.
4. A local contact sheet was generated successfully for triage.
5. One reference image was loaded into the conversation context with the local image viewer before calling built-in image_gen.
6. The selected first output target was a Shopee-style product hero cover based on the olive-green pedal pair image.

Reproduction Steps

1. Start in Codex Desktop on Windows.
2. Use the imagegen skill for an image-editing task where the user explicitly requires built-in image generation/editing.
3. Load a local product image into the conversation context with the image viewer so the built-in image edit path has a visible image reference.
4. Call the built-in image_gen tool with a product-edit prompt. The first prompt requested a premium Shopee Indonesia 1:1 commercial listing cover, preserving the exact Enlee olive-green bicycle pedal pair and adding marketplace copy.
5. Observe the first failure: TooManyRequests / rate-limit response before any output is produced.
6. Wait approximately 20 seconds.
7. Retry with a shorter prompt for the same image and same constraints.
8. Observe the second failure: the same TooManyRequests behavior.
9. Wait approximately 75 seconds.
10. Retry again with a similarly concise prompt.
11. Observe the third failure: the same TooManyRequests behavior.
12. Check $CODEX_HOME/generated_images; no new generated image files were created for the failed attempts. The newest existing files were from the previous day, confirming that the failed attempts did not produce hidden output files.

Example Prompt Shape

A shortened version of the retry prompt was:

Edit the visible Enlee bicycle pedal product image into a premium square Shopee Indonesia listing cover. Preserve the pedal pair exactly: olive green nylon frame, pins, axle, markings, and proportions. Improve lighting, sharpness, background, and commercial layout only. Use clean studio white/light gray background with subtle orange-green marketplace accents and soft shadow. Add readable text exactly: "ENLEE PEDAL BEARING", "NYLON FIBER FLAT", "TAPAK LEBAR ANTI SLIP", "285g | 112x125x18mm", "5 PILIHAN WARNA". No timestamp, watermark, Monkey Bike, fake logo, clutter, or distorted product.

Expected Behavior

• The built-in image_gen tool should generate or edit at least the first image, or return an actionable rate-limit response with enough detail to recover gracefully.
• If there is a quota or service-side limit, the response should expose useful information such as whether the limit is user/session/global, whether a retry-after duration exists, and whether the task can continue later.
• The failure should not leave the agent in a state where the only possible fallback is API-key-based CLI generation, because the default built-in image workflow is documented as not requiring OPENAI_API_KEY.

Actual Behavior

• The built-in image_gen call failed with TooManyRequests three consecutive times.
• No image was generated.
• No new file appeared under $CODEX_HOME/generated_images.
• The task became impossible to complete while respecting the user's explicit requirement to use imagegen.
• The only available fallback path required OPENAI_API_KEY, which was not set locally and is not expected for the default built-in tool path.

Evidence Collected Locally

• OPENAI_API_KEY_SET=False
• $CODEX_HOME=C:\Users\<redacted>\.codex
• Newest existing generated image before/after the failed attempts: previous day, 2026-06-05 21:25:48 local time
• Incident attempt window: approximately 2026-06-06 10:28-10:31 Asia/Jakarta
• Generated outputs from the failed attempts: none

Impact

This blocks image-editing workflows in Codex Desktop when users explicitly require the default built-in image generation/editing path. The failure mode is especially problematic for batch marketplace-asset work because the first image cannot be produced, and the user receives no actionable retry guidance beyond trying again later or switching to an API-key fallback.

Requested Investigation

Could the Codex team check whether the built-in image_gen backend is currently applying an unusually strict or stale rate limit, or whether Codex Desktop is misclassifying these edit calls as over-limit before generation starts?

It would also help if the tool surfaced structured retry information, such as a retry-after value or the quota scope, so agents can wait appropriately instead of retrying blindly or falling back to API-key-based generation.