Repository navigation
image_gen returns image data in session records but no image is shown, saved, or exposed as a path #32153
Description
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_callrecords with a non-emptyresultpayload, 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?
- Ask Codex to generate an image:
Use image_gen to generate a small cat image.
- Wait for the image generation call to finish.
- Check the conversation output: no image is displayed and no saved path is shown.
- Check the generated images directory: no new usable image file appears.
- 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
Activity
jianxunzhang1101 commentedon Jul 11, 2026
I can reproduce the same issue on macOS.
Environment:
26.707.413010.144.1cli_version:0.144.0-alpha.4What I observed:
image_generation_callitem."generating".resultfield is present.saved_pathis produced.I extracted the existing
image_generation_call.resultlocally without sending another generation request. The result was valid strict base64 and decoded successfully:2,990,628characters2,242,970bytes1536 × 1024IENDchunk: presenta9d955e92f53ba0e153f6c33aa2fa162a6fead5db6223fc5fc891c18d0c81a12The 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 commentedon Jul 11, 2026
Reproduced on macOS with a full local diagnostic — adding evidence since most reports here are from Windows.
Environment
Findings (read-only inspection of the task JSONL)
image_generation_call.resultpresent: 2,990,628 chars of base64statusstuck at"generating", nosaved_pathresponse.completedobserved for the call~/.codex/generated_imagesResizeObservererror 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 officialsaved_pathonce this bug is fixed:https://github.com/jianxunzhang1101/recover-codex-images
Happy to provide the full log excerpts (minus base64 payloads) if useful.