Clipboard manager cannot paste images into terminal apps: Shift+Insert is consumed as a text-only paste

[cxj05h]

What happened

Selecting an image entry in the Omarchy clipboard manager and pressing Enter puts the image on the clipboard correctly, but nothing is pasted when the focused window is a terminal. The same action works in GUI/webapp windows.

What I expected

The selected image to be pasted into the focused application, the same way text entries are.

Root cause

bin/omarchy-clipboard-paste-file always finishes with a Shift+Insert keystroke:

wl-copy --type "$mime" < "$path"

if [[ $copy_only == "true" ]]; then
  exit
fi

sleep 0.15
wtype -M shift -k Insert -m shift 2>/dev/null || true

The wl-copy half is correct — the image really is on the clipboard, and wl-paste --list-types reports image/png with byte-identical content.

The problem is the keystroke. Terminal emulators bind Shift+Insert to their own text-only paste and consume it before the running application ever sees it. foot's default, for example:

clipboard-paste=Shift+Insert Control+Shift+v XF86Paste

So the sequence is: image goes on the clipboard with only an image/png flavor, Shift+Insert is delivered, foot intercepts it, foot looks for a text flavor to write to the tty, finds none, and nothing happens. No error, no feedback.

By contrast, Ctrl+V is not in foot's binding list, so it passes through to the running program. Terminal applications that support image paste (Claude Code, for instance) read the clipboard themselves on Ctrl+V and pick the image up fine. That is why pressing Ctrl+V manually works while the clipboard manager's own paste does not.

This also explains why GUI apps are unaffected: there Shift+Insert reaches the toolkit's paste handler, which honours non-text clipboard flavours.

bin/omarchy-clipboard-paste-text uses the same Shift+Insert keystroke, which is correct for text (and deliberately terminal-safe, since Ctrl+V is not paste in a terminal). The image path appears to have inherited it without adjustment.

Steps to reproduce

1. Copy any image (e.g. omarchy capture screenshot).
2. Focus a terminal running an application that accepts pasted images (Claude Code is an easy target).
3. Open the clipboard manager (Super+Ctrl+V), select the image entry, press Enter.
4. Nothing is pasted. The overlay closes and the terminal is unchanged.
5. Press Ctrl+V manually instead — the image pastes, confirming it was on the clipboard the whole time.

Workaround

Use Shift+Enter in the clipboard manager (the --copy-only path), then press the application's own paste binding manually.

Suggested fix

For image entries, send Ctrl+V rather than Shift+Insert, or skip the synthetic keystroke entirely when the focused window is a terminal and let the user paste. An image can never be pasted into a terminal's text-paste path, so Shift+Insert has no valid case here.

Environment

• Omarchy 4.0.2-1
• Hyprland 0.56.2
• foot 1.27.0-2, wtype 0.4-2, wl-clipboard 1:2.3.0-1
• Reproduced with the stock omarchy.clipboard plugin, no local modifications

Still present on master as of filing — bin/omarchy-clipboard-paste-file is byte-identical to the installed copy.

[cxj05h]

Confirmed the proposed fix empirically on the affected machine.

Ctrl+V is the correct keystroke to send. Claude Code's documented Linux binding for clipboard image paste is Ctrl+V, and pressing it manually after selecting an image in the clipboard manager pastes the image successfully, producing an [Image #N] chip. So the image is on the clipboard and the receiving application is willing to take it — only the synthetic keystroke is wrong.

Worth noting the failure is a partial one, which makes it easy to misread. Pressing Enter on an image entry does two things:

1. wl-copy puts the selected image on the clipboard. This half works correctly, including for entries far down the history. Verified by hash: selecting the 4th entry in the history left exactly that image on the clipboard, not the most recent one.
2. wtype -M shift -k Insert -m shift is then sent, and the terminal swallows it.

So the practical symptom is that Enter appears to do nothing, when in fact it has already staged the right image and only the paste is missing. The user-visible workaround is to press Enter and then Ctrl+V manually.

This also confirms the earlier note that Shift+Enter (the --copy-only path) is not needed as a workaround: plain Enter already stages the clipboard identically, since the wl-copy runs before the keystroke.

Environment as originally reported, with the terminal chain being foot 1.27.0 -> herdr -> Claude Code. Neither foot nor herdr binds Ctrl+V, so it reaches the application; foot does bind Shift+Insert as a text-only paste, which is what consumes it.