Codex Desktop image editing produced no image output across repeated reference-image edit attempts

Open 💬 1 comment Opened Jul 15, 2026 by henson957

Summary

In Codex Desktop on macOS, repeated built-in image-edit requests using a reference cover image failed without producing any image output. From the user's perspective, image editing was unavailable: no preview, file path, or usable fallback image was ever returned.

This is related to #33050, but the reproduction here is specifically the reference-image editing path rather than text-to-image generation.

Environment

  • Product: Codex Desktop
  • Platform: macOS (Apple Silicon)
  • Workflow: built-in image generation/editing in a local project thread
  • Operation: edit an existing Chinese WeChat cover image

Requested edit

The task was intentionally narrow:

  • preserve the existing illustrated person, dark background, torn grid-paper panel, and blue brush accents;
  • replace only the title text with a new Chinese three-line title;
  • produce one reviewable cover image.

Observed behavior

Two separate reference-image edit attempts failed:

  1. Create a title-free reusable cover master by removing existing title ink while preserving the rest of the image.
  2. Replace the existing title on the reference cover with a new Chinese three-line title.

Neither attempt produced a generated image, preview, saved path, or usable output artifact. The task history recorded the image-generation action as failed.

The agent then had to fall back to deterministic local text overlay, which was visually inferior for the requested poster-style Chinese typography and does not replace a functioning image-edit capability.

User impact

A user cannot treat the feature as available if repeated edits produce no image at all. Saying that image editing is theoretically supported is not useful when the visible outcome is zero generated images.

This also made the surrounding task much worse: the failed image action remained in the thread history, subsequent “continue” requests spent time recovering that failed path, and the thread later became unreliable.

Expected behavior

For a supported reference-image edit, Codex should either:

  • return a generated image with a clear saved/preview location; or
  • return a structured, actionable failure that distinguishes rate limiting, transport failure, service timeout, unsupported edit semantics, and moderation.

It should not leave the user waiting for a long time and then provide no image and no actionable diagnostic.

Requested improvements

  1. Surface the raw failure category and safe request correlation ID.
  2. Show an explicit timeout/retry policy for image edits.
  3. Clearly distinguish “image generation is running” from a stalled or failed request in the Desktop UI.
  4. Ensure a failed image request cannot silently poison later thread recovery.
  5. Consider a robust, deterministic text-replacement path for cover-image workflows where exact text and layout preservation matter.

No API keys, account identifiers, or source images are included in this report.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗