Codex Desktop built-in image_gen: byte-identical prompt can succeed in 26–87 seconds or fail after 265 seconds with a generations network error

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.8479.0

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Summary

Codex Desktop's built-in image_gen produced both success and failure for the same caller-visible request during a small, strictly serial test window.

I submitted one byte-identical prompt seven times with zero reference images, using one tool invocation per observation and no caller-initiated retry. Six calls produced valid 1254×1254 PNG files in 26.396–86.858 seconds. One call failed after 265.238 seconds with this exact error:

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

No other image-generation call was active in the inspected Codex task tree during these observations. No PNG was written in the failed call's local output window. Activity outside the inspected task tree, including host-wide or account-wide service state, could not be fully controlled.

This finding came from a larger prompt-obligation experiment. S20/S40/S60/S80 all failed, an S0 control succeeded, and five midpoint calls all failed, yielding an exploratory interval of [0, 0.625]. However, a zero-object version of the positive night-market template also failed, and the exact S0 prompt later produced both outcomes. The evidence therefore does not support treating [0, 0.625] as a deterministic model-complexity threshold.

The sample is small and is confounded by time and execution order. The observed 6 success / 1 failure is a description of these seven calls only, not an estimate of a long-run failure rate.

Environment

| Item | Value |
|---|---|
| Product | Codex Desktop |
| Codex Desktop version | 26.707.8479.0 |
| Codex CLI version | 0.130.0 |
| OS | Windows 10, build 19045 |
| Date/time zone | 2026-07-14, UTC+8 |
| Image path | Codex built-in image_gen |
| Operation | Text-to-image generation |
| Reference images | 0 |
| Scheduling | Strictly serial; one image call at a time |
| Caller retry policy | None; one tool invocation per recorded observation |
| Per-call cutoff | 600 seconds |
| Requested shape | Square; 1024x1024 was requested in natural language |
| Successful output shape | 1254×1254 |
| Network | A Windows proxy was configured and was required for basic chatgpt.com connectivity in this environment; no valid direct-vs-proxy image-generation A/B was available |

The proxy is a participant in the request path, but this report does not identify it as the cause. An unauthenticated short HEAD probe is not equivalent to a long authenticated image request.

Official documentation context and caller-visible controls

The Codex image-generation documentation says the built-in path uses gpt-image-2 and supports semantic generation/edit workflows. The Image API guide separately documents API generations/edits operations and explicit output controls.

In the built-in caller surface available to this test, I could supply:

• a natural-language prompt; and
• optional reference-image inclusion.

I could not supply API-style explicit size, quality, or edit fields. The requested 1024x1024 was therefore prompt text, not an explicit size parameter. This issue concerns the built-in Codex tool, not a direct Images API request.

Minimal reproduction: identical caller-visible request

1. Open Codex Desktop and invoke the built-in image-generation capability.
2. Do not attach a reference image.
3. Ensure no other image-generation call is active in the current Codex task tree.
4. Submit the exact prompt below once and wait for either an image or a tool error.
5. Record start/end time, raw tool result, and whether a PNG appears in the generated-image directory during the exact call window.
6. Repeat sequentially without changing the prompt. Because the behavior is intermittent, a small number of repetitions may all succeed.

Exact repeated prompt:

Use case: illustration-story
Asset type: diagnostic complexity-threshold square illustration
Primary request: Create a plain empty courtyard at night, viewed from slightly above. Required scored elements: none.
Composition/framing: exact square canvas intended as 1024x1024 pixels; show one simple open ground plane and one plain dark wall, without layered depth requirements.
Lighting/mood: warm amber market lighting with subtle cool moonlight; uniform medium-detail illustration style.
Constraints: no stalls; no human figures; no market props; no lantern strings; no balconies; no readable words; no logo; no watermark.

The seven recorded requests used this prompt byte-for-byte, with zero reference images and one built-in tool call each.

Prompt-obligation scoring and method

The score below is an experiment-defined input prompt-obligation score, not an OpenAI model metric or a measurement of internal model complexity.

The protocol defines 20 globally ordered obligation blocks worth 5 points each. Higher initial levels contain all lower-level obligations. Lighting, viewpoint, square framing request, style, and negative constraints remain fixed.

| Score | Nested requested obligations |
|---:|---|
| S20 | Two stalls and five figures |
| S40 | S20 plus a third stall, fountain, fruit baskets, and lantern strings |
| S60 | S40 plus a fourth stall, pottery, steam, and reflected damp cobblestones |
| S80 | S60 plus a fifth stall, five more figures, and a bicycle |
| S0 | A separate plain-empty-courtyard transport control with no scored objects |

The initial levels were run once each in ascending order. Because all four failed, S0 was run once and succeeded. The observed adjacent pair [S0 success, S20 failure] was then bisected five times. Fractional scores reduce the visibility/detail burden of the first stall obligation; they never request a fractional object.

Important method limitation: S0 belongs to a simpler prompt family. It changes the semantic scene, composition language, and constraints as well as object count. The later V2 crossover control kept the positive night-market template but removed all scored object obligations.

Results: initial ladder and transport control

All failures in this report returned the same raw generations endpoint error shown above. Each failed call had no PNG in its exact local call window.

| Run | Local start time | Score | Elapsed | Result | Other image calls in inspected task tree |
|---|---|---:|---:|---|---:|
| S20 | 14:46:00.620 | 20 | 314.083 s | Network-error failure | 0 |
| S40 | 14:56:28.039 | 40 | 319.008 s | Network-error failure | 0 |
| S60 | 15:09:49.802 | 60 | 259.175 s | Network-error failure | 0 |
| S80 | 15:17:40.125 | 80 | 312.296 s | Network-error failure | 0 |
| S0 | 15:28:35.643 | 0 | 39.132 s | Success; valid 1254×1254 PNG | 0 |

Failure time did not increase monotonically with score: S60 was the shortest initial failure.

Results: five midpoint calls

| Split | Pre-call interval | Score | Incremental obligation | Elapsed | Result | Post-call interval |
|---:|---|---:|---|---:|---|---|
| M1 | [0, 20] | 10 | Two distinct stalls | 314.121 s | Network-error failure | [0, 10] |
| M2 | [0, 10] | 5 | One distinct stall | 314.480 s | Network-error failure | [0, 5] |
| M3 | [0, 5] | 2.5 | One simple, clearly visible stall | 312.122 s | Network-error failure | [0, 2.5] |
| M4 | [0, 2.5] | 1.25 | One small, distant, mostly occluded stall | 319.431 s | Network-error failure | [0, 1.25] |
| M5 | [0, 1.25] | 0.625 | One tiny, distant, barely visible, mostly occluded stall | 317.039 s | Network-error failure | [0, 0.625] |

The final [0, 0.625] range is an exploratory single-sample transition between prompt families. It is not a deterministic threshold and does not estimate failure probability.

Results: prompt-template crossover controls

| Run | Caller-visible prompt relationship | Objects requested | Elapsed | Result |
|---|---|---:|---:|---|
| S0 | Plain-empty-courtyard control | 0 | 39.132 s | Success |
| V1-S0-R1 | Byte-identical replay of S0 after all five midpoint failures | 0 | 35.783 s | Success |
| M5-S0.625 | Positive night-market template; first stall at 1/8 visibility/detail burden | 1 | 317.039 s | Network-error failure |
| V2-PositiveTemplate-Zero | Positive night-market template with every scored object removed | 0 | 316.227 s | Network-error failure |

V2 and M5 had six lines each and differed only in their primary-request line: V2 requested no scored elements, while M5 requested one tiny, mostly occluded stall. All other lines were case-exact identical.

This single crossover does not support the claim that a nonzero object obligation was necessary for the observed failure. It instead leaves several possibilities open: prompt-family semantics, hidden routing/scheduling, time-varying service state, or a transport/request lifecycle. One unreplicated V2 sample cannot distinguish them.

Results: identical S0 prompt stability observations

These seven observations are listed in chronological order. All used the exact prompt from the minimal reproduction section.

| Observation | Run | Local start time | Elapsed | Result | Local artifact |
|---:|---|---|---:|---|---|
| 1 | S0 | 15:28:35.643 | 39.132 s | Success | Valid 1254×1254 PNG |
| 2 | V1-S0-R1 | 16:50:23.632 | 35.783 s | Success | Valid 1254×1254 PNG |
| 3 | STAB-S0-03 | 17:17:22.003 | 86.858 s | Success | Valid 1254×1254 PNG |
| 4 | STAB-S0-04 | 17:22:20.664 | 34.158 s | Success | Valid 1254×1254 PNG |
| 5 | STAB-S0-05 | 17:25:54.993 | 38.835 s | Success | Valid 1254×1254 PNG |
| 6 | STAB-S0-06 | 17:32:14.038 | 265.238 s | Network-error failure | No PNG in the call window |
| 7 | STAB-S0-07 | 17:41:18.886 | 26.396 s | Success | Valid 1254×1254 PNG |

The exact same caller-visible request succeeded both immediately before and after the failed observation. This disproves deterministic success for this prompt in this seven-call window and weakens a deterministic prompt-complexity explanation. It does not establish a long-run failure rate or show that prompt content is irrelevant to failure probability.

Actual behavior

• A byte-identical, zero-reference built-in request produced both valid images and a generic network failure.
• Successful copies completed in 26.396–86.858 seconds; the failed identical request returned after 265.238 seconds.
• The failed call exposed no structured timeout category, backend status, correlation/request identifier, or retry guidance in the tool result.
• The same error fingerprint also appeared in every positive scored call and the zero-object positive-template crossover call.
• Failed calls did not write a PNG during their recorded local call windows. This does not rule out a server-side orphan result that was never delivered.

Expected behavior

• The same supported caller-visible request should not intermittently terminate only with a generic error sending request for url after several minutes.
• If generation cannot complete, the built-in tool should return a structured, actionable error that distinguishes client transport, gateway/request timeout, service overload, moderation, and image-model failure where possible.
• The error should expose a safe correlation identifier and retry guidance so a maintainer can trace whether the request was accepted, rendered, or lost during delivery.
• Caller-visible timeout/retry behavior for long-running built-in image requests should be documented or surfaced.

Interpretation and confidence

Directly observed

• The identical S0 prompt had six successes and one failure in this seven-call, time-local sequence.
• All recorded failures used the same /backend-api/codex/images/generations network-error text.
• Positive-score failure durations were not monotonic with the operational score.
• S0 and its immediate post-bisection replay both succeeded quickly, while V2 failed after all scored objects were removed from the positive template.
• No other image-generation call was active in the inspected task tree for the listed calls.

Cautious working hypotheses

The repeated long waits followed by the same transport-shaped error are consistent with some request, connection, delivery, or gateway lifecycle being reached. The varying failure times (259.175–319.431 seconds in the new scored/control runs) do not show one exact fixed client timeout.

Time-varying backend load, queueing, hidden semantic routing, or delivery state could explain why identical caller-visible inputs had different outcomes. The V2 crossover makes object count alone an insufficient explanation in that one comparison, but it does not prove semantic routing.

The configured proxy is required for connectivity in this environment and could participate in long-request failure. It could not be isolated with a valid direct-vs-proxy image-generation A/B, so it is not identified as the root cause.

Limits

• The sample is small: one call per score and seven observations for the repeated S0 prompt.
• Runs were sequential but not randomized; time and execution order are confounded with prompt level.
• Host-wide, account-wide, backend-load, and hidden-routing state were not observable.
• The operational score measures prompt obligations only; it is not an internal model-complexity value.
• 6/7 must not be interpreted as a stable success probability or 1/7 as a long-run failure rate.
• Local directory scans cannot prove whether a server-side image was generated but never delivered.
• The evidence does not establish complexity, proxy behavior, endpoint routing, Codex Desktop, or the image backend as the unique root cause.

Related issues

• openai/codex#23015 — appears related; I am not asserting that this report is a duplicate.
• openai/codex#21360 — appears related; I am not asserting that this report is a duplicate.

Information requested from maintainers

1. Can the backend identify whether these requests were accepted and whether image rendering completed before the client received the network error?
2. Is there a known built-in image-request, gateway, or delivery lifecycle around roughly 4–6 minutes?
3. Can Codex expose a safe request/correlation ID and a structured failure layer for built-in image-generation errors?
4. Does the built-in path use hidden semantic routing or materially different scheduling for prompt families that are not visible in the caller schema?
5. Is there a supported debug-log category that would separate upload/request submission, queueing, rendering, image delivery, and local persistence timestamps?
6. Is retry expected to be automatic or caller-driven for this error class, and can retry guidance be included in the error?

Attachment manifest

The accompanying report package uses only relative, sanitized names:

• protocol.md — full operational scoring and bisection protocol.
• results.json — normalized records for all 17 new calls, exact prompts, timing, error fingerprints, image hashes, cohort definitions, and the sanitized earlier-matrix summary.
• assets/ — the six successful byte-identical S0-family PNG outputs.
• official-doc-evidence.md — documentation sources and the built-in/API distinction.
• network-handshake-ab.md — sanitized short-connectivity probe and its interpretation boundary.
• report-artifact.json — validated report manifest, chart/table datasets, and source metadata.

Privacy statement

This issue body and the listed attachment copies contain no username, private absolute filesystem path, full Codex thread/task identifier, authentication material, proxy process name, or sensitive configuration. Home-directory paths, generated internal IDs, cookies, authorization headers, tokens, environment variables, and unrelated process/network data were excluded.

What steps can reproduce the bug?

1. Open Codex Desktop 26.707.8479.0 on Windows 10 x64.
2. Make sure no other image-generation call is active in the current Codex task.
3. Invoke the built-in image_gen tool once, with zero reference images and the exact prompt below.
4. Wait until either an image or an error is returned. Do not retry the call automatically.
5. Repeat the same request sequentially several times without changing any prompt bytes or caller-visible parameters.

There is no direct API/SDK code snippet for this reproduction because the failure occurs in Codex Desktop's built-in image-generation tool. The exact reproduction payload is:

Use case: illustration-story
Asset type: diagnostic complexity-threshold square illustration
Primary request: Create a plain empty courtyard at night, viewed from slightly above. Required scored elements: none.
Composition/framing: exact square canvas intended as 1024x1024 pixels; show one simple open ground plane and one plain dark wall, without layered depth requirements.
Lighting/mood: warm amber market lighting with subtle cool moonlight; uniform medium-detail illustration style.
Constraints: no stalls; no human figures; no market props; no lantern strings; no balconies; no readable words; no logo; no watermark.

In my controlled sequential test, this byte-identical request was submitted seven times with one built-in tool invocation per observation and no reference images:

• Six calls succeeded in 26.396–86.858 seconds and produced valid 1254×1254 PNG files.
• One call failed after 265.238 seconds with:

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

The exact same request succeeded immediately before and after the failed observation. Because the behavior is intermittent, a small number of repetitions may all succeed.

What is the expected behavior?

_No response_

Additional information

_No response_