Image paste/drag-drop issues on macOS: inconsistent behavior with Cmd+V and Ctrl+V, multiple file paste/drag-drop, unclear UX, etc
What version of Codex is running?
codex-cli 0.31.0
Which model were you using?
N/A
What platform is your computer?
macOS (Darwin 23.6.0 x86_64 i386) - using iTerm2 terminal
What steps can reproduce the bug?
- Take a screenshot to clipboard using Cmd+Ctrl+Shift+4 and select a region.
- In Codex TUI, try to paste with Cmd+V — nothing happens; try Ctrl+V — image is attached.
- In Chrome, right click an image and select 'copy image'. In Codex, try Cmd+V — nothing happens; try Ctrl+V — image is attached.
- In Finder, copy a single image file and paste with Cmd+V — image is attached as expected. This also works fine with Ctrl+V.
- In Finder, copy multiple image files and paste with Cmd+V — file paths are pasted as text. Paste with Ctrl+V — only the first image is attached.
- In Finder, drag a single image file and drop it onto the Codex session - image is attached as expected.
- In Finder, drag multiple image files and drop them onto the Codex session — file paths are added as text
- Copy some normal text and paste with Cmd+V — text is pasted; Ctrl+V — nothing happens.
- Review PR #3211 for recent changes/fixes to paste behavior.
What is the expected behavior?
Both shortcuts work for all image paste scenarios, or clear documentation/UI guidance is provided about their limitations.
Ideally, both Cmd+V and Ctrl+V should consistently support all image paste cases described in the docs (screenshots, image copies from browsers, Finder files—single and multiple). If there are technical limitations (e.g., terminal key handling or clipboard format issues), these should be explicitly documented and clarified in the UI and docs.
When multiple images are copied, all should be attached, or a clear message should explain limits. Paste from Chrome/right-click should work if possible. Users should not have to guess which paste shortcut to use for which clipboard content.
What do you see instead?
Image paste behavior is inconsistent and confusing on macOS:
- Taking a screenshot to clipboard (Cmd+Ctrl+Shift+4) and pasting with Cmd+V does not attach the image; Ctrl+V works.
- Copying an image via right-click in Chrome and pasting with Cmd+V does not work; Ctrl+V sometimes works.
- Copying a single image file in Finder and pasting with Cmd+V does work and attaches the image.
- Copying multiple image files in Finder and pasting with Cmd+V pastes the file paths as text; Ctrl+V pastes only the first image (should attach all, up to a reasonable limit).
- Copying normal text and pasting with Cmd+V works; Ctrl+V does nothing (unexpected if Ctrl+V is the canonical paste for images).
- etc (refer to reproduction steps above for canonical list)
This leads to a confusing experience. As a (well informed and technical) user, I assumed image paste was simply broken / non-existent until I saw a fix (PR #3211) and tried Ctrl+V specifically.
Additional information
- The current docs (https://github.com/openai/codex/blob/main/docs/getting-started.md#image-input) imply both Cmd+V and Ctrl+V work for image paste, but this is only true for some clipboard sources.
- The recent PR #3211 fixed some paste/image issues, but there are still confusing edge cases.
- If terminal limitations prevent Cmd+V from being detected, this should be made clear to users (in the docs and maybe in-app help).
- The UX for pasting multiple images should be improved (either support or error/warning if not supported).
- Discovery is an issue: users may not realize Ctrl+V can paste images if Cmd+V doesn't work as expected.
6 Comments
While the cases outlined above are my main limitations; as a stretch goal (that might be useful in some cases, and annoying in others, so it would need to be thought through); if I have selected some text that also includes images, and paste that into
codex, it might be nice if those images were included alongside the text; currently it seems to do nothing in that case (with either of Cmd+V or Ctrl+v)I don't pretend to understand this area deeply, but I know I can inspect the types of content with something like this:
And off the top of my head I can imagine that HTML and RTF content could probably contain some form of embedded images.
In the HTML it would probably mostly just be an
<imgtag or similar; and if it linked to an external resource that might raise privacy concerns (or just not work in a network restricted environment), but if the image data was included inline (eg.<img src="data:image/svg+xml;base64,ABC...) then maybe that could be parsed/extracted into a 'real image' fairly easily.I can imagine cases where you don't want those images though (eg. copied text from a website that includes inline images for UI elements/etc); so if this were implemented, maybe it shouldn't be the default behaviour, and only triggered explicitly somehow/etc.
These issues shouldn't have existed in the first place. Although they are minor, they've caused significant confusion. I once thought Codex couldn't paste images at all, until I discovered that the shortcut for pasting images is actually Ctrl+V, different from pasting text — which is just plain stupid
Also, thanks for doing such a detailed test—OpenAI should give you a bonus.
This bug hasn't received any posts or upvotes in more than three months. Closing.
@etraut-openai this seems like a bizarre way to triage issues - paste is broken on a major OS with a clear issue description and repro but it's closed because people didn't like the issue enough?
FWIW, there are other posts about this:
https://github.com/openai/codex/issues/10523
https://github.com/openai/codex/issues/6080
I would advocate for this issue to be reopened.
It would be super important and useful to have an easy way to cmd+v (especially directly from the clipboard) an image or selection of an image.
CC @etraut-openai
I hit this same macOS Cmd+V image paste issue and prepared a small patch here:
The change treats
SUPER+Vas an image paste shortcut alongside the existing Ctrl+V / Ctrl+Alt+V path, which covers macOS terminals that forward Command asKeyModifiers::SUPERwhen enhanced keyboard reporting is active. It also adds a focused test for the shortcut matcher.I could not open a PR directly because GitHub shows: "An owner of this repository has limited the ability to open a pull request to users that are collaborators on this repository."
Validation I could run locally:
git diff --checkNot run locally:
cargo test -p codex-tui paste_image_shortcutbecause this environment does not have cargo/rustc installed.