›_ Codex Issues
Codex Issues / #26731

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

Open 💬 2 comments Opened Jun 6, 2026 by Avisenaprima
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #26567
  • #26727
  • #26595

Powered by Codex Action

Avisenaprima · 2 months ago

Follow-up: public reports suggest this is not isolated

After filing this issue, I searched for similar public reports across Reddit, GitHub, and OpenAI Status. The evidence below suggests that the failure pattern I hit may not be isolated to my account, prompt, or source image. I am not claiming these reports all share the exact same root cause, but several of them line up closely with the symptom reported here: Codex/image generation reporting a rate-limit failure before any useful image output is produced, or Codex usage limits behaving unexpectedly.

1. Very similar Reddit report: imagegen rate limit before first image

A Reddit thread in r/codex titled "Can no longer get codex to use imagegen?" describes nearly the same user-visible failure mode:

  • URL: https://www.reddit.com/r/codex/comments/1txdw8f/can_no_longer_get_codex_to_use_imagegen/
  • The OP says they previously could generate images with Codex, but now Codex reports a rate limit before generating even one image.
  • This maps closely to my incident: the built-in image_gen tool returned TooManyRequests repeatedly, and no output file was created under $CODEX_HOME/generated_images.
  • Other comments in that thread indicate additional users were seeing the same behavior, including comments equivalent to "same problem" and speculation that it might be a service-side issue.

Why this matters: this is the closest public match I found. It points specifically to Codex/imagegen, not just general Codex coding-turn limits.

2. Reddit discussion about Codex image generation throughput and recent rate limits

Another Reddit thread asks about real-world image generation throughput in Codex plans:

Why this matters: this supports that native/built-in Codex image generation is actively used by users, that rate limits are visible in real workflows, and that throughput/limit behavior is currently unclear to users.

3. GitHub issue: 429 Too Many Requests despite high remaining limits

There is a prior Codex GitHub issue for a 429 Too Many Requests error where the user reported high remaining limits at the same time:

  • URL: https://github.com/openai/codex/issues/12781
  • Title: exceeded retry limit, last status: 429 Too Many Requests, request id: ...
  • The issue body shows reported remaining limits like 5h limit: 96% left and Weekly limit: 86% left, yet the user still hit a 429.
  • This issue was not imagegen-specific, but it is relevant because it suggests a class of Codex rate-limit failures where visible remaining usage and backend rejection may diverge.

Why this matters: my current failure looked similar from the user perspective. The workflow had not generated any new image output, yet the built-in image tool still failed repeatedly with a rate-limit-style error.

4. GitHub issues showing image-heavy Codex sessions can have additional failure modes

These are not the same symptom as this issue, but they are relevant because they show Codex image/image-heavy workflows can stress desktop/session infrastructure in ways users do not expect:

Why this matters: even when image generation succeeds, image-heavy workflows appear to interact with session persistence/context accounting in ways that can create secondary failures. My issue is earlier in the chain, but it may be worth checking whether image generation calls, image inputs, generated image metadata, or session replay artifacts are being counted unexpectedly against Codex limits.

5. Related OpenAI Status history

OpenAI Status also shows recent historical incidents that are directionally relevant:

Why this matters: the current symptom could be a new/recurring service-side issue or a separate accounting/gating issue. The prior incidents make it plausible that users can hit abnormal Codex limits even when the local workflow itself is not unusually heavy.

Updated hypothesis

Given the additional public evidence, this looks less likely to be caused only by my specific prompt, source image, or local ZIP workflow. A few possibilities worth checking:

  1. A transient or regional backend issue affecting Codex built-in image generation.
  2. Codex Desktop/app-server incorrectly mapping a service-side image generation limit into a generic TooManyRequests failure without structured retry information.
  3. Built-in image_gen calls consuming or checking Codex included limits too aggressively, possibly before output is generated.
  4. A mismatch between visible Codex usage/limits and the backend quota gate used by image generation.
  5. Image input/context/session artifacts being counted toward limits unexpectedly before generation begins.

Requested addition to the investigation

Could the team compare my issue with the public Reddit report above and check whether there was a spike in built-in Codex image_gen TooManyRequests failures around June 5-6, 2026?

It would be especially helpful to know whether these failures are:

  • account-level quota exhaustion,
  • shared service capacity throttling,
  • a per-model/per-tool image generation limit,
  • a Codex included-usage accounting issue,
  • or a desktop/app-server request-building issue.

If the tool can return a structured retry_after, quota scope, and whether the failed attempt consumed any usage, agents can handle this much more gracefully instead of repeatedly retrying or incorrectly telling users they need API-key fallback.