Generated images are not automatically embedded after image generation
What version of the Codex App are you using (From “About Codex” dialog)?
26.417.41555
What subscription do you have?
Plus
What platform is your computer?
Linux 6.6.87.2-microsoft-standard-WSL2 x86_64 x86_64
What issue are you seeing?
When I have codex generate images with the built in image generation tool, the images are created and saved correctly, however in the chat it doesn't embed correctly so all I see are empty responses or "Generated Image #".
The multiple images were generated under this path : mnt/c/Users/<my_user>/.codex/generated_images/...
But the response itself did not include the Markdown image tags, so nothing appeared visually in the conversation until I asked why the images were not showing. Codex had to manually locate the files and embed them with absolute Markdown links to show up in the chat.
<img width="806" height="521" alt="Image" src="https://github.com/user-attachments/assets/a9eec949-00e3-47b9-b842-0d92aeb52fac" />
What steps can reproduce the bug?
- Ask codex to generate mockup images or any images using the built in image generation tool
- Wait for image generation to complete
- Observe if Codex returns a response without image embeds.
- Check if Codex can find the files or check if the files were generated at the image generation path
- See if Codex can embed the files manually afterwards.
Model : GPT 5.4 XHigh
Session ID: 019db360-7e19-7210-8402-dfae24d13313
Context Window: 133k / 258k
What is the expected behavior?
The expected behavior is Codex should automatically render the generated image files inline in the chat using the Markdown image tags with absolute paths. It should visually show each image inline and embedded right after the prompt asking for the image generation without further prompting necessary.
Additional information
This happened in a WSL workspace. Generated files were saved under /mnt/c/Users/<my_user>/.codex/generated_images/..., so path translation may also be involved. However, the first failure was that Codex did not include any Markdown image embeds after image generation.
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This is not a duplicate as my issue is about using image generation in the Codex App not embedding correctly. The other issue is about non generated images not refreshing when file path is overwritten.
I encountered the same issue today with Windows and WSL2.
<img width="326" height="44" alt="Image" src="https://github.com/user-attachments/assets/e304eb33-baa4-4528-9c15-689f9a4729c0" />
Same issue on WSL2 and Codex 26.422.30944
same issue here for weeks.
per codex debug, the app is using the placeholder name in the generated markdown message, instead of the real filename.
II I ask to display the image using the real filename works.
If there is a process that translate the placeholder to the real name, also could be that.
Also happening for me, but this used to work a few days ago.
Additional macOS reproduction on the current extension-backed image path.
Environment:
The code-mode call followed the tool contract exactly:
const result = await tools.image_gen__imagegen({ prompt: "..." });
generatedImage(result);
Observed:
A separate no-generation canary, calling generatedImage with a valid 1 x 1 PNG data URL, also produced only a functions.exec tool output containing input_image; it did not produce a visible generated image card.
I am not treating the absence of a legacy image_generation_call record as proof by itself, because PRs #31596, #31597, and #30188 changed the extension and rollout paths. The user-visible defect is that a successful extension result is present and valid, yet the extension-to-app display handoff renders nothing.
This differs from the original WSL report only in that the PNG is saved successfully. It is also related to #32153, which reports the same Desktop version and image data reaching the session without a usable UI result.
PR #32866 removes the post-generation silence instruction, which should prevent the empty-message symptom, but it does not appear to address the missing image display handoff.
Expected: generatedImage output should be visible on the active tool surface or be projected into a renderable image item.
I can share the private session through in-product feedback if maintainers need the full trace; no user paths or prompt contents are included here.