Codex (desktop/CLI) can’t use provided images or generate new ones

Resolved 💬 2 comments Opened Mar 17, 2026 by MaxSmile Closed May 10, 2026

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

Codex Version 26.311.21342 (993) (desktop app / terminal-based coding assistant)

What subscription do you have?

Plus

What platform is your computer?

Mac OS 15.6 Apple Silicone

What issue are you seeing?

Summary:
Two workflow blockers when working on a web repo that needs image assets:

No integrated image generation (e.g., DALL·E / image model) to produce raster assets directly in the workspace.
Images attached in chat are visible to the assistant, but the assistant cannot access them as file bytes to rename/crop/convert/save into the repo. This forces a manual “download from chat → save to disk → tell the assistant the filename” loop, which defeats the purpose of an agentic coding tool.
Impact:

Slows down common tasks like creating/updating blog cover images/OG images.
Causes confusion: user assumes “attached image” is usable as an input file, but it isn’t.
Workarounds are clunky (manual file export) or non-equivalent (assistant re-screenshots a website instead of using the user-provided screenshot).
Expected behavior:

Either (a) allow the assistant to import chat-attached images into the workspace (with an explicit “Save to workspace” action/permission), or (b) expose a stable local path/handle for attachments so tools can process them.
Optional: built-in image generation tool or first-class “generate image into file” flow.
Actual behavior:

Assistant can view attachments but cannot access them as files.
No native image-generation capability in this environment.
Repro steps:

Attach a PNG screenshot in chat and ask the assistant to crop/convert it into public/assets/.../*.webp.
Assistant reports it cannot access the attachment as a file and asks user to manually save it locally.
Task cannot be completed end-to-end without manual intervention.
Notes:

This limitation is especially painful for web projects where images are part of the deliverable (Next.js blog covers, OG images, etc.).

What steps can reproduce the bug?

See description

What is the expected behavior?

See description

Additional information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗