`image_gen` regression: local reference images are ignored for image-to-image generation after 0.139.0
Summary
After upgrading from Codex 0.139.0, image_gen no longer appears to use a local reference image when asked to create a new image based on that reference. The same workflow worked in 0.139.0, while 0.142.0 and 0.142.2 generate an unrelated image with no visible relationship to the supplied reference.
0.140.0 also broke image_gen more broadly for me, so I could not narrow the first bad released version by direct testing. The behavior was still broken when image generation became usable again in 0.142.0, and I reproduced it again in 0.142.2.
Reproduction prompt
Use a workspace containing a single local reference image, for example reference.png, then run:
make a cartoon page using image_gen, based on reference.png for character references and style. save it on cartoon.png, and do not read any other files in the repo.
Expected behavior
image_gen should use reference.png as an image input/reference, preserving the character/style cues from that file in the generated cartoon.png.
This worked in 0.139.0: the agent inspected the referenced image, generated a cartoon page that matched the reference's character/style, and saved the requested output.
Actual behavior
In 0.142.2, the agent attempted to inspect the reference image but failed in the sandbox/image-view path. It then proceeded to call image_gen with a prompt that only named the reference file in text. The output image was unrelated to the reference image.
The failed run contained messages equivalent to:
- local image viewing/read failed in the sandbox before the PNG could be attached
- the agent confirmed only that the file existed
- generation proceeded with text like
reference.png is the character and style reference - the resulting generated image had no visible clues from the reference
Regression notes from local code inspection
The likely regression window starts after rust-v0.139.0.
Potentially relevant commits:
19ce6394af86b5e721f648cb9b68e52c2cb1f1ea/ PR#27498- "Route image extension reads through turn environments v2"- This changed
codex-rs/ext/image-generation/src/tool.rsfrom directstd::fs::read(path)forreferenced_image_pathsto environment-backed reads throughenvironment.file_system.read_file(..., Some(&environment.file_system_sandbox_context)). - This commit is included in
rust-v0.140.0and later, not inrust-v0.139.0. 1829ed11228d9ffad6bf7d6db615324126065b23/ PR#27711- "Fix image extension PathUri conversion"- This fixed a compile/path conversion issue after
#27498, but kept the sandbox-backed read behavior. e79d72d75d479c1aceaf6a5853833e7ddad33c29/ PR#29429- "remove flag for image preparation"- This made
view_imageemit deferredapplication/octet-streamdata and rely on centralized response-item image preparation. It is included inrust-v0.142.0and later.
Current relevant code areas:
codex-rs/ext/image-generation/imagegen_description.md- says to use
referenced_image_pathsfor local image files andview_imagebefore editing. codex-rs/ext/image-generation/src/tool.rsreferenced_image_pathsis optional.- if omitted,
request_for_call_argsbuilds a freshImageGenerationRequest, not an edit request. - if provided,
image_urlreads through the selectedToolEnvironmentfilesystem and sandbox context. codex-rs/core/src/tools/handlers/view_image.rsview_imagealso reads viaPathUriandfile_system_sandbox_context.
This creates a bad failure mode for the natural-language workflow:
- The user asks to create a new image "based on reference.png".
- The agent tries
view_image. - If
view_imagefails due to sandbox/Windows DPAPI issues, the reference is never attached to conversation history. - The agent still calls
image_genwith no effective image input, and the generated result is text-only.
Why this looks like a regression
The same prompt pattern worked in 0.139.0, where the reference image was actually inspected and the generated result followed the reference. In 0.142.2, the transcript shows the reference image was not successfully attached/loaded before generation, and the final image_gen call behaved like a pure text-to-image generation.
Suggested fixes or checks
- Ensure local reference images can still be attached to
image_genreliably on Windows when the file is inside the allowed workspace. - If
view_imageorreferenced_image_pathscannot attach/read a required reference image, fail the turn or ask for permission instead of silently producing a text-only generation. - Add regression coverage for the full workflow:
- user prompt references a local image by path
- assistant inspects or attaches that image
image_genreceives an actual image input, not just a filename in prompt text- generated/edit request goes through
/v1/images/editswhen a reference image is required - Add a Windows sandbox test for local workspace PNG reference reads, including the DPAPI failure mode if possible.
Versions observed
- Working:
0.139.0 - Broad image_gen failure:
0.140.0 - Reference-image behavior still broken:
0.142.0,0.142.2
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗