`image_gen` regression: local reference images are ignored for image-to-image generation after 0.139.0

Open 💬 1 comment Opened Jun 25, 2026 by aprendendo-codex

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.rs from direct std::fs::read(path) for referenced_image_paths to environment-backed reads through environment.file_system.read_file(..., Some(&environment.file_system_sandbox_context)).
  • This commit is included in rust-v0.140.0 and later, not in rust-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_image emit deferred application/octet-stream data and rely on centralized response-item image preparation. It is included in rust-v0.142.0 and later.

Current relevant code areas:

  • codex-rs/ext/image-generation/imagegen_description.md
  • says to use referenced_image_paths for local image files and view_image before editing.
  • codex-rs/ext/image-generation/src/tool.rs
  • referenced_image_paths is optional.
  • if omitted, request_for_call_args builds a fresh ImageGenerationRequest, not an edit request.
  • if provided, image_url reads through the selected ToolEnvironment filesystem and sandbox context.
  • codex-rs/core/src/tools/handlers/view_image.rs
  • view_image also reads via PathUri and file_system_sandbox_context.

This creates a bad failure mode for the natural-language workflow:

  1. The user asks to create a new image "based on reference.png".
  2. The agent tries view_image.
  3. If view_image fails due to sandbox/Windows DPAPI issues, the reference is never attached to conversation history.
  4. The agent still calls image_gen with 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_gen reliably on Windows when the file is inside the allowed workspace.
  • If view_image or referenced_image_paths cannot 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_gen receives an actual image input, not just a filename in prompt text
  • generated/edit request goes through /v1/images/edits when 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

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗