image_gen regression in 0.140.0: valid generated image is not saved when status remains generating

Resolved 💬 17 comments Opened Jun 16, 2026 by aprendendo-codex Closed Jun 23, 2026

What version of Codex CLI is running?

0.140.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4-mini

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

Summary

In Codex CLI 0.140.0, image_gen can return a valid generated PNG payload but never save it to the generated images directory.

The issue appears to be caused by a new persistence gate added in codex-rs/core/src/stream_events_utils.rs: image generation results are now only persisted when image_item.status == "completed".

However, I observed a successful image generation response where:

status was still "generating"
result contained a non-empty base64 payload
the payload decoded to a valid PNG
no file was written under <codex_home>/generated_images/<thread_id>/<call_id>.png

Rolling back to 0.139.0 made image saving work again.

Observed behavior

A session produced an image_generation_call like this, with identifiers anonymized:

type: image_generation_call
id: <image-call-id>
status: generating
result: <non-empty base64 PNG>

The result field was valid:

decoded bytes: >1 MB
PNG signature: 89 50 4E 47 0D 0A 1A 0A

But the expected file was not created:

<codex_home>/generated_images/<thread-id>/<image-call-id>.png

What steps can reproduce the bug?

Use $image_gen to create an image using codex 0.140.0

What is the expected behavior?

If an image generation item contains a valid non-empty image result, Codex should persist it to the generated images directory, even if the status is still "generating".

Alternatively, the status should be normalized to "completed" before the persistence path runs.

Suspected regression

This change in codex-rs/core/src/stream_events_utils.rs appears to be the cause:

if let TurnItem::ImageGeneration(image_item) = &mut *turn_item
    && image_item.status == "completed"
{
    persist_image_generation_item(sess, turn_context, image_item).await;
}

Before this change, Codex attempted to persist every ImageGeneration item. In 0.140.0, if a successful result arrives with status: "generating", persistence is skipped entirely.

Additional information

Suggested fix

Persist image generation results based on whether there is image data, not only on the status string.

For example:

if let TurnItem::ImageGeneration(image_item) = &mut *turn_item
    && !image_item.result.trim().is_empty()
{
    persist_image_generation_item(sess, turn_context, image_item).await;
}

Or, if preserving the completed-status behavior is important:

if let TurnItem::ImageGeneration(image_item) = &mut *turn_item
    && (image_item.status == "completed" || !image_item.result.trim().is_empty())
{
    persist_image_generation_item(sess, turn_context, image_item).await;
}

This should still avoid saving failed image generations, because failed items appear to have an empty result.

Suggested regression test

Add a test where a ResponseItem::ImageGenerationCall has:

status: "generating".to_string(),
result: "Zm9v".to_string(), // or valid PNG base64

Then assert that finalize_turn_item or the relevant response handling path persists the image and sets saved_path.

The important case is:

status is not "completed"
result is non-empty valid base64
persistence should still happen

Environment

Codex CLI: 0.140.0
Platform: Windows
Regression: 0.139.0 saves successfully; 0.140.0 does not in the case above

View original on GitHub ↗

17 Comments

hiroto172516 · 1 month ago

I can reproduce the same regression on macOS with an npm-managed Codex CLI.

Environment:

Codex CLI: 0.140.0 reproduced the issue
Rollback target: 0.139.0 restores saving
Platform: macOS
Model in the Codex session: gpt-5.5
CODEX_HOME/generated images path: .codex/generated_images

Observed behavior on 0.140.0:

The built-in image_gen tool successfully generated an image and displayed it inline in the conversation.
No new PNG was written under ~/.codex/generated_images after generation.
The generated_images directory existed and was writable.
Searching ~/.codex and the home directory for recently modified PNG/JPG/WebP files did not find the generated image.
The latest generated_images file remained from an earlier date, so the image artifact was not persisted locally.

After downgrading:

Ran: npm install -g @openai/codex@0.139.0
Restarted the Codex CLI session.
Re-ran the same built-in image_gen flow.
The image was saved again under:

~/.codex/generated_images/<thread_id>/<image_id>.png

Example saved path after rollback:
.codex/generated_images/xxxx/xxxx.png

This makes the regression appear specific to 0.140.0 rather than a local permissions or directory setup issue.

WeirenHsu · 1 month ago

Confirming this on Linux x86_64 as well (not Windows-specific):

codex-cli 0.139.0: built-in image_gen from the CLI writes the PNG to ~/.codex/generated_images/<session-id>/ig_<id>.png (verified with the notify hook disabled, so it's genuine native behavior).
codex-cli 0.140.0: same prompt/flags, nothing written to disk anywhere (neither generated_images nor CWD).

In the 0.140.0 rollout the image_generation_call item carries a full valid PNG base64 in result while "status":"generating", which matches your root-cause analysis of the status == "completed" gate in stream_events_utils.rs. Auth was ChatGPT sign-in (no OPENAI_API_KEY), built-in tool path. Downgrading to 0.139.0 restores saving.

silviucm · 1 month ago

Confirming this (codex cli inside a Docker Ubuntu 24.04 sandbox container). I literally had to tell Codex CLI to invoke another codex sub-instance and retrieve the image from the session logs despite the status saying generating. This is a very unpleasant 0.140.0 bug

WilliamHYZhang · 1 month ago

We’re seeing what looks like the same regression in our environment.

Environment:

Codex CLI: codex-cli 0.140.0-alpha.19
Codex Desktop: 26.611.61753 / build 4008
macOS, Codex Desktop session
CODEX_HOME effectively /Users/billyzhang/.codex (~/.codex exists and is used for config/logs/plugins)

Observed behavior:

Built-in image_gen calls complete successfully and the image appears inline in the Codex conversation.
No image file is written under /Users/billyzhang/.codex/generated_images.
A filesystem search for recent png/jpg/jpeg/webp/heic files under both ~/.codex and /Users/billyzhang found no generated artifact.

So from the user-visible side this matches the “generation succeeds but no persisted file is available” behavior described here.

weathour · 1 month ago

I can confirm the same regression on Linux with Codex CLI 0.140.0.

Observed locally:

image_generation_end / image_generation_call records contain a non-empty PNG base64 result.
The decoded payload is a valid PNG.
The item status remains "generating".
saved_path is absent and no PNG is written under ~/.codex/generated_images/<thread-id>/.

I also checked the current upstream state:

rust-v0.140.0 still gates persistence on image_item.status == "completed".
main appears to persist image generation items based on a non-empty result instead.

So the behavior appears fixed on main, but absent from rust-v0.140.0; a release containing this main-branch change would resolve the observed regression.

One possible follow-up test, if useful, would be a focused regression case in codex-rs/core/src/stream_events_utils_tests.rs that passes an ImageGenerationCall with status: "generating" and a non-empty base64 result through the finalization path, then asserts that saved_path is set and the generated image file is written.

asqer7 · 1 month ago

Confirming the same persistence failure on Windows / Codex Desktop.

Environment and evidence:

Platform: Microsoft Windows NT 10.0.26200.0 x64
Codex Desktop session state recorded cli_version = 0.140.0-alpha.19 for the affected thread.
Built-in image_gen completed and rendered inline in the conversation.
The session rollout contains image_generation_end / image_generation_call entries with:
non-empty base64 PNG result
status: "generating"
no saved_path
Decoding the rollout payload produced a valid PNG, 2,930,367 bytes.
No matching file was written under %USERPROFILE%\.codex\generated_images\<thread-id>\.
The generated_images directory was writable; I verified write/delete with a temporary test file, so this was not a local filesystem permission issue.
An older archived Desktop session on the same machine with cli_version = 0.137.0-alpha.4 did include event_msg.payload.saved_path, and the referenced generated image file existed.

This matches the suspected status-gate regression: the image payload is present and valid, but persistence is skipped while the item remains in generating status.

angelcoding · 1 month ago

I'm seeing this in the macOS Codex Desktop App now since upgrading to 26.611.61753.

duckband · 1 month ago

I can reproduce this on another Windows install of Codex CLI 0.140.0. Adding details here rather than opening a duplicate because the symptom matches this issue closely.

Repro summary

In a fresh Codex session, after verifying the image generation prerequisite, the agent attempted to generate a recipe hero image from a prompt file and save it as a project PNG.

Observed behavior:

Built-in image generation returned an inline image in the Codex thread.
No valid image file was persisted under ~/.codex/generated_images.
No image file was available in %TEMP% or the target project folder.
The agent could not save the PNG itself because the tool response exposed no file path, no base64 payload, and no image bytes to the shell/session.
A retry in a new session produced the same outcome: inline image visible in the thread, no saveable artifact on disk.

The failed workflow was essentially:

$imagegen generate image from prompt and save as <workspace>\photo.png

Expected behavior:

If the image is rendered inline successfully, Codex should also expose or persist a saveable artifact, e.g. under ~/.codex/generated_images/<thread>/<call>.png, or expose enough result metadata for the agent to write the target file.

Actual behavior:

Inline image only; no persisted artifact and no accessible bytes/path.

Local checks

codex-cli 0.140.0
codex login status: Logged in using ChatGPT
image_generation                     stable             true
OPENAI_API_KEY: not set [using built-in ChatGPT-backed image generation]

`codex doctor` summary

codex doctor --json completed with overallStatus: ok. Relevant redacted fields:

{
  "overallStatus": "ok",
  "codexVersion": "0.140.0",
  "runtime": {
    "platform": "windows-x86_64",
    "install_method": "npm",
    "version": "0.140.0"
  },
  "system": {
    "os": "Windows 10.0.26200 (Windows 11 Professional) [64-bit]",
    "os_language": "en-US"
  },
  "auth": {
    "stored_auth_mode": "chatgpt",
    "stored_API_key": false,
    "stored_ChatGPT_tokens": true
  },
  "config": {
    "model": "gpt-5.5",
    "model_provider": "openai",
    "feature_flags_enabled": 29,
    "feature_flag_overrides": "none"
  },
  "network": {
    "proxy_env_vars": "none",
    "reachability_mode": "ChatGPT auth",
    "websocket_handshake": "HTTP 101 Switching Protocols",
    "wire_API": "responses",
    "supports_websockets": true
  },
  "sandbox": {
    "approval_policy": "OnRequest",
    "filesystem_sandbox": "restricted",
    "network_sandbox": "restricted"
  },
  "terminal": {
    "terminal": "Windows Terminal",
    "WT_SESSION": "present",
    "stdout_is_terminal": false,
    "stderr_is_terminal": false
  }
}

No doctor checks failed. This looks consistent with the persistence gate described in the issue: generation can succeed visibly, but the artifact persistence path does not leave a usable local PNG for the agent to move or copy.

peterc · 1 month ago

Can confirm on 0.140.0 on macOS also. Materialized in a funny way, asked it to generate an image and the results were like stick figures because Codex noticed the generations weren't working and used a Python PIL script to attempt to produce the requested image instead.

l2102025 · 1 month ago

I’m seeing the same regression in Codex desktop app 26.611.62324 (4028) on macOS. Built-in image_gen produces image_generation_call entries with status="generating" and a non-empty valid PNG base64 result, but no file is written to ~/.codex/generated_images/<thread-id>/<call-id>.png and no saved_path is recorded.

Expected: generated image is persisted under ~/.codex/generated_images/.
Actual: image exists only in the session JSONL result payload.

sebthom · 1 month ago

Same issue with latest 0.141.0. Downgrading to 0.139.0 restores image_gen capability.

ray-amjad · 1 month ago

Confirming the same regression on macOS (Apple Silicon), codex-cli 0.140.0 installed via Homebrew cask, ChatGPT auth (no OPENAI_API_KEY), model gpt-5.5, image_generation feature reported stable true.

image_gen runs but nothing is persisted under ~/.codex/generated_images/<thread_id>/. The last successfully saved session dir on this machine is from 2026-06-15, and the 0.140.0 cask landed 2026-06-16 (/opt/homebrew/Caskroom/codex/0.140.0, binary mtime Jun 16 05:51). The break lines up exactly with the upgrade window described here.

Two distinct downstream symptoms in codex exec --json headless runs, both consistent with the status == "completed" persistence gate:

When the model simply calls image_gen, the inline image appears but no PNG lands in the session dir, so anything reading generated_images/ finds nothing.
When pushed to use a reference (referenced_image_paths), the model notices the generation didn't land and falls back to hand-writing a ~150-line Python/PIL script (rounded rects + grain texture) to fake the requested image. This matches @peterc's "stick figures via PIL" observation — it's reproducible, not a one-off.

+1 for persisting whenever result is non-empty regardless of status, per the suggested fix. Downgrading to 0.139.0 is the only thing restoring saved artifacts right now (and per a comment above, 0.141.0 still carries the bug).

vibin-dirty · 1 month ago

And now the recent codex app requires 0.141.0 on remote hosts, so image_gen became completely unusable in codex app

0xdeafbeef · 1 month ago

I can reproduce the same failure on Codex CLI 0.141.0 on Linux x64.

Observed in the rollout transcript:

type: image_generation_call
status: generating
result: <non-empty base64 payload>
saved_path: None

The result payload decodes successfully and starts with the PNG signature:

89 50 4e 47 0d 0a 1a 0a

No file is written under the expected generated-images path for the thread/call. This still matches the suspected regression: persistence is gated on image_item.status == "completed", but the backend response can carry a valid image payload while the status remains "generating".

So this is not limited to 0.140.0 or Windows; it is still present in 0.141.0 on Linux.

varo6 · 1 month ago

Present on Linux 0.141.0 too.

CDT · 1 month ago

Same on Windows 0.141.0

aprendendo-codex · 27 days ago

It seems to have been fixed by #28656. Tested with 0.142.0 and seems alright, so I'm closing this.