›_ Codex Issues
Codex Issues / #32153

image_gen returns image data in session records but no image is shown, saved, or exposed as a path

Resolved 💬 2 comments Opened Jul 10, 2026 by nickear Closed Jul 16, 2026

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

26.707.31428

What subscription do you have?

ChatGPT Plus

What platform is your computer?

_No response_

What issue are you seeing?

Built-in image_gen no longer produces a usable image output in either Codex CLI or Codex App.

Environment:

  • Platform: Windows x64
  • Codex CLI: codex-cli 0.144.1
  • Codex App: 26.707.31428

Actual behavior:

  • No generated image is displayed in the conversation.
  • No saved image path is returned or printed.
  • Asking Codex where the generated image was saved does not produce a valid path.
  • No new generated image is found under the default generated image directory, e.g. `%USERPROFILE%

\.codex\generated_images`.

  • Local session inspection shows image_generation_call records with a non-empty result payload, but no

saved_path.

Example diagnostic shape from local session records:

  PayloadType = image_generation_call
  Status = generating
  HasSavedPath = False
  ResultLen > 0

There is no visible error message in the UI. The failure mode is that image data appears to exist internally, but
Codex does not display it, does not persist it to a generated image file, and does not expose a usable path.

This looks related to the older image persistence regression in #28422 / #28526, which was fixed by #28656, but this is happening on codex-cli 0.144.1 and Codex App 26.707.31428.

Possibly related but different from #32128: that issue is about base64 image data causing session/log size growth.
This issue is about generated image data not being displayed, saved, or exposed as a path.

What steps can reproduce the bug?

  1. Ask Codex to generate an image:

```text
Use image_gen to generate a small cat image.


  2. Wait for the image generation call to finish.
  3. Check the conversation output: no image is displayed and no saved path is shown.
  4. Check the generated images directory: no new usable image file appears.
  5. Inspecting the session JSONL shows an image_generation_call with a non-empty result, but no saved_path.

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

2 Comments

jianxunzhang1101 · 1 month ago

I can reproduce the same issue on macOS.

Environment:

  • Codex Desktop: 26.707.41301
  • Codex CLI: 0.144.1
  • Session metadata cli_version: 0.144.0-alpha.4

What I observed:

  • The session JSONL contains an image_generation_call item.
  • Its status remains "generating".
  • A non-empty and complete result field is present.
  • No saved_path is produced.
  • No standalone image file is automatically created.
  • Codex Desktop displays an empty image placeholder.

I extracted the existing image_generation_call.result locally without sending another generation request. The result was valid strict base64 and decoded successfully:

  • Base64 length: 2,990,628 characters
  • Decoded size: 2,242,970 bytes
  • Format: PNG
  • Dimensions: 1536 × 1024
  • PNG header: valid
  • PNG IEND chunk: present
  • SHA-256: a9d955e92f53ba0e153f6c33aa2fa162a6fead5db6223fc5fc891c18d0c81a12

The manually recovered PNG opens normally, so the image generation result reached the local session record intact. The failure appears to happen after the result is received, during local file persistence and/or UI exposure.

This resembles the earlier issue fixed by #28656, where image data could be available while the status was still "generating". Since the image-generation architecture was recently moved to the extension-based pipeline, this may be a regression in the new save/display path.

jianxunzhang1101 · 1 month ago

Reproduced on macOS with a full local diagnostic — adding evidence since most reports here are from Windows.

Environment

  • Codex CLI: 0.144.1 (embedded task CLI: 0.144.0-alpha.4)
  • Codex Desktop: 26.707.41301
  • macOS

Findings (read-only inspection of the task JSONL)

  • image_generation_call.result present: 2,990,628 chars of base64
  • Strict-decodes to a valid 2,242,970-byte PNG, 1536×1024 (header + IEND intact, chunk CRCs pass)
  • status stuck at "generating", no saved_path
  • No response.completed observed for the call
  • No file created in ~/.codex/generated_images
  • UI shows nothing (a ResizeObserver error appears in Desktop logs around render time)

So generation, transfer, and encoding all succeed — the failure is in the persist/display handoff, consistent with the pre-0.142 regression (#28422, fixed by #28656 via the !result.is_empty() check) resurfacing after the extension-based image pipeline switch (#31596 / #31597 / #29711).

Temporary workaround until this is fixed: I published a local, read-only recovery Skill that extracts the image from the task JSONL, validates it (base64 + PNG CRC), saves it to ~/.codex/generated_images, and displays it — it also auto-runs alongside normal image requests and hands back to the official saved_path once this bug is fixed:

https://github.com/jianxunzhang1101/recover-codex-images

Happy to provide the full log excerpts (minus base64 payloads) if useful.