Built-in image generation repeatedly fails with a generic network error

Open 💬 1 comment Opened Aug 4, 2026 by lxedison198816

Summary

Codex Desktop's built-in image_gen tool repeatedly fails for ordinary, policy-safe image-generation requests across unrelated projects. This is not limited to one prompt, asset type, or conversation.

The observed error is:

image generation failed: network error: error sending request for url (https://chatgpt.com/backend-api/codex/images/generations)

Frequency and impact

  • Reproduces repeatedly across multiple sessions and projects.
  • Previously affected creation of a custom Codex pet based on a personal avatar.
  • Also affects a three-panel sports-documentary static design review image.
  • A typical full request waits for several minutes and then returns the generic network error.
  • This blocks both new image generation and production design workflows in Codex Desktop.

Environment and network checks

  • macOS desktop environment.
  • Codex is authenticated through a ChatGPT account.
  • Wi-Fi HTTP and HTTPS system proxy are enabled and point to a local Clash proxy at 127.0.0.1:33210.
  • A read-only connection check can reach chatgpt.com through that configured proxy, so the base proxy path is available.
  • No API key is configured; this report concerns the built-in Codex image-generation route, which should not require an API key.

Reproduction

  1. Open Codex Desktop and start a task.
  2. Invoke the built-in image-generation tool with an ordinary, policy-safe prompt.
  3. Wait for the tool request to complete.
  4. Observe the generic network error above rather than an image result.

Example prompt:

Create one wide landscape triptych with three equal, tall vertical sports-documentary motion-graphics panels. Use original vector-style graphics, no real players, no logos, and no broadcast footage.

Expected result

The tool should either return a generated image or surface a specific actionable cause such as an authentication, rate-limit, model, policy, or server-side timeout error.

Actual result

The request reports a generic network error for the Codex image-generation backend endpoint after a long wait, despite ordinary web connectivity and a configured system proxy.

Requested investigation

Please investigate the Codex Desktop image-generation request path for backend queueing, timeout, retry, proxy handling, or error-reporting issues. The generic network error makes it difficult to distinguish a local network issue from a service-side failure.

Optional details to add before submitting

  • Codex version from Codex → About Codex
  • macOS version
  • Approximate local time of the most recent failure

View original on GitHub ↗

1 Comment

Crescenx · 9 days ago

Additional reproduction from Codex CLI on WSL2, with a minimal success/failure control that suggests the failure is request-dependent rather than a general connectivity or authentication issue.

Environment

  • Codex CLI 0.147.0, linux-x86_64
  • WSL2 with mirrored networking
  • Authentication: ChatGPT login
  • No OPENAI_API_KEY; using the built-in image generation path

Controls that succeed

  1. A trivial request: a plain blue circle on a white background.
  2. A single-panel scientific-educational schematic: several gray abstract marks converge into one blue central mark, then diverge into several gray marks.

Both generate successfully and are saved under ~/.codex/generated_images/....

Minimal failing variant
A wide landscape request containing exactly three separated studies, where each study repeats essentially the same gray → blue → gray convergence/divergence geometry.

That request enters the rendering/processing state, waits for some time, and then consistently fails with:

image generation failed: network error: error sending request for url
(https://chatgpt.com/backend-api/codex/images/generations)

So the observed boundary is approximately:

single scientific study                         -> succeeds
same basic schematic as three separated studies -> fails

This also reproduces with a more detailed publication-oriented three-panel scientific moodboard request.

Additional diagnostics

  • codex doctor --summary, run outside the restricted shell, reports WebSocket connectivity successfully (HTTP 101 Switching Protocols).
  • Provider endpoints are reachable over HTTP.
  • The local Codex log identifies the failed request as the POST to /backend-api/codex/images/generations, but does not expose the HTTP status, underlying backend error, or whether the failure occurred during submission, generation, polling, or timeout handling.

This does not prove that the three-panel layout itself is the root cause, but the successful single-panel control makes a persistent local networking/authentication failure much less likely. It may instead be related to multi-panel/wide requests, longer-running generation jobs, backend queueing, or timeout/polling behavior.

It would be useful to:

  1. include Linux/WSL Codex CLI in the investigation, in addition to the Desktop path; and
  2. preserve the underlying transport/backend error (HTTP status, timeout phase, upstream error, etc.) instead of collapsing it to the generic network error.