Issue: Built-in image_gen generates an inline image, but does not return or expose a usable saved file path. Environment: Windows Codex CLI: codex-cli 0.130.0-alpha.5 Date: 2026-06-18 Steps: 1. Use the built-in image_gen tool in a Codex desktop thread. 2. Generate a simple image with no input-image dependencies. 3. The image appears inline in the conversation. 4. Check C:\Users\79447\.codex\generated_images and common cache/temp directories. Actual: The image is visible inline, but no new PNG

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #28887 - #28848 - #28881 - #28849 - #28873 *Powered by [Codex Action](https://github.com/openai/codex-action)*

Built-in image_gen generates an inline image, but does not return or expose a usable saved file path.

Open 💬 4 comments Opened Jun 18, 2026 by CandlelightOVO

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Issue: Built-in image_gen generates an inline image, but does not return or expose a usable saved file path.

Environment:
Windows
Codex CLI: codex-cli 0.130.0-alpha.5
Date: 2026-06-18

Steps:

Use the built-in image_gen tool in a Codex desktop thread.
Generate a simple image with no input-image dependencies.
The image appears inline in the conversation.
Check C:\Users\79447\.codex\generated_images and common cache/temp directories.

Actual:
The image is visible inline, but no new PNG/JPG appears in .codex\generated_images.
The tool response exposes no saved_path/file_path/artifact_path.
From the agent side this is effectively path = null.

Expected:
image_gen should return a usable saved_path, or save consistently to .codex\generated_images, or expose an artifact handle that Codex can copy into the workspace.

Impact:
Generated images cannot be copied into the project, versioned, post-processed, or referenced reliably by path.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 2 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#28887
#28848
#28881
#28849
#28873

Powered by Codex Action

waitingformywind · 2 months ago

I can reproduce this on Windows with the Microsoft Store Codex Desktop app, and I have some additional regression evidence.

Environment:

OS: Windows
Codex Desktop: 26.611.8604.0, installed from Microsoft Store
Internal Codex binary / CLI in session metadata: 0.140.0-alpha.19
Model provider: chatgpt-http

Observed behavior on 0.140.0-alpha.19:

The built-in image generation call succeeds and the image renders inline in the conversation.
The image_generation_end event contains base64 PNG data in result, but no saved_path field.
No corresponding folder/file is created under C:\Users\PC\.codex\generated_images\<thread-id>.
The decoded result is a valid PNG, so generation itself is not failing; the filesystem persistence / saved_path handoff appears to be failing or skipped.

Example failing event shape from a diagnostic thread:

payload.type = image_generation_end
keys = [call_id, result, revised_prompt, status, type]
result_len = 1162052
base64 decodes to valid PNG, decoded bytes = 871538
missing folder = C:\Users\PC\.codex\generated_images\019eda46-5f29-7f71-89d6-f73149fb92f6

Regression comparison from local session logs:

0.136.0-alpha.2: saved_path present, saved 14/14 image_generation_end events
0.137.0-alpha.4: saved_path present, saved 5/5
0.138.0-alpha.7: saved_path present, saved 3/3
0.140.0-alpha.2: saved_path present, saved 41/41 and 18/18 in two checked sessions
0.140.0-alpha.19: saved_path missing, saved 0/20, 0/2, 0/8, 0/34, 0/9, and 0/1 across checked sessions

A known-good 0.140.0-alpha.2 image_generation_end event had this extra field:

saved_path = C:\Users\PC\.codex\generated_images\<thread-id>\ig_<image_id>.png

The default directory exists and is writable. Some files that appeared later under generated_images were manually extracted from session JSONL by scripts, not automatically saved by the built-in image generation path. The reliable discriminator is whether image_generation_end contains saved_path; on 0.140.0-alpha.19 it does not.

Expected:

Either restore automatic saving to CODEX_HOME/generated_images/<thread-id>/ig_<image_id>.png and include saved_path on image_generation_end, or expose a stable artifact/file handle so Codex can copy the generated image into a workspace without scraping base64 from rollout logs.

forsakenMystery · 2 months ago

it exists on 0.141 too, any workaround?

jianxunzhang1101 · 1 month ago

Same signature reproduced on macOS 0.144.1 / Desktop 26.707.x — complete, CRC-valid PNG in the JSONL, status: "generating", no saved_path. Now tracked in #32153 after the extension pipeline switch.

Workaround that automates exactly what you did manually (strict decode → validate → atomic save → display), and defers to the official saved_path once fixed: https://github.com/jianxunzhang1101/recover-codex-images