Clipboard history not working on Omarchy 4

Omarchy 4 replaced Walker’s clipboard provider with a Quickshell plugin. Super + Ctrl + V opens it, Super + V is universal paste. When people say “clipboard history is broken” on 4.x they usually mean one of three different faults, and they have different fixes. Checked against v4.0.0 through v4.0.4, with v3.8.4 as the last 3.x reference.

The fix

1. History stopped recording text (most common on 4.x)

Symptoms: the picker opens fine and keeps every old entry, new images still land in it, but text you copy stops showing up. Look for a wedged capture process:

pgrep -af 'clipboard/capture.sh'

On a healthy system this prints nothing. capture.sh runs for a fraction of a second per copy. Anything listed has been stuck long enough to block the watcher. Confirm the age:

ps -eo pid,etimes,args | grep '[c]lipboard/capture.sh'

Kill it:

pkill -f 'clipboard/capture.sh'

Text capture picks up again with the next copy. No shell restart or logout is involved. This is issue #9443, still open on v4.0.4, with a fix proposed in PR #9488 that has not merged.

2. The picker does not open at all

Check that both watchers are alive:

pgrep -af 'wl-paste .*--watch'

You should see exactly two, one --type text and one --type image/png. If either is missing, or if Super + Ctrl + V does nothing, restart the shell:

omarchy restart shell

You can also call the picker directly to separate a broken keybinding from a broken plugin:

omarchy-shell shell toggle omarchy.clipboard
omarchy-shell shell listPlugins

If the shell crashes the moment the picker opens, and you are on v4.0.0 or v4.0.1, update. The clipboard preview rendered entries as rich text, so a copied web page could crash Quickshell with a SIGSEGV (issues #8676 and #9302). v4.0.2 set textFormat: Text.PlainText on those elements, shipped as “Prevent remote image injection in shell text elements”. That change is present in the v4.0.2, v4.0.3 and v4.0.4 sources.

3. Super + V, C or X does nothing, or flashes a Lua error

If you see send_key_state: key not found, the history is fine. The universal copy and paste binds are failing. This bites hardest on non-Latin layouts, because Hyprland resolves the key name against the active xkb group only, and a Cyrillic, Thai or Arabic group has no c or v keysym to find. Put a raw keycode version in ~/.config/hypr/bindings.lua:

hl.unbind("SUPER + C")
hl.unbind("SUPER + V")
hl.unbind("SUPER + X")

local function send_once(mods, key)
  return function()
    hl.dispatch(hl.dsp.send_key_state({ mods = mods, key = key, state = "down" }))
    hl.timer(function()
      hl.dispatch(hl.dsp.send_key_state({ mods = mods, key = key, state = "up" }))
    end, { timeout = 50, type = "oneshot" })
  end
end

local function in_terminal()
  local window = hl.get_active_window()
  if not window then return false end
  for _, tag in ipairs(window.tags or {}) do
    if tag:gsub("%*$", "") == "terminal" then return true end
  end
  return false
end

local function universal(mods, key, term_mods, term_key)
  return function()
    if in_terminal() then send_once(term_mods, term_key)() else send_once(mods, key)() end
  end
end

o.bind("SUPER + C", "Universal copy", universal("CTRL", "code:54", "CTRL", "Insert"))
o.bind("SUPER + V", "Universal paste", universal("CTRL", "code:55", "SHIFT", "Insert"))
o.bind("SUPER + X", "Universal cut", send_once("CTRL", "code:53"))

code:54, code:55 and code:53 are the physical C, V and X keys in Hyprland’s xkb numbering, so the lookup skips xkb entirely. Issues #7371 and #8960 quote the evdev numbers 46, 47 and 45 instead; Hyprland wants the xkb form, which is what the shipped tiling.lua uses for code:20 and code:21. Credit to assada on issue #7027 for the diagnosis and the keycode form, and #11201 confirms it on a us,ru setup. The terminal branch is kept from the shipped default/hypr/bindings/clipboard.lua so terminals keep getting Ctrl + Insert and Shift + Insert.

If you get the same error on a plain Latin layout, the keycodes will not help. That case is the race #7027 was opened for: the bind fires while Super is still held and the injected chord fails or misfires. Three PRs (#7285, #7375, #10247) move the shipped binds to keycodes, none merged as of v4.0.4, and nothing in tree addresses the race.

4. On 3.x

3.8.4 and earlier had no Quickshell plugin. History came from Walker and its elephant backend, bound to Super + Ctrl + V since v3.1.0. When it stopped adding entries the fix was to restart the services:

omarchy-restart-walker

Restarting Walker is what resolved issue #2832. The longer thread on the same symptom, issue #2875, was handled on the elephant side: the original reporter was fixed by elephant 2.7.7, a later reporter was still losing text on 2.7.8, and the Walker maintainer asked that person to uninstall wl-clip-persist because elephant already re-copies for persistence. 3.8.4 does not ship wl-clip-persist, so on a stock install there is nothing to remove.

Verify it worked

Copy two different strings from two different apps, then:

jq 'length' ~/.local/state/omarchy/clipboard-history.json
stat -c %y ~/.local/state/omarchy/clipboard-history.json

The count should grow and the timestamp should be seconds old. Open Super + Ctrl + V and both entries should be at the top. Copy an image too, since text and image capture are independent and one can work while the other is dead.

Why it happens

The plugin does not poll. On startup it reaps leftover watchers, then spawns two wl-paste --watch processes that call shell/plugins/clipboard/capture.sh, one for text and one for image/png. Each watcher runs its capture command to completion before it will look at the next clipboard change, so a capture that hangs takes that whole flavour of history down with it, and nothing logs the fact.

In the shipped capture.sh, the image branch is guarded with timeout 2s, but the wl-paste --list-types call at the top and the final text read are not. If the app that owns the clipboard goes away while wl-paste is still negotiating with it, the read never returns, so one unlucky copy is enough to wedge text capture. That asymmetry is why images keep working while text quietly dies. The same stalled-owner behaviour also shows up as a one to two second freeze when a focused panel reads the clipboard (issue #8753).

The shell does restart a watcher that exits, on a one second timer. It has no way to notice a watcher that is alive but blocked, which is exactly this case.

For the paste keys, the cause is different. send_key_state resolves a key name against the currently active xkb group and caches the result per keyboard and key name, without the group in the cache key. So the same binding can work all day and then fail after a config reload or an input hotplug. A related report, issue #10701, describes the injected key retriggering its own bind because Super is still physically held, spinning up thousands of forks a second.

If that did not work

• Selecting an image in the picker copies it but does not paste. In terminals this is reliable: omarchy-clipboard-paste-file finishes with Shift + Insert, which terminals intercept as a text-only paste, so press Ctrl + V yourself after picking the entry (issue #10526). Issue #7058 reports the same miss in a Chromium field and blames the 0.15 second wait before the keystroke, so the image is on the clipboard either way and a manual paste works.
• Selecting any entry auto-pastes into whatever is focused. That is current behaviour, not a fault, and issue #7613 argues it should be copy only.
• Copies from a password manager never appear. capture.sh deliberately drops anything flagged CLIPBOARD_STATE=sensitive or carrying the x-kde-passwordManagerHint type. Sensitive-content exclusion shipped with the plugin in v4.0.0.
• Old entries vanish on their own. The picker keeps 300 entries.
• As a last resort, reset the store. This loses your history: mv ~/.local/state/omarchy/clipboard-history.json{,.bak} then omarchy restart shell.
• Non-Latin layouts break more than clipboard keys. See keyboard layouts and locale.

Nothing here needs a reinstall, and none of the open issues above have shipped a fix as of v4.0.4. The capture.sh and clipboard.lua on the main branch still match v4.0.4 on the lines that matter.

Related

• Quickshell crashes or the bar is missing
• Custom keybindings lost after Quattro
• Walker launcher missing after update
• Upgrading 3.x to 4 Quattro
• Keybindings reference
• Still broken on the current release
• Manual chapter: Unified Clipboard & History