Allow image attachments when answering request_user_input questions

Open 💬 0 comments Opened Aug 8, 2026 by ajaecheolgeo

What variant of Codex are you using?

Codex desktop app on macOS.

What feature would you like to see?

Allow image attachments (including a local image path) when answering a structured request_user_input question.

The regular Codex composer supports image inputs, and Codex CLI can accept a local image path. However, when Codex displays the structured multiple-choice question UI, the custom/free-form answer field only accepts text. There is no attachment button, image paste/drop target, or way to submit a localImage with the answer.

This matters when the information needed to choose an option is visual—for example, selecting a UI implementation based on a screenshot, comparing layout options, or clarifying which element in a design should change.

Steps to reproduce

  1. Open a chat in the Codex desktop app.
  2. Have Codex call request_user_input with multiple options and an “Other”/custom-answer path.
  3. Open the custom-answer field.
  4. Try to paste, drag, or attach an image while the question is pending.

Actual behavior

Only a text answer can be submitted. To provide an image, the user must first resolve or skip the structured question, return to the regular composer, attach the image, and ask Codex to present the question again.

Entering an absolute file path in the custom-answer field is only text; it is not represented as an image attachment and depends on whether the agent can access that path.

Expected behavior

Ideally, the custom-answer field should accept the same image inputs as a normal user turn:

  • paste an image from the clipboard
  • drag/drop an image
  • select an image file
  • attach a local image path

If structured answers must remain text-only, an alternative would be a “Respond in composer” action that dismisses the question UI, preserves the pending question, and opens the regular composer with image attachments enabled.

Additional context

The current public protocol models normal user-turn content as text, image, or localImage, while RequestUserInputAnswer is a Vec<String>:

This suggests the limitation exists at the structured-answer protocol boundary, not only as a missing attachment button in the desktop UI.

View original on GitHub ↗